Minutes of IPP Working Group Meeting May 17-18, 2000 1. Meeting Attendees Shigeru Ueda Canon Lee Farrell Canon Information Systems Atsushi Uchino Epson Dave Kuntz Hewlett Packard Trevor Wells Hewlett Packard Ron Bergman Hitachi-Koki Harry Lewis IBM Mark Vander Wiele IBM Henrik Holst i-data Jerry Thrasher Lexmark Don Wright Lexmark Bill Wagner NETsilicon Hugo Parra Novell Roelof Hamberg Océ Huibert Jongen Océ Gail Songer Peerless Paul Moore Peerless Satoshi Fujitani Ricoh Craig Whittle Sharp Tom Hastings Xerox Bob Herriot Xerox Carl-Uno Manros (Chair) Xerox Peter Zehler Xerox 2. Day 1 Carl Uno-Manros opened the IPP meeting and provided the suggested agenda topics: - IPP Event Notification - Collections - Implementer’s Guide - IPP Bake-off - UPnP/IPP coordination Based on the UPnP Printing meeting that had occurred the previous day, Peter Zehler suggested that some time should be allocated to discuss some of the issues that had been raised at that meeting. A few items related to IPP. Carl-Uno stressed that he would like to conclude the discussions on Notifications, but was willing to allocate an hour for UPnP discussions at the end of the first day. 2.1 IPP Event Notification Specification Bob Herriot led a review of the latest changes to the IPP Notification Specification document: ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-not-spec-000511.pdf For Job Creation operation: - Changed job-notify collection to notify-xxx attributes * allow only one subscription per Job-Creation * remainder between Create-Job and Send-Document - (notify-max)-jobs-supported * changed name * required only if Create-Job-Subscription supported Changed Event Notification (section 7) - Reduced set to a few mandatory ones - Added optional attribute * notify-requested-attributes and –supported * contains set of additional attributes Bob listed “recommended attributes” that would be useful for the event notifications: - notify-sequence-id - notify-charset - notify-natural-language - notify-text - notify-text-format Required attributes: - printer-uri - trigger-event - printer-up-time - printer-current-time (if this attribute is supported) [Required Job and Printer attributes were also listed.] Changes to specification - Discovered that document made assumptions that contradicted the four delivery methods * rewrote to be abstract model (was previously too IPP- specific) - Rewrote section on human consumable * changed “notify-format” back to “notify-text-format” * specified RECOMMENDED information Hugo Parra suggested that the subscription id should be included (required) in the INDP delivery notification. He also proposed that it would be useful for this attribute to be required in all notifications. The group agreed. Issue - What happens when optional events are not implemented? * Does the state change become inaccessible? * Does some other event “pick this up”? printer-restarted -> printer-state-changed? printer-shutdown -> printer-state-changed? printer-media-changed -> printer-config-changed? It was suggested that the three events above should be made conditionally mandatory. But this was rejected in favor of trying to define a more generalized solution. After some discussion, the group agreed that the set of events should not be restricted to be disjoint. This way, a hierarchy of events could be defined such that a given event could be triggered from a variety of other events— including optional events. The following modifications were agreed: - Section 5.6, second paragraph – change to “A Printer MUST…” - Section 9.1.1, item 12 – change text to indicate that the printer should not return any of the attributes. - Section 9.3.1 – move the Group 2 subscription attributes into Group 1 operation attributes. - Appendix A and B will be removed. Additional work to be done by July meeting: - Add Subscription Template section * similar to Job Template section in IPP/1.1 Model * will consolidate information repeated elsewhere - Add Subscription Description section - Make all attributes start with “notify-” - Change notify-xxx operation attributes in Job Creation operations to subscription attribute group like Create-Job- Subscription and Create-Printer-Subscription * makes this operation like the other two * without this change, Job Creation is different It was decided that a subscription attribute group should exist in both request operations as well as responses. Hugo proposed to support multiple subscription objects per Job Creation. It was determined that it would probably be easier to allow it—rather than to forbid it. If a Printer doesn’t support more than one subscription object, it will return an error on the remaining objects. After further discussion, it was suggested that a “fidelity” attribute could be included to support the desire to reject a print job if a subscription cannot be supported. (I.e. “Don’t print this Job unless you can notify me.”) The group tried to consider a simpler approach: If the Printer cannot support a subscription in a Job Creation, the Job will fail with a “insufficient notification resources” (or some similar?) error message. Then it would be up to the client to resubmit the Job. But this raised the problem of how a client would know which subscription(s) or attribute(s) caused the failure. Bill Wagner reminded the group that one of the original premises of Notifications was that they are not reliable. Therefore, he suggested that all of the discussion about handling the above “corner case” situation is inappropriate and mis-focused. He suggested that if the subscription fails, the Print Job should succeed anyway. Summary agreements: - More than one subscription attribute group is allowed on both request response operations - The max number of subscriptions per Job will be the same as the maximum number of notifications supported by the Printer Bob will update the document and publish it for Working Group Last Call. He will identify the modifications for easy reference. Carl-Uno indicated that he is anxious for the document to be reviewed and approved by the group so that it can be submitted to the IESG before the July meeting. 2.2 Job Progress Attributes Tom Hastings led a review of the changes in the Job Progress Attributes document: ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-job-prog-attr- 00509.pdf The group agreed to the changes. Tom will issue the document for WG Last Call. 2.3 Notification over SNMP via Job Monitoring MIB Ron Bergman and Ira McDonald will coordinate to update and publish this document for Last Call: ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/draft-ietf-ipp-not-over- snmp-02.pdf 2.4 IPP-Get Notification Polling Method Bob Herriot led a review of the latest changes to the Notification Polling Method document: ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-poll- 000511.pdf It was pointed out that Section 3 on Model and Operation should be reviewed for consistency with recent changes in other documents. Given the frequent modifications, it was suggested that references to the other document(s) should be used instead of duplicating the text in more than one place. More than one individual noted that this “Notification” method is not really notification at all—it is polling. 2.5 UPnP/IPP Coordination Peter Zehler noted that many of the IPP representatives are attending the UPnP meeting. He asked if this should be interpreted as an indication that support for IPP is waning. He wanted to discuss the likelihood of “practical co-existence” of the two standards. Peter would like to take advantage of the IPP model and—if possible—define an automatic mapping of IPP to UPnP. Paul Moore has written a draft document that maps a subset of IPP features to the UPnP model. It attempts to maintain consistency with the IPP semantics. Harry Lewis indicated that the same concerns should be relevant to the Bluetooth and Jini efforts that are currently ongoing. The Jini members agreed that because Xerox has been driving the Jini Printing effort (and Sun has allowed them to), they have been very successful at maintaining a close consistency with IPP. The group mentioned the difficulties involved in having a standard succeed if a popular desktop OS vendor chooses not to support it. Currently, it appears that Microsoft’s support for IPP seems to be only very basic—and does not provide many of the more beneficial features. It was suggested that a “killer application” using IPP would be helpful. If the market found it useful, then customers would be unhappy with less functionality. Hopefully, this would encourage stronger support of IPP. The QualDocs effort was identified as a possible means of improving IPP deployment. To help deal with the UPnP concern, it was proposed that proposals for a stripped-down “IPP-lite” model and protocol (i.e. RFC 2565) should be created and delivered to the UPnP organization. It was noted that further e-mail discussion on this topic should occur on the “PWG-IPP” mail list—not the normal IPP mail list. [See the PWG website at www.pwg.org for details on how to subscribe.] 3. Open Source IPP Client The PWG-IPP group held a special evening session to discuss the idea of an “Open Source” IPP Client. [Michael Sweet, Ira McDonald, Dave Kellerman, and Jay Martin joined the group via telephone to participate in the discussion.] Carl-Uno presented slides on the material distributed in his May 3 e- mail. It was suggested that the group should enlist the participation of other platform vendors. Mobile phones and Palm Pilot were both mentioned as possibilities. Although many people agreed with this idea, it was considered a lower priority. The group decided to first focus on developing a successful solution on Windows and Linux before addressing other platforms. Henrik Holst reported that his company is developing Bluetooth. i- data has announced that they plan to provide printing over Bluetooth. It was suggested that a critical analysis of Microsoft’s client should be provided. What exactly is missing? Which “important features” are believed to be necessary/desirable? Will most customers/users agree? If the source code is generally available, does the PWG wish to allow anyone to modify it and incorporate it into his/her company product(s)? What licensing restrictions (if any) should be established? Other early steps that also need to be established and/or questions that need to be resolved were identified: - Who will be responsible for doing what? - What is the list of feature requirements for the client? - What will be the process for the development effort(s)? - How can the PWG help to enable the development of IPP “killer applications”? Carl-Uno made it clear that he is not the right person for leading this activity. It was suggested that if the group cannot find a leader for this effort, it should not go any further. Would it need to be a joint development effort—or could a single company just donate their own software solution? One suggestion was that each of the PWG member companies could contribute money to collectively pay for a third party group to do the effort. Another suggestion was for all the individual companies to contribute their existing code into a common “pool” and make it available for anyone who is interested in doing anything they want with it. [Then the group would “wait and see” what happens…] The group agreed that the highest priority “next step” is to identify the specific goals, objectives, and feature requirements for the project. ACTION: Each member should propose a set of “important client features”—explained by suggested scenarios—and submit them for discussion on the PWG-IPP e-mail list. Craig Whittle volunteered to lead the effort of reaching consensus on the relative priorities of the client feature set. 4. Day 2 4.1 IPP Bake-off Peter Zehler reported that Oak Technologies of Xionics will host the Bake-off in the Boston area October 17-20. Testing will include: - IPP/1.1 - Backward compatibility: IPP/1.1 clients with IPP/1.0 printers - Notifications - More extensive security testing Peter is assuming that Genoa will bring their 1.0 test suite. Approximately 25 companies have indicated interest in attending so far. Peter will coordinate pair-wise testing prior to the event. Only Bake-off participants are welcome to attend. Later in the meeting, during review of one of the notification documents, the question was raised about which notification method(s)—if any—should be mandatory. It was noted that unless a mandatory method is identified, the Bake-off interoperability testing might be difficult. 4.2 Notification via E-mail Carl-Uno led a review of the Mailto: Notification Delivery Method document: ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-mailto- 000509.pdf Section 3, 4th paragraph – It was agreed that no discussion of a receiver is necessary, and that the term “sender-SMTP” could be replaced by “SMTP.” All of Section 3 (and maybe 4?) should be shortened to avoid possible conflict with the other IPP documents. Content should be moved to the appropriate document, and references should be used more liberally. There was some discussion about whether using SMTP is required or not. Could any mail system be used instead? The group agreed that the specification should require a message format that is consistent with RFC 822. However, it is not required to use SMTP as the message transport. The document will specify that a compliant implementation SHOULD use SMTP to send the notification. Based on the previous agreement, this document needs a review of all occurrences of the term “SMTP.” In particular, Section 6.1 needs to be reworded to indicate that the attribute is optional. Also, the Table 1 headers should reference “RFC 822”—not SMTP. Section 4, “notify-user-data” – The terms “client”, “user”, and “subscriber” should be clearly defined and used consistently. Also, the attribute SHOULD be included—not MUST. The entry in Table 1 should be modified to explain what happens if the attribute is not supplied. A new Printer attribute will be added to include a default “From” mail address configurable by an administrator. This value will be used when the client does not supply a value for “notify-user-data.” The term “subscriber-user-data” should be changed to “notify-user- data.” There was a long discussion about the technique used for assigning a value to the “From:” field. There was concern that the machine- readable form (mail address) is not consistent with the display name that the human user would see. It was finally agreed that Table 1 should be changed. The value for the “From:” field should be “printer-name” <“printer-mail-address”>. The “Sender:” field should be optional. Both the “Sender:” and the “ReplyTo:” value should be <“notify-user-data”>. There was a discussion about limiting the message to “text only” for low-bandwidth implementations. It was suggested that this should be addressed explicitly—rather than using the currently defined attributes. If a specific MIME type cannot be requested, is “notify- additional-formats-supported” useful? After a very lively exchange of opinions, the group agreed to add a mandatory “notify-mailto-text only” (boolean) attribute. (This attribute is only mandatory if the Printer supports the mailto: delivery method.) If true, then only a text/plain format MUST be set. If it is set to false, then the Printer may send any format(s). If the client does not supply the attribute, then the value should be set to false. The group also agreed to remove the “notify-additional-format” attribute. The group discussed whether the “notify-text-format” attribute should apply to mailto: notifications. It was agreed to eliminate it. While reviewing “notify-charset”, it was suggested that the text should include a MIME reference. Section 5.2 – This section will be deleted. Section 6.2 – This section will also be deleted. 4.3 The INDP Event Notification Delivery Method Hugo Parra led a review of the INDP Event Notification Delivery Method document: ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/draft-ietf-indp-method- 01-000503.pdf Section 3 – Should be “compacted” and will reference the base Notification document. This document should also be updated to be consistent with the modifications in the base document. Section 4.1 – The text should reflect that only Machine-Consumable notifications will be sent. Section 4.1.2 – Various changes to the list of status code responses were suggested. Hugo captured the agreed changes and he will include them in the next draft of the document. 4.4 Collections The Collection Attribute Syntax document is ready for Last Call: ftp://ftp.pwg.org/pub/pwg/ipp/new_COL/ipp-collection-attr- syntax-000504.pdf There was no review. [However, the usual question about whether Collections are really desirable was discussed.] 4.5 General Concern About IPP Progress [At the end of the session, there was a discussion about the frustration involved with the development of IPP. It has taken a long time, and what can we show for it? How does it offer a solution that is “better” than existing methods? Carl-Uno admits that he is having trouble answering this question. Originally, the group wanted to create a print capability that would “go through firewalls.” This has not happened. He said that he was expecting Notifications to be an attractive benefit—but we still don’t have a simple notification scheme. Nor have we even been able to agree on a mandatory method. [QualDocs has been referenced as a possible “killer application” that could be used to convince the Firewall vendors to “keep the connection open” for IPP. A few people think that this could enable them to take some of the Fax market away from the telephone companies. This might be a very attractive concept to the Firewall vendors that would encourage them to support IPP. Even if this is true, it was noted that QualDocs has not even been given an IETF Charter yet. [Perhaps the QualDocs effort should not wait for a Charter? To get things moving faster, maybe the PWG could start working on it before a Charter is established? [The group discussed the possibility of going to the IETF and demanding a faster response on the current specification documents. It was suggested that if IPP/1.1 is not approved by the IESG by a certain deadline (e.g., the next IETF Plenary), then the PWG should request to take the specification back—and publish it under the PWG/IEEE-ISTO banner.] 4.6 Mandatory Notification Method? After further discussion about a possible mandatory notification method, the group agreed that the INDP Notification method should become mandatory. [It was proposed that IPP/1.3 (or whatever minor revision number is appropriate) should be defined to include whatever is necessary to support QualDocs. This would include the “INDP” notification method.] IPP Meeting adjourned.