[Simple] Comments on draft-ietf-simple-message-sessions-07

[Paul Kyzivat <pkyzivat at cisco.com>]

Ben,

This is great!!! It is really coherent and readable now.
The following are a few things I found in a first read thru,
up to the examples. These are largely nits.

	Paul

4.4 Connection Model, 3rd paragraph:

s/hostname port of the URL/hostname part of the URL/
                                     ^

5. MSRP URLs

      transports.  A MSRP URL with multiple, contradictory transports is
      invalid, unless some other document specifies meaning for the
      particular combination of transport parameters.

I don't understand the above. The specified syntax for the url only 
permits a single transport token, so it is syntactically impossible to 
have contradictory transports in a single url.

   An MSRP URL server part identifies a participant in an MSRP session.
   If the server part contains a numeric IP address, it MUST also
   contain a port.  The resource part identifies a particular session

The term 'server' is defined in RFC2396, but it isn't used in the 
definition of the MSRP_urls, so its reference here is undefined. This 
could be fixed by changing the syntax to:

      MSRP_urls = msrp-scheme "://" server ["/"
        resource] ";" transport
      server = [userinfo "@"] hostport
      msrp-scheme = "msrp" / "msrps"
      resource = 1*unreserved
      transport = "tcp" / token

This definition is consistent with the one in 2396, in that the same 
names are used for the same parts of the url, though this is more 
restrictive.

5.1 URL comparison

"The host part is compared as case insensitive". What if it is an ip 
address? is it compared char by char? (What about leading zeros?)

Is port comparison char by char, or numeric? (leading zeros again.)

6.1.1 Delivering SEND requests

   The default disposition of body is "render".  If the sender wants
   different disposition, it MAY insert a Content-Disposition header.
   Since MSRP is a binary protocol, transfer encoding MUST be "binary".

Are we supposing any particular semantic to content-dispositions? The 
ones defined with mime aren't especially specific, and the ones defined 
with sip aren't especially meaningful.

6.3.1  Receiving SEND requests

   What is done with the body is outside the scope of MSRP and largely
   determined by the MIME type.  The body MAY be rendered after the
   whole message is received or partially rendered as it is being
   received.

Content-Disposition was mentioned earlier. Perhaps it should also be 
mentioned here, as in:

   What is done with the body is outside the scope of MSRP and largely
   determined by the MIME Content-Type and Content-Disposition.  The
   body MAY be rendered after the whole message is received or partially
   rendered as it is being received.

If we were going to discuss the significance of content dispostions, 
someplace near here would be a good place to do it.

7.1  SDP Offer-Answer Exchanges for MSRP Sessions

      While MSRP could theoretically carry any media type, "message" is
      appropriate.  For MSRP, the port number is always ignored--the
      actual port number is provided in an MSRP URL.  Instead "9" is
      used, which is an innocuous value which is assigned to the discard
      port.  The protocol is always "msrp", and the value of the format
      list is always a single asterisk character ("*").

I thought we determined that the same address+port can't be used for 
more than one media session in the same SDP. If so, then it must be 
possible to use other port values, in order to permit multiple msrp 
sessions in same offer or answer. Or do we have another answer to that? 
(I only remember this fuzzily - I may be crazy.)

      All types listed in either the accept-types or
      accept-wrapped-types attributes MAY include a max-size parameter,
      indicating the largest message it is willing to accept of that
      type.  Max-size refers to the complete message, not the size of
      any one chunk.  Senders MUST NOT exceed the max-size limit, if
      any, when sending messages of any listed type.  If a type is
      listed without the parameter, then no preset size limit exists.

Its weird to associate the size with a type, but make the size apply to 
the message. The size should apply to the encoded body part representing 
the type. This is especially important when a type might be placed in a 
wrapper that can also contain other types.

9.  Formal Syntax

No definition of namespace.

Syntax of Report-Success and Report-Failure doesn't have for the 
"receipt-type" parameter referenced in section 6.1.2:

   REPORT requests MAY include a body.  If a body is included, it SHOULD
   be of the DSN MIME type detailed in RFC1894 [8], but MAY be of some
   other type if the sender of the SEND request indicated support in the
   "receipt-type" parameter of the respective Report-Success or
   Report-Failure header field.  This parameter contains the alternative

That's all for now.


_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple