Attendees: Hugo Parra, Ira McDonald, Peter Zehler, Bob Herriot, Tom
Hastings, Harry Lewis
1. Editor's summary of the state of the IPP/1.1 I-Ds
The editors gave an editor's view of the IPP/1.1 Model and Semantics and
IPP/1.1 Encoding and Protocol Internet-Drafts that have just been published.
The Issues are high lighted as "Issue nn" next to each piece of text that
changed from the February 1999 I-Ds. These will be removed after the WG
Last Call completes.
2. Adding IPP channel enum to the Printer MIB
We discussed adding IPP as a new Job Submission Channel 'chIPP' enum in the
draft Printer MIB. The group agreed that we should add it before the draft
Printer MIB is published. We agreed to the following keywords that are
needed in order for a job submission client to be able to set up a channel:
URI MANDATORY
Client Authentication OPTIONAL, default 'none'
Security OPTIONAL, default 'none'
Version OPTIONAL, default '1.0'
ACTION ITEM (Ira McDonald): Write up a complete proposal.
3. Notification
Tom and Harry are still working on updating the proposal for the
Philadelphia meeting. Anyone send any comments to the DL on the issues
raised in the current two documents or any other comments:
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-990121.docftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-990121.pdfftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-printer-980701.docftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notification-printer-980701.pdf
4. Larry Masinter's mail:
a. Need "job-recipient-name(name)" when different from the submitting user.
ACTION ITEM (Tom Hastings): propose such a single valued attribute for
inclusion in IPP/1.1.
b. Need better document-format negotiation. E.g., PostScript level 1, 2, or
3, or various TIFF features. We agreed that these IPP extensions should be
done as part of the QUALDOCS project, not added to IPP/1.1.
c. Need a REQUIRED document-format for interoperability. QUALDOCS has
agreed on TIFF for that. So QUALDOCS will have additional features and
requirements over IPP/1.1.
5. Issue 17: dateTime vs. integer (re-opened)
There has been concern expressed that the current resolution of Issue 17
which added 'dateTime' attribute syntax to the 3 REQUIRED job description
attributes to give:
time-at-creation(integer | dateTime)
time-at-processing(integer | dateTime)
time-at-completed(integer | dateTime)
has some problems. A Printer can't return both forms. A client can't
indicate which form it wants (except to request '1.0' which is the only
behavior that is conditioned to the version-number in the request.
Instead of adding 'dateTime' to the three existing IPP/1.0 attributes, add 3
new RECOMMENDED attributes:
date-time-at-creation(dateTime)
date-time-at-processing(dateTime)
date-time-at-completed(dateTime)
Also make "printer-current-time(dateTime)" RECOMMENDED. REQUIRE these 3
attributes, if "printer-current-time" is supported.
We came up with two alternatives about what to do about the three existing
"time-at-xxx(integer)" attribute and request the DL to comment:
1. Make the 3 "time-at-xxx(integer)" REQUIRED
2. REQUIRE either or both of the 3 "time-at-xxx(integer)" or the 3
"date-time-at-xxx(dateTime)"
Alternative 1 is easier to document, but requires the time tick approach.
Alternative 2 is harder to document, but heads implementations toward
dateTime while not requiring it.
ACTION ITEM (Tom Hastings): Send out the two alternatives to the DL.
6. The Implementer's Guide for IPP/1.1 and IPP/1.0
The Implementer's Guide for IPP/1.0 as already been submitted to the IESG.
We agreed that we don't need to add any discussion to the IIG for IPP/1.0
that has been clarified in the IPP/1.1 Model and Semantics document.
ACTION ITEM (Carl-Uno): Find out why it wasn't published with the other
IPP/1.0 RFCs as Informational, since there doesn't need to be anything more
added to it.
For IPP/1.1, we finally agreed that the Implementer's Guide should contain
the supplemental information agreed to as part of the resolutions to the
BakeOff2 Issues. See:
ftp://ftp.pwg.org/pub/pwg/ipp/Issues/Issues-raised-at-Bake-Off2-990510.docftp://ftp.pwg.org/pub/pwg/ipp/Issues/issues-raised-at-bake-off2-990510.pdf
The IPP/1.1 Implementer's Guide needs some discussion for client and
Printers that want to support IPP/1.0 as well as IPP/1.1 for
interoperability. But the IPP/1.1 IIG does not need to explain things that
were not clear in IPP/1.0. The implementer of IPP/1.0 should look in the
IPP/1.1 Model and Semantics for any clarifications that might be useful.
7. Allowing delta time and dateTime to be supplied in the "job-hold-until"
Several comments on the DL and previous meetings have indicated that the
"job-hold-until" should allow the client to supply a delta time or a
dateTime. The "job-hold-until-supported" can indicate the maximum delta
time and the "job-hold-until-default" could contain a delta time.
There was debate as to whether the delta time should be using the current
'integer' or a new attribute syntax (and new attribute syntax code). And if
a new attribute syntax, should it be an integer or an ISO 8601 type of data
type with fields for years, months, days, hours, minutes, and seconds?
ACTION ITEM (Tom Hastings): Send out a proposal to the DL