I think 1 and 3 are unnecessary "requirements" (where did they come fro=
m?)
which are causing confusion. Any refinement of a specification that res=
ults
in a "dotted" version obviously represents the current state of that
specification. If the current state of a specification is (for example)=
v2.7 and, for some reason, someone is interested in implementing (exact=
ly)
v1.3... the best way to accomplish this is to go read v1.3. Why someone=
might want to do this is beyond the scope of this discussion.
If someone is implementing the specification and is interested in
understanding the progression of finds, fixes, changes etc... I think i=
t is
helpful in some appendix or implementer=92s guide to carry a categorize=
d list
like
MAJOR FIXES
v1.4 - Fixed the reference to dimmy-flop
v1.6 - Clarified the meaning of doofus so even the most naive cannot
misinterpret
MINOR FIXES
v1.5 - Added the proverbial foo-bar
ADDITIONS
v1.1 - Added various forms of security ;-)
Whether this "running history" is embodied in an IETF or PWG document i=
s
immaterial. It would certainly be a "service" to developers of the
standard, regardless of the "official" repository.
While I think the above recommendation is the most useful and
straightforward approach, I don't object to "bracketed" comments in the=
specification intended to help the reader "bridge" versions... as long =
as
it doesn=92t seriously encumber reading the current version and ESPECIA=
LLY as
long as the end result can, in no way, be viewed as a redefinition of a=
ny
existing version!
Harry Lewis
IBM Printing Systems
harryl@us.ibm.com
"Hastings, Tom N" <hastings@cp10.es.xerox.com> on 04/27/99 10:54:50 AM
To: Harry Lewis/Boulder/IBM, "Wagner,William" <bwagner@digprod.com>,
ipp@pwg.org
cc: "Hastings, Tom N" <hastings@cp10.es.xerox.com>
Subject: RE: IPP> MOD - Issue 33 - proposed resolution to combining IP=
P/1.
0 and IPP /1.1 into the IPP/1.1 document
=
--0__=bn28q66CN6Bz1BcoAKoFKmrsoxSdvUdfPfhnvJJr9rRISYhh2YNEPrR5
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
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.
--0__=bn28q66CN6Bz1BcoAKoFKmrsoxSdvUdfPfhnvJJr9rRISYhh2YNEPrR5--