I may have confused things by using the term "supersede", instead of
"obsolete".
What I meant to say was that one of the goals of combining the
specifications for the IPP/1.0 protocol and IPP/1.1 protocol into the
IPP/1.1 document as agreed at the IETF March meeting, was so that the RFC
Editor would say the new IPP/1.1 document obsoletes RFC nnnn [where nnnn is
the Experimental RFC for IPP/1.0, i.e., obsoletes the November document].
Looks like there is not much support for obsoleting the November 1.0
document and attempting to specify IPP/1.1 protocol and the IPP/1.0 protocol
in one document in a way that doesn't change the IPP/1.0 protocol.
In other words, the folks who have responded on the mailing list so far to
my proposed resolution of ISSUE 33 have all though it better and simpler to
have the new standards track document only specify IPP/1.1 with an Appendix
that lists the differences from the IPP/1.0 November document. In this
case, the IPP/1.1 RFC will not Obsolete the IPP/1.0 RFC.
Ok?
Thanks,
Tom
-----Original Message-----
From: Ron Bergman [mailto:rbergma@dpc.com]
Sent: Tuesday, April 27, 1999 13:27
To: Hastings, Tom N
Cc: harryl@us.ibm.com; Wagner,William; ipp@pwg.org
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 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@psg.org (so may not have been
seen
> by all).
>
>
>
> -----Original Message-----
> From: harryl@us.ibm.com [mailto:harryl@us.ibm.com]
> Sent: Tuesday, April 27, 1999 07:43
> To: Wagner,William; ipp@psg.org
> Cc: hastings@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@us.ibm.com
>
>
>
> "Wagner,William" <bwagner@digprod.com> on 04/27/99 07:05:23 AM
>
> To: "'Hastings, Tom N'" <hastings@cp10.es.xerox.com>, ipp <ipp@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@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.
>
>
>
>