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

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

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

From: Scott Hollenbeck (sah@428cobrajet.net)
Date: Tue Mar 16 2004 - 12:00:50 EST

  • Next message: Scott Hollenbeck: "IPP> IESG Comments: draft-ietf-ipp-ops-set2"

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



    This archive was generated by hypermail 2b29 : Tue Mar 16 2004 - 12:01:26 EST