Re: [MMUSIC] I-D Action: draft-ietf-mmusic-msrp-usage-data-channel-10.txt - Comment on msrp-cema attribute

[RIchard Ejzak <[e-mail]>]

Hi,

Since I wrote the original text, I should probably reply...

I agree with Christer that the CEMA attribute is not needed.  It was 
originally included to make it clear that the path attribute could not 
be used to establish the data channel.  But this is obvious for this new 
type of transport.  RFC7977 (WebSocket transport for MSRP) handles this 
very nicely by using an .invalid domain name in the path attribute.  I 
suggest adopting this approach for dc.

Richard


On 4/22/19 3:32 PM, Christer Holmberg wrote:
> Hi,
>
>>> First, in general, I don't want attributes to be "assumed". If an extension (CEMA in this case) mandates an attribute to be included, it shall be included.
>>     
>>     I can rewrite so the attribute is always there. I think the intention is
>>     to make using legacy MSRP stacks (that may not be supporting CEMA)
>>     transparently use data transport.
>    
> I think we first need to think whether it is needed.
>
> Keep in mind (and that should probably better described in the document) that the normal MSRP routing procedures don't apply. The MSRP messages will be routed in the data channel, which is established between the SIP peers (or whatever signaling protocol is used). I guess proxies and application servers can look at the top-most path attribute, but that is not going to be the primary routing input. I don't think the draft says anything about that - it just seems to assume that the data channel will end up in the intended MSRP peer.
>
> If there then is a gateway that forwards the MSRP messages towards a legacy MSRP endpoint it may use CEMA, but that's a separate thing.
>
>>> Second, I am not sure I understand the text on "ensuring that the data channel is not established using the path attribute". How would you
>>> establish a data channel using the path attribute?
>>     
>>     The way I understand this is "make sure path attribute is ignored for
>>     setting up the transport".
>>     
>>     This is also connected to CEMA being assumed. I believe the overall
>>     intention of the paragraph is that transport establishment must always
>>     use CEMA, even if the attribute is not there, and path should never be
>>     used. So, for data channel transport, CEMA is not optional, as RFC6714
>>     says. Maybe a rewriting making this more clear is needed.
>    
> But the transport establishment of a data channel does not use CEMA.
>
> Maybe there is a reason for all of this (it's such a long time since I looked at it), but it needs to be clear why we mandate certain things.
>
> Regards,
>
> Christer
>
>
>    
>      
>      _______________________________________________
>      mmusic mailing list
>      [e-mail]
>      https://www.ietf.org/mailman/listinfo/mmusic
>      
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic