To me, saying you are extending RFC2911 and RFC2910 is the same as saying
you are extending IPP 1.1. Then a reader might question extension of IPP
1.0 or 1.2.
So how about if I put no mention of the IPP RFCs at all when I say I'm
extending IPP. Then the references section with include 2910 and 2911 in
the Normative references and 2565 and 2566 in the Informative references.
I really want to find a way to NOT imply that 1.1 is a prerequisite for
"-actual"s.
Dennis
"Hastings, Tom N"
<hastings@cp10.es To: Ron.Bergman@hitachi-ps.us, Dennis Carney/Boulder/IBM@IBMUS, pwg-ipp@pwg.org, "Hastings,
.xerox.com> Tom N" <hastings@cp10.es.xerox.com>, imcdonald@sharplabs.com
cc:
01/23/03 08:01 PM Subject: RE: PWG-IPP> Last Call Comments on IPP "-actual" Attributes Docum ent
Ron's point about what happens when IPP/1.2 is part of the reason that
Ira's
and my suggestion did not talk about the version of IPP in either the
Abstract or the Introduction. We didn't say IPP/1.0 or IPP/1.1. Our
proposed statement simply is:
Abstract: This specification extends the Internet Printing Protocol (IPP)
(RFC2911 and RFC 2910) by defining ...
Introduction: This specification extends the Internet Printing Protocol
(IPP) [RFC2911, RFC 2910] by defining ...
So when IPP/1.2 comes along, these extension documents still apply. And by
the same reasosing these extension document also apply to IPP/1.0.
The only difference between the Abstract and the Introduction is that
another IETF rule is no references in the Abstract.
Tom
-----Original Message-----
From: Ron.Bergman@hitachi-ps.us [mailto:Ron.Bergman@hitachi-ps.us]
Sent: Thursday, January 23, 2003 16:58
To: dcarney@us.ibm.com; pwg-ipp@pwg.org; hastings@cp10.es.xerox.com;
imcdonald@sharplabs.com
Subject: RE: PWG-IPP> Last Call Comments on IPP "-actual" Attributes
Docum ent
Dennis,
The restriction on references in the abstract is a relatively new
requirement from the IETF so the RFCs got in under the wire. The
references in the ISTO documents were obviously missed. You will
also notice the format was not even close to ISTO requirements.
These earlier documents need a major overhaul.
I believe that if you explicitly state IPP 1.0 and 1.1 in the
Introduction, as I previously stated, there will be no confusion
as to its applicability. Still, there are no rules as to what
you can and can't implement. If you stated in the document that
it is only for IPP 1.1, what is to stop anyone from including it
in a 1.0 implementation. If we later develop an IPP 1.2 version,
will everyone assume that all previous extensions are not applicable
because the old documents only say 1.1?
The difference in conformance requirements between 1.0 and 1.1
are understood. This is why the version number was changed.
All of the differences are documented in the 1.1 specs.
Ron
-----Original Message-----
From: Dennis Carney [mailto:dcarney@us.ibm.com]
Sent: Thursday, January 23, 2003 4:19 PM
To: pwg-ipp@pwg.org; Ron.Bergman@hitachi-ps.us;
hastings@cp10.es.xerox.com; McDonald, Ira
Subject: RE: PWG-IPP> Last Call Comments on IPP "-actual" Attributes
Docum ent
All,
I would like to point out that RFCs 3380, 3381, and 3382, which all went
through IETF approval and got OK'd in September 2002, all have mentions of
"IPP 1.0" in their abstract and introduction, AND have references to either
[RFC2565] or [RFC2566] or both in their introductions. In addition, ALL
four currently published PWG IPP extensions (PWG 5100.1, 5100.2, 5100.3,
5100.4) have mentions of "IPP 1.0" AND references to [RFC2565, RFC2566] in
their abstracts (yes, with the "[" and "]" instead of "(" and ")"). So
every (I think?) existing IPP extension standard does what I'm trying to
do: extend IPP 1.0 as well as IPP 1.1.
So, that said, I am happy with whatever wording I have to do AS LONG AS an
implementer of the "-actual" spec is not forced to also implement IPP 1.1.
(Note that IPP 1.1 *did* add additional conformance requirements compared
to 1.0, such as Digest Authentication.)
OK to fashion my wording and references to match RFCs 3380-3382?
Dennis
Ron.Bergman@hitac
hi-ps.us To:
hastings@cp10.es.xerox.com, Dennis Carney/Boulder/IBM@IBMUS
cc:
Ron.Bergman@hitachi-ps.us, pwg-ipp@pwg.org
01/23/03 04:26 PM Subject: RE: PWG-IPP> Last
Call Comments on IPP "-actual" Attributes Docum ent
Tom,
Yes, I forgot that references should not be in the abstract. I suggest
that the abstract then be simplified even more to:
This specification extends the Internet Printing Protocol by defining ...
Anyone actually implementing the document will get the details later.
Ron
-----Original Message-----
From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
Sent: Thursday, January 23, 2003 3:15 PM
To: Dennis Carney
Cc: Ron.Bergman@hitachi-ps.us; pwg-ipp@pwg.org
Subject: RE: PWG-IPP> Last Call Comments on IPP "-actual" Attributes
Docum ent
Dennis,
What Ira and I came up with doesn't refer to IPP/1.0 at all, since it has
been obsoleted by IPP/1.1. (Of course an implementer is free to extend
IPP/1.0 anyway he wants).
Here is what we suggest for the Abstract (which isn't supposed to have any
[] document references, so parens are used):
This specification extends the Internet Printing Protocol (IPP) (RFC2911
and
RFC 2910) by defining ...
And for the Introduction:
This specification extends the Internet Printing Protocol (IPP) [RFC2911,
RFC 2910] by defining ...
I'm editing these suggested phrases into a proposed IEEE-ISTO template,
along with all of your other comments on the template.
Tom
-----Original Message-----
From: Dennis Carney [mailto:dcarney@us.ibm.com]
Sent: Thursday, January 23, 2003 10:24
To: pwg-ipp@pwg.org; Ron.Bergman@hitachi-ps.us
Subject: RE: PWG-IPP> Last Call Comments on IPP "-actual" Attributes
Docum ent
Ron,
1. Okay, so if I get rid of all references to 2565 and 2566, but leave the
claim that I'm extending both 1.0 and 1.1, I'll get what I want, right?
Thanks for the clarification.
4. Yeah, I know I can force a line-break, but I thought there might be a
better way. (By the way, some people actually do pronounce this proposal
the "dash actual proposal", or say "Now we'll move to a discussion of dash
actuals.")
Thanks again for the comments,
Dennis
Ron.Bergman@hitac
hi-ps.us To: Dennis
Carney/Boulder/IBM@IBMUS
cc:
01/23/03 11:14 AM Subject: RE: PWG-IPP> Last
Call Comments on IPP "-actual" Attributes Docum ent
Dennis,
(Numbers correspond to my original message below.)
1. The original protocol and model documents are obsolete since the
new documents apply to both. (i.e. IPP 1.0 is a subset of 1.1)
The differences between IPP 1.0 and 1.1 are extensively covered
in the latest documents. All you need to say in the Abstract
and Introduction is: "This document specifies an extension to
the Internet Printing Protocol/1.0 and 1.1 [RFC2910, RFC2911]."
4. I have encounter problems like this with WORD before. The only
way to correct this (that I have found) is to insert a return
at the beginning of the string. This is not a big problem in
this case since you are not justifying the paragraph. But if
the paragraph is ever modified later, the return may then have
to be removed. (But, at least the text looks better!)
Another suggestion is to change "-actual" to "Actual" in the
entire document. (e.g. PWG Standard for IPP: "Actual"
Attributes) This would eliminate the strange looking "-"
throughout the document. (and no one is going to pronounce
the dash when discussing the document anyway)
Hope these comments help.
Ron
-----Original Message-----
From: Dennis Carney [mailto:dcarney@us.ibm.com]
Sent: Thursday, January 23, 2003 6:49 AM
To: pwg-ipp@pwg.org; Ron.Bergman@hitachi-ps.us
Subject: Re: PWG-IPP> Last Call Comments on IPP "-actual" Attributes
Document
Ron,
Thanks for the review. I'll cover your comments one by one.
1. I want the "-actual" proposal to extend both IPP 1.1 AND 1.0. That is,
some implementer that implements 1.0 (maybe they can't do 1.1 due to not
doing security?) could still implement the "-actual" extension. I
*definitely* don't want to limit this to only extending IPP 1.1--to tell a
1.0 implementer that to do "-actual"s they also have to do 1.1.
So, I don't understand the situation. If 2565 and 2566 are obsolete, does
that mean IPP 1.0 is "obsolete"? Is it against the rules to extend an
obsolete standard, no matter how many implementations might exist in the
real world? Is there a way to extend 1.0 without breaking any rules (like
maybe just remove the two RFCs from the references section, or make them
Informative References)?
2. I like your suggestion.
3. I don't mind getting rid of that text, but thought it made things
clearer, if not to the editorial reader then to the implementer. What do
others think?
4. Is there a way in Word to tell it not to do that?
5. Tom Hastings was putting together a new "PWG template", and in that, he
was making the argument to use the page numbering and headers you see in
the "-actual" spec, for usability (especially Acrobat Reader) reasons. He
convinced me (and Harry went along) to use the more usable method in this
document. If need be, I can change these.
Dennis Carney
IBM Printing Systems
Ron.Bergman@hitac
hi-ps.us To: pwg-ipp@pwg.org
Sent by: cc:
owner-pwg-ipp@pwg Subject: PWG-IPP> Last Call
Comments on IPP "-actual" Attributes Document
.org
01/22/03 04:36 PM
Technically the document looks very sound. The following comments
are primarily editorial.
1. RFC 2565 and 2566 are obsolete. It is not appropriate to reference
obsolete documents, especially as a normative reference. See
Line 146 (in section 1 Introduction)
Line 228 (in section 3 -actual attributes)
Line 331 - 336 (in section 7.1 Normative References
2. In lines 151 & 152 recommend changing "(or are going to print)" to
"(or are expected to be printed)" to be more consistent with the
example in section 3.3.
3. In line 239 remove "that has the" and all of the text in the
following line. This additional text adds nothing and results in
a sentence that is very difficult to read.
4. In lines 279 and 280 there is a strange split (by WORD) of the
string "-attribute".
5. The formatting of the document is not per ISTO requirements.
Specifically page numbering and headers. Is there a procedure
for format review prior to final publication? I propose that
this needs to be established.
Ron Bergman
Hitachi Printing Solutions
This archive was generated by hypermail 2b29 : Fri Jan 24 2003 - 11:18:50 EST