My memory agrees with Bill's
**********************************************
* Don Wright don at lexmark.com *
* Director, Strategic & Technical Alliances *
* Lexmark International *
* 740 New Circle Rd *
* Lexington, Ky 40550 *
* 606-232-4808 (phone) 606-232-6740 (fax) *
**********************************************
bwagner%digprod.com at interlock.lexmark.com on 04/27/99 09:05:23 AM
To: hastings%cp10.es.xerox.com at interlock.lexmark.com,
ipp%pwg.org at interlock.lexmark.com
cc: (bcc: Don Wright/Lex/Lexmark)
Subject: RE: IPP> MOD - Issue 33 - proposed resolution to combining IPP/1. 0
and IPP /1.1 into the IPP/1.1 document
Tom,
I think one significant question was whether the IPP1.1 document was to be
the definitive document for IPP1.0. You proposal below suggests that it is.
If the IPP1.1 document is the normative document for IPP1.0, then saying
that "The agreed principle was that the IPP/1.1 document was NOT to change
anything for the IPP/1.0 protocol." is meaningless, because if the document
defines IPP1.0, it cannot change IPP1.0.
My understanding of consensus was that the November IPP1.0 document, perhaps
in its Experimental RFC incarnation, was to remain the definitive IPP1.0
document. This is somewhat clouded by the one change and several
clarifications to this document that have been felt necessary. The
clarifications are reasonably handled by the IPP1.0 Implementers guide; my
own belief is that the change relative to the handling of compression should
also be handled (for 1.0) as a clarification in the implementers guide since
implementing the desired response does not violate the IPP1.0 requirements
and not implementing it causes an irritation (and potential waste of paper),
but not major inoperability.
Therefore, I believe the contention was that the document set identified as
IPP1.0 is and remains the definitive IPP document set. Any reference to
IPP1.0 in the IPP1.1 document set is for reference and convenience only. In
case of discrepancy, the IPP1.0 set must take precedence.
If this is consensus, than this must be clearly stated in the IPP1.1
documents. I cannot conceive of two different documents describing the same
protocol that will not at some place allow different interpretations of some
detail of that protocol. You cannot reasonably have two different definitive
document sets.
Bill Wagner
-----Original Message-----
From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
Sent: Monday, April 26, 1999 10:05 PM
To: ipp
Subject: IPP> MOD - Issue 33 - proposed resolution to combining IPP/1.0
and IPP /1.1 into the IPP/1.1 document
At the New Orleans IPP WG meeting we discussed the resolution of Issue 33 of
how to combine the IPP/1.0 and IPP/1.1 protocol specifications into a single
document, as agreed at the March IETF meeting. We did not reach complete
agreement and so the minutes indicate that we deferred the discussion. This
mail note proposes a resolution to this issue, based on the discussions that
we had.
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
IPP/1.1 document?
Suggested change:
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
[ipp-mod1.0]]
[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
differences).
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
combination.
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
IPP/1.0.
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
implementations.
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
implementations.
Here is the definition of the UNSPECIFIED term:
13.1.2 UNSPECIFIED
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.