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

ned.freed at innosoft.com ned.freed at innosoft.com
Tue Dec 5 18:49:12 EST 2000


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