IPP> IESG Comments: draft-ietf-ipp-not-spec

IPP> IESG Comments: draft-ietf-ipp-not-spec

IPP> IESG Comments: draft-ietf-ipp-not-spec

Scott Hollenbeck sah at 428cobrajet.net
Tue Mar 16 12:00:50 EST 2004

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



 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 

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

         This section contains rule for special cases.

 I cannot figure out what this means, but I think it can simply be 

 4. Section 19 (a.k.a. Appendix D) is using words that are already 
 defined in RFC 2119. Why?


 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 
 doesn't have any mechanism to prevent abuse of the third party
 notifications. If you allow the printer to optionally parse the 
 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. 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 
 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 
 specified in the "notify-charset" attribute. This section should 
 how to avoid conflict if text/plain has a charset parameter that does 
 match the notify-charset attribute. Disallowing a charset parameter 
 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, 
 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, 
 though the cited RFC 2911 makes that clear, it might be useful
 to say "additional ENUM Attribute Value Registrations within the IPP 
 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 
 common form and leave the question of whether it is normative or
 informative to the lawyers.

 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.

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.


 - Document draft-ietf-ipp-not-spec-11.txt on page 37 says:
         The 0 value is not permitted in order to allow for compatibility
         "job-id" and with SNMP index values, which also cannot be 0.

     And that is not exactly correct. First of all, most people will
     understand what is meant by "SNMP index value". But "MIB table index
     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
     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

More information about the Ipp mailing list