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