I've also posted them at:
Subj: Minutes of IPP Telecon, Oct 7, 1998
From: Tom Hastings
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:
-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 firstname.lastname@example.org and email@example.com with TES at the
beginning of the Subject line. Any problems in the specifications
should be sent to just firstname.lastname@example.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:
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
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
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.