Subj: Minutes of IPP Telecon, Oct 14, 1998 From: Tom Hastings Date: 10/14/1998 File: ipp-telecon-981014.doc Attendees: Ron Bergman, Maulik Desai, Tom Hastings, Bob Herriot, Swen Johnson, Carl Kugler, Harry Lewis, Ira McDonald, Hugo Parra, Pete Zehler 1 Test Suites Hugo Parra and Bob Herriot reported that there are some problems with the Xerox Test Suite V2 versus V3 with the bo26-27 and bo29 scripts. The V2 version may work better for those scripts than V3. However, V2 doesn't work well for Windows 95, because you can't display output and put it to the log as the same time. ACTION ITEM (Swen): Confir with Hugo and Bob on fixing these problems. 2 Interoperability Test results Peter is nearly 80% complete on compiling the results of the interoperability tests. The p7 printer vendor did not supply Peter with any results. He has sent e-mail several times. The p3, p5, p11, and p15 vendors have not supplied Peter with the summaries requested in the Test Plan. He will produce the results by the end of this week whether he gets the missing data from these vendors or not. 3 IFAX and IPP compatibility Ron Bergman reviewed the results of Richard Shockley's document examining the suitability of using IPP for IFAX. ACTION ITEM (Ron): Request that Don setup a new mailing list on the PWG server for the IFAX and IPP discussion and invite the IFAX folks to join the discussion. The name will be "ifx", following our convention of three letter names for mailing lists. Ron clarified that what IFAX means by re-direction is quite different from what HTTP means by re-direction. For IFAX re-direction means either (1) that the phone number can be included in the URL explicitly, or (2) that a URL can represent a phone number or a set of phone numbers implicitly. In either case the IPP Printer object would dial the appropriate phone numbers to make the connection, after receiving the print job. IFAX needs access to date and time, but that access could be obtained by an IPP Printer object from the network, if the IPP Printer didn't have an internal date and time clock. The requirement for a banner on top is the responsibility of the application that generates the PDL data and is not a feature that requires any change to the IPP spec. One of the attractions of using IPP for IFAX, is that the client can query the IPP Printer for the supported document-formats and other capabilities. With IFAX over e-mail, the sender has to assume TIFF/F. 1 Only if the sender knows that the recipient supports TIFF/FX, can it send TIFF/FX. Supporting query with e-mail is very problematic. ACTION ITEM (Ron): Ffind out more about what IFAX means by "Job Ticket". Richard's document mentions "Job Ticket" and "VCARD" which is virtual (business) card. 4 Simplifying Natural Language Override Support There are two proposals to simplify the Natural Language Override mechanism in the Model and Semantics document: 4.1 Remove the job-level natural language override for Get-Jobs Remove the optimization that allows an IPP object in the Get-Jobs Response to return the "attributes-natural-language" attribute for each job that has a natural language which is different than the natural language being returned for the response as a whole. If the natural language is different for an attribute than the response as a whole, require the IPP object to return the attribute using the 'nameWithLanguage' or 'textWithLanguage' attribute syntaxes that explicitly specifies the natural language. ACTION ITEM (Tom): Send out a request for vote on the mailing list to remove the job-level natural language override for Get-Jobs. 4.2 Remove the entire Natural Language Override mechanism Remove the 'textWithoutLanguage' and 'nameWithoutLanguage' attribute syntaxes altogether. They add complexity to the protocol which may introduce bugs or interoperability problems. They are only optimizations of responses. In fact, they are not very good optimizations, because it requires a response to have more than 5 or 6 text and/or name attribute values (of the same language), before the number of octets is less than if each attribute used the 'textWithLanguage' representation. This is because the "attributes- natural-language" operation attribute requires about 37 octets, and each attribute only requires about 6-9 extra octets per value to represent the natural language explicitly. This simplification does not reduce any functionality. It had been suggested by Keith Moore last May as well. There was considerable support for this proposal. On the other hand, implementations of IPP have been announced, so that we need to get real feedback from the participants on whether to make this simplification. We also need to see whether the complete spec in the Model document for Natural Language Override mechanism was actually implemented or not. ACTION ITEM (Tom): Send out a request for vote on the mailing list to remove the 'textWithoutLanguage' and 'nameWithoutLanguage' attribute syntaxes. 2 5 Review of Issues We reviewed the proposed Answer text in the Issues List posted on Oct 6 in: ftp://ftp.pwg.org/pub/pwg/ipp/proposed-clarifications/ipp-issues-list- mod-1.3.pdf Any issues that have no comments against them at either a telecon or on the mailing list for two weeks will be considered resolved using the explicit text in the Answer section. ACTION ITEM (Tom): Edit those proposed text clarifications into the IPP Model and Semantics specification starting Oct 21, 1998 that have no comments. 5.1 Issue 1.10 - Case sensitivity in URLs There were no comments on the proposed text in the e-mail message from me on Monday, Oct 12, for the model document. For the IIG, we should add a sentence pointing out that HTTP/1.1 contains more descriptions of how to compare URLs. 5.2 Issue 1.24 - Definition of 'successful-attributes-substituted-or- ignored' and unsupported attribute values in Get-Xxxx operations ACTION ITEM (Tom): Propose the text for adding the reason for returning this status code and all status codes for each operation specification in the Model. 5.3 Issue 1.28 - What MUST an IPP object do if Create-Job never gets an Add-Document or Send-Document with 'last-document' set to 'true'? We discussed that we had forgotten that the June Model and Semantics document contains a "multiple-operations-time-out" Printer Description (see section 4.4.28) that allows the IPP Printer to indicate the length of time before it closes down multi-document jobs that haven't had another operation performed on them. We agreed to the following: 1. Clarify that "multiple-operations-time-out" is a "minimum", not a promise to close the job after exactly that much time. 2. We reconfirmed that it is a requirement of the IPP Printer to clean up such jobs, not the client. 3. The "multiple-operations-time-out" attribute is an OPTIONAL attribute, but that an IPP Printer MUST support the "multiple- operations-time-out" Printer Description attribute if it supports the Create-Job and Send-Document operations, i.e., if it supports multi-document jobs. 4. The system administrator can set the "multiple-operations-time-out" attribute to any value. He/she is not restricted to a one to four 3 minute value. Instead, the one to four minute value will be the RECOMMENDED default value for this attribute. ACTION ITEM (Tom): Update the proposed text for Issue 1.28 for another two week review. 5.4 Issues 1.4, 1.10, 1.12, 1.14, 1.24 We reviewed the proposed text for these issues and no comments or objections were raised. ACTION ITEM (all): Carefully review the proposed text in each Answer section of the Issues list by Oct 21, 1998 and send any comments to the mailing list. ACTION ITEM (Tom and Bob): Propose new text for any issues for which there is discussion to the mailing list before incorporating it into the Issues List document. This will reduce the number of versions of the Issues List document. 6 SLP and new "pages-per-minutes" Printer Description attribute Ira McDonald is updating the SLP directory schema for Printers. This schema is intended to cover both IPP and LPD. We agreed that the SLP schema must align with our current documents. However, a directory entry should have some indication of the speed of a printer. So we agreed that we should propose a new "pages-per-minute" Printer Description attribute for registration. Then the SLP spec can reference it. We agreed that the attribute should not attempt to be precise about the performance of the printer. Instead, it should be the "optimal nominal speed for simplex black and white that is used in marketing literature to generally describe the device". ACTION ITEM (Tom): Propose specific text for this OPTIONAL Printer Description attribute. ISSUE: But how can the SLP spec reference an IPP attribute if we can't officially register an attribute until the IPP documents are approved as RFCs. So maybe we should consider adding this attribute to the Model and Semantics document? Or would the SLP spec just not reference the IPP Model and Semantics document for this one directory attribute? 4