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