IPP Mail Archive: RE: IPP> AD review of a bunch of IPP docum

IPP Mail Archive: RE: IPP> AD review of a bunch of IPP docum

RE: IPP> AD review of a bunch of IPP documents

From: Carl-Uno Manros (carl@manros.com)
Date: Tue Dec 05 2000 - 21:17:28 EST

  • Next message: Hastings, Tom N: "IPP> RE: IPP print channel Discovery using SSDP"

    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@pwg.org [mailto:owner-ipp@pwg.org]On Behalf Of
    > ned.freed@innosoft.com
    > Sent: Tuesday, December 05, 2000 3:49 PM
    > To: ipp@pwg.org
    > Cc: ned.freed@innosoft.com; paf@cisco.com; scoya@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
    >
    >



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