I've also posted them at:
ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-telecon-981014.doc
ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-telecon-981014.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-telecon-981014.txt
Tom Hastings
(310) 333-6413
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