Internet Printing Project October 29-30, 1997 IPP Working Group Meeting Minutes October 29-30, 1997 Boulder, Colorado The meeting started on October 29 at 8:30 AM. The attendees were: Ron Bergman - Dataproducts Corp. Dennis Carney - IBM Lee Farrell - Canon Information Systems Steve Gebert - IBM Jeff Haemer - QMS Tom Hastings - Xerox Corp. Bob Herriot - Sun Microsystems Scott Isaacson - Novell David Kellerman - Northlake Software Carl Kugler - IBM Harry Lewis - IBM Carl-Uno Manros, Xerox, Corp. Jay Martin - Underscore Pat Nogay - IBM Jerry Podojil - Genicom Stuart Rowley, Kyocera Yuji Sasaki, JCI Ron Sherer - Peerless Randy Turner - Sharp Atsushi Uchino - Epson Dale Wick, True Spectra Atsushi Yuki - Kyocera Lloyd Young - Lexmark Peter Zehler, Xerox, Corp. 1. Agenda 1) What is needed to make the Model and Protocol documents eady to initiate the WG last call from and that priority ONE is to make sure we get any remaining comments reviewed, so that we can get the "final" draft version of the documents out and start the last call some time next week. Other subjects, which we decided to leave out from Version 1.0 or other left overs are: 2) The Mapping document to LPD/LPR 3) Asynchronous Notifications 4) Document level attributes 5) Dictionary Syntax 6) IPP use of TLS (when that spec gets frozen) 7) IPP prototyping/interoperability testing 1 Internet Printing Project October 29-30, 1997 2. Model and Semantics Document Issues The following issues were identified and the indicated resolutions were agreed to. Scott will include them in the next version of the Model and Semantics document for review by the DL. 2.1 Adding new Operation attributes in the future? It was agreed that adding new Operation attributes would require that the major version number be incremented. So a Printer object SHALL reject requests that contain Operation attributes that are not supported, independent of the setting of the "ipp-fidelity" attribute. Thses requirements will help with interoperability. NOTE: Job Template attributes that a Printer object does not support SHALL be ignored when the "ipp-fidelity" attribute is 'false', so most of the registered and private extensions will be in the Job Template attributes group, not the Operation Attribute group. 1.2 Remove "document-charset" Operation attribute? We don't need this attribute for PostScript™. PCL drivers embed an escape sequence to indicate the charset of the document, so we don't need this attribute for PCL. We agreed that any media type that needed a charset specification should indicate it in the media registration specification. Even 'application/octet-stream' for PDL sniffing does not need a charset; the Printer object will assume the printer's default charset, if the document doesn't have an embedded indication of charset. 1.3 Get-Attributes requesting an unsupported attribute - error or ignore? We decided that the Printer object SHALL ignore any requests for unsupported attributes and return no indication of such an occurrence. The client looks at the attributes that are returned which are only the supported attributes. 1.4 How to return supported attributes whose values are not yet known? We decided that to use an out-of-band coding for all attribute syntaxes, including enums and integers. So, unlike the Printer and Job Monitoring MIBs, the -2 value will NOT be used for integers and the +2 will not be used for enums to indicate a value that is not yet known to the Printer object. Mapping from the MIB representation to the IPP representation of unknown is straightforward for implemenations that support both IPP and the Printer or Job Monitoring MIBs. 2 Internet Printing Project October 29-30, 1997 1.5 The term "imposed page" vs. "impression" We agreed that we didn't need the new term "imposed page" because "impression" is the same. 1.6 Should the Model require conformance to the Protocol? We agreed to remove the statement in the Model document that an implementation MUST also conform to the Protocol document. Retaining the statement would preclude ever having a different protocol document. The protocol document already requires conformance to it. 1.7 When "ipp-attribute-fidelity" = 'false' MAY an IPP object reject a request? We agreed that when "ipp-attribute-fidelity" is 'false', that the IPP object MUST try its best to perform the create operation and SHALL not reject the create job operation. 1.8 Should IPP attributes include ISO 10646 level 3? Since the IPP protocol does not require any attribute matching, the difficulty that level 3 introduces of multiple ways to encode the same (accented) letters is not a problem. So we agreed to remove the restriction that utf-8 'text' and 'name' attributes had to be ISO 10646 level 2 or less. [Editor's note: but the Cancel-Job operation does require the IPP object to make sure that user requesting the operation is the same as the one that submitted the job, so that there is a comparison of user names that could include accented letters that use level 3 encoding with non-spacing accents. Also if the security policy is that users can only get attributes for their own jobs, then the IPP object will also be doing compares for Get-Attributes and Get-Jobs operations on user names submitted with the request to those stored with the job.] 1.9 Natural-language override: differs between Model and Protocol We agreed to use the mechanism in the Protocol document with the CompoundValue tag that indicates the number of following attribute values that are taken together, rather than just have two values, 'naturalLanguage' followed by 'text' or 'name'. The CompoundValue is more general and less ad hoc. It could be used for other purposes in the future. In the case of the natural-language override, the value of the CompoundValues value SHALL be as '2', immediately followed by the natural-language value followed by the 'text' or 'name' value. A CompoundValue is then treated as if it were a single value. The Model document will say nothing about the representation of the natural-language override or the concept of 3 Internet Printing Project October 29-30, 1997 CompoundValue. The protocol document will introduce the concept of CompoundValue. 1.10 Are Operation attributes MANDATORY? We re-affirmed that all operation attributes are MANDATORY for the Printer object to accept and support in requests and for the client to accept in responses. 1.11 Do we need both "printer-uri' and "print-tls-uri"? We agreed that there should be only one uri for a Printer object. So delete the "printer-tls-uri attribute from both the Printer object and the directory schema. If the one URI has a scheme that requires security, then that is sufficient. The "printer-uri" attribute will remain single- valued in both the Printer object and the directory entry. 1.12 What security is MANDATORY in IPP/1.0? We agreed that clients MUST issue and Printer objects MUST accept TLS with at least SSL3 framing. The client and the Printer object MAY then negotiate down to null (no-auth). But a client SHALL NOT start out without TLS and a Printer SHALL NOT accept non-TLS. It is expected that when TLS is finished, that it will have SSL3 compatibility, since so much SSL3 is deployed today. 1.13 Do we need "security-schemes-supported"? We agreed to delete security schemes supported, since now the Protocol document will MANDATE that the HTTPS: scheme be used for IPP. ACTION ITEM (Randy, Carl-Uno): work on an Appendix or implementation notes that could be a separate information RFC on how the security negotiation works. 1.14 Should the Protocol recommend a port to use when not using the default port for the scheme in use? The default port for HTTP: is 80. The default port for HTTPS: is some other value which becomes the default port for IPP. The Protocol document will mention this default port. If an alternate is wanted for IPP, the Protocol document will recommend a particular (different) port that will have to be explicit in the URI. There is a problem in UNIX in that an explicit port number (below) 1024 can be used only if the client is logged in as root. No fix for this problem was forth coming. ACTION ITEM (Carl-Uno): Apply for this alternate port for IPP. 4 Internet Printing Project October 29-30, 1997 1.15 Remove reference to Send-URI in Validate-Job Section 3.2.3: Remove the reference to Send-URI in Validate-Job. 1.16 MUST return all unsupported attributes, not just the first one Section 3.2.1.2: We agreed that the Printer object MUST return all unsupported attributes and attribute values in the create operation response, not just the first unsupported attribute or value. Implementations have found that it isn't more difficult to return all and returning all will mean that the client can fix up all problems and try again. 1.17 Remove vendor extension for per-document attributes Section 3.2.1.1: Remove the mention of vendor extension for per-document attributes. We need to work together on this extension in order to keep interoperability. 1.18 Auto-sensing is best-efforts Section 4.1.9: Add a note that application/octet-stream auto-sensing is not absolutely guaranteed, but customers love it none-the-less. 3. Comments on the Protocol document The following agreements were reached on the Protocol document. Bob will include them in the next version of the Protocol document for review by the DL. 3.1 Remove the redundant attribute syntax descriptions The Protocol document will only explain the representation of each attribute syntax, not the semantics. The model will describe only the semantics. 4. Other Documents The following additional documents will be produced and the indicated actions taken: 4.1 LPD Mapping to IPP document Bob Herriot says that the LPD Mapping document is finished. The last July Internet-Draft is the final version. It will become an informational RFC. ACTION ITEM (Carl-Uno): Announce it for a two week WG last call immediately. 4.2 The Rationale document The Rationale document is being updated by Steve Zilles. It will become an informational RFC. It is desirable for it to be available when the Model and Protocol documents are. 5 Internet Printing Project October 29-30, 1997 ACTION ITEM (Steve Zilles): Send the final Internet-Draft to the IETF Secretariat and announce a two week WG last call when the Secretariat announces the I-D. 4.3 The Requirements document Don Wright has finished the requirements document. It will be an informational RFC. ACTION ITEM (Carl-Uno): Announce it for a two week WG last call. 5. Asynchronous Event Notification After much discussion back and forth we agreed that the WG needs to work on a program parsable representation for asynchronous events after forwarding IPP/1.0 Model and Protocol documents to the IESG. The IPP WG charter includes such. We removed the asynchronous event notification from IPP/1.0 document because we only had a simple text representation that programs might try to parse. The experience with PostScript error messages being only text made us realize that leaving in only text messages would cause the same problems all over again. One approach would be to define a multi-part/alternative media type that contains a program parsable alternative and an text/plain alternative. The recipient chooses which alternative to use. Such a media type could be sent using a mailto: scheme. The second problem with asynchronous event notification is the transport of the event messages. The Simple Event Notification System Environment (SENSE) is a candidate. Jay Martin presented its concepts to the group. It has been implemented and deployed in printing applications over the last two years. It seems general enough for IPP needs. It is also very portable. The specifications are on the PWG FTP server under: ftp://ftp.pwg.org/pub/pwg/SENSE/ In order to be used with IPP, a specification of the SENSE properties to be used in a publication and an edition needs to be written and agreed to for use with IPP. Otherwise, interoperability between one vendors subscribers and another vendors publishers is not possible. See separate minutes produced by Jay to the SENSE DL. The IPP WG can produce another RFC which augments the current IPP Model and Protocol documents, just as MIME has done. We need to specify this as soon as possible, least implementers invent their own representations and transports and the opportunity for interoperability is lost. This topic will be on both the next IPP WG agenda and the IETF IPP agenda. 6 Internet Printing Project October 29-30, 1997 6. Interoperability Testing Randy Turner and Peter Zehler indicated that they were close to trying pair-wise interoperability testing over the Internet. Peter is installing a prototype outside the Xerox firewall. Randy indicated that he has the same capability. Others are encouraged to participate. From the experience with the Printer MIB interoperability/bake-off, we agreed that we need to develop a specification of a set of operation requests, including the attribute values supplied and the expected attribute and status code responses. Error conditions need to be included. This specification was called a set of scenarios and needs to be executable. 7. Next IPP WG meeting, 12/3/97, Los Angeles The next IPP WG meeting will be Wednesday, in Los Angeles. Reservations need to be make by 11/7/97 to get the low rate. Else the rate doubles. We will probably only need one day, which will be Wednesday. 8. Next IETF meeting, week of 12/8/97, Washington DC Carl-Uno has requested a two hour slot. We may only need one hour. We agreed that it was important to have the slot. We can reduce the time near the end of November. The meeting adjourned at 5:30 PM. 7