PWG Internet Printing Project Meeting Minutes May 15, 1997 San Diego, CA The meeting started on May 15, 1997 at 8:45 AM led by Carl-Uno Manros. The attendees were: * Ron Bergman - Data Products * Lee Farrell - Canon * Don Wright - Lexmark * Scott Isaacson - Novell * Jeff Copeland - QMS * Bob Pentecost - HP * Sylvan Butler - HP * Tom Hastings - Xerox * Harry Lewis - IBM * William Wagner - Digital Products * Robert Herriot - Sun * Carl-Uno Manros - Xerox * Keith Carter - IBM * Stuart Rowley - Kyocera * Peter Zehler - Xerox * Steve Zilles - Adobe * Randy Turner - Sharp * Paul Moore - Microsoft * J.K. Martin - Underscore * Larry Masinter - Xerox * Tony Liao - Vivid Image * Stephen Holmstead * Takami Kurono - Brother * Jerry Hadsell - IBM * Rick Yardumian - Xerox * Xavier Riley - Xerox * Zhi-hony Huang - Zenographics * Gary Roberts - Ricoh * Richard Schneider - Epson * Robert Kline - TrueSpectra * Patrick Powell - SDSU * David Kellerman - Northlake Software * Dave Kuntz - HP * David Manchala - Xerox Planned Agenda Morning: * Report of outcome from PWG MOD meeting May 14 (Scott Isaacson) * Presentation on SWP - Paul Moore, Sylvan Butler * CPAP Presentation - JK Martin * HTTP/NG - Larry Masinter * IPP Discussion - Bob Herriot, Randy Turner Afternoon: * Discussion about Prototyping efforts supporting the IPP protocol choices - Peter Zehler * Discussion of IPP Security - Carl-Uno Manros Model Meeting Report (Details will be published in model meeting minutes) * Discussed whether model was meeting the goals and the requirements as outlined in the Requirements I-D. * Discussed the job template attributes * Discussed what does "best efforts" mean - new values: "shall" and "should" * New draft to the IETF will take a little while due to re-formatting, etc. Probably would be 2 weeks before the next the draft. Presentation by Paul Moore on SWP (Simple Web Printing) (Charts and document are available on the PWG Web site.) - Work has been underway for some time - Enhanced and changed based upon feedback from IETF, etc - It mandates * Print submission protocol - Command sequence - data format - encoding - return values * HTTP 1.1 * Security - It suggests * Client configuration * Return URL * Access Control - It excludes * job monitoring and control protocol * printer discovery and client configuration * print by reference ** Discussion on if HTTP is correct ** Discussion on use of Unicode versus a charset value for the text in the headers ** Discussion on using HTTP chunking to determine the length of a job ** Should SWP send big-endian or little-endian? - big - Management, discovery * via HTML * no client changes * Not mandated - Implementation planned to be similar to what Babak presented in February. - Issues: 1) Enumerations versus keywords 2) Byte ordering 3) application/SWP 4) Mandate return URI - yes 5) What about unsupported attributes - ignore? 6) Adornments 7) Denial of service for anonymous users --- 8) Security 9) Is this to be an IETF standard? 10) TYPE as text versus 32-bit INT 11) Transport independent except length of print data 12) Charset - mandate unicode? 13) one post or multiple post (to get back job URI before whole job is posted) 14) What does the server do if the print job is too big? 15) Discovery of printers and their capabilities 16) Should we have SWP as well as a full-blown version to replace LPR. Should one be a subset of the other? IPP Model and Protocol Overview Steve Zilles discussed briefly the material he presented at the IETF meeting in Memphis. CPAP - JK Martin No presentation -- time was used for discussions. ** Wide ranging discussion on: - what are we trying to do? - what is wrong with LPD? - are we trying to do everything through HTTP? - is asynchronous notification a requirement? - job submission versus status queries? - is something like CPAP needed for Intranet solutions? - how is policy reflected back to the client? - should the protocol be self-describing? - how are the MIBs (printer and job monitoring) related to IPP? HTTP New Generation - Larry Masinter - HTTP-NG is a promise, not yet real - An effort to "fix" HTTP - HTTP mission creep (too many projects hopping on the HTTP band-wagon) - Need something to address the inefficiencies of HTTP - More information from www.w3.org or ftp.parc.xerox.com/pub/masinter/http-ng.html Lunch Break Protocol Discussion - Bob Herriot 1) Encoding SWP HTTP-like application/IPP CPAP form-based - attributes * Herriot proposal for application/IPP - document data * swp (content length implicit) * explicit doc #, chunk # - operations - responses (attributes and status) 2) 1 job operation or 2 A long discussion again was held on the issue of HTTP and the concept of using something like SWP versus form-based upload. The SWP proposal does not require the use of the browser in any way to perform the actual printing. The browser simply insures that the remote printer/server is accessible via HTTP and through firewalls, etc. that might be present. The group in attendance voted to recommend to the entire working group that the first proposal should be based on HTTP/1.1 versus a newly created UDP or TCP/IP protocol. The results were 6 to 16 in favor of HTTP (Paul Moore of Microsoft voted twice.) Resumed discussion on encoding. A discussion was held on how to encode data. Embedded white space versus including a length value was discussed. Using embedded white space was perceived as being more difficult and time consuming that length. This results in an encoding of the attributes that looks like: Length | Attribute-Name | Length | Attribute-Value [00 08] JOB-NAME [00 0C] MSWORD-NOTES First byte: Major Version (starts at 1) Second byte: Minor Version (starts at 0) Content Length includes all the attributes and not the length itself. The minimum value is 0 which means no attributes. Discussion on how to do multiple documents within a job - multiple chunking - meta-job - doing the simple case and adding it via versioning - multiple content-types: application/ipp - using an attribute ("document count") to indicate multiple documents ** resolution: using "send-job" with single document count for the single document per job and use "create-job" with multiple document count to associate multiple documents Operation is an attribute and is the first attribute in the list. Operations: - create-job (create a job, data to follow, URI returned) - send-data (data (attributes & pdl) for a previously sent create-job) - print-job (attributes and print data all in one, URI returned) - cancel - get-jobs - get attributes - validate (attributes but no PDL, no URI returned) What is the minimum implementation? Is an IPP implementation in a printer required to support multiple documents within a job? A printer could reject a create-job operation and force the client to use multiple print-job operations instead. Resolution: Paul Moore will be writing a proposal for a level 1 conformance (encoding, operations and the transport) which will be a new version of the SWP document within the next couple of weeks. This draft will be made available to the group for review before publishing it as an IETF draft. It will be viewed and discussed at one of the conference calls. Security Carl-Uno Manros presented the security sub-group's work-in-progress and status. His charts will be available on the WEB/ftp server. The combination of Digest Authentication and Transport Layer Security (=SSL3) look like a good combination for our specification. If a weaker security all that is necessary then Digest would be used; TLS if a stronger security is needed. A new security negotiation "Simple Authentication and Session Layer" or SASL is gaining mind share within the IETF. Issues: - object security works only with original MIME - channel security protocols only work with a particular protocol - if a new transfer protocol is used, there might not be a security means available. Goal is to have a new internet-draft available in the next two weeks. Implementation Discussion Can a special service provider register for a particular document type so that it can be "filtered" before it is printed? - yes, in the SWP case, via an ISAPI extension, etc. Documents Work done by the protocol group will be reflected back into the model document (new operations, conformance.) A directory document should be published in the next few weeks by Keith Carter. Next meeting - June 25/26 in Nashua, NH. The meeting adjourned at 6:10PM.