Subject: [Simple] MSRP: Comments on draft-ietf-simple-msrp-relays-00.txt

From: Ben Campbell <[email-masked]>
Date: Fri, 21 May 2004 16:25:31 -0500

nit: "message" appears twice in the glossary section.

Section 3:

I don't think the concept of a "message taker" belongs here. I am not 
proposing that they are bad ideas, or that SIMPLE should not work on 
them. But I don't think they are in scope for this work item.

I am uncomfortable with the idea that we have more than one transaction 
model. In particular, SEND is hop-hop, but others, such as REPORT are 
end-end. I understand why, but I personally prefer the simplicity of 
making all methods work the same. (Upon further reading, I see this 
might be problematic for AUTH when an endpoint chooses to use multiple 
relays. But in any case, I think we need more dicussion here.)

Example REPORT requests do not follow the base spec DSN usage, in that 
they do not include a DSN body. I realize this is an early draft, but I 
am not sure if I should infer just that there is additional work to do 
to get the drafts in sync, or that you are suggesting a simpler REPORT 
mechanism.

5.1.1: You mention using TLS to authenticate relays when you AUTH. That 
may be problematic when using more than one relay, as TLS will only be 
helpful for the first hop.

Similarly, you say " NOTE - only auth not auth-int is needed because TLS 
provides integrity". This is not true if the relay you are AUTHing with 
is not the first hop, right?

5.1.2:

"The procedure for sending SEND, VISIT, and REPORT requests is identical 
for clients whether relays are involved or not. The specific procedures 
are described in section TODO of [MSRP]." This is not entirely true, as 
the contents of the To-Path header is different if relays are used.

5.1.4: You suggest slightly different handling for clients connecting to 
  other clients vs. clients connecting to relays. However, a client that 
does not implement the relay spec may still connect to a relay. It just 
doesn't know the difference. It would be really nice to have consistent 
connection handling regardless of relay support.

5.2.3: "It MUST ensure that the message is either being forwarded from 
an entity that did the AUTH request that resulted in this URI or it is 
being forwarded to the the entity that did the AUTH request that 
resulted in this URI." We probably need to say more about this. If the 
connection that the AUTH was received on survives, and uses TLS, this is 
fairly easy. But if we bounce the connection, things get harder.

5.2.6: This handling of responses forces the relay to keep transaction 
state until a response comes back. Since we are talking about e2e 
transactions, the time for this will be affected by length of the relay 
chain. SIP has shown us how that can be problematic. (This issue is 
contingent upon any discussions about multiple transaction models.)

Section 10: The SDP examples use the SIMS style (hop attributes, 
endpoint URL in m-line) rather than MSRP style (path attribute 
containing full path including endpoint.)

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