> Tom, any chance that you can dig out the exact Area Director
> comments on
> these drafts and republish them on the DL to remind us all
> what they were?
As the new AD I'll jump in here and post what I see in the IESG's document
tracker. One message per document (I currently see 4 enqueued) with all
comments included.
-Scott-
----------
DISCUSS:
========
Russ:
Comments:
1. Numbering in section 5.2 is confusing (at least to me). Shouldn't
paragraph 4 contain subparagraphs with letters a) and b)?
2. Section 5.3.1 says:
The Printer MUST treat the address part of this attribute as
opaque.
This seems like a very bad idea. The security considerations
acknowledge that IPP notifications can be a source of SPAM. If the
Printer is not allowed to look at the address portion of a URL, how
can a vendor implement responsible filters?
3. Section 5.3.3.5.3 says:
This section contains rule for special cases.
I cannot figure out what this means, but I think it can simply be
deleted.
4. Section 19 (a.k.a. Appendix D) is using words that are already
defined in RFC 2119. Why?
Ted:
In the rules for processing subscription Template Attributes, Section
5.2, Rule 8 d, the Status code 'client-error-too-many-subscriptions'
indicates that the client SHOULD try again later when a subscription
object could not be created because the printer is out of space
for subscription objects. For the per-job subscription, this seems
too strong a recommendation, given that the job may complete
while the client waits to resubscribe. Is there another reason this
is not a MAY?
In notify-recipient-uri (Section 5.3.1, page 23), there is a
requirement that
the printer MUST treat the address part of the attribute as opaque.
This doesn't
make sense to me. One of the real security issues here is that the
system
doesn't have any mechanism to prevent abuse of the third party
notifications. If you allow the printer to optionally parse the
address,
you could at least have simple rules like "all notifications must be
within example.com". I don't see any reason to disallow that
by forcing the printers to treat them as opaque. They MAY treat
them as opaque, of course.
5.3.3.5.3 on special cases for matching rules says that a printer MUST
NOT try to consolidate seemingly identical even notifications and MUST
NOT reject subscription creation operations that would create this
scenario.
Splitting the examples so that they handled this case separately
would help, as the current text mixes the allowed case (delivering a
notification for only the more specific state when two are subscribed)
with this case in confusing ways.
8.2 says that the message in notify-text is in text/plain with the
charset
specified in the "notify-charset" attribute. This section should
explain
how to avoid conflict if text/plain has a charset parameter that does
not
match the notify-charset attribute. Disallowing a charset parameter
would
work, but it needs to be specified.
The structure of the appendices is pretty strange for an RFC, given
that Appendices A-F occur in what we would consider the body
of the RFC, and G and H after. I'd suggest that the appendices prior
to the Authors' addresses be given normal section identifiers,
especially
since they are interleaved with standard text. Also, do we
commonly have normative appendices (see Appendix D, for example)?
The IANA registration section 24.2 indicates an Enum attribute value
registration. This is actually in the ipp-registrations IANA registry,
and
though the cited RFC 2911 makes that clear, it might be useful
to say "additional ENUM Attribute Value Registrations within the IPP
registry"
to avoid confusion.
The document lists the Copyright statement as an appendix (appendix H)
and gives its status as Informative. I think it would be better to use
the
common form and leave the question of whether it is normative or
informative to the lawyers.
Allison:
Overall I would give the documents a no-objection, though they are
repetitive and under-edited. But draft-ietf-ipp-notify-get-09.txt
leads me to a Discuss because of the following material. The first
Note is too casual the error condition if the connection is closed and
the client does not receive a response. What is the recovery after
this? Does it not depend on the particular response? Some are more
critical than others: the system is not made to be idempotent. The
document needs to recommend (Strong SHOULD) that the peers not do
abnormal connection close. TCP CLOSE ensures delivery of the data so
it can be ensured that the response has been received. Also, when a
proper TCP CLOSE is done, because for instance the printer server
wants to reduce some transport state, it will keep the the IPP state
of the client, or not? This is something that should be stated here.
The second Note is ungrammatical (no proxy want) and unnecessary in
this overlong document. The printer protocol cannot control what
proxies in its environment will do, right?
--------
4. If the client requested Event Wait Mode ("notify-wait" =
'true'), and the Printer initially honored the request, but
later wishes to leave Event Wait Mode, the Printer MUST
return the "notify-get-interval" operation attribute (see
section 5.2.1). The Printer returns the response as an
application/ipp part which MUST be inside an
multi-part/related type.
Note: All of the above is without either the Printer or the
Notification Recipient closing the connection. In fact, the
connection SHOULD remain open for any subsequent IPP operations.
However, either the Notification Recipient or the Printer can
abnormally terminate by closing the connection. But, if the
Printer closes the connection too soon after returning the
response, the client may not receive the response.
The Printer MAY chunk the responses, but this has no
significance to the IPP semantics.
Note: While HTTP/1.1 allows a proxy to collect chunked responses
over a period of time and return them back as a single
un-chunked response (with a Content Length instead). However, in
practice no proxy wants to have an infinite buffer. Also no
proxy want to hold up responses, since user would be furious.
COMMENTS:
=========
Steve:
I would be nice to add (via RFC editor's note) some text to Appendices
A and B that warns about the security risks of proxied notifications.
Security is then no longer end-to-end, which creates some added risks.
Bert:
However,
- Document draft-ietf-ipp-not-spec-11.txt on page 37 says:
The 0 value is not permitted in order to allow for compatibility
with
"job-id" and with SNMP index values, which also cannot be 0.
And that is not exactly correct. First of all, most people will
probably
understand what is meant by "SNMP index value". But "MIB table index
value"
would be the better/correct terminology.
Also, such an index value is recommended NOT to be zero, but legaly it
actually can take a value of zero. Maybe not in the table that they
use it in (which they are not specifying).
As I said, I think most people will understand, only an occasional
purist
may bitch about it, so I don't want to raise a discuss for this.
- document draft-ietf-ipp-not-06.txt
- uses FQDN like IBM.COM instead of example.com (page 4)
- Are the question marks on pages 10/11 meant as bullets, or does it
indicate that they have no idea which of these are real
requirements?