Subject: IPP> FW: IESG review comments on IPP Notifications specs - May 2003

From: "McDonald, Ira" <[email-masked]>
Date: Mon, 25 Jul 2005 15:32:02 -0700

Hi folks,

These are from a local email copy of mine - haven't searched
the PWG archive for this note or for Ned Freed's additional
comments on specifically IPP Mailto.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

------------------------------------------------------

From: Carl [[email-masked]]
Sent: Sunday, May 04, 2003 8:50 PM
To: [email-masked]
Subject: IPP> 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 [email-masked]
Web    www.manros.com

-----Original Message-----
Date: Sun, 04 May 2003 14:28:27 -0700 (PDT)
From: [email-masked]
Subject: IESG review comments on the revised notification documents
To: [email-masked]
Cc: [email-masked]
Message-id: <[email-masked]>
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?