IPP> AD review of a bunch of IPP documents

IPP> AD review of a bunch of IPP documents

IPP> AD review of a bunch of IPP documents

Carl-Uno Manros carl at manros.com
Tue Dec 5 21:17:28 EST 2000


Ned,

Thanks for getting round to review this series of IPP documents. I will ask
the editors to fix up the documents with the suggested changes and produce
revised drafts as appropriate.

Carl-Uno

> -----Original Message-----
> From: owner-ipp at pwg.org [mailto:owner-ipp at pwg.org]On Behalf Of
> ned.freed at innosoft.com
> Sent: Tuesday, December 05, 2000 3:49 PM
> To: ipp at pwg.org
> Cc: ned.freed at innosoft.com; paf at cisco.com; scoya at ietf.org
> Subject: IPP> AD review of a bunch of IPP documents
>
>
> I've completed review of quite a few of the pending IPP
> documents. Attached
> below are my comments.
>
> I would like to point out up front that almost all of the issues
> I have are
> procedural in nature; there is little if any technical substance here.
> And while process issues aren't my favorite things, it is nice not to have
> technical issues to deal with. Well done, folks.
>
> draft-ietf-ipp-implementers-guide-v11-01.txt
>
>  This document needs to explain its relationship to RFC 2639.
> Does it replace
>  it or add to it? I assume the former, in which case you want to add an
>  Obsoletes: RFC 2639 to the first page and an explanation and
> reference to the
>  Abstract.
>
>  The reference to IPP-MOD needs to be updated to refer to RFC
> 2911. (Normally
>  I'd be inclined to leave this to the RFC Editor, but since there
> are other
>  changes might as well get this done too.)
>
>  The reference to IPP-PRO needs to be updated to refer to RFC 2910.
>
>  Section 1.3. The URL
>
>   ftp://ftp.pwg.org/pub/pwg/ipp/issues/issues-raised-at-bake-off2.pdf
>
>  is also available as .txt and .doc files. You might want to refer
>  to these alternative formats of the document as well.
>
>  Section 3.1.1. I find tables 1 and 2 very hard to read. But I
> don't know how
>  you'd be able to do much better in plain text. Hopefully the RFC Editor
>  can do something...
>
>  Section 3.1.2.1.6. The phrase "MAY or MAY NOT" is used here, but
> "MAY NOT" is
>  not defined. (In fact RFC 2911 says "MAY NOT" is confusing...) I
> suggest a
>  simple MAY is appropriate here.
>
>  Section 3.1.2.3.11. This section talks about how UTF-8 support
> is required. In
>  practice this is a very complex thing indeed that goes way past
> knowing how
>  many bytes there are in a character. Lots of characters, complex
> directionality
>  rules, complex ligatures, and so on. I don't think it is
> necessary to expand on
>  this in the present version of this document, but if a new
> version is ever
>  produced I suggest that this is an area that needs a lot of additional
>  attention.
>
> draft-ietf-ipp-job-printer-set-ops-02.txt
>
>  Abstract. "Internet Printing Protocol/1.1: Model and Semantics (this
>  document)" should be "Internet Printing Protocol/1.1: Model and Semantics
>  (RFC 2911)". (Cut and paste error.)
>
>  References to IPP-MOD need to be updated to refer to RFC 2911 throughout.
>  (Normally I'd do this with an RFC Editor note, but since there are other
>  changes might as well get this done too.)
>
>  The reference to IPP-PRO needs to be updated to refer to RFC 2910.
>
>  Section 10, first paragraph. First of all, the reference to RFC 2566 here
>  is wrong -- you need to refer to the standard-track version, RFC 2911.
>  Second,  this business about "there is no need to also register the
>  operations, attributes, status codes, and out-of-band values
> defined here-in
>  with IANA" because "this is intended to be a standards track
> document" isn't
>  appropriate, because then IANA has to dig through this entire
> document looking
>  for the things it needs to register. The right thing to do here
> is list the
>  things you're adding to each registry. You don't have to justify them;
>  merely list them so it easy for IANA to add them. And finally, one minor
>  typo: "site" -> "cite".
>
>  Section 15. Is this to be retained in the final document? If not I
>  suggest a note at the beginning explaining what is to be done.
>
> draft-ietf-ipp-collection-03.txt
>
>  Abstract. "Internet Printing Protocol/1.1: Model and Semantics (this
>  document)" should be "Internet Printing Protocol/1.1: Model and Semantics
>  (RFC 2911)". (Same cut and paste error.)
>
>  Again, references to IPP-MOD and IPP-PRO need to be updated to refer to
>  RFC 2911 and RFC 2910 respectively throughout.
>
>  The terms MUST, MUST NOT, and so on are not defined in this document and
>  need to be, I assume by reference to RFC 2911 as usual.
>
>  Section 5. It isn't immediately clear whether this is merely an
> illustrative
>  example of how collections are defined or an actual definition. I suggest
>  stating this explicitly at the beginning.
>
>  Section 6. Same concern as 5.
>
>  Section 7. Same concern as 5.
>
>  Section 9 IANA Considerations. This needs to explain what is
> being registered;
>  the current text is inappropriate. A simple list of the things being
>  registers would be sufficient.
>
> draft-ietf-ipp-job-prog-01.txt
>
>  This document needs to enumerate what is being registered with IANA in
>  Section 4.
>
>  Again, since a change is needed might as well fix the references
> to IPP-MOD
>  and IPP-PRO in the new version.
>
> draft-ietf-ipp-not-04.txt
>
>  There's a peculiar situation here. This document uses the
> capitalized terms
>  REQUIRED and OPTIONAL without defining them. However, this is an
> informational
>  document, and these terms are only used indirectly, that is, in
> describing
>  what has to be supplied in documents meeting these requirements.
> So, rather
>  than putting in the usual boilerplate paragraph about capitalized terms,
>  or even the boilerplate you've used in other IPP documents, what
> I'd suggest
>  is that the first bullet item in Section 4 be changed to cite RFC 2911
>  section 12.1 directly in regards to these terms.
>
>  Again, since a change is needed might as well fix the references
> to IPP-MOD
>  and IPP-PRO in the new version.
>
> draft-ietf-ipp-not-spec-05.txt
>
>  I'm certainly no expert, but it seems to me that this document defines
>  a bunch of new attributes, attribute groups, and so on. If so, don't
>  these need to be enumerated in an IANA Registrations section so that
>  they can appear in the appropriate IPP IANA registries?
>
>  The new IANA procedures here are fine, incidentially -- I'm only
> concerned
>  about stuff this document adds to other registries.
>
>  Here again, if a change is needed you might as well fix the references to
>  IPP-MOD and IPP-PRO in any new version.
>
> Finally, a note regarding RFC 2910. It uses the compliance term "NEED NOT"
> without defining it. (I'm surprised we didn't catch this; usually
> we're more
> careful with capitalized terms.) There's a definition in RFC
> 2911, but it isn't
> referenced in section 2. This needs to be fixed the next time the
> document is
> revised.
>
> 				Ned
>
>




More information about the Ipp mailing list