All,
Since Tom's PC is currently being upgraded I am sending this out on his
behalf.
Pete
I've updated "The IPPFAX/1.0 Protocol" document with the
agreements reached at the December 14, telecon and down-loaded
version D0.9 to:
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-09-rev.pdfftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-09-rev.docftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-09.pdfftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-09.doc
The changes are (as indicated in the published telecon notes):
1. Remove the "ippfax-" prefix from all the new attributes and
clarify that they MAY be supported by an IPP Printer as
OPTIONAL extensions to IPP as well. This allows the user
to have all of the benefits of IPPFAX for document exchange
without requiring the security when that is desired, such
as within a company on its LAN.
2. Add back "ippfax-version-number" operation attribute and
"ippfax-versions-supported" Printer Description attribute
and clarify that an IPP Printer MUST NOT support them.
Clarify that the "version-number" parameter and "ipp-
versions-supported' Printer Description attribute applies
to the IPP Protocol that is part of the IPPFAX protocol, so
that IPPFAX really has two version numbers, one for its IPP
and the other for IPPFAX itself. Clarify that the Sender
MUST supply the "ippfax-version-number" operation attribute
to indicate that the request is an IPPFAX request (along
with the 'ippfax:' scheme in the "printer-uri" operation
attribute). Clarify that the way that the Sender
determines that the Printer is a Sender is that the Printer
supports the "ippfax-versions-supported" Printer
Description attribute, instead of comparing the "printer-
uri-supported" which would require the much more
complicated URI matching rules. Clarify that the Receiver
MUST check both the "version-number" parameter for the
proper
3. Allow Receivers to support the single allowed value for
some of the Job Template attributes for which other values
would be inappropriate for the "FAX-like" service of
IPPFAX, rather than forbidding support of such attributes
altogether.
4. Continue to allow a Receiver to support 'none' for Client
Authentication in the "uri-authentication-supported"
Printer Description attribute (Table 13) so that anonymous
users can be supported if the administrator wishes, but NOT
allow a Receiver to support 'none' for security in the uri-
security-supported" Printer Description attribute (Table
15). An IPPFAX Exchange MUST always start out in TLS.
The following 3 minor issues remain:
ISSUE 01: For the "operations-supported" Printer Description
attribute should we remove the "MUST depend on the role of the
authenticated requesting user" or change to SHOULD or MAY?
ISSUE 02: Can we simplify "uif-profile-capabilities" (1setOf
text(MAX)) by making it single-valued, especially now that UIF
provides some short hand equivalents for common CONNEG
capabilities? UIF CONNEG capabilities above the minimum should
now fit in 1023 ASCII octets.
ISSUE 03: OK that the Receiver MUST support "auto-notify" with
at least the 'false' value, so that all new attributes defined
by this document are REQUIRED?
Please send any comments on these issues or anything else about
the document to the mailing list.
Tom
Peter Zehler
XEROX
Xerox Architecture Center
Email: PZehler at crt.xerox.com
Voice: (716) 265-8755
FAX: (716) 265-8871
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-30E
Webster NY, 14580-9701