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

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 21 May 2004 15:33:03 -0700

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

thx, will fix.

> them. But I don't think they are in scope for this work item.

i don't have a strong feeling.  i mainly wanted to introduce the term 
so folks knew it was ok to do that.  It doesn't introduce any normative 
requirements at least.

> 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 don't consider this two different transaction models.  In both cases 
a transaction is still one request and one response.  You can't make 
SEND end-to-end, so if you want consistency, you would need to make all 
requests hop-by-hop and create another hop-by-hop acknowledgment 
request or something along those lines.

> 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 discussion here.)

Making all requests hop-by-hop would be pretty ugly, so let me ask if 
there is any *technical* objection rather than a philosophical one.

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

I intend to update the relay spec to match the base spec here.

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

Cullen and I have a minor disconnect here.  I think he may have 
imagined opening an individual connection to the "2nd relay" directly 
to setup the 2nd AUTH.

In any case, you authenticate your first hop with TLS, and quite 
likely, transitive trust between the 1st relay and the 2nd relay is OK 
if the 2nd relay and the 1st relay have an administrative relationship

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

no, auth really is sufficient, even with multiple hops. What I should 
have said is that auth-int just doesn't work in this environment 
period, but enough integrity is provided for us to do Digest for sure.

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

the *procedure* is the same (you put the contents of the path attribute 
into the To-Path header), even if the contents may be different.

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

a client connecting to a foreign relay and a client should be 
identical.  I think it is acceptable to use different procedures to 
connect to "your" relay.

> connection that the AUTH was received on survives, and uses TLS, this 
> is fairly easy.

yes

> But if we bounce the connection, things get harder.

don't do that.  ;-)

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

yes, you are right, there are race conditions here.  at least there is 
no forking though.  I guess the key question is if you have a better 
proposal?

> containing full path including endpoint.)

i intend to update to reflect the MSRP style.

thanks,
-rohan

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 21 May 2004 15:33:03 -0700

thx, will fix.

yes

don't do that.  ;-)

thanks,
-rohan