Tom,
One correction, as we have put some of the latest interoperability
resolutions in the Implementer's Guide, I expect to make a Last Call on that
draft, as we discussed in the last IPP telecon.
Carl-Uno
Carl-Uno Manros
Manager, Print Services
Xerox Architecture Center - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: manros at cp10.es.xerox.com
-----Original Message-----
From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
Sent: Wednesday, January 24, 2001 4:36 PM
To: ipp (E-mail)
Subject: FW: IPP> AD review of a bunch of IPP documents
Peter Zehler just called me from the IPP WG meeting to ask about the Area
Director's comments on the 6 IPP documents indicated in the detailed agenda.
Here is a repeat of Ned's comments as sent out on December 5, 2000. I have
finished most of the edits. They were only editorial as indicated by Ned
and so do not need another IPP WG Last Call.
I hope to publish them as Internet-Drafts this week. Then Ned will forward
them to the IESG for their Last Call.
Tom
-----Original Message-----
From: ned.freed at innosoft.com [mailto:ned.freed at innosoft.com]
Sent: Tuesday, December 05, 2000 15:49
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