Tom,
I don't believe that I heard anyone say that IPP 1.1 does not supercede
1.0. What I heard was that the 1.1 document does not redefine 1.0. An
appendix with the differences is essential.
I am not sure that an explicit statement is required indicating that any
1.1 features are allowed in 1.0. It seems that this is understood. (I
would not object to such a statement as long as it is brief and to the
point.)
Ron Bergman
Hitachi Koki Imaging Solutions
On Tue, 27 Apr 1999, Hastings, Tom N wrote:
> Harry and Bill,
>> The intent of the proposed ISSUE 33 resolution was as you both say, NOT to
> redefine the November 1.0 document, but just to indicate what IPP/1.1 things
> were not in the November 1.0 document. Then an implementer that wants to
> implement both IPP/1.1 and IPP/1.0 need not keep referring to two documents,
> but can use our IPP/1.1 document alone. Furthermore, our IPP/1.1 document
> could then say that is supersedes the IPP/1.0 November RFC, since the
> IPP/1.1 document makes clear what things were not present in the IPP/1.0
> November document.
>> So I'm quite confused with your comments, since your goals are the same as
> the proposed resolution. The square bracketed notes in the body of the text
> meet the following goals:
>> 1. Allow a reader reading the IPP/1.1 document to know what was in the
> November 1.0 document without having to read the November IPP/1.0 document
> as well. This is useful for anyone who wants to implement both IPP/1.0 and
> IPP/1.1 in the same implementation. (Something our Implementer's Guide is
> pointing out increases interoperability).
>> 2. Don't make any changes to IPP/1.0 protocol from what is in the November
> document.
>> 3. Allow an implementer of the IPP/1.0 protocol only who want to implement
> any IPP/1.1 feature as an extension of IPP/1.0 to do so without having to
> read two documents.
>> 4. The IPP/1.1 RFC document can formally supersede the IPP/1.0 November
> document when published.
>>>> On the other hand, it would be a lot easier for the body of the text NOT to
> have all these indications of [xxx was UNSPECIFIED in [ipp-mod1.0]] as
> suggested by Bill, Harry, and Ron. The implementer can just read the
> differences list in the Appendix (see the February 1999 I-D to see how easy
> this is to use for someone implementing both IPP/1.0 and IPP/1.1). But it
> does go against the suggestion at the IETF meeting in March.
>> Lets hear from others. So far, Bill, Harry, and Ron are against having the
> comments in the body of the document and are against having the IPP/1.1
> document supersede the IPP/1.0 document.
>> Comments?
> Tom
>> P.S. The original message was sent to ipp at psg.org (so may not have been seen
> by all).
>>>> -----Original Message-----
> From: harryl at us.ibm.com [mailto:harryl at us.ibm.com]
> Sent: Tuesday, April 27, 1999 07:43
> To: Wagner,William; ipp at psg.org> Cc: hastings at cp10.es.xerox.com> Subject: RE: IPP> MOD - Issue 33 - proposed resolution to combining
> IPP/1. 0 and IPP /1.1 into the IPP/1.1 document
>>>>> Bill has put it very well... and I agree. We can't change the definition of
> IPPv1.0 at this point. We can clarify and relay implementation experiecne
> in seperate documents and we can evolve the standard ala IPPv1.1. As such,
> we should consider v1.1 the current, most up to date representation of IPP.
> But, this does not mean IPPv1.1 "defines" IPPv1.0. We already did that.
>> Harry Lewis
> IBM Printing Systems
>harryl at us.ibm.com>>>> "Wagner,William" <bwagner at digprod.com> on 04/27/99 07:05:23 AM
>> To: "'Hastings, Tom N'" <hastings at cp10.es.xerox.com>, ipp <ipp at pwg.org>
> cc: (bcc: Harry Lewis/Boulder/IBM)
> 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.
>>>>