The agreed principle was that the IPP/1.1 document was NOT to change
anything for the IPP/1.0 protocol. Therefore, the IPP/1.1 document must
clearly indicate differences right in the middle of the document. These
differences are mostly additions or clarifications, with a few changes, from
the IPP/1.0 November 1998 document. Also an Appendix will summarize by
section these same differences between the IPP/1.1 document and the November
1998 IPP/1.0 document.
Here is the proposed resolution to ISSUE 33. Please send any comments this
week to the mailing list. We will also discuss this Issue resolution at the
Wednesday, 4/28, IPP telecon.
33) ISSUE: Ok to include the IPP/1.0 conformance requirements in the
The IPP/1.1 Model and Semantics document and the Encoding and Transport
document are going to cover both the IPP/1.0 protocol and the IPP/1.1
protocol, as agreed at the March IETF meeting. However, we also agreed that
the IPP/1.1 document will NOT make any changes to the IPP/1.0 November 16,
1998 document. Therefore, all clarifications, additions, and changes
referred to in this Issues document refer to the IPP/1.1 document. In order
to make it clear to the reader which phrases, sentences, and paragraphs have
been added to the IPP/1.1 document that were not present in the November
1998 IPP/1.0 document, the new term UNSPECIFIED will be used to indicate
something that was not present in the cited document.
However, we have also agreed that any clarification or addition described
for the IPP/1.1 protocol in the IPP/1.1 document MAY be supported by an
IPP/1.0 conforming client or IPP/1.0 conforming Printer as an extension to
the IPP/1.0 protocol. Therefore, any clarification, addition, or change
will be labeled in the IPP/1.1 Model and Semantics and the IPP/1.1 Encoding
and Transport immediately following with one of the following indicators:
[sentence was UNSPECIFIED in [ipp-mod1.0]]
[paragraph was UNSPECIFIED in [ipp-mod1.0]]
[section was UNSPECIFIED in [ipp-mod1.0]]
[operation was UNSPECIFIED in [ipp-mod1.0]]
[attribute was OPTIONAL in [ipp-mod1.0]]
[attribute was UNSPECIFIED in [ipp-mod1.0]]
[value was UNSPECIFIED in [ipp-mod1.0]]
[paragraph was limited to queries in [ipp-mod1.0]]
[behavior of attribute-group extensions was UNSPECIFIED in
[conditions 1 and 2 were UNSPECIFIED in [ipp-mod1.0]]
where UNSPECIFIED is a new conformance term (see below) and [ipp-mod1.0] is
a Reference to the November 16, 1998 IPP/1.0 Model and Semantics document.
Also a change list Appendix will summarize each difference from the November
16, 1998 documents (see February 1999 I-Ds for the first set of
For those clarifications or additions for which the conformance is REQUIRED
for IPP/1.1, but OPTIONAL for IPP/1.0, state: "IPP/1.1 xxx MUST ...;
OPTIONAL for IPP/1.0", where xxx is either clients or Printers.
Here are the 7 items for which the conformance requirements differ between
IPP/1.0 and IPP/1.1:
1. IPP/1.1 clients and Printers MUST support the IPP scheme;
UNSPECIFIED for IPP/1.0.
2. 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; UNSPECIFIED for IPP/1.0. IPP/1.0 clients SHOULD support
SSL3 and non-SSL3 access; OPTIONAL for IPP/1.1.
3. IPP/1.1 Printers:
MUST support the secured channel part of TLS access with at
least Basic authentication OR the user authentication part of Digest;
UNSPECIFIED for IPP/1.0.
MAY support access without TLS, or MAY support any
MAY support SSL3 access, access without SSL3 or both.;
OPTIONAL for IPP/1.0.
4. 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.
5. 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].
6. IPP/1.1 Printers MUST support "queued-job-count"; RECOMMENDED for
7. IPP/1.1 Printers MUST support "job-state-reasons" and
"printer-state-reasons"; OPTIONAL for IPP/1.0.
For the IIG:
8. Discuss that the advantage for client implementations to support
both IPP/1.1 and IPP/1.0, so that they can interoperate with either Printer
9. Discuss that the advantage for Printer implementations to support
both IPP/1.1 and IPP/1.0, so that they can interoperate with either client
Here is the definition of the UNSPECIFIED term:
This term is not included in RFC 2119. The adjective "UNSPECIFIED"
indicates a part of this document that was not specified as part of the
referenced document. Such indications are included inside square brackets.
For example, the indication "[sentence was UNSPECIFIED in [ipp-mod1.0]]"
means that the preceding sentence was not present in the November 1998
IPP/1.0 Model and Semantics document.
A conforming IPP/1.0 client or IPP/1.0 Printer MAY support the UNSPECIFIED
item as an extension to the IPP/1.0 protocol, unless this document
explicitly specifies otherwise.