Subj: Minutes of IPP Telecon, Oct 7, 1998 From: Tom Hastings Date: 10/9/1998 File: ipp-telecon-981007.doc Attendees: Hugo Parra, Pete Zehler, Ira McDonald, Ron Bergman, Bob Herriot, Carl Kugler, Harry Lewis, Tom Hastings 1 Interoperability Test and Test Suites Peter is still collecting results of the September bake-off. Participants are expected to fill in section 4 of the Interoperability Test document (IPP-Test-Plan-980916.doc) with the results of their tests with TS1, TS2 and TS3 test suites. Peter has sent out reminders to those participants who did not post their results at the bakeoff. Peter will take all the results and produce a single Section 5 to show the coverage of the interoperability tests. If two clients and two IPP Printers successfully interoperated on an operation or attribute, Peter will mark it in the combined Section 5. During the bake-off, most of the bugs in the scripts were fixed. However, participants are not expected to re-run their tests with the final scripts from the bakeoff. However, participants and others are encouraged to use scripts that were improved during the bake-off as bugs in the scripts were reported. The final Xerox scripts from the bake-off were posted in: ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/Test_Scripts/Xerox/Xerox_Bake_Off/ -rw-rw-r-- 1 pwg staff 5503 Sep 30 01:12 BO21-22.test -rw-rw-r-- 1 pwg staff 23287 Sep 30 01:13 BO214.test -rw-rw-r-- 1 pwg staff 2660 Sep 30 01:13 BO23.test -rw-rw-r-- 1 pwg staff 29107 Sep 30 01:13 BO24.test -rw-rw-r-- 1 pwg staff 31205 Sep 30 01:13 BO25.test -rw-rw-r-- 1 pwg staff 58385 Sep 30 01:13 BO26-27.test -rw-rw-r-- 1 pwg staff 10699 Sep 30 01:14 BO28.test -rw-rw-r-- 1 pwg staff 29747 Sep 30 01:14 BO29.test -rw-rw-r-- 1 pwg staff 9603 Sep 30 01:14 MyPrinterDefs.test -rw-rw-r-- 1 pwg staff 14357 Sep 30 01:14 StdDefs.test Over the next few weeks, additional Xerox scripts that were in the test plan, but not provided, will be produced that implementers can use to further test their implementations and to further test the clarity of the specifications. Any problems in these scripts should be reported to the ipp@pwg.org and xerox-ipp-tools@cp10.es.xerox.com with TES at the beginning of the Subject line. Any problems in the specifications should be sent to just ipp@pwg.org with MOD or PRO at the beginning of the Subject line as usual. Swen responded to the problem of running the Xerox test suite of how to get just the unexpected results, rather than the full script output. To get less output, run the program "by hand" and omit the "-report" switch (this is equivalent to saying "-report summary"). In the output, you will see any mismatches, plus script annotations (lines in the script beggining with "@"). To be even more terse, you can get rid of the annotations by specifying "-report mismatches". We re-confirmed that the next bake-off will be in February 1999. 2 Review of Clarification Issues We decided to lengthen the review of the proposed resolutions to the issues to give a full two weeks of review. So we will have three telecons, Oct 7, 14, and 21 and two weeks of discussion on the mailing list Oct 7 through Oct 21. 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 of: ftp://ftp.pwg.org/pub/pwg/ipp/proposed-clarifications/ipp-issues-list- mod-1.3.pdf I will edit those proposed text clarifications into the IPP Model and Semantics specification starting Oct 21, 1998. 2.1 Issue 1.10 - Case sensitivness in URLs We agreed that the Model document sentence in Section 4.1.5 'uri': The URI and URL standards allow for mixed-case values that are case-sensitive. needed to be changed to not re-specify anything about the case of URL, but to refer to the new RFC 2396 "Uniform Resource Identifiers (URI): Generic Syntax" which is now an IETF Proposed Standard (which REQUIRES that the scheme and host name be case-insensitive, but that the path and parameters MAY be case-sensitive). Harry Lewis took an action item to propose a statement for the IIG which is: IPP client and server implementations must be aware of the diverse uppercase/lowercase nature of URLs. [RFC 2396] defines URL schemes and Host names as case insensitive but reminds us that the rest of the URL may well demonstrate case sensitivity. When creating URL's, where the choice is completely arbitrary, it is probably best to select lower case. However, this cannot be guaranteed and implementations MUST NOT rely on any specific case type in the URL beyond the URL scheme and host name. Any additional discussion on this statement that is agreed to will be included in the IIG. 2.2 1.33 Equality between different syntaxes? Reviewing the proposed Answer section of Issue 1.33 in the Issue list, V1.3, we agreed: 1. change the case-insensitive matching rules for attributes with the 'name' attribute syntax from SHOULD to MUST, since such attributes are completely within the province of IPP, and are not the subject of other standards and are not handled by any off-the-shelf code conforming to other standards. 2. Since there are currently no 'text' matching attributes specified in MOD, that MOD would be silent on any rules for matching 'text' attributes. So the proposed resolution to Issue 1.33 only applies to the 'name' attribute syntax. 3. to remove any statement about any other equivalencies, such as accent insensitiveness or other character equivalencies, such as Unicode composed accented letters versus composite accented letters. 4. change from MAY to SHOULD that a language without a country matches a language with a country. The editors of MOD (Tom Hastings) and PRO (Bob Herriot) will propose new text for any issues for which there is discussion to the mailing list before incorporating it into the Issue list document. This will reduce the number of versions of the Issues document.