Tom,
My understanding of the consensus in New Orleans agrees with Bill's
response below. I also believe that it was agreed that the IPP 1.1
document body would not contain references to 1.0 unless absolutely
necessary. The differences between 1.1 and 1.o would appear only as an
appendix in the 1.1 documentation.
I feel that your newly defined "UNSPECIFIED" term is overkill and not
necessary. Just explain the differences in plain english
Ron Bergman
Hitachi Koki Imaging Solutions
On Tue, 27 Apr 1999, Wagner,William wrote:
> 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.
>>