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