Attached below are review comments on a bunch of IPP documents. Some of
these have been reviewed by the IESG; others await AD approval prior to
initial IESG presentation. They are grouped together primarily because
the IESG review in general and IANA/RFC Editor review in particular
raised a bunch of issues that affect all of these documents regardless of
status.
Ned
-------------- next part --------------
draft-ietf-ipp-implementers-guide-v11-02.txt
Internet Printing Protocol/1.1: Implementer's Guide [informational]
The RFC Editor reports that the abstract of this document is too long.
I suggest moving the IPP overview material that is currently in the
abstract to the introduction.
The document mentions [IANA-CS] but there is no mention in the
references section. I suspect it should be something like:
[IANA-CS] IANA Registry of Coded Character Sets:
ftp://ftp.iana.org/in-notes/iana/assignments/character-sets
The reference to [RFC2567] needs to be updated. The I-D string
draft-ietf-ipp-req-03.txt needs to be replaced with RFC 2567 and
the date needs to be updated to April 1999.
There's a missing closing brace on the [RFC2568] entry in the
references section.
The meaning of the security consideration section of this document is
unclear. It currently says:
6 Security Considerations
This section corresponds to the RFC2911 Section 8 "Security
Considerations.
It needs to say something like:
6 Security Considerations
The security considerations given in RFC2911 Section 8 "Security
Considerations" all apply to this document. In addition, the
following section describes security consideration that have arisen
as a result of implementation testing.
****
draft-ietf-ipp-job-printer-set-ops-03.txt
Internet Printing Protocol (IPP): Job and Printer Set Operations
[proposed]
First, a question/comment about registration procedures. If I
understand this stuff correctly, a new operation manifests in
two places: (1) As an operation a client can ask the printer
to perform and as a new attribute value a printer can return
when asked for the "operations-supported" printer attribute
If this is indeed the case, then shouldn't new operations result
in two registration entries: A new attribute value in the
attribute-value area under the operations-supported attribute
and a new operaiton in the operations area? If so, then I believe
it would be appropriate to indicate the new attribute values
created by this document in a new section 10.5.
The abstract of this document is much too long. The overview
material that is currently in the abstract needs to be moved to the
introduction.
The references to ftp.isi.edu throughout section 10 need to be
changed to ftp.iana.org. I would also suggest making them valid
ftp URLs.
The IANA has requested that the registrations in this document be
clarified. The authors are welcome to contact the IANA directly about
these concerns, however, based on the feedback from the IANA and
my comment above I suggest changing section 10 to read:
10 IANA Considerations
This section contains registration information for IANA to add to the
various IPP Registries according to the procedures defined in RFC 2911
[RFC2911] section 6.
Note to RFC Editors: Replace RFC NNNN below with the RFC number for
this document, so that it accurately reflects the content of the
information for the IANA Registry.
10.1 Operation Registrations
The following table lists all operations defined in this document.
These are to be registered according to the procedures defined in
RFC 2911 [RFC2911] section 6.4.
Operations: Ref. Section:
Set-Printer-Attributes RFC NNNN 4.1
Set-Job-Attributes RFC NNNN 4.2
Get-Printer-Supported-Values RFC NNNN 4.3
The resulting operation registrations will be published in the
ftp://ftp.iana.org/in-notes/iana/assignments/ipp/operations/ area.
10.2 Attribute Registrations
The following table lists all attributes defined in this document.
These are to be registered according to the procedures defined in
RFC 2911 [RFC2911] section 6.2.
Operation attributes: Ref. Section:
printer-message-from-operator (text(127)) RFC NNNN 5.1
job-message-from-operator (text(127)) RFC NNNN 5.2
Printer Description attributes: Ref. Section:
printer-settable-attributes-supported (1setOf type2 keyword)
RFC NNNN 6.1
job-settable-attributes-supported (1setOf type2 keyword)
RFC NNNN 6.2
document-format-varying-attributes (1setOf type2 keyword)
RFC NNNN 6.3
printer-message-time (integer(MIN:MAX)) RFC NNNN 6.4
printer-message-date-time (dateTime) RFC NNNN 6.5
printer-xri-supported (1setOf collection) RFC NNNN 6.6
xri-uri-scheme-supported (1setOf uriScheme) RFC NNNN 6.7
xri-authentication-supported (1setOf type2 keyword) 6.8
xri-security-supported (1setOf type2 keyword) RFC NNNN 6.9
The resulting attribute registrations will be published in the
ftp://ftp.iana.org/in-notes/iana/assignments/ipp/attributes/ area.
10.3 Status code Registrations
The following table lists the status code defined in this document.
This is to be registered according to the procedures defined in
RFC 2911 [RFC2911] section 6.6.
Status codes: Ref. Section:
'client-error-attributes-not-settable' (0x0413) RFC NNNN 7.1
The resulting status code registration will be published in the
ftp://ftp.iana.org/in-notes/iana/assignments/ipp/status-codes/
area.
10.4 Out-of-band Attribute Value Registrations
The following table lists all out-of-band attribute values defined in
this document. These are to be registered according to the procedures
defined in RFC 2911 [RFC2911] section 6.7.
Out-of-band Attribute Values: Ref. Section:
'not-settable' out-of-band value RFC NNNN 8.1
'delete-attribute' out-of-band value RFC NNNN 8.2
'admin-define' out-of-band attribute value RFC NNNN 8.3
The resulting out-of-band attribute value registrations will be
published in the ftp://ftp.iana.org/in-notes/iana/assignments/ipp/
out-of-band-attribute-value-tags/ area.
10.5 Additional values for the "operations-supported" Printer attribute
The following table lists all the new attribute values defined in
this document as new "operations-supported" type2 enums. These are
to be registered according to the procedures defined in RFC 2911
[RFC 2911] section 6.1.
Value Ref. Section:
Set-Printer-Attributes 0x0013 RFC NNNN 4.1
Set-Job-Attributes 0x0014 RFC NNNN 4.2
Get-Printer-Supported-Values 0x0015 RFC NNNN 4.3
The resulting attribute value registrations will be published in the
ftp://ftp.iana.org/in-notes/iana/assignments/ipp/attribute-values
/operations-supported/
area.
****
draft-ietf-ipp-collection-04.txt
Internet Printing Protocol (IPP): The 'collection' attribute syntax
[proposed]
I believe some corrections for this document were posted to the
ipp list. If so, since a new draft needs to be posted anyway you
might as well attend to them as part of the update.
The RFC editor reports that the abstract is too long. I suggest
moving the overview material to the introduction.
In the "References" section, reference [RFC2910] needs to be
updated. The I-D string and month and year need to be removed from the
citation and replaced with RFC 2910, September 2000.
In section 9.1 the reference to ftp.isi.edu needs to be changed to
ftp.iana.org.
The IANA requests that the registrations in this document be clarified.
The authors are welcome to contact the IANA about these concerns, however,
based on the feedback from the IANA I suggest changing section 9 to read:
9 IANA Considerations
The following table provides registration for the "collection"
attribute syntax defined in this document. This is to be registered
according to the procedures defined in RFC 2911 [RFC2911] section
6.3.
Note to RFC Editors: Replace RFC NNNN below with the RFC number for
this document, so that it accurately reflects the content of the
information for the IANA Registry.
Attribute Syntaxes: Ref. Section:
collection RFC NNNN 3
The resulting attribute syntax registration will be published in the
ftp://ftp.iana.org/in-notes/iana/assignments/ipp/attribute-syntaxes/
area.
Note that I have eliminated section 9.1 entirely.
****
draft-ietf-ipp-job-prog-02.txt
Internet Printing Protocol (IPP): Job Progress Attributes [proposed]
MUST is used without a definition (I missed this during my review -- sorry).
You need to add the usual section referencing RFC 2911 or RFC 2119.
Feedback from the RFC editor is that the abstract is too long.
It needs to be broken into "Abstract" and "Introduction" sections.
The reference to ftp.isi.edu in section 4.1 needs to be changed to
ftp.iana.org. I would also suggest making this a valid ftp URL.
Section 4.1 also isn't clear that it is registering the sheet-collate,
job-collation-type, sheet-completed-copy-number,
sheet-completed-document-number, and
impressions-completed-current-copy attributes.
Given the last two issues, I suggest changing 4 to read:
4 IANA Considerations
The attributes defined in this document shall be
registered by IANA according to the procedures in RFC 2911
[RFC2911] section 6.2. The following table lists all such
attributes in this document as well as the required registration
information:
Note to RFC Editors: Replace RFC NNNN below with the RFC number for
this document, so that it accurately reflects the content of the
information for the IANA Registry.
Job Template attributes: Ref. Section:
sheet-collate (type2 keyword) RFC NNNN 1.1
Job Description attributes: Ref. Section:
job-collation-type (type2 enum) RFC NNNN 2.1
sheet-completed-copy-number (integer(0:MAX)) RFC NNNN 2.2
sheet-completed-document-number (integer(0:MAX))RFC NNNN 2.3
impressions-completed-current-copy (integer(0:MAX))
RFC NNNN 2.4
The resulting list of registered attributes will be published
in the ftp://ftp.iana.org/in-notes/iana/assignments/ipp/attributes/
area.
****
draft-ietf-ipp-not-05.txt
Internet Printing Protocol: Requirements for IPP Notifications
[informational]
The RFC editor reports that the abstract is too long. It needs to be
broken into "Abstract" and "Introduction" sections.
In the "References" section, references [RFC2567], [RFC2568], and
[RFC 2569] need to be updated. The I-D strings need to be removed from
the citations and replaced with the RFC number and date published
(e.g., [RFC2567] - replace draft-ietf-ipp-req-03.txt, November 1998,
with RFC 2567, April 1999.)
****
draft-ietf-ipp-not-spec-06.txt
Internet Printing Protocol (IPP): IPP Event Notification Specification
[proposed]
The RFC editor reports that the abstract is too long. The IPP overview
material needs to be moved to the introduction.
In the "References" section reference [IANA-CON] needs to be updated.
The I-D string and month and year need to be removed from the citation
and replaced with BCP 26, RFC 2434, October 1998.
The IANA considerations section needs work. In addition to having the
same problems as previous IPP documents, I believe section 13.2 is
out of whack. This document defines a number of new operations and as
part of that it defines new attribute values for the
operations-supported attribute. But it doesn't define the
operations-supported attribute itself, as this section sort of
indicates.
Whether or not the new attribute values for operations-supported
attribute need to be listed as new attribute values independent of
enumerating the new operations themselves gets back to the issue I
raised in draft-ietf-ipp-job-printer-set-ops-03.txt. In that
document they weren't listed and I added them. I think this is what
section 13.2 needs to do.
Another issue with the IANA considerations section is that it
doesn't mention the "notify-schemes-supported" attribute. Should
it? (Note that I didn't add it below since I wasn't sure that
it should be there.)
I therefore suggest all of section 13 except for section 13.7
be changed to something like:
13 IANA Considerations
This section contains registration information for IANA to add to the
various IPP Registries according to the procedures defined in RFC 2911
[RFC2911] section 6. In addition, two new registries are defined:
One for event notification delivery methods and another for IPP
delivery methods.
Note to RFC Editors: Replace RFC NNNN below with the RFC number for
this document, so that it accurately reflects the content of the
information for the IANA Registry.
13.1 Attribute Registrations
The following table lists all attributes defined in this document.
These are to be registered according to the procedures defined in
RFC 2911 [RFC2911] section 6.2.
Subscription Template attributes: Ref. Section:
notify-recipient-uri (uri) RFC NNNN 5.3.1
notify-events (1setOf type2 keyword) RFC NNNN 5.3.2
notify-attributes (1setOf type2 keyword) RFC NNNN 5.3.3
notify-user-data (octetString(63)) RFC NNNN 5.3.4
notify-charset (charset) RFC NNNN 5.3.5
notify-natural-language (naturalLanguage) RFC NNNN 5.3.6
notify-lease-duration (integer(0:67108863)) RFC NNNN 5.3.7
notify-time-interval (integer(0:MAX)) RFC NNNN 5.3.8
Subscription Description Attributes:
notify-subscription-id (integer (1:MAX))) RFC NNNN 5.4.1
notify-sequence-number (integer (0:MAX))) RFC NNNN 5.4.2
notify-lease-expiration-time (integer(0:MAX))) RFC NNNN 5.4.3
notify-printer-up-time (integer(1:MAX))) RFC NNNN 5.4.4
notify-printer-uri (uri)) RFC NNNN 5.4.5
notify-job-id (integer(1:MAX))) RFC NNNN 5.4.6
notify-subscriber-user-name (name(MAX))) RFC NNNN 5.4.7
Printer Description Attributes:
printer-state-change-time (integer(1:MAX))) RFC NNNN 6.1
printer-state-change-date-time (dateTime)) RFC NNNN 6.2
Attributes Only in Event Notifications
notify-subscribed-event (type2 keyword) RFC NNNN 8.1
notify-text (text(MAX)) RFC NNNN 8.2
The resulting attribute registrations will be published in the
ftp://ftp.iana.org/in-notes/iana/assignments/ipp/attributes/ area.
13.2 Additional values for the "operations-supported" Printer attribute
The following table lists all the new attribute values defined in
this document as new "operations-supported" type2 enums. These are
to be registered according to the procedures defined in RFC 2911
[RFC 2911] section 6.1.
Value Ref. Section:
Create-Job-Subscriptions 0x0017 RFC NNNN 11.1.1
Create-Printer-Subscriptions 0x0016 RFC NNNN 11.1.2
Get-Subscription-Attributes 0x0018 RFC NNNN 11.2.3
Get-Subscriptions 0x0019 RFC NNNN 11.2.4
Renew-Subscription 0x001A RFC NNNN 11.2.5
Cancel-Subscription 0x001B RFC NNNN 11.2.6
The resulting attribute value registrations will be published in the
ftp://ftp.iana.org/in-notes/iana/assignments/ipp/attribute-values
/operations-supported/
area.
13.3 Operation Registrations
The following table lists all operations defined in this document.
These are to be registered according to the procedures defined in
RFC 2911 [RFC2911] section 6.4.
Operations: Ref. Section:
Create-Job-Subscriptions Operation RFC NNNN 11.1.1
Create-Printer-Subscriptions operation RFC NNNN 11.1.2
Job Creation Operations - Extensions RFC NNNN 11.1.3
Validate-Job Operation - Extensions RFC NNNN 11.2.1
Get-Printer-Attributes - Extensions RFC NNNN 11.2.2
Get-Subscription-Attributes operation RFC NNNN 11.2.3
Get-Subscriptions operation RFC NNNN 11.2.4
Renew-Subscription operation RFC NNNN 11.2.5
Cancel-Subscription operation RFC NNNN 11.2.6
The resulting operation registrations will be published in the
ftp://ftp.iana.org/in-notes/iana/assignments/ipp/operations/ area.
13.4 Status code Registrations
The following table lists the status codes defined in this document.
These are to be registered according to the procedures defined in
RFC 2911 [RFC2911] section 6.6.
Status codes: Ref. Section:
successful-ok-ignored-subscriptions (0x0003) RFC NNNN 16.1
client-error-ignored-all-subscriptions (0x0414) RFC NNNN 16.2
Status Codes in Subscription Attributes Groups:
client-error-uri-scheme-not-supported (0x040C) RFC NNNN 17.1
client-error-too-many-subscriptions (0x0415) RFC NNNN 17.2
successful-ok-too-many-events (0x0005) RFC NNNN 17.3
successful-ok-ignored-or-substituted-attributes (0x0001)
RFC NNNN 17.4
The resulting status code registrations will be published in the
ftp://ftp.iana.org/in-notes/iana/assignments/ipp/status-codes/
area.
13.5 Attribute Group tag Registrations
The following table lists the attribute group tags defined in
this document. These are to be registered according to the procedures
defined in RFC 2911 [RFC2911] section 6.5.
Attribute Group Tags: Ref. Section:
subscription-attributes-tag RFC NNNN 18
event-notification-attributes-tag RFC NNNN 18
The resulting attribute group tag registrations will be published in the
ftp://ftp.iana.org/in-notes/iana/assignments/ipp/attribute-group-tags/
area.
13.6 Format for Event Notification Delivery Method Registration
proposals
This section describes the procedures for registering Event
Notification Delivery Method proposals with IANA to be used with this
document. Such Delivery Method proposals that require a new URL
scheme MUST be defined by an IETF standards track document according
to RFC 2717 [RFC2717].
Section 13.7 also needs work. The problem is that it lists a number of
requirements registrations must meet, but doesn't specify a mechanism
for reviewing registrations to see that they meet these requirements.
This is necessary; see RFC 2434. Needless to say, the process once
defined needs to be followed by subsequent notification mechanism
drafts.
****
draft-ietf-ipp-indp-method-05.txt
Internet Printing Protocol (IPP): The 'indp' Delivery Method for Event
Notifications and Protocol/1.0 [proposed]
This material in table 1 doesn't make sense to me:
8. What are the latency and
reliability of the transport itselfs(see [RFC2911]).IPP/1.1
and delivery protocol?
9. What are the security aspects 15
of the transport and delivery
protocol, e.g., how it is See section
handled in firewalls?
Section 6.2.1 talks about adding a value to the notify-schemes-supported
attribute. Where is this attribute defined? I cannnot find it anywhere.
Section 12.2 and elsewhere. I don't see any reason why you cannot go ahead
and get a port allocated for IDNP now, rather than waiting for it to be
done for you later. (According to the IANA web page all you need to
have is a published internet-draft to put the registration in.) Doing it
yourselves insures that the port number appears in all the right places
and also cleans up the IANA considerations section. (Note that the
separation of the IANA and RFC Editor functions has made IANA
registration actions that then require document revision somewhat
awkward.)
The first two paragraphs of section 12.5 appear to be unnnecessary
duplicates of the first two paragraphs of section 12.1, and should
be deleted. (Unless, of course, I'm missing something.)
The IANA considerations section needs work. I suggest it be changed to
something like the following.
13 IANA Considerations
IANA shall register the indp URL scheme as defined in section 12.
The rest of this section contains the exact information for IANA to
add to the IPP Registries according to the procedures defined in RFC
2911 [RFC2911] section 6.
Note to RFC Editors: Replace RFC NNNN below with the RFC number
for this document, so that it accurately reflects the content of
the information for the IANA Registry.
13.1 Operation Registrations
The following table lists the operation defined in this document.
This are to be registered according to the procedures defined in
RFC 2911 [RFC2911] section 6.4.
Operations: Ref. Section:
Send-Notifications operation RFC NNNN 8.1
The resulting operation registration will be published in the
ftp://ftp.iana.org/in-notes/iana/assignments/ipp/operations/ area.
13.2 Additional values of existing attributes
13.2.1 Additional values for the "notify-schemes-supported" Printer
attribute
The following table lists the additional value for the
"notify-schemes-supported" uriScheme attribute value that has
been defined in this document. It will be registered by IANA
according to the procedures in RFC 2911 [RFC2911] section 6.1.
Ref. Section:
indp RFC NNNN 6.2.1
The resulting attribute value registration will be published in the
ftp://ftp.iana.org/in-notes/iana/assignments/ipp/attribute-values
/notify-schemes-supported/
area.
13.2.2 Additional values for the "operations-supported" Printer
attribute
The "operations-supported" type2 enum attribute value defined in this
document will be registered by IANA according to the procedures in RFC
2911 [RFC2911] section 6.1. The attribute value to register is:
Value Ref. Section:
Send-Notifications 0x001D RFC NNNN 6.2.1
The resulting attribute value registration will be published in the
ftp://ftp.iana.org/in-notes/iana/assignments/ipp/attribute-values
/operations-supported/
area.
13.3 Status code Registrations
The following table lists the status codes defined in this document.
These are to be registered according to the procedures defined in
RFC 2911 [RFC2911] section 6.6.
Status codes: Ref. Section:
successful-ok-ignored-notifications (0x0004) RFC NNNN 9.1.1
client-error-ignored-all-notifications (0x0416) RFC NNNN 9.1.2
The resulting status code registrations will be published in the
ftp://ftp.iana.org/in-notes/iana/assignments/ipp/status-codes/
area.
****
draft-ietf-ipp-ops-admin-req-00.txt>
Internet Printing Protocol (IPP):
Requirements for Job, Printer, and Device Administrative Operations
[informational]
This document appears to have expired, in spite of the fact that
you asked for publication as Informational back on 19 Sep 2000.
Is the intention still to publish it? In any case, I have reviewed it
and my comments appear below. If the intent is not to publish it is
no big deal.
The first paragraph of the abstract is unnecessary and should
be deleted.
Abstract, second paragraph. The word "OPTIONAL" should not be
capitalized in this context.
Abstract, third paragraph. "The scope of IPP, is characterized" ->
"The scope of IPP is characterized"
The fourth and subsequent paragraphs of the abstract do not belong
in an abstract. If there is a desire to retain them they should be
moved to some sort of "overview of IPP" section.
The word "MAY" is capitalized at various places in this document
and should not be.
All references to ipp-mod and ipp-pro should be replaced with
RFC 2911 and RFC 2910, respectively.
Section 4. This makes it sound like this document actually
registers some operations with IANA when in fact it does not.
The reference to the obsolete RFC 2566 doesn't make sense
either, nor does the FTP path. I suggest that this section simply
be removed; an informational requirements document like this
would only have IANA considerations if it imposed requirements
on possible new registries in this space, and as far as I can
tell it doesn't do anything like that. But if the section
is to be retained it needs to be reworded to talk about
possible IANA registration requirements while making it clear
that nothing is actually being registered.
Section 6. The security considerations given are about IPP in
general; they need to be rewritten or amended to deal with
issues specific to administrative operations.