Subject: [Simple] MSRP Comments - specific issues

From: Aki Niemi <[email-masked]>
Date: Thu, 16 Oct 2003 18:55:34 +0300

Hi,

I tried to make a truly thorough read of MSRP, and provide some comments 
on it. I didn't have time to go through the examples, though. Maybe next 
time ;)

Here are first some specific issues about the draft. Mainly some 
corrections and clarifications. I will send a separate email with all of 
the nits I found in the draft.

I will probably also send a couple of other emails each with a bit 
bigger issue I felt might be important to address separately.

Regards,
Aki

---

- Chapter 1, 1st paragraph, last sentence: Should probably add that in 
page-mode, there is usually only an imaginative session, but messages 
are not related in any other way. Versus in session mode where there is 
a concrete relationship between messages.

- Ch 2., 1st para., last sentence is confusing. No need to couple MSRP 
and SIP like that.

- Ch 6.2, 3rd para., definition of the "both" direction is somehow 
confusing. It uses three names (host, visitor, answerer) for two 
entities. Need to make names consistent.

- Ch 7, 2nd para.: Doesn't this spec only define use of TCP? Why this 
wording?

- Ch 7.1.2, last para., When MSRP URL is communicated outside SDP, why 
would protocol need to be communicated, if the default is TCP, and MSRPS 
requires TLS? Wouldn't DNS SRV be enough here?

- Ch 7.2, what is the extensibility model of MSRP? Should there be:
	
	Method = SEND / BIND / VISIT / other-method
	other-method = token

- Ch 7.2, would be nice to have the ABNF definitions collected into one 
place instead of spread across chapters.

- Ch 7.3, 3rd para., Why not make TR-ID global uniqueness be a MUST? 
That would help detect duplicate messages in case a relay crashes while 
SEND is pending, and the client resends the message.

- Ch 7.4.1, bullet 1., Should clarify that the temporary, hard-to-guess 
property applies specifically to the "resource" part

- Ch 7.4.1, bullet 4, What are the "circumstances" that would warrant 
the different timeout? Last sentence makes no sense to me.

- Ch 7.4.1, 2nd set of bullets, paragraph after 3rd bullet, 2nd 
sentence: This sentence is really hard to parse. Suggest splitting it up 
to simplify.

- Ch 7.4.3, 1st set of bullets, bullet 6, why is this needed (as opposed 
to just sending a 400)? The endpoints have already negotiated the set of 
allowed MIME types. Why add this dynamic removal, and is there a similar 
way to dynamicly add media types in a session?

- Ch 7.4.3, 2nd set of bullets, 3rd bullet, same as above.

- Ch 7.5.4, 3rd bullet, relay is supposed to send 500, but 500 is only 
defined as response for SEND.

- Ch 7.6, 1st para., it states that MSRP digest doesn't support the 
realm. Why is that? In HTTP digest, realm is a textual string intended 
for the user to consume and to help select the correct username/password.

- Ch 7.9.3, says "...usually in response to a digest authentication 
challenge." When else would this happen?

- Ch 7.9.3, ABNF and definition for request-digest, SHA1 produces as 
output 160 bits (MD5 is 128bits), so this should be <"> 40LHEX <">.

- Ch 7.9.4, text claims extensibility of authentication mechanism, but 
syntax only allows for "Digest".

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Ben Campbell <[email-masked]>
Date: Fri, 17 Oct 2003 12:28:59 -0500

> a concrete relationship between messages.

OK.

> - Ch 2., 1st para., last sentence is confusing. No need to couple MSRP 

Hmm. The point was to illustrate that this was different than SIP, and 
that MSRP messages do not follow the SIP path. Obviously this is 
meaningless if you are not using sip at all--but I wanted to include 
this to contrast MSRP from previous proposals (and page mode) that _did_ 
  traverse the SIP proxy fabric. I will attempt to re-word.

> entities. Need to make names consistent.

Hmm. The third paragraph is "The direction attribute is included in an 
SDP a-line, with a value taking the following syntax:" I assume this is 
  the paragraph you meant.

Actually, there are 4 names: Offerer, answerer, host, visitor. Offerer 
and answerer are specific to who sends the SDP offer. Host and visitor 
are specific to who hosts the MSRP session. The offerer/answerer and 
host/visitor choices are not bound together, that is, the offerer could 
end up the visitor, and the answerer could end up the host.

> - Ch 7, 2nd para.: Doesn't this spec only define use of TCP? Why this 

I am clarifying elsewhere that this draft specifies a TCP binding, and 
other drafts could specify other bindings. However, any such bindings 
must use reliable transports. I can accept that it is not this draft's 
job to say what kind of transports could be used. If someone tries to do 
a UDP binding, we can worry about it then.
> requires TLS? Wouldn't DNS SRV be enough here?

Because we may have future bindings to other protocols. (There is 
already interest in an SCTP binding.)

>     Method = SEND / BIND / VISIT / other-method

Good point.

> place instead of spread across chapters.

I have heard opinions either way. I think your comment tips the balance 
in favor of collecting it all in one place.

> SEND is pending, and the client resends the message.

I don't want to do this unless we have concensus to go all the way to 
build a cross-session duplicate surpression mechanism--which will 
require more work than just having unique IDs. Otherwise, it just 
creates a calculation burden of having to create a guid for each message.

> property applies specifically to the "resource" part

Why does that matter. If someone comes up with some weird scheme to have 
a different host part in each, and makes them all resolve correctly, why 
do we care?

> the different timeout? Last sentence makes no sense to me.

One possibility would be known network conditions that cause TCP 
connections to typically take longer than average. I will put that in as 
an example, But I don't think it is up to this draft to enumerate 
circumstances that might call for a different value. I am glad you 
brought it up though, as in the process of following up, I noticed the 
BNF for this is wrong (the timeout option is on "passive" rather than 
"both".)

> sentence: This sentence is really hard to parse. Suggest splitting it up 

OK. That one made me dizzy when I wrote it :-)

> way to dynamicly add media types in a session?

The SDP allows one to negotiate a "try anything" approach. This was to 
avoid insanely large format lists for rich endpoints.

> defined as response for SEND.

OK

> for the user to consume and to help select the correct username/password.

I seem to recall having a discussion about this at one of the meetings 
where the consensus was that we did not need realm. I must admit that I 
cannot remember the reasoning. I will have to dig to see if I can find 
something.

> challenge." When else would this happen?

I think we had at one point assumed that the client could attempt to 
preemptively load CAuth with a previously seen nonce. Since we have not 
specififed that behavior, I will adjust the wording.

> output 160 bits (MD5 is 128bits), so this should be <"> 40LHEX <">.

OK

> syntax only allows for "Digest".

We decided at the interim meeting not to include extensibility. I will 
adjust the wording that indicates otherwise.

---

From: Ben Campbell <[email-masked]>
Date: Fri, 17 Oct 2003 12:28:59 -0500

OK.

Good point.

OK

OK