Minutes of IPP Working Group Meeting January 19-20, 1999 1. Meeting Attendees Nick Webb Auco Katsuaki Sekiguchi Canon Shigeru Ueda Canon Lee Farrell Canon Information Systems Don Purpura Canon Information Systems Michael Yeung Canon Information Systems Ron Bergman Dataproducts Bill Wagner DPI/NetSilicon Brian Batchelder Hewlett Packard Jan Idomir Hewlett Packard Sandra Matts Hewlett Packard Harry Lewis IBM Henrik Holst i-data Michael Wu Kodak Kaoru Yamagishi Komatsu Don Wright Lexmark Raymond Balmes OCE Eric Random Peerless Grant Gilmour Qmaster Software Tom Hastings Xerox Bob Herriot Xerox Carl-Uno Manros (Chairman) Xerox Rick Yardumian Xerox Pete Zehler Xerox 2. Day 1 Carl Uno-Manros opened the IPP meeting and provided the suggested agenda topics: * Implementer's Guide * IPP/NV * IPP URL scheme * TLS security * Notifications * Test plan for Bake-off * IPP/1.0 extensions * SLP schema for printing * Salutation presentation * JINI presentation 2.1 Implementer's Guide Tom Hastings distributed the latest update to the Implementer's Guide. (This document is available at: "ftp://ftp.pwg.org/pub/pwg/ipp/proposed-clarifications/ipp-implementers-guide-990108-rev.pdf".) Tom led a review of the changes to the document. All of them were minor edits for clarification. There were very few changes and there were even fewer comments. The more significant changes include: * Several REJECT/RETURN error codes were clarified in Section 2.2.1.4.3 * Section 2.6.1 includes a recommendation to support US-ASCII in addition to UTF-8 * Section 3 includes a clarification on responding to an error before all data is received * Sections 3.6.2 and 3.6.2.1 were added to discuss the use of chunked requests with CGI script implementations During the review, it was noted that items 1 and 2 in Section 3.6.2 seemed to contradict one another: 1. All HTTP/1.1 [HTTP] applications (IPP recipients) that receive entities MUST accept the "chunked" transfer-coding, thus allowing this mechanism to be used for messages when the message length cannot be determined in advance. 2. However, an origin server MAY refuse to accept a request without a defined Content-Length by responding with status code 411 (Length Required). The apparent contradiction was not resolved during the meeting, and was deferred for Tom to investigate further. There still seems to be much confusion regarding the interaction of HTTP chunking and CGI scripts. Carl-Uno suggested that we should reach agreement on this topic soon-or remove it from version 1.0 of the Implementer's Guide. He believes that it might be more appropriate to wait for more implementation experience, and include the results in a later version of the Implementer's Guide. However, as an attempt to reach a quick agreement, he also suggested that the Implementer's Guide should recommend the following: * servers shouldn't use CGI script implementations of IPP * if you use chunking, be prepared to receive an error-and then fall back to non-chunking Another recommendation was proposed: * if you know the content length, don't use chunking No consensus was reached. Harry Lewis volunteered to contact Carl Kugler (the author of much of the background e-mail on this issue) during the lunch break. Harry will then draft a proposal for final text modifications. It was also suggested that there should be a test included in the Bake-off to exercise this particular issue. More discussion will occur on the e-mail list to clarify this topic further. [The next day, Bill Wagner, Harry Lewis, and Carl Kugler (and others?) reached an agreement on some proposed text via e-mail. The modified text will be included in the updated version of the Implementer's Guide.] Tom indicated that the document needs to clarify what is meant as the "closest version number" to be used during version negotiation. (This was identified as an action item at the previous meeting.) However, he now recommends that we should wait until a new version of IPP is actually defined before we attempt to clarify this. Harry suggested that we could avoid this whole concern by making sure that all future versions of IPP are backward compatible. The group agreed to defer the topic until the next version of IPP is defined. 2.2 IPP/NV ("Next Version") The group agreed that "IPP/NV" should now be called "IPP/1.1". It was noted that the set of documents that define IPP/1.0 has been submitted to the IETF as Informational RFCs, but no response has yet been received from the IESG. Carl-Uno said that the group needs to issue new Internet-Draft documents for each of the following subjects in order to gain acceptance by the IETF as a standards track document set: * IPP URL scheme * IPP TLS security * IPP Notifications (this might only be required for IFX) Carl-Uno provided a very brief review of the current status on each of the above topics. He said that he would like to try and complete these documents as quickly as possible (i.e. February?) for IETF submission. Carl-Uno noted that the IFX (IPP as a Facsimile Service) group will need to have a standards track version of IPP to reference to complete their work. ACTION: Bob Herriot will be Editor for the URL scheme and will create the next document version. ACTION: Carl-Uno will get John Wenn from Xerox to author the next TLS document. (He asked for other volunteers to participate in writing this document, but no one offered.) Carl-Uno volunteered to review the document. He will also attempt to get Randy Turner to proofread it. After a discussion on the necessity for TLS Security support, the group decided not to create a separate document. Instead, the appropriate text will be included in both the Model and Encoding/Transport documents (as it was done originally.) To achieve this, John Wenn will need to collaborate with the Editors of these two documents. [Later in the day, a similar decision was made to merge the IPP URL document content into the other documents, instead of keeping it as a separate document.] The group agreed that the decision to include IPP Notifications in IPP/1.1 should be deferred. Until then, the Notification document will be kept separate from the others. 2.3 Notifications Tom Hastings distributed an updated version of the IPP Event Notifications document. (This document is available at "ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notifications-very-short-990118.pdf".) He led a review of the latest document changes listed in Section 10. Tom then provided a page-by-page review of the document, and discussed the other edits made since the previous version. He also reviewed/resolved the various ISSUEs that are noted in the text. Tom will modify the document to reflect all the discussions on each of the ISSUEs. During the discussion, Carl-Uno strongly suggested that we use MIME types for all methods of notification. 2.4 Test Plan For Bake-Off Peter Zehler reported that the Bake-off registration form has been sent out on the e-mail list (Feb 1 registration deadline.) Novell, Netscape, and Microsoft implementations will be available during the test effort. He is still working on the detailed schedule for the Bake-off. A "brainstorming" discussion will be held on Tuesday, March 9 at the Bake-off to prepare for the testing activity of the week. Peter is asking each of the attendees to provide information on what type of equipment they will be bringing. Other information will also be required, including whether the implementation supports security, chunking, etc. He is coordinating this information via the registration forms. A (tentative) prioritized list of the tests to perform has been created, however Peter still needs to identify more details before it is complete. Peter reviewed a list of the various tests that will be performed. He expects to distribute this list via e-mail. 2.5 IPP/1.0 Extensions Currently, the most important Extensions document (for IPP/1.0) is the "Set 1 Operations" document. Should we include these Operations in the IPP/1.1 specification? The consensus was that they should be included. It was also decided that they should be merged with the other IPP document(s)-rather than kept as a separate document. It was also decided that the IPP URL Scheme information should be merged into the other IPP documents-rather than kept as a separate document. It was suggested that the updated documents should include a discussion of the IPP Scheme in the Encoding and Transport document. Are we going to republish the Goals document for IPP/1.1? Most people felt that this is not necessary. 2.6 Pages-per-minute A new version of the document describing the new attribute was distributed. (This document is available at: "ftp://ftp.pwg.org/pub/pwg/ipp/proposed-registrations/attributes/ipp-pages-per-minute- attr-990118.pdf".) Tom Hastings reviewed the latest changes. After a very brief review, the group decided to add the pages-per-minute attribute to the IPP/1.1 specification. 2.7 Finishings A new version of the document describing new attribute values was distributed. (This document is available at: "ftp://ftp.pwg.org/pub/pwg/ipp/proposed-registrations/attribute-values/ipp-finishings- attr-vals-990118.pdf".) Tom Hastings reviewed the latest changes. The group decided to add these attribute values to the IPP/1.1 specification. 2.8 Collections Tom Hastings noted that there was no progress on the Collections document since the previous meeting. This item will probably not be included in the IPP/1.1 specification. ACTION; Tom Hastings will forward the Collections syntax proposal document to Graham Klyne (member of the IETF CONNEG WG) for his review. 2.9 SLP Printer Template ACTION: Bob Herriot will attempt to get James Kempf and Ira McDonald to agree on the SLP Printer Template issue of whether there is one printer entry per URL. Tom reported that Ira has posted a long list of changes since the last proposal. There are now about eight mandatory attributes that must be provided. All other attributes are optional, and will have default values provided. Tom encouraged everyone to review the latest proposal and provide comments to Ira. 3. Day 2 3.1 Salutation presentation Bob Pecora from the Salutation Consortium provided a presentation on Network Resource Management. (The slides are available at: "ftp://ftp.pwg.org/pub/pwg/ipp/PWG-Presentations/sal-pwg-ipp- 12099.pdf".) Salutation has a large membership list of big companies. They started in 1994 with five member companies. Several Salutation-enabled products have been shipped. According to Pecora, Salutation has a user focus: "I want to be able to work from where I am, not from where the network thinks I am-and with the tools at hand." Principles * Open to industry * Use existing standards * Simple design for interoperability * Independent of processor, O/S and transport protocol * Scaleable structure and code * Worldwide defacto first, then "standard" as required Larry Stein asked why Salutation was making a presentation to the IPP group. Is there a particular problem that IPP is facing that Salutation solves? Harry Lewis explained that the purpose of having both Salutation and JINI presentations is primarily to make the IPP members aware of related technologies that address the features that should be considered for Server-to-Device Protocol (SDP). 3.2 Jini presentation Bob Scheifler from Sun presented slides on Jini. (The slides are available at: "ftp://ftp.pwg.org/pub/pwg/ipp/PWG-Presentations/jini.pdf".) 3.3 Next Meeting Carl-Uno reminded everyone that there will not be a IPP meeting during the PWG meeting in March. (Instead, the Bake-off will be held on March 9-12.) The next IPP meeting will be held during the week of April 12-16 in New Orleans, LA. IPP meeting adjourned.