I've down loaded the IPPFAX protocol spec version 0.8 for the Friday
December 14 telecon. This version has the agreements reached at the IPPFAX
WG meeting in San Antonio, October 24. See the minutes. The version
without revisions is 56 pages (one longer than the previous version). The
files are:
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-08-rev.pdf
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-08-rev.doc
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-08.pdf
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-08.doc
The telecon details are:
Friday, December 14, 9-11 AM PDT (12-2 PM EDT)
Phone: 1(712) 884-1555, (Xerox folks: 8*596-5170), passcode: 654970
The agenda for the telecon will be:
1. The 5 issues embedded in the document (excerpted below).
2. Also the minutes of the IPP WG meeting indicate that we didn't finish the
security section.
3. Review each of the tables which have conformance requirements for each
attribute and operation. Certain entries that need special attention are
highlighted (yellow on the screen and color printers, gray on black and
white printers).
4. Any issues that attendees raise or have been raised on the mailing list.
You should all read the entire document, since I think it is pretty close to
finished, except for any issues that your careful review would raise.
Please send any comments to the DL before the telecon, especially, if you
cannot make the telecon.
The 5 issues are:
1a. Page 8, section 1.3 Namespaces Used:
ISSUE 01: Why can't all of the "ippfax-xxx" attributes defined in this
document be supported OPTIONALLY by an IPP Printer as IPP extensions to the
IPP Protocol as well? This would allow IPP to support UIF document format
and profiles, along with vCard, and provide a simple way for an anonymous
user mode. If so, shouldn't we remove the "ippfax-" prefix from all these
attributes in this document, since they wouldn't be restricted to IPPFAX?
From the TOC, these attributes are:
4.2 ippfax-uif-profile-requested (type2 keyword) operation
attribute
5.6 ippfax-uif-profiles-supported (1setOf type2 keyword)
Printer Description attribute
5.7 ippfax-uif-profile-capabilities (1setOf text(MAX))
Printer Description attribute
5.8 ippfax-auto-notify (boolean) Printer Description
attribute
6.1 ippfax-sending-user-vcard (text(MAX)) operation/Job
Description attribute
6.2 ippfax-receiving-user-vcard (text(MAX)) operation/Job
Description attribute
6.3 ippfax-sender-uri (uri) operation/Job Description
attribute
7.2.1.2 ippfax-uif-profiles (1setOf type2 keyword) Job
Creation operation attribute
1b. Page 18, section 6.2 ipp-versions-supported:
ISSUE 02: OK that the IPP/1.1 "version-number" parameter that contains the
IPPFAX version number is compared with the (existing) IPP/1.1
"ipp-versions-supported" Printer Description attributes that contains the
IPPFAX version number (rather than defining a new
"ippfax-versions-supported" Printer Description attribute and not using the
"ipp-versions-supported" attribute)?
1c. Page 27, Table 7:
Repeat of ISSUE 01
1d. Page 29, Section 9.2, Job Template Attributes, Table 8:
ISSUE 03: The Sender supply and the Receiver support columns have a lot of
"MUST NOT". Instead of not allowing these attributes at all, how about a
MAY but restricted to the obvious default values, i.e., "number-up"=1,
"job-priority"=50, "insert-sheet"='none', x-image-shift=0, etc. Otherwise,
there is some interworking problems with a client or forwarding Printers
that supports both IPP and IPPFAX and supplies these attributes with their
obvious default values (instead of omitted them).
1e. Page 40, section 11.2 uri-authentication-supported, Table 13:
ISSUE 04: We agreed at the October meeting to make 'none' be "MAY support
and MAY use" for a Receiver. However, a better way to get public access, is
to use IPP with UIF and vCard exchange. See ISSUE 01 which suggests that
IPPFAX attributes be OPTIONAL IPP attributes as well. Then 'none' could go
back to MUST NOT.
1f. Page 42, section 11.4 Using IPPFAX with TLS:
ISSUE 05: OK that we deleted the "ippfax-sending-user-certificate-uri (uri)
operation/Job Description attribute? The client MUST pass the certificate,
whether by value or by reference in the TLS record layer.
1g. Page 42, section 11.5 Access Control:
ISSUE 04 (repeated): Why not use IPP, instead of IPPFAX for anonymous user
access, if we agree to allow all IPPFAX attributes as OPTIONAL extensions to
IPP as well?
Thanks,
Tom
This archive was generated by hypermail 2b29 : Tue Dec 11 2001 - 19:09:12 EST