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

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Jul 2004 23:24:54 -0400

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Jul 2004 10:38:13 -0400

A few more comments, starting with the examples:

11.1 - the numbering of the messages doesn't agree with what is in the 
diagram. Also, message 5 is missing a blank line between Content-Type 
and the body.

11.3 - I find the sysadmin example highly unlikely. Why would MSRP 
(rather than page mode MESSAGE) be used for this? A session would first 
have to be established. This would only make sense if there was already 
a session established, or there was expectation that many such messages 
will be sent using the same session.

11.4 - I presume the last message in this example was intended to be 
REPORT, not SEND.

11.5 - Nice example! s/MSPR/MSRP/
Toward the end, when the MSRP session is set up to the nurse, I believe 
"art thou hither" would be sent, just as it was to the other attempts.

12. Extensibility

I believe the decision was that we didn't need version numbers because 
sessions are established using another protocol (e.g. SIP) which can 
handle version negotiation. But we don't have any provision for versions 
there either. The only options I can see that are open for revisions are:

- use a different scheme name (not msrp) in the urls. (ugh)
- invent a new a-line to carry versioning information that can be
   negotiated.

Another possibility, if we plan now, is to put a little more 
extensibility into the msrp url, such as:

         resource] ";" transport *( ";" msrp-option )
       msrp-option = gen-param

This would of course require a change to the comparison rules for urls, 
and could make comparison somewhat more complex.

I think we just have a clear idea of a workable strategy for moving to a 
revised protocol.

	That's it,
	Paul

---

From: Ben Campbell <[email-masked]>
Date: Wed, 28 Jul 2004 15:41:02 -0500

On Jul 21, 2004, at 10:24 PM, Paul Kyzivat wrote:

[...]

> have contradictory transports in a single url.

It is impossible now. But if someone does an SCTP extension, we don't 
want URLs that include both a TCP and an SCTP token.

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

Hmm. How do we do that for other schemes?

> ones defined with mime aren't especially specific, and the ones 
> defined with sip aren't especially meaningful.
>

It seems to me the same level of vagueness that is appropriate for 
email is appropriate here. (How's that for a cop-out.)  Or in other 
words: I don't know, does anyone care?

[...]

> sessions in same offer or answer. Or do we have another answer to 
> that? (I only remember this fuzzily - I may be crazy.)
>

I think you are right. Maybe we need to go back to allowing any value 
there, with a "SHOULD be 9 if that does not create a conflict" clause.

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

I think we have a terminology problem. The remember, a message of type 
"foo/bar" can be sent as many chunks. The point was, the max-size 
refers to the entire "foo/bar" message, not each individual chunk.

[...]

---

From: Ben Campbell <[email-masked]>
Date: Wed, 28 Jul 2004 15:44:30 -0500

On Jul 22, 2004, at 9:38 AM, Paul Kyzivat wrote:

> (rather than page mode MESSAGE) be used for this? A session would 
> first have to be established. This would only make sense if there was 
> already a session established, or there was expectation that many such 
> messages will be sent using the same session.
>

OK, would a better example be to have a conference owner say "this 
conference is about to end"?

> 11.4 - I presume the last message in this example was intended to be 

Yes.

> Toward the end, when the MSRP session is set up to the nurse, I 
> believe "art thou hither" would be sent, just as it was to the other 
> attempts.
>
> 12. Extensibility
>
> handle version negotiation. But we don't have any provision for 
> versions there either. The only options I can see that are open for 
> revisions are:
>

That is sort of what I was assuming...

> This would of course require a change to the comparison rules for 
> urls, and could make comparison somewhat more complex.
>
> I think we just have a clear idea of a workable strategy for moving to 
> a revised protocol.

I don't have a strong opinion here. Others?

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Jul 2004 18:35:33 -0400

> want URLs that include both a TCP and an SCTP token.

You miss my point, I think. My point is not that we don't have two 
different kinds of transports to conflict. It is that the specified 
syntax for a msrp url doesn't allow there to be two transport parameters 
at all.

For instance, an MSRP URL with multiple, conflicting transports might be:

       msrp://host.example.com:8493/asfd34;tcp;sctp

But that isn't legal according to the syntax:

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

If an sctp extension was defined, then

       msrp://host.example.com:8493/asfd34;sctp

would be legal, but that doesn't have multiple conflicting transports. 
For multiple conflicting transports, the syntax must permit the 
transport parameter to be repeated.

I don't really see why it would be useful to have multiple transport 
parameters, so I see no reason to change the syntax for that. So I think 
it would be sufficient to remove the highlighted sentence above.

> Hmm. How do we do that for other schemes?

I believe each scheme has its own comparison rules. For sip comparison 
is at least component by component. 3261 is not specific on whether the 
port is compared numerically or alphanumerically, but I know of at least 
one stack that compares them numerically. Similarly, I don't really know 
if ip addresses are to be compared numerically or alphanumerically.

That is why I am asking. If the assumption here is that entire urls can 
be compared alphanumerically, it puts constraints on the creators of 
those URLs to write them in canonical form. But I see no requirement to 
do so.

> It seems to me the same level of vagueness that is appropriate for email 
> is appropriate here. (How's that for a cop-out.)  Or in other words: I 
> don't know, does anyone care?

Well, do the people implementing IM know what mail programs do? Is it 
even written down? Are mail and IM sufficiently similar to know what to do?

E.g. suppose I want to send LoTR.mpg as a message. When it arrives there 
are at least two possibilities:
- the receiving client could render it directly, as streaming video
- it could be stored for future viewing.

I suspect this could be distinguished by the content-disposition - 
'render' means play it now, while perhaps 'attachment' means save it for 
later. But in other sip contexts I see 'attachment' used as a random 
catchall.

We can leave it vague for now in the interest of getting something done. 
But I think it calls for followup work.

> "foo/bar" can be sent as many chunks. The point was, the max-size refers 
> to the entire "foo/bar" message, not each individual chunk.

I think you miss my point again. It has nothing to do with chunking.

Suppose that max sizes have been declared as follows:

- text/plain: 128
- text/html: 1024

Now suppose I have a message that contains:

- multipart/alternative
   - text/plain - size 256
   - text/html  - size 512

and suppose the total size of the multipart/alternative is 1500 (256 + 
512 + some extra).

What limits apply, and to what?
- Is it ok because there is no limit for multipart/alternative
   and that is all that matters?
- Is it bad because 256 exceeds the max size for text/plain?
- Is it bad because 1500 exceeds the size for text/plain?
- ???

And does it make sense to include the message headers in the limit? The 
size of the headers is an independent variable vs the size of the body. 
It can't help with buffering strategy, because you have to read the 
headers before you know what type the body is. And if the size applies 
to the reassembled message, it is built after headers have been 
processed anyway.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Jul 2004 18:44:43 -0400

> conference is about to end"?

Yes, that is a much better one! (Wish I had thought of it.)

> That is sort of what I was assuming...

Ugh! That would be unpleasant. Do the keepers of scheme names want us 
using them for version control?

> I don't have a strong opinion here. Others?

I'm pretty confident that this protocol will need to be revised.

I also suspect we are going to need extra url parameters for something. 
In fact, it seems that Rohan has already had in mind the use of 
parameters to multiplex a single msrp url assigned by a relay for 
multiple sessions at the client.

If we need url parameters anyway then using one to convey the protocol 
version is little extra pain.

	Paul

---

From: Ben Campbell <[email-masked]>
Date: Wed, 28 Jul 2004 18:00:17 -0500

> - Is it bad because 1500 exceeds the size for text/plain?

OK, I get it now. I interpret it to mean this is okay _if_ the imbedded 
text/plain does not exceed any limit for text plain _and_ the text/html 
does not exceed its limit, etc. If their had been a limit specified on 
multipart/alternative, then it would imply to the entire object.

> And does it make sense to include the message headers in the limit? 
> The size of the headers is an independent variable vs the size of the 
> body. It can't help with buffering strategy, because you have to read 
> the headers before you know what type the body is. And if the size 
> applies to the reassembled message, it is built after headers have 
> been processed anyway.

I don't think the headers should count here. We are talking about 
content size.