IPP Mail Archive: IPP> AD review of a bunch of IPP documents

IPP Mail Archive: IPP> AD review of a bunch of IPP documents

IPP> AD review of a bunch of IPP documents

From: ned.freed@innosoft.com
Date: Tue Dec 05 2000 - 18:49:12 EST

  • Next message: Carl-Uno Manros: "RE: 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



    This archive was generated by hypermail 2b29 : Tue Dec 05 2000 - 19:55:55 EST