Internet Printing Project Meeting Minutes January 28/29, 1998 Kaanapali, Maui, Hawaii The meeting started on January 28, 1998 at 10:30 AM led by Carl-Uno Manros. These minutes were recorded by Don Wright. The attendees were: - Randy Turner - Sharp - Ron Bergman - DataProducts - Peter Zehler - Xerox - Lee Farrell - Canon - Bob Pentecost - HP - Dave Kuntz - HP - Kris Schoff - HP - Don Wright - Lexmark - Tom Hastings - Xerox - Carl-Uno Manros - Xerox - Stuart Rowley - Kyocera - Bob Herriot - Sun - Henrik Holst - I-Data - Atsushi Uchino - Seiko-Epson - Xavier Riley - Xerox - Harry Lewis - IBM - Josh Cohen - Microsoft - Paul Moore - Microsoft - Jim Walker - Dazel - Roberto Sannino - SGS Thomason Conference Call Dial-in Participants: - Jay Martin - Underscore - Ira MacDonald - HighNorth - Scott Isaacson - Novell - Roger Debry - IBM - Keith Carter - IBM - Steve Gebbler - IBM - Carl Kugler - IBM - Sven Johnson - Xerox - Peter Michalek - Shinesoft System - Daniel Manchala - Xerox - Shivaun Albright - HP Carl-Uno Manros reviewed the agenda for the day. Paul Moore started off the meeting with an overview of the Microsoft XML proposal including the proposal to use another method rather than POST. The charts used were distributed on the mailing list as IPPPRES.PPT, IPPPRES.PDF and as text before the meeting. The first area of discussion was whether we should use the POST method or create new methods. John Cohen presented the results of an informal survey he conducted asking HTTP server and Firewall vendors what they thought about it. He reported that most of those he surveyed did not what to overload POST. Next, Paul Moore presented the reasoning behind proposing XML as the structured data representation rather than the current IPP proposal. XML offers a way of describing complex structured data that wasn't available when the group originally considered using an simple ASCII representation. The proposal includes including the DTD in the spec but not forcing run-time DTD checking. Additionally XSL would not initially be included. Paul and Josh suggest using weak typing using multi-part related MIME. When should we do this? - with IPP V1 * XML is not ready yet * Creates legacy - with IPP V2 - Never Paul and Josh recommend doing it now using a simple subset of the total XML definition. Paul Moore listed the benefits of going to XML: 1) Extensibility issues which we haven't hit are probably already addressed by XML. 2) 3rd party tools that know how to parse XML will be able to parse IPP. 3) In environments where XML already exists, less new code is needed. The group identified some disadvantages of XML: 1) Over the wire, XML is less byte efficient than existing IPP. 2) Implementation experience would indicate that an XML parser would take 2 to 3 times more code space. The group broke for lunch. After lunch, the conference call began. The first issue discussed was whether we should discuss the technical merits of the proposal or discuss its appropriateness first. The group voted as to whether to discuss the technical merits or to reject the proposal as "too late" (Yes = Discuss, No = Reject) No Votes 13: Jay Martin, Ira MacDonald, Scott Isaacson, Roger Debry, Keith Carter, Steve Gebert, Carl Kugler, Sven Johnson, Peter M. (Shinesoft System), Daniel M. (Xerox), Ron Bergman, Harry Lewis, Don Wright Yes Votes 16: Randy Turner, Bob Pentecost, Kris Schoff, Dave Kuntz, Stuart Rowley, Henrik Holst, Paul Moore, Josh Cohen, Asushi Uchino, Lee Farrell, Jim Walker, Bob Herriot, Xavier Riley, Peter Zehler, Tom Hastings, Carl-Uno Manros The group began discussing the issue of replacing the POST method with one or more IPP specific methods. Paul Moore presented a summary of this issue for the conference call participants. There were are number of arguments presented from the other side including changes needed for many web servers, the fact that others use POST to pass data to back-end applications, etc. Roger Debry questioned the capability of adding additional methods to servers and hooking those methods to a Java Serverlet. The group discussed whether having a separate method would assist firewall administrators in differentiating print function versus using other ways to different and deal with the security issues of POST. Once the proposal goes to the IESG, there is a real possibility that the issue of POST could be raised as well as almost any other thing including the perpetual question of "why are we using HTTP?" No decision was made on this issue. The group moved to the issue of XML. Paul Moore presented the summary of "why XML" again. Bob Herriot presented his views on the PROs and CONs of using XML. The group discussed the issues again including data typing, new data types, footprint size of XML parser, etc. There were widely divergent opinions expressed. A discussion on the overall merits of XML and the problems with delaying IPP due to time to market issues. If we delay will some now non-compliant internet printing products ship confusing the marketplace? Randy Turner proposed forwarding the document to the IESG for last call to prevent the group spending 3 to 6 month on XML and then having the IESG reject the XML proposal. Should we send the current documents with the binary protocol to the IESG for last call? Submit Now: Roger Debry, Carl Kugler, Steve Gebert, Keith Carter, Harry Lewis, Ron Bergman, Jay Martin, Ira MacDonald, Shivaun Albright, Daniel M., Stuart Rowley, Henrik Holst, Atsushi Uchino, Don Wright, Bob Herriot, Xavier Riley, Peter Zehler, Tom Hastings, Carl-Uno Manros, Randy Turner Wait later: Bob Pentacost, Kris Schoff, Dave Kuntz, Paul Moore, Josh Cohen, Jim Walker The group re-affirmed its desire to take the existing documents to last call. The group began discussing what should be discussed tomorrow; some of wich could be considered for future enhancements for IPP V1+: - Enhancements in the area of multiple documents per job - document object - attributes for that object - Have we tried to please too many masters by developing a protocol for both the embedded printer and server based solutions? - Should we add a higher level of abstraction above "printer" to be able to represent a server with a pool of printers attached. - Revisit the philosophical decision to limit the intersection of IPP and SNMP. Should all the SNMP information be available through the IPP? - Automatic IPP printer installation - Notifications - Authorization (Access Control Lists) - Job Management - Printer Management - Print System Management - IPP MIB - Printing Commerce - Accounting - Fonts - Dictionary Syntax - Universal Print Driver Overview The meeting adjourned for the day at 5:15 PM. The meeting resumed on Thursday at 8:45 AM. Peter Zehler led the discussion on the Testing and Prototyping effort. The agenda was: A) Testing methodology 1) How to test an implementation - test suite - scenarios - simple instructions, capture of results, compare - trace file repository 2) Internet Pair-wise test/bake-off 3) Face to face bake-up 4) How to document results 5) Establish milestones - develop test plan (Pete & Randy) 2 weeks - organize pair-wise testing (Pete) - update FAQ (Carl-Uno) 2 weeks 6) Public Demo - At a trade show such as Xplor or Fall Networld-Interop - At some other locale B) Conformance/Compliance 1) Minimum level definition 2) Operation & Attribute coverage 3) Security coverage & intervention C) Preliminary Schedule for milestones, action items and deliverables - Who is developing IPP clients/servers? IBM (prototype client ready, server not ready) Sharp (prototype server ready, client almost) -- ipp.sharplabs.com HP (defers to Microsoft (client and server)) Kyocera (not ready) I-Data (not ready) Microsoft (client and server prototypes subsequent to NT Beta 1) Epson (not ready) Canon (not ready) Dazel (not ready) Lexmark (not ready) Sun (not ready) Xerox (1 test client, 2 servers) - How soon can pair-wise testing occur? - Develop test plan (Pete & Randy) - test cases - good - bad - chunked - collect and document problems, post to TES DL (Pete Z) - Hide owners of prototype in test - less of concern with early prototypes versus shipping products - advantage of privacy from 3rd party - disadvantage in follow-up - should focus on misunderstandings of the spec - data gathered could be used to create an "Implementers guide to IPP" What do we think the behavior be if the client is unable to send a job to a non- spooling printer? - should operations, etc. be defined in the protocol to handle this? - should the client report back the situation but continue trying but send without "locking out" the user? - is this a TCP/IP, an HTTP, or an IPP error? - How do we make IPP a great experience? - How can IPP be able to do much more than what LPD and other existing print services? - Can we come up with a consistent contention model due to the interaction of IPP with Web servers, etc. - Contention is not an error, it is really normal operation. - Should we more accurately call some of the responses as status codes rather than error codes? - Randy will post a list of network programming issues for IPP. A subgroup will be formed from interested parties after this is posted. Paul Moore and Randy Turner will kick off this effort to clarify the contention behavior of V1 and identify potential work in this area for a future enhancement to IPP V1. The LP-to-IPP mapping document should include this issue. The group attempted to identify the high priority items from the discussion list created yesterday. 6 - Enhancements in the area of multiple documents per job - document object - attributes for that object 0 - Have we tried to please too many masters by developing a protocol for both the embedded printer and server based solutions? 2 - Should we add a higher level of abstraction above "printer" to be able to represent a server with a pool of printers attached. 10 - Revisit the philosophical decision to limit the intersection of IPP and SNMP. Should all the SNMP information be available through the IPP? 2 - Automatic IPP printer installation 6 - Notifications 0 - Authorization (Access Control Lists) 6 - Job Management 6 - Printer Management 1 - Print System Management 0 - IPP MIB 1 - Printing Commerce 3 - Accounting 5 - Fonts 1 - Dictionary Syntax 9 - Universal Print Driver Overview 1 - defaulting Dictionary Syntax: Tom Hastings and Roger Debry will present a proposal. IPP versus SNMP: - server based versus embedded - if we add a "server" to the model, on which end of the protocol is the server? + from the printer perspective the server is on the source end + from the client perspective the server is on the target end - IPP Method to retrieve SNMP OID? - Could additional printer attributes to enable getting and setting printer characteristics that are now only accessible by using SNMP. - What would the media model be -- select by tray or select by name? -- the OS probably needs both because the user might want to see it presented different ways. - Could use IPP to configure drivers? - We could push to get SNMP mgmt of printers allowed through firewalls - Tom Hastings will kick off the efforts. Interested participants should contact Tom. Universal Printer Driver: Paul Moore described the capabilities of GPD and Unidrive 5 from the perspective of creating a universal print driver. +--------------------+ | | | Client | | | +--------------------+ ^ | V +--------------------+ | | | Unidrive 5 | | | +--------------------+ ^ | Generic | | +-------+ Printer ------- +---->| | Description | Prtr | +-------+ The OS uses the GPD to dynamically build the UI for the printer based upon the device options, constraints and other information provided with the printer and information provided at install time. The GPD syntax has the ability to include macros which can be called to set a group of setting to achieve some singular purpose (fastest, best quality, etc.) GPDs - ASCII text - about 30K per printer - escapes for advanced features / UI - NT 5 supports about 1000 printers Documentation for GPD is available in the NT 5 DDK. Paul Moore proposed that the group look at the current GPD syntax and investigate standardizing the syntax. There are certain parts of GPD today that are Windows specific and would perhaps need to be made more general. Additionally, additional functions could be identified that might need to be added. The group decided to take a look at specification and whether to work on this as a standard will be discussed at a future meeting. Notification: Randy Turner presented his thoughts on notification. . . - Should it be ASYNC (out of band)? - How timely should the notification occur? - Should it be reliable - Should we use a protocol outside IPP? - What type of information should be included in a notification? (Enumerate type of notifications) - Subscription and filtering - Subscription lifetimes ** Are "job finished" kind of messages which might be e-mailed different from other types of notifications (i.e. alerts( such as "interpreter error" ** Should the "alert" contain both machine readable and human readable fields ** Should notifications be directly readable by the recipient or should an application that receives the notifications be assumed? ** E-mail is really a special case that should be optional and included with the job submission that creates an e-mail when the job completes, aborts, etc. ** Could have both e-mail and IPP protocol notifications where the IPP protocol notification reports a superset of the e-mail method. ** LDAP includes something called a "persistence search" which includes maintaining an open connection which causes the notification to return when the criteria is met. We could use a similar concept. ** If we specified a means where the printer would notify by opening a connection on a certain port then that would require the client to listen for opens. ** Should we look at SENSE again? How is it applicable to this scenario? There are a number of issues about opening and maintaining connections. How does the server remember subscriptions if the connection is closed? John Cohen says there are some other efforts underway to create a generic notification service. He will post more information on the mailing list. Job Management: - Additional job management operations like * Hold, Resume * Move * Modify Printer Management: - Is SNMP good enough? - What about its reliability? What about firewalls and SNMP? Multi-document Jobs: - Need to add the Document Object back into the model - Would allow more flexibility to controlling documents - Jim Walker will distribute his thoughts on this subject to the DL. Do we need a slot in the next IETF meeting? -- Yes. The meeting adjourned at 5:35 PM.