Internet Printing Project Meeting Minutes December 3, 1997 Los Angeles, CA The meeting started on December 3, 1997 at 8: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 - Philip Thambidurai - Okidata - Bob Pentecost - HP - Don Wright - Lexmark - Keith Carter - IBM - Steve Zilles - Adobe - Roger deBry - IBM - Tom Hastings - Xerox - Scott Isaacson - Novell - Carl-Uno Manros - Xerox - Dave Kellerman - NorthLake - Stuart Rowley - Kyocera - Bill Wagner - DPI/Osicom - Bob Herriot - Sun - Chuck Adams - Tektronix - Henrik Holst - I-Data - Frank Zhao - Panasonic - Yuji Susalai - Japan Computer Industry - Atsushi Uchino - Seiko-Epson - Rick Yardumian - Xerox - Xavier Riley - Xerox - Gary Roberts - Ricoh - Dale Wick - TrueSpectra - Mike Moldovan - Genoa Technology - Gary James - Genoa Technology - Jun Fujisawa - Canon - Harry Lewis - IBM - Kevin Osborn - Sun (JavaSoft) Carl-Uno Manros reviewed the agenda for the day and dealt with the administrivia of the meeting. ISSUES ------ Scott Isaacson started off the meeting by going through the issues list which is posted on the server as ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp- issues.pdf M01) Versioning rules for major/minor revisions - resolved per the suggested changes in "ipp-section-15-3-norev.doc" (posted on the server.) Private extensions do not cause the major/minor versions to change. Only changes to the documents (protocol and model) cause a change to the versions. Implementations shall accept all request with the same major version and any minor version. Fidelity will control the behavior should unknown attribute or operations be encountered from a different minor version. -- Add statements in the versioning section * Not reassign objects between versions * Each major version will state what prior versions are to be supported M02) Issues concerning groups in operations: - What should a printer do if an operation contains an unexpected group? ** see proposed new 15.3.3.1 - What should a printer do if the correct groups are present but in the wrong order? ** see proposed new 15.3.3.1 - If Get-Attributes is returning no job/printer attributes, what does it return? ** Clients should send the group tag even if there are no attributes. The general philosophy should be to be conservative in what is sent and liberal in what is accepted. Overall for groups and attributes, group tags may be included with no attributes or the group tags can be omitted. Therefore receivers of data shall accept both. M03) Return not supported operation attributes in Get-Attributes operation. ** Not an issue because all the operation attributes are mandatory but allow for the group to show no support for extensions M04) Moving job-k-octets, job-impressions, compression and job-media-sheets to become optional operations attributes? ** These operation attributes get mapped into job description attributes. Now all job-template attributes are affected by fidelity. Section 3.1.1 of the model document needs to be updated to reflect these changes. M05) Keep document-format as operation attribute ** Yes M06) See issues M04 M07) Upper bounds ** See "ipp-min-max" on the server. Generally, attributes will be sized by type but on an attribute by attribute basis, special cases will be dealt with. M08) Granularity of error messages? This has been addressed in the latest version. M09) Semantics of unsupported and supported. This has been addressed in the latest version. M10) Statement that validation is attribute specific. This has been generally fixed in the latest version. M11) Add semantics to section 3.1.5.2 about requesting-user-name operation attribute. ** Bob Herriot will write up some clarifying language for this section. Remove the requirement for creating a unique name if one is not provided. The name does not have to be unique. M12) Add (1:MAX) to limit in section 3.2.6.1 of the model. ** OK M13) We will remove "copies-collated-*" M14) Change SHOULD to SHALL in section 4.1.9 ** Both SHOULDs need to be changed to SHALLs in this section. M15) Why is "attributes-natural-languages" special? ** When a client submits something and specifies the language it is used as a "post-it". We will change the following: natural-language -> generated-natural-language-default natural-language-supported -> generated-natural-language-supported We will add the -default to "charset" and "document-format" M16) Semantics of multiple-document-handling (section 4.2.4) ** Not resolved for Version 1. M17) Semantics of Page-ranges attribute (section 4.2.7) Change to specify non- overlapping ranges provided in ascending order. M18) Fixed in "ipp-section-15-3-norev.doc" M19) No M20) Conformance Language for natural-language ** Optional for object to support M21) Conformance Language for media-ready ** Optional M22) What status code is returned when printer is "accepting jobs" is false? ** Add an error code "server error - not accepting jobs" will be added/ M23) Semantics of server-error-version-not-supported need clarification ** See changes suggested in "ipp-model-last-call-comments-th.doc" M24) Semantic changes needed in 15.3 ** See "ipp-section-15-3-norev.doc" The series of checks provided in this new section are semantic examples and not conformance requirements. Some implementations may be softer and allow some non-conforming operations/attribute. Some of the semantics and interactions contained in the section are important but are not found elsewhere. M25) Occurrences of HTTP in Model document ** The references to HTTP will be removed from the MODEL document. M26) Internationalization clarifications ** Section 7: add classification of various text attributes and their source and interaction of language and charset with them. ** Revisited M15 and change to natural-language-configured. Scott will take a work item to clarify this. M27) Align our syntax descriptions with ** Carl-Uno Manros and Steve Zilles will explore this with our area directors. P01) Do we want to define and mandate a client-specified transaction ID. ** Yes, it will follow the version number in the protocol, it will be mandatory and will be 4 bytes and the range 0 -> (2^31)-1 P02) Does text on the Network Byte Order (protocol, sect 3) need improvement? ** Bob Herriot will fix. P03) We need a better description of how HTTP chunking is done by IPP. ** Bob Herriot will add some text about this and reference the HTTP/1.1 document as a reference for people implementing both IPP and HTTP. ** Some additional areas needing clarification were identified and will be written up by several people and added to the protocol document as "hints" or "implications of IPP over HTTP" P04) Do we need to refine CompoundValue? ** We have removed CV and replaced it with two new tags called "localized-text" and "localized-name" This will be written up in the next version of the document. I02) Revise definition of Application/IPP so it can be run over other transports. **This will be fixed in the documents. P05) OK P06) A long discussion ensued over the idea of using a special marker to indicate the end of the header and also indicating that there is or isn't more data. ** Resolution: Rename the "data" tag to be called the "end-of-header", "end-of-attributes" or "end-of-parsing" tag that indicates the end of the IPP header. GENOA ----- A presentation was made by Gary James from Genoa Technology about what Genoa is doing testing protocols. A discussion followed about how Genoa would do an IPP test suite. Genoa has looked at the IPP protocol and they are in the process of making a business decision to prioritize the various other projects they are investigating. They currently plan to do an IPP test suite and are trying to decide when to do it. They expect a decision by early '98. ADOBE ----- Steve Zilles made a presentation on some work on Job Tickets that is being done by Adobe. Version 1.0 of the Job Ticket specification was completed on October 6th. The document is available on the Adobe Web site in the developer's area in the tech notes area as tech note #5620. ISSUES ------ P07) Wording has been changed. P08) Remove the issue statement from the section. P09) Bob Herriot will add some additional examples in this section. P10) When does the IPP server rejects an operation? ** Randy has an action item to write up. The suggested tests listed in the new 15.3 section says not to quite checking early, i.e. when the first error is found. P11) OK, Bob will incorporate new wording into the protocol document based upon wording from Carl-Uno. P12) Port numbers for IPP? ** Carl-Uno will request an IPP and an IPP/TLS port. S01) Accept Randy Turner's text S02) Accept Randy Turner's text S03) Make "digest authentication" optional ** Yes, IPP will defer to the HTTP/1.1 security requirements. S04) Security terminology ** Leave the wording as is. S05) Move security to earlier in the document. ** According to the IETF, Section 8 is suppose to be the security section. We will add a forward reference earlier in the document pointing to sect. 8. D01) Alignment of IPP with Service Location Protocol Printer Scheme. ** Scott Isaacson will coordinate with the SRVLOC people. I01) Parameters for application/octet-stream MIME type. ** Application/octet-stream does not support CHARSET, OK -- no action. I03) Register document formats as MIME media types ** Action item for Tom Hastings to post a list of what will be registered and what will not to the mailing list. He will provided a deadline for comments back to him. I04) Register application/ipp with IANA ** Action item for Carl-Uno to do this after Ira MacDonald posts the text to the mailing list. Scott Isaacson reviewed the changes made at the Boulder meeting that were reflected into the "last call" document. The following caused additional discussion and/or decisions: 1) We will remove the "0" value of number-up and be silent on the embellishment issue relating to number up. 2) A discussion was held about issue of time. We decided to leave the time attributes as currently defined. DOCUMENTS --------- After the IETF meeting in Washington DC, we will send the resultant documents to the mailing list first and everyone should do a quick review before sending we send them to the IESG as the last call document. We expect to do this before the end of the year. The Rationale and Mapping documents may need some updates based upon today's work before going out to the IESG for last call. The Requirements document will go as is to the IESG for last call. The meeting was adjourned at 5:30 PM PST.