All,
Since Tom's PC is currently being upgraded I am sending this out on his
behalf.
Pete
Here is the new Section 20 (Appendix A) comparing IPP and IPPFAX
as suggested at the telecon. I was surprised at how many
differences there are, so there may be some discussion as to how
to remove some of them. I've indicated the differences that
require conditional code with ** in order to support both IPP
and IPPFAX in a singe implementation (requiring separate IPP and
IPPFAX print objects). A number of differences can be handled
without conditional code, if the IPP protocol implementation
part doesn't support the IPP OPTIONs that IPPFAX forbids. These
are indicated by *. Differences without any asterisks can be
handled without conditional code, if the IPP Printer
implementation supports the indicated IPPFAX features as part of
IPP as well.
Appendix A: Comparison of IPP/1.1 and IPPFAX/1.0
(Informative)
This informative appendix compares IPP/1.1 and IPPFAX/1.0 with
references to the appropriate sections for details. If this
appendix contradicts or omits any differences, it is a mistake
and the body of this document still prevails. Most of the
differences are in conformance requirements only. Therefore,
for most of the differences, it is possible to implement both
with the same code (without conditional branches).
Legend:
** Where IPP/1.1 is a must and IPPFAX/1.0 is a MUST NOT
(indicated below by leading **), would a conditional branch
be needed in the implementation code in order to support
both IPP/1.1 and IPPFAX/1.0.
* Where IPP/1.1 is a may and IPPFAX/1.0 is a MUST NOT
(indicated below by a leading *), would a conditional
branch be needed in the implementation code in order to
support both IPP/1.1 and IPPFAX/1.0, but only if the
IPP/1.1 part supports the feature.
Differences between the IPP/1.1 protocol and the IPPFAX/1.0
protocol:
1. ** IPP uses the 'ipp' URL scheme with a default port of
631, while IPPFAX uses the 'ippfax' URL scheme with a
default port of xxx [TBA by IANA] (section 4.1 and 16).
2. ** IPP has only one version number parameter, while IPPFAX
has two version numbers: the "version-number" parameter
(section 4.2) and the "ippfax-version-number" operation
attribute (section 4.3).
Differences between an IPP client and a Sender:
1. An IPP Client may use any IPP operation, while a Sender
MUST use at least Get-Printer-Attributes (sections 5 and
7.1), Validate-Job (section 7.2), and Print-Job operations
(section 9). A Sender MUST use the Get-Notifications
operation, unless the Sending User has explicitly indicated
otherwise (section 9.6).
2. In the Get-Printer-Attributes request, an IPP Client may
supply the "document-format" and "uif-profile-requested"
operation attributes, while a Sender SHOULD (sections 5.1
and 5.2).
3. ** In the Job Creation operations and the Validate-Job
operation, an IPP Client may supply the "ipp-attribute-
fidelity" operation attribute with either the 'true' or
'false' value or may omit the attribute entirely, while the
Sender MUST always supply the attribute and with the 'true'
value (sections 7.2 and 9.1.1).
4. In the Job Creation operations and the Validate-Job
operation, an IPP Client may supply the "document-format"
operation attribute, while the Sender MUST supply it
(section 9.1.2).
5. * An IPP Client may support any MIME Media Type as the
value of the "document-format" operation attribute, while
the Sender MUST support at least the 'image/tiff' MIME
Media Type, MAY support the 'image/tiff-fx' MIME Media
Type, and MUST NOT support any MIME Media Type unless it
has the same "blind interchange" guarantee of document
presentation fidelity as TIFF-FX [tiff-fx] (section 6.6).
6. In the Job Creation operations and the Validate-Job
operation, an IPP Client may supply the "media" Job
Template attribute, while the Sender MUST supply it
(section 9.2.1).
7. * An IPP Client may supply any keyword listed in [RFC2911]
section 14 (Appendix C) for the "media" Job Template
attribute or the Media Size Self Describing Name keyword
values defined in the IEEE-ISTO 5101.1 "Media Standardized
Names" [pwg-media], while the Sender MUST use the keyword
values from [pwg-media] (section 9.2.1).
8. There are no requirements for an IPP Client to indicate the
client or the client user in the document, while the Sender
MUST supply the "sender-uri" value along with a date and
time, on at least the cover page (section 9.5).
9. An IPP Client need not support Event Notification, while
the Sender MUST support at least the 'ippget' Pull Delivery
Method (section 9.3), which REQUIRES using the Get-
Notifications operation (section 9.6).
10. An IPP Client may support any events, while a Sender
MUST NOT support the 'job-config-changed' and any Printer
events (section 9.3.2).
11. An IPP Client may support Client Authentication, while
a Sender MUST support at least 'digest' and 'certificate'
(section 11.2).
12. An IPP Client may support Data Integrity and Data
Privacy, while a Sender MUST support with at least the 128-
bit TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite (section
11.2).
Differences between an IPP Printer and a Receiver:
1. In the Get-Printer-Attributes response, an IPP Printer may
color the attribute values returned according to the
"document-format" supplied, while a Receiver MUST color the
values returned according to both the "document-format" and
"uif-profile-requested" operation attributes supplied
(sections 5 and 6), including the "printer-resolutions-
supported" attribute (section 9.2.2.1).
2. * An IPP Printer is not required to support any particular
document formats, while a Receiver MUST support the UIF
'image/tiff' format with profile uif-s, MAY support
'image/tiff-fx', and MUST NOT support any others, unless
they have the same level of "blind interchange" guarantee
for document presentation fidelity as TIFF-FX (section 6.6)
.
3. * An IPP Printer may support 'application/octet-stream'
(auto-sensing - [RFC2911] 4.1.9.1), while a Receiver MUST
NOT (section 6.6).
4. An IPP Printer may support the IPPFAX attributes: "uif-
profile-requested", "uif-profiles-supported", "uif-profile-
capabilities", "auto-notify", "sending-user-vcard",
"receiving-user-vcard", "sender-uri", and "uif-profiles",
while a Receiver MUST (sections 5.2, 6, 8, and 9.1.3).
5. ** An IPP Printer MUST NOT support the "ippfax-versions"
and "ippfax-versions-supported" attributes, while a
Receiver MUST (sections 4.3 and 6.3).
6. ** An IPP Printer must support both values of the "ipp-
attribute-fidelity" operation attribute, while the Receiver
MUST support only the 'true' value (section 9.1.1).
7. ** An IPP Printer must assume a value of 'false' if the IPP
Client omits the "ipp-attribute-fidelity" operation
attribute, while the Receiver MUST reject the request with
the 'client-error-bad-request' status code (section 9.1.1).
8. An IPP Printer is not required to support any particular
Job Template attributes, while a Receiver MUST support at
least the "media" and "printer-resolution" Job Template
attributes, including the "media-ready" Printer attribute
(section 9.2).
9. * An IPP Printer may supply any keyword listed in [RFC2911]
section 14 (Appendix C) for the "media" Job Template
attribute or the Media Size Self Describing Name keyword
values defined in the IEEE-ISTO 5101.1 "Media Standardized
Names" [pwg-media], while the Receiver MUST support a
subset of the keyword values from [pwg-media] (section
9.2.1).
10. * An IPP Printer may support any Job Template
attribute values, while a Receiver is restricted to a
single value for many Job Template attributes that would
alter the appearance of the document or provide a non-FAX-
like feature (section 9.2).
11. * An IPP Printer may support Print-URI and Send-URI
operations, while a Receiver MUST NOT (section 10.1).
12. An IPP Printer must support Get-Jobs and Get-Job-
Attributes operations, while a Receiver NEED NOT (section
10.1).
13. ** An IPP Printer must support Cancel-Job operation,
while a Receiver MUST NOT (section 10.2).
14. An IPP Printer may support administrative operations
without authentication, while a Receiver MUST authenticate
administrative operations, if they are supported (section
10.1).
15. * An IPP Printer may support the following operations
from an authenticated operator or administrator: Print-Job,
Print-URI, Validate-Job, Create-Job, Purge-Jobs, Cancel-
Current-Job, Send-Document, Send-URI, Cancel-Job, Cancel-
Subscription, and Schedule-Job-After, while a Receiver MUST
reject such operations from an authenticated operator or
administrator.
16. An IPP Printer may support Event Notification, while a
Receiver MUST support Event Notification (sections 9.3 and
10.1) and at least the 'ippget' Delivery Method (section
9.6), which REQUIRES support for the Get-Notifications
operation.
17. If an IPP Printer supports Event Notification, it must
support the 'job-state-changed' and 'job-created' events
for Per-Job Subscriptions, while a Receiver NEED NOT
(section 9.3.2).
18. ** If an IPP Printer supports Printer Events, then it
MUST support them for both Per-Job and Per-Printer
Subscriptions, while a Receiver MUST NOT support them for
Per-Job Subscriptions (section 9.3.2).
19. If an IPP Printer supports Event Notification, it may
support the 'job-progress' event, while a Receiver MUST for
Per-Job Subscriptions (section 9.3.2).
20. * If an IPP Printer supports Event Notification, it
may support the 'job-config-changed' event, while a
Receiver MUST NOT (section 9.3.2).
21. If an IPP Printer supports the Set-Printer-Attributes
operation, then it may support setting the Attribute
Coloring values according to the "document-format"
operation attribute, while the Receiver, if it supports the
Set-Printer-Attributes operation, MUST support setting the
Attribute Coloring values according to the "document-
format" and "uif-profile-requested" operation attributes
(section 10.5).
22. An IPP Printer should support and may use TLS, while a
Receiver MUST support and MUST use TLS (section 11.3).
23. An IPP Printer may support Client Authentication,
while a Receiver MUST support at least 'digest' and
'certificate' (section 11.2).
24. An IPP Printer may support Data Integrity and Data
Privacy and support them with any cipher suite, while a
Receiver MUST support both Data Integrity and Data Privacy
with at least the 128-bit TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
cipher suite (section 11.2).
If you have any comments about these differences, please send
them to the mailing list.
Thanks,
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