Internet Printing Project Meeting Minutes September 17-18, 1997 Atlanta, GA The meeting started on September 17, 1997 at 8:40 AM led by Carl-Uno Manros. These minutes were recorded by Don Wright. The attendees were: * Randy Turner - Sharp * Ron Bergman - DataProducts * Xavier Riley - Xerox * Peter Zehler - Xerox * Lee Farrell - Canon * Yuji Sasaki - Japan Computer Industry * Philip Thambidurai - Okidata * Bob Pentecost - HP * Rick Landau - Digital * Richard Hart - Digital * Lloyd Young - Lexmark * Dale Wick - TrueSpectra * Bill Wagner - DPI/Osicom * Jeff Van Wie - Kodak * Bob Herriot - Sun * Don Wright - Lexmark * Harry Lewis - IBM * Steve Zilles - Adobe * Mabrey Dozier - QMS * Roger deBry - IBM * Tom Hastings - Xerox * Scott Isaacson - Novell * Carl-Uno Manros - Xerox Carl-Uno Manros reviewed the agenda for the two days. Scott Isaacson reviewed the decision from the last conference call to stop adding functionality and hold additions for a version 2.0. At that call, we decided not to make any of the job template attributes also document attributes. Additionally, IPP V1 will have NO ATTRIBUTES for documents including no longer having a document name. Scott went through his list of issues which were posted to the FTP server (ftp://ftp.pwg.org/ipp/new_MOD/issues- 970916.pdf). 1) Cancel semantics: trailing edge, new job-state reasons from Tom Hastings. 2) Global: MUST, SHOULD, SHALL editor will fix 3) Global: Directory document will become an appendix to the model document 4) Global: URI versus URL: leave as URIs. We will include a requirement that the printer must support an http scheme URL. If notification is supported then you must support at least the mailto scheme. 5) Get-Jobs operation: What order are jobs returned? There were a number of arguments on both sides of this issue. Not all OS's return jobs in the same order. The document will state that pending jobs SHALL be returned in the expected order of execution. Completed jobs SHALL be returned with the most recently completed jobs returned first. A enum attribute will be added to specify whether the request is for pending or completed jobs. Pending Held jobs are be included as active jobs. Where they are included in the list is implementation dependent. 6) References to Printer MIB and Job Monitoring MIB: We will include references to these documents but not indicate whether they are I-Ds or not. 7) Attribute Syntax: Text attributes are specified as 1 to 4095 characters. Anything that might be expected to be exported to a MIB would need to be up to 255. -- Leave as it is. 8) URL versus URI - see #4 above. 9) Attribute Syntax - date/time - reference the correct RFC - Scott will do this. 10) Job Template Attributes: Job Priority - All implementations must accept on the wire values of 1 to 100 and map them evenly to the internal priority levels. An administrator can limit the range a particular user can assign to his job. (100 is the highest priority.) How a UI maps from the user to the wire is outside the scope of this effort. Scott will write it up in the document as described here. 11) Event Notification Content: Job-State Message and Printer-State Message will be UTF-8 encoded ISO10646 characters in the human language negotiated. 12) Document Format: Change "mimeType" to "MediaType" and reference RFC2046. 13) user-human-language: should be renamed to job-user- human-language? - No - This is a job template attribute which we currently plan to use information from the HTTP headers (general or application/IPP?) to set this value. Steve Zilles will write this up for inclusion in the model document. printer-name: need not be translated (set by admin) printer-location: need not be translated (set by admin) printer-description: need not be translated (set by admin) printer-make-and-model: should be translated (set by mfg) printer-state-message: translated (computed) job-name: not translated (set by user) job-state-message: translated (computed) job-message-from-operator: need not be translated (set by oper) The typical internationalization religious discussion ensued. Scott will update the model document to change the definition of attribute syntax type text and name to include a "language tag" (RFC2184) to precede the actual body of the text returned. This is for both server and client created text and names. The client will be able to ask for a certain language from the server using the accept header from HTTP. Implementations may need to remember the language request so that notification or an event is returned in the requested language. 14) time-since-pending/processing/completed -- perform the editing change suggested and time will be in seconds and not ticks. Lunch Break: 11:30 - 1:00 Job-URI versus Job-id At 1:00 we began the conference call to discuss the issues of Job-URI versus Job-ID issue. Some of the issues were listed: 1) Existing, job-id oriented APIs 2) Potential Object-oriented APO 3) Gateways - IPP client <-> legacy system - Legacy client <-> IPP Printer 4) Redirection 5) Scalability 6) "Helper" Attribute could return the numeric job id The issue of the value of being able to see jobs submitted via some legacy means as well as IPP submitted jobs using IPP was discussed. Some participants felt that it is necessary to expose all jobs submitted from any means while others believed that this need was only temporary until clients moved to IPP from the legacy environment. How do we resolve the difference between the way the Job MIB reports jobs versus a Job-URI? Since the Job MIB provides more information such as which page of the current job is printing, a client might want to use the Job MIB to get these details that are not available using IPP. How do you correlate the Job-URI with the JOB ID? We could add an attribute to the JOB MIB that would be the JOB-URI -- Hastings We could mandate a job id to be a part of the Job-URI using some delimiters - P. Moore For the cancel job case, the client must know how to build the URI for the job if the URI is not retained just the numeric job id - P. Moore What if we provided two ways to identify the job: 1) job-URI 2) Printer-URI plus job-id job-URI Discussion Conclusion: All IPP printers shall generate, store (with the job information) and return both the job-URI and a 32-bit job-id on Print-Job, Print-URI or Create-Job. It will accept all job operations (cancel-job, send-document, send-uri, and get-attributes) on either the job-URI or on the Printer-URI plus the job-id. Clients can utilize either method, i.e. they can reference a job using the job-URI or the Printer- URI plus the job-id. IDs are only meaningful in the context of the Printer-URI to which it was originally submitted. Get-Jobs will have to return both job-URI and job-ID as the default. Scott will write this up in the model document. If an "IPP printer" also implements the Job MIB, then the job-id will be the same between the MIB and IPP. - After the conclusion of the job-URI discussion, we reviewed some of the directions set during the morning session with those on the conference call. - While the conference call was still open, we discussed the use of a port besides 80. It was the consensus that we would not mandate an alternative port number but we would not preclude some implementations from using alternative ports. The protocol document should make a statement that by default IPP should be supported by servers and clients over port 80. Model Issues: 15) Change PDL Override back to Boolean -- no 16) Covered by #13 17) Delete appendix C and reference IANA MIME registry: yes, but include a couple of examples in the actual attribute section. 18) Addition of document-formats-detected: No - if the client knows the document format then it should use that attribute and not depend on auto-sensing. 19) If Create-Job is supported then Send-Document must be supported and Send-URI is optional. 20) No document level attributes - yes 21) Delete orientation as a job attribute - no - we will add reverse landscape -- these only apply to the case of simple text. 22) Compression - IPP will support none, compress, gzip and deflate 23) Any character from ISO10646 (level 2) will be encoded in UTF-8. 24) What does the server do when a time-out occurs after a create-job? - delete? (This action could depend on the fidelity setting) - close and hold? - close and schedule? Scott will document these cases and the ramifications. 25) Is any notion of time (absolute, relative) mandatory? - absolute time is not mandatory - relative time is mandatory 26) "media-ready" versus "media-supported" There was a long discussion on the value of a "media- supported" attribute so that a media that could be loaded by an operator would be available to the client to choose from. If a job is submitted with FIDELITY=TRUE and the media requested is not in either list (media-ready or media- supported) then the job would be rejected. If the media is supported and not ready, the job would be held until the media is loaded. If FIDELITY is not TRUE, the job would be printed on the best available media. Scott will write this up for immediate review. 27) Delete syntax for "copies-supported" - We will leave it as it is and add an attribute "collated-copies-supported" that would be available if the printer supported collating copies. 28) Support for ftp and http schemes are required for all IPP printers that implement Send-URI and Print-URI. Document-URI-schemes-supported will not be implemented for V1. User name and password from the ftp URL will be used if provided otherwise anonymous will be used. The printer should check for a supported scheme and reject unsupported ones (a new error code is needed.) 29) Confusion over the group "printer-description" versus the actual "printer-description" attribute. Scott will document a change to remove the ambiguity. 30) Change "color-supported" to provide more information -- no change for V1. 31) Editorial: operations are changed to be like type2 enums and the pseudo-keywords will follow the keyword syntax. 32) Status Codes and Operations will look like a type2 enum but the name space will be managed separately from other type2 enums. Scott will clean up this and #31 in the next document. 33) Job-URI versus Job-id : see discussion and conclusions above. 34) Need some text distinguishing minor version number versus major version number. A change in the major version implies a significant structural change while a minor version can be parsed around and properly ignored. Steve Zilles will submit some proposed wording for inclusion. 35) See #28 above. 36) Document attributes: document attributes are gone. 37) Default Job Template Attributes should not be treated as PDL overrides. 38) If Fidelity is false and attributes are ignored, should the response indicate what attributes were ignored? Yes - document in the model document. 39) Same as #38. 40) See #19. 41) What should be used for media type when PDL is automatic? * When document format is missing then default is used. * When application/octet-stream is sent to the printer the printer does its best to figure it out and print it. * Application/octet-stream is valid as the default and means use the auto-sensing mechanism. 42) The last-sent document can be an empty document. In fact any document can be empty. An empty document does not print a blank sheet; however it will cause a partial sheet to be printed. 43) The last-document attribute (either true or false) must be included in any send-document or send-uri and is an error if omitted. 44) If the printer implements the job-state-message then it must return it in the Create-Job, Send-Job, and Send-URI response. 45) "message-to-operator" operational attribute: keep 46) -- This number was skipped -- 47) Document attribute issue - all document attributes removed 48) Attribute Syntax assignments: Scott will not have assignments in the model document. They will be in the protocol document. 49) Delimiter Tag enums: These will also be in the protocol document. The meeting adjourned at 5:35PM The meeting resumed at 8:30AM, working through the Model issues. 50) Should the enum values be in decimal or hex. -- leave them in hex. 51) Resolution attribute syntax: Will be fixed by Scott. 52) Does '1setOfX' attribute syntax need to indicate whether order is important? : Yes, a statement will be added 53) Does 'rangeOfX' need to specify that lower is first: yes 54) Should notify-addresses have a default value? NO 55) printer-resolution should be of type resolution: Yes 56) Should compression have a default value? Don't need it; client specifies any compression, default doesn't make sense. 57) Job-sheets: When the client provided job-sheets is invalid and FIDELITY is true then the printer will reject the job. 58) Add printer-state-message as an optional field in event notification content: OK 59) Event Notification Content -- What printable format is time in? Scott will reference the RFC which defines an ASCII format for time. Scott will move this to the optional items at the end of the list. 60) Event Notification Content needs to be internationalized: All 'text' and 'name' will be internationalized with the language tag at the front of the string. 61) 'multiple-document-handling' and slip sheets: Job- sheets will be multi-valued. We will not, at this time, add slip-sheets since this is type4 but it could be added later. 62) 'number-up' will be changed to a type 'setof' integers. The lower bound will be 1. Borders on n-up images will be implementation dependent. Scott will clean up the definition of what 'logical' pages are based upon a suggestion from Steve Zilles. Interaction of n-up, orientaton, duplex and finishing need to be discussed in the document -- Steve Zilles will send a draft to the list for review. 63) IPP should explain printer resolution rather depending upon the MIB - Yes 64) print-quality: Change to say that the value of the attribute SHALL be used for the job -- ok 65) In the orientation section, change langSimpleText to the right MediaType -- ok 66) orientation -- added reverse landscape and see Tom Hasting write-up sent on 9/16, subject: MOD - ISSUES in 09/03 Model document. 67) "document-name" mandatory? - no document attributes 68) Should job-URI be a Job Status Attribute? -- It is now returned as an operation attribute. Scott will change this and add job-id to be just a job attribute that is returned. Add 'number of intervening jobs' as an optional attribute returned on the create request. 69) Generic Alerts from the Printer MIB - Peter will list them and Scott will add these as additional printer events. 70) What about Media-Ready: covered as #26 71) Compression: covered as #22 72) Job URI versus job-id: covered in conference call on Wednesday. 73) job-name versus job-user-label: No, we will have no job- user-label 74) "user-human-language" fixed yesterday as #13. 75) New 'processing' description: New proposal from Tom Hastings to be added with some additional clarification. 76) Show partitioning of state reasons with states -- No 77) see #76. 78) printer-up-time mandatory - yes 79) Proposal to fold the security document into the model document - Scott will merge the documents and the result reviewed by the working group. We will state that an IPP printer must support all required authentication security specified in HTTP/1.1 (change in protocol document). (Carl- Uno reported that TLS will probably become a proposed standard in the next few weeks.) After some discussion, the group came around to the fact that in order to read what security means are supported, you must already have made a connection to the printer because the security mechanisms are at the HTTP level or below and not at the IPP level. The group did not want to include a mandate for TLS or TLS framing as a part of IPP. The attribute "security- mechanism-supported" is removed. We will add an attribute "printer-tls-uri" which will have the uri for accessing the printer in a TLS secure mode. If a server does any security, it SHALL support TLS. If additional security means are provided, we must add additional attributes. Randy Turner will investigate and report on the interoperability between SSL and TLS. The security document mentions that the IPP printer must be aware that a virus could be contained in the print job. How that is to be prevented is not addressed by IPP. The document should make this clear. 80) server-error-device-error: This error would only be returned if the device error prevents the create from happening. For example, if a printer doesn't spool and has a limited buffer and the create can't happen because of a device error (e.g. paper jam) then this error would be returned. In the case of an IPP Printer with spooling, this error would not be returned. 81) langAuto -- covered in #41. 82) Relationship to Printer MIB: If an implementation chooses to have both IPP and the Printer MIB, a specified set of attributes/object shall be identical. Harry Lewis will draft this wording. 83) Relationship to Job MIB: If an implementation chooses to have both IPP and the Job MIB, a specified set of attributes/object shall be identical. Harry Lewis will draft this wording. Lunch break: 11:45 until 1PM 84) Proposal on tags (Attribute, Parameter, Data) in the protocol now that Parameters are gone. -- After discussion, we felt it was cleaner to have separate tags to divide up the various sections of attributes: - Operation Attribute Tag - Printer Attribute Tag - Job Attribute Tag - Unsupported Job Attribute Tag - Data Tag By having separate printer-attribute and job-attribute tag we can add a document-attribute tag or something else later. This strategy will make parsing easier. Any Data-Tag would be last; any Operational-Tag would be first. Each operation will explicitly list the order of the tags. Scott will document this approach and include explanation of why various attributes are in each category. More issues from Tom Hastings iss-903a.doc file. Starting with issues 34. TH34) Finishing and orientation: Will be covered by Steve Zilles in his orientation, n-up, etc. document. TH34a1) See RFC2046 TH34a2) Not applicable TH35) user-human-language -- already covered in #13 TH36) job-id: will be positive number TH37) user-human-language -- already covered in #13 TH38) job-state -- leave as type 1 TH39) time-x-x change from milliseconds to seconds - yes, already decided TH40) number-of-intervening-jobs: align with JOB MIB - yes TH41) We will align k-octets, impressions and sheets with the Job MIB. TH42) Change the name of printer-description to printer-info as decided in #29 above. TH43) Copy some language from printer-driver-installer to printer-make-and-model & others: Yes TH44) Add text to indicate there should be an error reason when the printer is "stopped." TH45) Scott will add text to the document. TH46) We have previously agreed not to align with the JOB MIB in the area of defining what an active job is. See #5. TH47) printer-human-language: Already decided in #13 TH48) Color: Already decided as #30 TH49) Internationalization: already decided in #13 TH50) Indicate that supported values might require human (i.e. operator) action. An example of this should be included in the completed description. -- OK TH51) Add a suffix to some attributes (-supported) to make it clear whether an attribute is default or supported -- OK When we add this suffix, the base attribute name will not be changed for grammatical reasons. SECURITY There are reserved port numbers for TLS & SSL on HTTP (port 443) TLS is backwards compatible with SSL3. Actually TLS is SSL3.1 The TLS I-D describes how to support SSL3 interoperability. The group then discussed wording choices for stating the security protocol requirements (SSL3, TLS, etc.) There were four wording alternatives explored: 1) IPP Client/Servers must implement TLS with SSL3 compatibility 2) IPP Client/Servers shall be interoperable with a TLS communicant 3) IPP Client/Servers must be TLS compliant. 4) #2 above plus "with SSL3 backward compatibility" Decision: #1 with some section talking about a transition to TLS. PAGE FORMATING (N-UP, ORIENTATION, Etc.) Steve Zilles presented material on this subject. Steve will detail this more and post to the mailing list. Because all the interactions with finishing will not be defined for V1, the following enums for finishing were removed: 5,6,7,8,9,10. These values could be added back in for V2 when more work has been done to define them. The values for punch, cover and bind will be moved up. While some languages bind on the right and others bind on the left, we will leave this as site specific. Bind-left and bind-right could be added later. MEDIA TYPES Registration of printer datastreams -- Harald A. believes that the only way to make sure it gets done is to do it ourselves. Alternatives for registration: 1) application/print.xxx (application/print.ipds) 2) application/vnd.xxx (application/vnd.ppds) 3) application/vnd.company.xxx (application/vnd.adobe.printgear) 4) application/xxx (application/postscript) Anything that this group registers could include versions and level but it is unclear if level and version could be added to something that is already registered. The group unanimously believed that it must do the registration and would try to do #1 above with #2 as a fall-back. MODEL Add a new type called "range-of-int" that would be 8 bytes, 4 bytes for the low end and 4 bytes for the high end of the range. -- YES, this would clearly differentiate range from setof. We can now remove range-of-x since integer is the only one we use. SZ1) "Instance of a Printer", "Printer Object", "IPP Printer" and "Instance of Printer Object" are all used to mean the same thing. We should use only one -- "Printer Object" - once the model document has introduced the concept of an object. SZ2) 3.2.1 needs more clarification in the area of Validate- Job: Scott will clarify this text. SZ3) When is Job-name generated: The name is generated before the response on the create is returned. SZ4) "snapshot" for all job status attribute is taken at the same time. SZ5) How unsupported attributes are returned needs some clarifications. Scott and Steve Zilles will work out this wording. SZ6) Section 3.3.4.1 change "_names (without values) or attribute groups_" to and/or. SZ7) Section 4.2 - Interaction of defaults with other values -- no simple solution -- ignore for now. Default should be described as the most likely value. For example is the default is 2-sided but the media selected is transparency then 2-sided does not apply. SZ8) Section 4.2.17 - clarification is needed that only the document data is compressed. SCHEDULE Carl-Uno reviewed the schedule -- There are now only two standards tracks documents -- "Model" and "Protocol." Informational documents -- "Requirements," "Rationale" and "LPR Mapping" When all these documents are published, Carl-Uno will issue a last call for the working group. These comments get reflected into the documents. The documents are then sent to the IESG for a last call to the area directors. Once they are turned over to the Area Directors much of the control is removed from the hands of the working group. After the documents have been turned over to the IETF, the PWG group can continue to work on: 1) Interoperability testing 2) V2 requirements 3) Prototyping 4) etc. The meeting adjourned at 5:20 PM. 14