At the 4/28 IPP telecon with a good number of participants, we agreed NOT to
have the IPP/1.1 document attempt to specify IPP/1.0 conformance. We did
agree that the Appendix will have a list of differences between IPP/1.1 and
IPP/1.0. See the February I-D. There will be two lists:
clarifications and OPTIONAL additions to IPP/1.1
changes in conformance requirements of existing IPP/1.0 features or new
REQUIRED IPP/1.1 features.
This issue resolution list the items for the second list.
ISSUE 33: Include the IPP/1.0 conformance requirements in the IPP/1.1
document?
Suggested change:
No. The IPP/1.1 Model and Semantics document and the IPP/1.1 Encoding and
Transport document will only cover IPP/1.1. They will NOT obsolete the
experimental RFC that describes IPP/1.0. They will NOT describe IPP/1.0 at
all.
The IPP/1.1 document will say that for interoperability with IPP/1.0
clients, that an IPP Printer SHOULD accept IPP/1.0 requests
("version-number" parameter = '1.0') and, if they accept the request, MUST
respond with IPP/1.0 responses ("version-number" parameter = '1.0') .
Furthermore, an IPP/1.1 conforming Printer or an IPP/1.0 conforming Printer
MAY respond with any IPP/1.1 feature in such an IPP/1.0 response that would
not jeopardize interoperability with any IPP/1.0 client. See Issue 17 for
an example of an IPP/1.1 extension that MUST NOT be returned in a '1.0'
response. If the IPP/1.1 Printer does not support version '1.0' requests,
then it MUST reject such requests and return the
'server-error-version-number-not-supported' status code with the
"version-number" parameter set to '1.1'.
The IPP/1.1 documents will contain an appendix that summarizes each
difference from IPP/1.0 by section number and a brief description (see
February 1999 I-Ds). The appendix will contain two separate lists: one is
clarifications and OPTIONAL additions to IPP/1.1 and the other is changes in
conformance requirements of existing IPP/1.0 features or new REQUIRED
IPP/1.1 features. Here are the items for the second list in the Appendix:
1. IPP/1.1 clients and Printers SHOULD support IPP/1.0 requests and
responses (see above and Issue 36).
2. IPP/1.1 clients and Printers MUST support the IPP scheme; IPP/1.0
clients and Printers MUST support the http scheme.
3. IPP/1.1 clients MUST support the secured channel part of TLS with at
least Basic authentication AND the user authentication part of Digest and
non-TLS access; IPP/1.0 clients SHOULD support SSL3 which uses the https
scheme and non-SSL3 access. (See Issue 32)
4. IPP/1.1 Printers MUST be configurable to support the secured channel
part of TLS access with at least Basic authentication OR the user
authentication part of Digest; IPP/1.0 Printers SHOULD support SSL3 which
uses the https scheme and non-SSL3 access. (See Issue 32)
5. IPP/1.1 Printers MUST support the (new)
"uri-authentication-supported (1setOf type2 keyword)" Printer Description
attribute. (See Issue 2)
6. IPP/1.1 Printers implemented as a forwarding server that can't get
status from the device or print system (such as LPD) that it forwards jobs
to, MAY put the job into the 'completed' state after forwarding the job.
However, such implementations MUST support the "job-state-reasons" attribute
with the 'queue-in-device' value when it puts the job into the 'completed'
state, as an indication that the job is not necessarily completed;
UNSPECIFIED for IPP/1.0 forwarding servers. (See Issue 14)
7. IPP/1.1 Printer MUST support "time-at-processing (integer(0:MAX))",
"time-at-processing (integer(0:MAX))", and "time-at-processing
(integer(0:MAX))" Job Description attributes; OPTIONAL in IPP/1.0. Add the
'dateTime' attribute syntax for OPTIONAL support with these Job Description
attributes. However, the dateTime attribute syntax MUST NOT be returned in
responses to version '1.0' requests. (See Issue 17)
8. IPP/1.1 Printers MUST support "compression" and
"compression-supported" attributes with at least the 'none' value; OPTIONAL
for IPP/1.0, but see Implementer's Guide [ipp-iig] that describes the bug if
the IPP Printer doesn't reject compression if it doesn't support
compression. (See Issue 28)
9. IPP/1.1 Printers MUST support "queued-job-count"; RECOMMENDED in
IPP/1.0. (See Issue 29)
10. IPP/1.1 Printers MUST support "job-state-reasons" and
"printer-state-reasons"; OPTIONAL in IPP/1.0. (See Issue 30)
11. IPP/1.1 Printers that support Create-Job and Send-Document MUST
support the (new) "multiple-document-jobs-supported (boolean)" Printer
Description attribute. (See Issue 34).
12. IPP/1.1 Printers MUST support the (new)
"ipp-versions-supported(1setOf type2 keyword)" Printer Description
attribute. (See Issue 36)
For the IIG:
1. Discuss the advantage for client implementations to support both
IPP/1.1 and IPP/1.0, so that they can interoperate with either Printer
implementations.
2. Discuss the advantage for Printer implementations to support both
IPP/1.1 and IPP/1.0, so that they can interoperate with either client
implementations.