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
>>