Minutes of IPP Working Group Meeting July 12-13, 2000 1. Meeting Attendees Paul Danbold Apple Shigeru Ueda Canon Lee Farrell Canon Information Systems Shinichi Tsuruyama Epson Atsushi Uchino Epson Ron Bergman Hitachi-Koki Harry Lewis IBM Mark Vander Wiele IBM Henrik Holst i-data Don Wright Lexmark Weihai Chen Microsoft Bill Wagner NETsilicon Dave Kellerman Northlake Software Hugo Parra Novell Paul Moore Peerless Gail Songer Peerless Satoshi Fujitani Ricoh Craig Whittle Sharp Tom Hastings Xerox Bob Herriot Xerox Carl-Uno Manros (Chair) Xerox Peter Zehler Xerox Norbert Schade Xionics 2. Day 1 Carl Uno-Manros opened the IPP meeting and provided the suggested agenda topics: - Notification Documents - IPP WG Last Call Comments - Driver Down-Load and Resource Object - IPP Bake-Off - QualDocs - Job and Printer Administration Operations - Open Source IPP Clients He said that discussions on Notifications would be limited to the first day only. Any further discussions will be held via e-mail. 2.1 IPP Event Notification Specification Bob Herriot led a review of the latest draft of the IPP Event Notification Specification document: ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-spec-000630.pdf He explained that the document has been shortened slightly and the structure has been modified. Bob said that no technical changes were added to the document -- except for the modifications that were approved at the previous meeting or a subsequent teleconference. The group reviewed the Table of Contents and the document structure. Figure 3 needs to be fixed for accuracy. The group agreed to add `printer-stopped' (required) and `job-stopped' (required or optional -- depending on the delivery method) attributes. ISSUE 01: OK that we changed the number from 5 to 2 because we have rearranged the categories of Events to have group events? Agreed. [It is recommended that implementations should do more.] ISSUE 02: OK to add `printer-full' Event? No. Also remove `printer-no-longer-full'. ISSUE 03: OK to add `printer-not-almost-idle' Event No. Also remove `printer-almost-idle'. Sections 5.3.2.1.2 and 5.3.2.1.3 -the first sentence should be removed. The group agreed to remove the `job-purged' keyword [`job-completed' can be used instead.] ISSUE 04: It would be better for this attribute to be a Subscription Description attribute that the Printer sets to show whether the Object is persistent or not. Agree? No. The group agreed that this attribute is not useful. The entire section on notify-persistence will be removed. ISSUE 05: OK that we added the REQUIRED "notify-job-id" attribute because it is needed for a Notification Recipient to determine from a random subscription-id whether a Subscription is Per-Printer or Per-Job -- and if the latter, which Job? Yes. ISSUE 06: OK to use MAX to mean no limit and 0 to mean that an admin has turned off subscriptions? The group agreed that notify-max-printer-subscriptions-supported is not useful and should be removed. ISSUE 07: OK to use MAX to mean no limit and 0 to mean that an admin has turned off subscriptions? The group agreed that notify-max-job-subscriptions-supported is not useful and should be removed. The group discussed the possibility of adding a "job-recipient" operation and Job Description attribute. It was agreed that a separate document should be written for proposing these items. ISSUE: The "notify-subscription-id" isn't used for 'snmpnotify' Method. Page 36, Table 5: REQUIRES the "notify-subscription-id" to be supported, but the 'snmpnotify' doesn't. Should we change the MUST to SHOULD? Agreed: snmpnotify to add the 32-bit integer to its Event Notification. During the discussion of this Issue, the group agreed to change the formats of the Tables in Section 9.1 and 9.2 to be more consistent. Also, it is desirable to make the distinction between "human consumable" tables and "machine consumable" tables more clear. [There was a complaint that the section header styles do not adequately reflect subordination.] The group had a very long discussion about event moderation. There was no clear consensus on a "reasonable" specification for moderating events. In the end, the group agreed on the following guidelines to be included in the specification: For machine consumable events, "every endeavor should be made" to supply every page-based events (i.e. do not moderate.) For human consumable events (e.g., mailto:), the specification should strongly recommend against page-level events. Section 9, fourth paragraph -- The description of "moderating events" should be clarified and restricted to `job-progress' events for the same Subscription object. The paragraph should be moved to the `job-progress' event. Harry Lewis suggested that support for client (and/or administrator) moderation of events should be added. A suggestion was made to allow the client to specify time-based event moderation (i.e. "send events no faster than every n seconds") and/or page-based moderation (i.e. "send an event every n pages"). The group agreed that only time-based moderation requests would be supported. Also, there will be no xxx-default and no xxx-supported. Bob Herriot will update the document and issue a new draft that reflects the above decisions. 2.2 mailto: Notification Delivery Method Bob Herriot led a review of the Mailto: Notification Delivery Method document: ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-mailto-000707.pdf The group reviewed the Table of Contents and the document structure. Section 4, item 2 -- Based on the "favorite notification delivery method poll" results, Carl-Uno declared a consensus of the group that Printer support for the mailto: method is REQUIRED. NOTE: Several of the attendees did not agree with Carl-Uno's interpretation of the e-mail poll as being a selection of a MANDATED method. Evidently, it was not clear to all people responding to the poll that an indication of a "favorite" method would be interpreted as an endorsement for a MANDATED method. It was suggested that an additional poll that explicitly addresses the topic of MANDATED notification methods should be done. Section 4, item 4 -- Change "MUST NOT" to "MAY" and delete the second sentence. Section 4, item 5 -- Change to "The Printer MUST send (push) the Event Notifications." ISSUE: RFC 2368 allows more than one mailbox. Do we want this or just 1? The group decided to change the syntax to remove the "1#" -- indicating that it allows one occurrence of `mailbox'. Section 5.2.1, second paragraph -- Clarify that the Printer MUST treat the characters following `mailto:' as an opaque string. ISSUE: This needs to change to real ASCII encoding for the IETF ASCII document. To avoid the issue with accented characters, Henrik will provide a Danish example. Bob Herriot will attempt to issue an updated draft soon. 2.3 INDP Event Notification Delivery Method Tom Hastings led a review of the INDP Event Notification Delivery Method document: ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/draft-ietf-ipp-indp-method-01- 000706.pdf The group agreed to change the title to "IPP Notification Delivery Protocol (`indp')" ISSUE 01: Is this what the Access Rights section should say for a Send- Notifications request? The text should change to indicate that the Notification Recipient MAY enforce access rights. If the Printer receives a rejection, the Printer SHOULD cancel the subscription. ISSUE 02: What version number goes here? 1.0 ISSUE 03: Ok that "requesting-user-name" SHOULD NOT be sent in Send- Notifications? The group agreed that the entire paragraph about Requesting User Name should be removed. ISSUE 04: Ok that "notify-text" has been changed from MAY to MUST? Yes. 3. Day 2 3.1 IPP WG Last Call Comments Carl-Uno gave the status for a few Internet-Drafts: - Job and Printer Set Operations -- finished Last Call - Collection attribute syntax -- under IPP WG Last Call - LDAP Schema for Printer Services -- under IPP WG Last Call - Job and Printer Administration Operations ("Set 2") - ? - Resource Objects and Get Resource Operations - ? Carl-Uno asked if anyone had any concerns about submitting the Collections document for standards track. There was no objection from the attendees -- however it was mentioned that [a minority of] individuals have raised concerns in the past via e-mail. Carl-Uno indicated that he would like to submit the following documents for Last Call as soon as possible: - Event Notification Specification - mailto: Notification Delivery Method - IPP Notification Delivery Protocol (`indp') - Requirements for IPP Notifications - Job Progress Attributes He noted that if they are not submitted by July 14, they will probably be delayed by a month or so -- because of IETF activity. The group reviewed Tom Hasting's July 5 e-mail to Carl Kugler in response to Carl's Last Call comments on the Set spec regarding an out of band value for "any" or "unknown." It was noted that if the requested modification were accepted, the Model document would also need to be changed. After some discussion, the group determined that if an out of band value of `any' were registered with IANA, the Model document would not need to change. It was acknowledged that existing implementations would not be able to take advantage of this feature. The group agreed to allow "document-format-supported" to contain only an `any' out of band value, which means that the Printer will accept any document format. The Implementer's Guide and the Set spec will be changed to reflect this decision. Tom will write up the proposed changes for review and acceptance. 3.2 Driver Down-Load Hugo Parra led a review of his Printer Installation Extension document: ftp://ftp.pwg.org/pub/pwg/ipp/new_DRV/draft-parra-install-00-000626.pdf Hugo explained that his document describes IPP extensions that would enable workstations to obtain the information needed to perform a proper printer driver installation using IPP. Much time was spent discussing the specific attribute fields and their meaning. It was suggested that the next draft of the document should include examples showing possible attribute values. It was agreed that new syntax tags will not be necessary for Hugo's proposal. 3.3 Resource Object Tom Hastings led a review of his Resource Object document: ftp://ftp.pwg.org/pub/pwg/ipp/new_RES/draft-ietf-ipp-get-resource- 00.pdf The document "extends the current closed IPP object model with a passive polymorphic object that is intended to satisfy most needs for new object types in the long-term evolution of IPP via an extensible object framework." Specifically for the near term, it is intended to support driver installation requirements. It was suggested that the document be split into two separate documents -- a "general framework" description and a "Printer Installation" profile. The group discussed the trade-off between adopting Hugo's document vs. Tom's. The Resource Object is intended to be more generic, while the Printer Installation Extension is intended to be more specific -- and simpler to implement. There is concern that the more general approach could take the group a longer time to review and accept. It was suggested that the group should focus on the approach that satisfies the high priority customer benefit. There was some question about whether a general solution is justified by other customer requirements. Fonts and media information were suggested as possible benefits that could be supported by the Resource Object. It was agreed that Hugo will update his document and the group will focus on his approach for the short-term need of driver download support. 3.4 IPP Bake-Off Carl-Uno suggested that the group should consider publicizing the IPP bake- off. Peter Zehler reported that Oak Technologies will host the Bake-off event. He said that he plans to issue a list of "things to be tested" and request feedback. One significant issue is to agree on the notification testing details. Peter provided a suggested list of test items: - IPP/1.1 - all mandatory operations - security (basic, digest, SSL3, TLS) - mailto: notification - indp notification - IPP/1.1 clients with IPP/1.0 printers and vice-versa - communication through firewalls Quality Logic will bring a test tool for exercising attribute and operation communication. Will there really be enough printer and client implementations ready to support notifications in October? [A few people admitted that the schedule is ambitious.] If there are not, should the group bother to hold a bake-off -- or should it be postponed? 3.5 Mandatory Notification Method? [revisited] It was proposed that the statement on MANDATORY notification method(s) should be modified as follows: IF an implementation supports a human consumable notification method, it must support e-mail. IF an implementation supports a machine consumable notification method, it must support indp. After more discussion that did not reach consensus, the group agreed on a compromise to eliminate any MANDATORY method: The IPP Notification documents will only say that e-mail and indp notification SHOULD be supported. 3.6 QualDocs Does the group want to discuss QualDocs as part of the PWG -- not IPP -- activity in the future? Currently, it appears that the IETF is not moving forward (at a reasonable pace) on granting a Charter to the QualDocs activity. There is some concern that the current PWG membership does not include sufficient expertise in other related areas -- such as fax. If the PWG takes on QualDocs as a project, Paul Moore said he could volunteer to be Chair. The group agreed to hold a QualDocs meeting on Friday of the next PWG session in September. An announcement will be made on the PWG e-mail list. 3.7 Job and Printer Administration Operations ("Set 2") Tom Hastings referenced the latest Job and Printer Administration Operations document: ftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/ipp-ops-set2-000706.pdf Tom reviewed various issues related to moving a print job from one Printer to another. Recently, there has been much e-mail on this topic. One of the problems identified involves authenticating the sender of a redirected job. It might be simpler to create a means of allowing a client to "take back" the job and submit it to the alternate Printer. There was no consensus reached on this topic. Until this topic is resolved, it was agreed that the Redirect-Job operation should be removed from the document. It was also agreed that a Schedule-Job-After operation should result in the job "inheriting" the same priority as the preceding job -- or the highest priority if it is moved to the front of the queue. 3.8 Open Source IPP Clients Carl-Uno was expecting a representative from VA Linux to speak about Open Source. Unfortunately, he never arrived. There will be a Linux Printing Summit held at the Sheraton hotel in Sunnyvale on July 27-28. All individuals that are interested in IPP are encouraged to attend. Several people are concerned that it is unlikely that any single PWG member company will be willing to donate a robust IPP client for Open Source use by the whole group. It was suggested that a more practical approach would be to get the members to collectively pay for an outside developer to create the desired client source code. A necessary first step is to agree on and publish a set of requirements. IPP meeting adjourned.