Minutes of IPP Working Group Meeting July 7-8, 1999 1. Meeting Attendees Stefan Andersson Axis Communication Nobuhiko Shinoda Canon Lee Farrell Canon Information Systems Greg LeClair Epson Mike Moldovan Genoa Sandra Matts Hewlett Packard Ron Bergman Hitachi-Koki Henrik Holst i-data Henrik Norby i-data Sune Pedersen i-data Chris Pott i-data Don Wright Lexmark Bill Wagner NetSilicon/DPI Stephane Berche Oce Ben Chun Samsung Michael Reffke SEH Matthias Wolff SEH Bob Herriot Xerox Carl-Uno Manros (Chair) Xerox 2. Day 1 Carl Uno-Manros opened the IPP meeting and provided the suggested agenda topics: * IPP Test Specification * Proposed new optional Administration Operations * IPP Notifications * Proposed minor extensions to IPP/1.0 and 1.1 * IPP/1.1 Implementer's Guide Carl-Uno noted that the IPP/1.1 documents that have been submitted to the IETF contain a reference to the TLS security documents. As a result, the progress of the IPP documents will be dependent upon the advancement of the TLS documents. 2.1 IPP Test Specification Mike Moldovan indicated that Genoa has not made as much progress on the Test Suite update as he had hoped. However, most of the tests have been re-written to eliminate much of the redundancy. As a result, the overall document size has been reduced-to approximately 900 pages. Bob Herriot asked if there is a shorter version that highlights the significant items-similar to an "executive summary." Mike said that this is a good idea, and he will consider developing this. Carl-Uno stressed that the PWG members should obtain a copy of the Test Suite and review its contents, providing feedback to Genoa and/or the IPP WG. There is a free beta version of the Test Suite that is available from Genoa. There was some discussion about the PWG endorsing the Test Suite as a "PWG recommended" document. Lee Farrell raised the concern that unless there is significant review (and support) by the individual member companies, no official endorsement should be considered. Don Wright suggested that the PWG members should first gain some experience with actually running the tests before endorsing the document. This led to a discussion about whether the PWG should really endorse any test suite. There is concern that if the PWG endorses a particular test suite, then it might be considered by the industry as the definitive measure of IPP conformance-rather than the specification itself. As an alternative to "official PWG endorsement," it was suggested that the PWG website could simply reference the Test Suite as an informational White Paper, accompanied with appropriate disclaimers. It was also suggested that the PWG website could include "informational tips" regarding experiences gained by PWG members during the use of the Test Suite. Mike announced that he will be leaving Genoa after August 1. However, he will still be working closely with Genoa and plans to make sure that the IPP Test Suite will be completed. At this point, he is not sure whether the Test Suite will be completed by Genoa or his new company. 2.2 Proposed New Optional Administration Operations Carl-Uno distributed a file copy of the latest update of proposed Administration Operations. (This document is available at: ftp://ftp.pwg.org/pub/pwg/ipp/proposed-registrations/operations/ipp-ops-admin-990630.doc.) There was a brief discussion reviewing the general arguments for and against incorporating the proposed operations. (There have been several opinions and comments expressed on the e-mail reflector.) At least one person asked why we want to do "management" functions using anything other than SNMP. Other people suggest that the operations proposed would be difficult (impossible?) to implement using SNMP. Another suggestion expressed was that we should make it clear that the operations apply to the IPP Service rather than the printer device (even though an IPP Server could be implemented by an individual device.) The operations being proposed include 7 Printer Object operations and 8 Job Object operations: * Set Printer Attributes * Enable Printer * Disable Printer * Reset Printer * Restart Printer * Space Printer * Shutdown Printer * Set Job Attributes * Reprocess Job * Cancel Current Job * Pause Job * Pause Current Job * Resume Job * Promote Job * Space Current Job Bob Herriot led a review of the proposal contents, describing the individual operations and the associated attributes. ISSUE: If a "printer message from operator" is blank, should it wipe out the previous message? ISSUE: Do we need an alternative to the date-time format (i.e. both ticks and dateTime)? In Section 6.1.1, it was suggested that the table entries under "Settable?" that contain the phrase "MUST NOT if attribute supported" should be changed to "MUST NOT". During further review of the table, a few people indicated that the terms MAY and SHOULD are not always clear-perhaps it is not necessary to make the distinction. Carl-Uno suggested that perhaps the Table is attempting to address too fine a granularity of detail-different implementations are unlikely to agree on whether certain IPP Printer Attributes are modifiable or not. [After spending much time discussing the table in Section 6.1.1 of the proposal, Carl-Uno suggested that the group was getting "bogged down" in too much detail. He was concerned that we were spending more time on the document review than he had hoped. It was agreed that further discussion be limited to one hour.] Under the topic of setting Printer Attributes, it was suggested that "ipp-attribute-fidelity" is an unnecessary complication. It was agreed that this could be eliminated, and the expected behavior of the operation would be to either succeed for all attributes specified, or the operation would fail. There will be no "partial success" allowed. There was some debate about whether the Disable Printer operation should also disable the printer from access by other protocols. It was generally agreed that this would be implementation-specific. A similar question applies to the Shut Down operation as well. For both operations, the issue of whether it is appropriate for IPP or whether it should only be done via SNMP continues to be unresolved. There is still disagreement about exactly what "Shutting Down" should mean. (Is it the same as "turning off power"? Should it result in the loss of current job state?) At the very least, a clear distinction between Shut Down, Disable, and Pause-and the respective impact on other printer behavior-needs to be specified before agreement can be reached. Several of the Issues in the proposal were referenced, but most of them were not resolved. There was some concern that IBM was not present for comment-and the topics were deferred. When discussing the "synchronize" attribute, it was noted that it is an OPTIONAL attribute for an OPTIONAL operation that is OPTIONALLY supported by the client and the Printer. The question was raised as to whether this is a reasonable feature for consideration as part of the IPP specification. Issue 12 - It was generally agreed that "processing-stopped" should be the job state after a Pause Job or Pause Current Job operation is completed. Why is Pause Current Job necessary? Why wouldn't Pause Job be sufficient? There was general concern regarding the support of job checkpointing-and the related complications. No one at the meeting could adequately explain why Promote Job would be necessary. Also, given that it only allows promotion to the first position in the job queue, there is concern that it is too limited to be desirable. While reviewing the Space Current Job operation, a few individuals noted that many of the proposed operations are relevant to a very narrow market. It was suggested that perhaps IBM should implement these operations as private extensions to IPP-instead of PWG extensions. 2.3 IPP Notifications - Requirements The latest draft of the notification requirements document was distributed and Carl-Uno led a detailed review of its contents. (This document is available at: ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/draft-ietf-ipp-not-02.txt.) It was generally agreed that the notification for "All Traps" should be clarified more-at least with regard to whether or not it is restricted to a particular job. Carl-Uno noted that some requests for notification have been based on job accounting requirements. However, he has concerns as to whether IPP should be burdened by this type of requirement. He acknowledges that IPP should not restrict someone from using and supporting accounting-related notifications, but he does not necessarily want to make the IPP protocol dependent on them, either. For example, IPP should not be expected to guarantee reliable delivery of accounting information. Section 2.19 refers to e-mail with store and forward as an example of "queued notification." Carl-Uno noted that he would like to see a better explanation of this term, with (at least) a different example. The topic of Human Readable vs. Machine Readable notification formats still needs further discussion. Do we really need both? If so, do we need to have Mixed format notifications? Carl-Uno suggested that the requirement for notifying a submitting client when the delivery of an event notification to a specified Notification Recipient fails should be eliminated. Henrik Holst would like to keep the feature, but would consider making it optional. The group agreed that the requirement for providing a mechanism to indicate the quality of service for delivery of event reports should be removed. The group discussed whether or not usage scenario #7 should be included in the document. By suggesting that IPP notifications could be used for auditing (or accounting?), the document might create a misleading impression. Carl-Uno then referenced a June 30 e-mail from Tom Hastings ("RE: IPP> comments on 'requirements for IPP notifications'") Although the group spent time reviewing the contents, no notable conclusions or decisions were made. Several of the items were deferred for further discussion with Tom. 3. Day 2 3.1 IPP Notifications Carl Uno led a review of the latest IPP Event Notification document. (This document is available at: ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-990518.pdf.) A general suggestion was made to review the usage of the word "device" throughout the document. A determination should be made if the term "IPP Printer Object" would be more appropriate. Carl-Uno suggested that more details of a notification model description should be included in the early part of the document before "jumping into the details"-perhaps as an introductory section. It was noted that the "summary" identified in Section 1 really doesn't offer much of an overview summary. Bob Herriot agreed that some of the text in Section 3 should be moved into Section 1. For the attributes that are labeled "OPTIONAL", the document should specify whether it is OPTIONAL for the Client or the Server (or both.) It was suggested that Section 3 should include a model of all the different scenarios of notification. Then, as each explanation is provided, it could refer to the specific model being discussed. In Figure 1, it was agreed that the term "Create Request" should change to "Job Creation Request" Is the term "Event Report" really the same thing as a "Notification"? If so, let's use the term "Notification"-rather than introducing a new term. If they are intended to be different things, the document should clarify the distinction. Section 4 - There were several questions about the behavior regarding a Job Submission subscription after a Restart Job. Carl-Uno felt that more clarification was necessary to explicitly address whether or not (and how) a subscription becomes valid again-after being "not valid". ISSUE 1 - Can event reporting be dropped if the device is too busy? A: There might not be a choice. Can a subscriber specify that events are allowed to be dropped if the device is too busy or should that be a policy of the Printer established by the Administrator or implementation? A: This should not be part of the protocol. Should we add the event device-dropping-events? A: No. It was agreed that controlling notification policy should not be part of the protocol. It could, however, be provided by a specific implementation. Section 4.1.1 - There was some doubt about whether a given notification delivery method should imply a fixed set of events. It was agreed that this point should be reconsidered (eliminated?) for the next document draft. ISSUE 2 - Should we make the 'http' notification method (using POST) REQUIRED, instead of 'ipp-tcp-notify' and 'ipp-udp-notify'? Then we don't need to register anything for the two REQUIRED methods. A: No, but keep in the list of OPTIONAL schemes. There was much discussion about which scheme(s) should be REQUIRED. Several people expressed concern about having too many different notification schemes-especially if they are (functionally) redundant. There was general agreement that udp and mailto should both be supported. Carl-Uno suggested that the question of reliability should be of concern. Is it really critical if a notification is lost? The group did not reach a final conclusion on this issue. ISSUE 3 - Is SNMP support even necessary? A: No. The group decided to remove SNMP from the document. ISSUE 4 - Need reference to NDPS documentation. Also need more description here, such as which end opens, does the recipient acknowledge, and any salient information about the transport. A: Until Novell provides an IETF reference document, "ndps-notify" should be removed from the Notification document. The group also agreed to remove "sense-notify" from the document. ISSUE 5 - Can we get rid of most of these notification methods? Having a large number means that we don't have much interoperability. A: Yes. The list of methods should be-and now has been-reduced. ISSUE 6 - Which URL parameters should we mention (which like SLP) are removed before being used? A: ??? [no conclusion reached?] ISSUE 7 - Should each subscription have a running event counter that increments by 1 so that a notification recipient can detect events that arrive out of order? A: The group agreed that this seems like a good idea. Should we put that counter into the 16-bit "request-id" field in the report? A: Yes. Section 6.3 - For job trigger events, what should happen when both the job state and the job state reasons change? Should this generate two events, or just one? The document should clarify this issue more explicitly. After some discussion, it was suggested that job state change and job state reason change should only be available as "paired" information. The topic was then deferred. ISSUE 8 - Should there be more job attributes in the "job-completed" event report, such as "impressions-completed" and "sheets-completed"? A: More attributes would be useful, but the group needs to agree on the list of items that should be included. ISSUE 9 - any other events that are REQUIRED? A: No. Section 6.8 - The group wondered whether "previous-job-state-reasons" is a useful attribute. No one present was able to justify why this attribute should be REQUIRED. Section 7.1 - It was suggested that "ready-for-just-in-time-job" was a bit too "over the edge" for inclusion in the specification and was removed. "device config changed" and "ready for job" were also removed. ISSUE 10 - Ok if "device-trigger-message" stays as a single value while "device-trigger-event" is multi-valued? When there are multiple codes, the message contains the concatenation of the messages or is a combined message, depending on implementation. A: This issue is no longer relevant. Section 11.3 - Carl-Uno suggested that we might not need to use multipart/report anymore. Bob Herriot will discuss this concept further with Larry Masinter. Henrik Holst asked how to "unsubscribe" from notification events on a job. Currently there is no method designed to do this. The subscription will (automatically) end whenever the job is completed. 3.2 IPP Notification - Job Independent Events Carl Uno led a review of the latest IPP Job Independent Events document. (This document is available at: ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-printer-990519.pdf.) Bob Herriot suggested that the Event Notification and the Job Independent Events document should be merged into a single document. There seemed to be general agreement to this idea. As with the other document, the use of the term "device" vs. "IPP Printer Object" should be reconsidered. The diagram in Figure 1 will need to change when the documents are merged. Should the Notification service send an explicit notification when a subscription lease expires? For a variety of reasons (unreliable delivery, "that's the way both DHCP and Jini do it", etc.), the group decided that this should not be done. Section 4.1, second sentence - This sentence needs to be clearer on which object is referred to by "it's" [sic]. There was a debate about whether access to the subscription list (and the associated attribute data) is useful or not. Other than for debugging purposes, the group could not agree on a clear justification for supporting this. The topic was deferred until a more concrete proposal (and sample usage scenario) is generated. ISSUE 1 - Who filters out duplicate subscriptions? Client or Printer? If it is the client, then the Subscription list needs to be made available to it. If it is the Printer, how are duplicate subscriptions defined? If a Subscribe operation is performed and the "notify-recipient" and "notify-events" match a subscription already granted (whose lease time has not expired), does the IPP Printer just update the subscription's "notify-events" and "lease-time"? How defend against malicious clients? If the Printer filters out duplicates, then can we get rid of the Renew-Subscription operation? A: The group agreed that it should not be assumed that the Printer will be able to identify duplicate subscriptions. This entire issue will be left to the particular implementation. ISSUE 2 - Ok to permit an implementation to assign a new Subscription ID on a Renew-Subscription or should we require the ID to remain the same (and not be returned in the response)? A: Do not allow the implementation to change the Subscription ID. ISSUE 3 - If the IPP Printer is forwarding Subscribe operations to a notification service which rejects the subscription, is there any way the IPP Printer can return that implementation specific error condition back to the client? Or is it better for the IPP Printer to map the error codes to standard IPP error status codes for interoperability? A: Deferred. This issue should be addressed in the Implementer's Guide. ISSUE 4 - Should we allow for an "Unsubscribe ALL" feature in some operation? A: Deferred. ("It looks dangerous.") ISSUE 5 - Should we define subscription service events? Such as: "subscription-about-to-expire", "subscription-expired", "are-you-alive" notification events? The Notification Recipient would have to know to issue the Renew-Subscription operation, (not the original client). These events would be ones that are available with the Subscribe operation, but not create operations, correct? A: No. ISSUE 6 - What happens when a printer crashes or reboots? Are the subscriptions lost or are they required to be retained of does that depend on implementation? How does rebooting affect lease times? A: Printers that support subscriptions are encouraged to maintain leases across reboots. However, for low-end devices this might not be possible. For this type of implementation, it is recommended that only "short" lease times be allowed. ISSUE 7 - Jini defines a sequence number for events so that clients can re-order the events if they are received out-of-order. IPP should support this too. A: IPP will include sequence numbers. ISSUE 8 - Section 8: Security Considerations of [ipp-mod] needs to be updated to reflect the use of these new operations related to security, especially regarding section 8.5: Operations performed by operators and system administrators. Also malicious clients renewing or unsubscribing subscriptions that do not belong to them. A: Correct. (This item still needs to be addressed.) The group agreed to have a new operation called Subscribe Job-which would be attached only to those events associated with a given job. 3.3 Proposed Minor Extensions to IPP/1.0 and 1.1 Bob Herriot reviewed Xerox's proposal to add an attribute extension for "output-bin." (This document is available at: ftp://ftp.pwg.org/pub/pwg/ipp/proposed-registrations/attributes/ipp-output-bin-attr-990521.pdf.) There were very few comments. It was suggested that a value of "front" could be added to the current list proposed. Subject to the possible removal of the value Integer, the group agreed to accept the proposal as written. 3.4 IPP/1.1 Implementer's Guide Carl-Uno reviewed the list of remaining items from "Issues-raised-at-Bake-Off2-990510.doc." (This document is available at: ftp://ftp.pwg.org/pub/pwg/ipp/Issues/issues-raised-at-bake-off2-990510.pdf.) He quickly identified those items that still need to be addressed to finalize the document. There were no comments or discussion. Carl-Uno requested help on any of the editing efforts that remain. He and Tom Hastings are busy with other activities, and need volunteers. Henrik Holst was the only one at the meeting that volunteered to help. [If anyone else is willing, please contact Carl-Uno.] 3.5 Future Steps What should our plans be for handling future enhancements to IPP/1.1? A discussion was held about the logistics involved in using an IANA registry for new Operations. For the foreseeable future, the group decided not to pursue re-chartering of the IPP WG under IETF. IPP meeting adjourned.