IFX Mail Archive: IFX> FW: IPP> NOT - IESG review comment

IFX> FW: IPP> NOT - IESG review comments on the revised notification d ocuments

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Tue Jun 10 2003 - 10:44:29 EDT

  • Next message: McDonald, Ira: "RE: IFX> June 11 Conference topic: IPP-GET notifications"

    Hi,

    Background for the discussion tomorrow about IPPGET notifications.

    Of course, the main task is to convert the two IETF specs
    (Notifications base and IPPGET) into IEEE PWG-style specs.
    For that we need editors (Tom Hastings has said that he is
    not available to take on this work).

    The two most recent Notifications I-Ds (21 Feb 2003) are:

    ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-not-spec-11.txt

    ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-notify-get-09.txt

    Cheers,
    - Ira McDonald
      High North Inc

    -----Original Message-----
    From: Carl [mailto:carl@manros.com]
    Sent: Sunday, May 04, 2003 8:50 PM
    To: ipp@pwg.org
    Subject: IPP> NOT - IESG review comments on the revised notification
    documents

    Please see IESG comments on Notification drafts below.

    It seems there is still a fair amount of work for the document editors to
    get these drafts through for IETF publication.

    Carl-Uno

    Carl-Uno Manros
    700 Carnegie Street #3724
    Henderson, NV 89052, USA
    Tel +1-702-617-9414
    Fax +1-702-617-9417
    Mob +1-702-525-0727
    Email carl@manros.com
    Web www.manros.com

    -----Original Message-----
    Date: Sun, 04 May 2003 14:28:27 -0700 (PDT)
    From: ned.freed@mrochek.com
    Subject: IESG review comments on the revised notification documents
    To: ipp@pwg.org
    Cc: ned.freed@mrochek.com
    Message-id: <01KVHWNL7QZQ002O3W@mauve.mrochek.com>
    MIME-version: 1.0
    Content-type: TEXT/PLAIN; CHARSET=us-ascii
    Content-transfer-encoding: 7BIT

    The IESG has reviewed the revised IPP notification specifications and
    has raised a fair number of discussion points. In keeping with new
    IESG policies, these discuss comments have been posted on the datatracker
    and are identified by the IESG member who made them. I'll also include a
    copy
    of the comments below.

                                    Ned

    Russ:

     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.

    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 Jun 10 2003 - 10:44:56 EDT