Minutes of IPP Working Group Meeting December 7, 2000 1. Meeting Attendees Satoshi Matsushita Brother Lee Farrell Canon Information Systems Shinichi Tsuruyama Epson Jim Sommer Granite Systems Ron Bergman Hitachi-Koki Christopher Pott i-data Don Wright Lexmark Bill Wagner NETsilicon Roelof Hamberg Océ Jason Likins Quest Software Satoshi Fujitani Ricoh Amir Shahindoust Toshiba Tom Hastings Xerox Carl-Uno Manros (Chair) Xerox 2. Administrivia Carl Uno-Manros opened the IPP meeting and provided the suggested agenda topics: Order and approval of the agenda Status of documents Issue resolution from the October 17-20 bake-off in Boston Driver down-load Notification Final voting process to start to become PWG standards: * IPP Production Printing Attributes - Set1 * IPP Override Attributes for Documents and Pages * IPP "output-bin" attribute extension * IPP "finishings" attribute values extension Media Size Names and Keywords Announcing IPP Using SSDP Proposal for "Complete Internet Printing" Resource alternatives (Resource object vs. '1setOf collection Printer attributes) LDAP and SLP Directory status and progress PPML and PODi relationship Open source client and Linux For information only 3. Nominations for New IPP Chair? Carl-Uno announced that Xerox will be limiting his travel. He doubts that he will be attending future meetings—at least for some time. Ron Bergman volunteered to act as IPP Chair for the January meeting, but he stressed that he is not [yet] accepting the role beyond that. 4. Any Interested Authors? Carl-Uno asked the group if anyone is interested in writing (or helping to write) a book about IPP. He believes that this would help increase the visibility of the IPP standard. If there are any aspiring authors that would like to get involved in this effort, please contact Carl-Uno. 5. Issue Resolution from the October 17-20 Bake-Off Tom led a review of the Bakeoff Issues document: ftp://ftp.pwg.org/pub/pwg/ipp/issues/issues-raised-at-bake- off3-001201.pdf Tom discussed each of the Bakeoff Issues, identifying the proposed resolutions. All proposed resolutions were accepted as written, except as noted for the two Issues below. The document identifies two proposed resolutions for Issue 3.2: Resolution 1 is that a challenge should be issued whenever an HTTP operation is received on a particular URL. (assuming the URL is part of an authentication space.) The client must accept and respond to a challenge the first time a URL is accessed. Resolution 2 allows the vendor to determine when a challenge is issued. The vendor is free to use the contents of the HTTP request to determine if the operation mandates a challenge. The client must accept and respond to a challenge at any time. No one at the meeting indicated any strong preference between the two alternatives. Ron Bergman suggested that we should accept Resolution 2. No one disagreed, and the specification will reflect this decision. On Issue 3.4, it was agreed to modify the proposed resolution to "Recommend D, allow C, warn client implementers about A and explicitly indicate that B must not be done." 6. Status of Documents Tom reviewed the e-mail from Ned Freed (IETF Applications Area Director) that indicates favorable comments on the latest IPP documents he has read. Ned only had procedural comments, and complimented the group that he had no technical issues. 7. Driver Down-Load Hugo Parra was not present to discuss his latest draft of the Printer Installation Extension document: ftp://ftp.pwg.org/pub/pwg/ipp/new_DRV/draft-ietf-ipp- install-01-001107.pdf Carl-Uno noted that the most common objection to this proposal is the general concern for security associated with downloading executable files. He believes that the current section on security might not be considered adequate for the IETF. Is this concern within the scope of IPP? Would it be acceptable to just identify the potential threats associated with the protocol? It was mentioned that Microsoft Windows uses a digital signature method for authenticating downloaded files. What about other Operating Systems? 8. Proposal for "Complete Internet Printing" Document Tom Hastings has suggested that a document should be written to explain "Complete Internet Printing." According to Tom, one of the shortcomings of IPP is that there is no single document that pulls together the set of standards necessary for end-to-end printing on the Internet and within the Enterprise. The IPP documents deal only with job submission, job management, and Printer (service) management. To overcome this problem, he proposes to write a short IETF standards document (10-15 pages) that would cite other standards for complete end-to-end printing. The purpose is to have a single standard that defines all the aspects of IPP Printing from boot- up, registration, discover, Client Print Support File down-load (print drivers, font metrics, etc.), job submission, job management, and Print Service management for Internet and Enterprise printing. He suggests that the document would identify certain profiles (e.g. Home, Inter-Enterprise, Intra-Enterprise, etc.) and recommend the appropriate elements for each. It was noted that for some profiles, it would be desirable to reference non-IETF standards (e.g., SSDP). Because of this, there might be some difficulty in obtaining IETF RFC status for the document. Bill Wagner asked who would use such a document? Without endorsement and participation from O/S vendors, would it be anything more than "an interesting exercise"? There was much discussion regarding possible methods to encourage IPP adoption. It was noted that many of the Printer vendors consider the development of IPP Clients as a necessary—but not profitable—expense. Perhaps a mock-up client that would illustrate "the many neat things that can be done with IPP" would be useful? 9. IPP Roadmap Proposal In reaction to the complexities associated with the previous proposal, Carl-Uno suggested that a [simpler] "IPP Roadmap" document could be written. It would serve as a reader's guide to IPP and related documents. No other specifics were discussed. 10. PWG Standards Documents 10.1 IPP Production Printing Attributes – Set1 Tom Hastings announced that Xerox has discovered a few problems with Impression Image Shifting Attributes in this document and would like to delay its progression to PWG Standard. They would like to include more terms, attributes, and clarifications in Section 3.18. Tom explained the new attributes and described several methods of placing impressions on paper. The proposed modifications have not yet been distributed for review, but Tom plans to issue a new draft soon. 10.2 IPP Override Attributes, Output-bin, and Finishings Tom reviewed the latest modifications to the following three documents: Override Attributes for Documents and Pages ftp://ftp.pwg.org/pub/pwg/ipp/new_EXC/pwg-ipp-override- attributes-001130.pdf "output-bin" Attribute Extension ftp://ftp.pwg.org/pub/pwg/ipp/new_ATT/pwg-ipp-output-bin- attr-001026.pdf "finishings" Attribute Values Extension ftp://ftp.pwg.org/pub/pwg/ipp/new_VAL/pwg-ipp-finishings- fold-trim-bale-001030-rev.pdf He identified these documents as the first ones to go through the PWG Standardization process. Carl-Uno said that he will be requesting a PWG Last Call for the documents. 11. Media Size/Type Names and Keywords The UPnP Imaging Committee has requested that the IPP WG develop a standard list of Media Sizes and Media Types that they can reference in the UPnP Printing specification. For Media Size, the following syntax has been suggested "name-mxn" As part of this syntax, the UPnP group has also requested to reserve the prefix "custom-" to indicate non-standard (i.e. vendor- or user-specified) media sizes. It was also agreed that minimum and maximum values for custom sizes should be supported. Special names will be reserved for this purpose: "custom-min-mxn" "custom-max-mxn" ACTION: Ron Bergman will develop a proposed list of Media Sizes. ACTION: Jim Sommer will develop a proposed list of Media Types. 12. Announcing IPP Using SSDP Tom reviewed his proposal for advertising an IPP Printer using SSDP. The SSDP Packet for IPP would look something like the following example: NOTIFY * HTTP/1.1 HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age = seconds until advertisement expires LOCATION: URL for IPP Printer with 'ipp' scheme NT: search target NTS: ssdp:alive SERVER: OS / version, IPP / 1.1, product / version USN: advertisement UUID There was a question raised about how useful this proposal might be. Is there a reasonable scenario that takes advantage of this capability? ACTION: Peter Zehler was "volunteered" to complete the SSDP packet for IPP proposal for publication and review. 13. LDAP and SLP Directory Status and Progress The IETF has not reserved an OID for LDAP. ACTION: Ira McDonald was "volunteered" to establish a PWG OID for LDAP. 14. PPML and PODi Relationship A PODi representative recently contacted Carl-Uno. The PODi organization has developed PPML (Personalized Print Markup Language), and they are anxious to advance its use. They have requested help on how to put their PPML objects into a Multipart MIME structure and pass it to printers via IPP. Carl-Uno said that Bob Herriot is currently considering a possible solution. Roelof Hamberg volunteered to work on this effort with Bob. 15. Resource Alternatives (Resource Object vs. '1setOf Collection Printer Attributes) Tom Hastings referenced the four documents pertaining to the Resource proposals: Counter Proposal - Resource as '1setOf collection Printer attributes summary ftp://ftp.pwg.org/pub/pwg/ipp/new_RES/resource-objects- counter-proposal-001127.pdf Third alternative Proposal - Separate resource objects and ops for each type ftp://ftp.pwg.org/pub/pwg/ipp/new_RES/resource-alt-3- separate-objects.pdf Original Proposal - Resource object summary ftp://ftp.pwg.org/pub/pwg/ipp/new_RES/resource-objects- summary-proposal-001127.pdf Original Proposal complete spec: "IPP Resource Objects" ftp://ftp.pwg.org/pub/pwg/ipp/new_RES/draft-ietf-ipp-get- resource-01-000901.pdf He generated a table of pros and cons comparing the alternatives: 1SetOfCollection access control by row could do a "MIB" walk can't query easy to add new Printer attribute client able to query new resources cut and paste for specification additions Resource Object access control by type get all objects of all types can't query easy to add new resource type client passes resource type to query heavy effort at initial specification, but less(?) work in the future Separate Objects access control by operation easy to query which operations Printer implements add new operations hard (impossible?) for client to use proper query cut and paste for specification additions A straw poll vote suggested that people preferred the "Separate Objects" approach (0, 1, and 5 votes, respectively—with 6 abstentions.) Tom will publish a summary pros/cons comparison on the e-mail list and ask for more votes between the three options. It was suggested that this document should become a PWG specification—not an IETF document. IPP meeting adjourned.