IPP> MOD - Issue 33 - proposed resolution to combining IPP/1. 0 and IPP /1.1 into the IPP/1.1 document

IPP> MOD - Issue 33 - proposed resolution to combining IPP/1. 0 and IPP /1.1 into the IPP/1.1 document

Ron Bergman rbergma at dpc.com
Tue Apr 27 16:27:20 EDT 1999


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.
> 
> 
> 
> 




More information about the Ipp mailing list