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

From: Christer Holmberg <[email-masked]>
Date: Mon, 22 Apr 2019 10:36:55 +0000

Hi,

Section 5.1.1.2 says:

   "The msrp-cema attribute SHALL be assumed to be present for every MSRP
   session using data channel transport, so the inclusion of the msrp-
   cema attribute is OPTIONAL.  This ensures that the data channel
   transport for the MSRP session is established without using the path
   attribute."

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.

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? 

Regards,

Christer

On 21/04/2019, 19.06, "mmusic on behalf of [email-masked]" <[email-masked] on behalf of [email-masked]> wrote:

    A New Internet-Draft is available from the on-line Internet-Drafts directories.
    This draft is a work item of the Multiparty Multimedia Session Control WG of the IETF.
    
            Title           : MSRP over Data Channels
            Authors         : Keith Drage
                              Maridi R. Makaraju (Raju)
                              Juergen Stoetzer-Bradler
                              Richard Ejzak
                              Jerome Marcon
                              Jose M. Recio
    	Filename        : draft-ietf-mmusic-msrp-usage-data-channel-10.txt
    	Pages           : 18
    	Date            : 2019-04-21
    
    Abstract:
       This document specifies how the Message Session Relay Protocol (MSRP)
       can be instantiated as a data channel sub-protocol, using the SDP
       offer/answer exchange-based generic data channel negotiation
       framework.  Two network configurations are documented: a WebRTC end-
       to-end configuration (connecting two MSRP over data channel
       endpoints), and a gateway configuration (connecting an MSRP over data
       channel endpoint with an MSRP over TCP or TLS endpoint).

    The IETF datatracker status page for this draft is:
    https://datatracker.ietf.org/doc/draft-ietf-mmusic-msrp-usage-data-channel/
    
    There are also htmlized versions available at:
    https://tools.ietf.org/html/draft-ietf-mmusic-msrp-usage-data-channel-10
    https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-msrp-usage-data-channel-10
    
    A diff from the previous version is available at:
    https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-msrp-usage-data-channel-10

    Please note that it may take a couple of minutes from the time of submission
    until the htmlized version and diff are available at tools.ietf.org.
    
    Internet-Drafts are also available by anonymous FTP at:
    ftp://ftp.ietf.org/internet-drafts/
    
    _______________________________________________
    mmusic mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/mmusic

---

From: Jose M Recio <[email-masked]>
Date: Mon, 22 Apr 2019 21:24:01 +0800

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

Any comments from the list?

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

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 22 Apr 2019 20:32:03 +0000

Hi,

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

---

From: RIchard Ejzak <[email-masked]>
Date: Mon, 22 Apr 2019 13:12:48 -0500

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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 23 Apr 2019 05:56:45 +0000

Hi Richard,

Long time no see - hopefully you are fine __
    
>    suggest adopting this approach for dc.
  
My point is that the path attribute is not used for establishing the transport to begin with: the SDP c/m= lines are used for that.

There aren't even going to be any "real" path attributes - they will be encapsulated within dcsa attributes.

Regards,

Christer

---

From: Jose M Recio <[email-masked]>
Date: Thu, 25 Apr 2019 19:08:04 +0800

>>     suggest adopting this approach for dc.

Would this be a fair summary:

- Paragraph in discussion was meant to prevent using path attribute, but that's a moot point for data channel anyway.

To make this more clear, we can: 1) remove the paragraph, adding a clarification sentence for the reader saying that, due to the nature of the transport, path is not used for dc establishment; and 2) remove all references to cema attribute.

With that, I think mandatory modification of the path is not needed, as it's clear that the address and port parts are not used for dc. It can be added as a way to make it more explicit.

---

From: Jose M Recio <[email-masked]>
Date: Thu, 25 Apr 2019 19:29:29 +0800

> 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 establis…

It indeed assumes that the data channel endpoint will be a MSRP peer, 
either another endpoint or a MSRP GW. If that's not clear enough it 
should be made more explicit.

If the endpoint is a GW, messages can be relayed, similar to the 
scenario where the connection to the GW is done using TLS, or 
WebSockets, instead of dc.

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 27 Apr 2019 18:07:57 +0000

Hi,

>> 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.  
>
> It indeed assumes that the data channel endpoint will be a MSRP peer, either another endpoint or a MSRP GW. If that's not clear enough it should be made more explicit.

I was not talking about the fact that the endpoint will be a MSRP peer/GW, but that legacy MSRP routing will not be used.

> If the endpoint is a GW, messages can be relayed, similar to the scenario where the connection to the GW is done using TLS, or WebSockets, instead of dc.      

Regarding the GW, I think that also needs more text. For example, *IF* the data channel MSRP client inserts multiple path attributes, will the GW then copy paste those in the outgoing legacy MSRP message? I assume it will, but there is very little detail on the GW procedures.

Regards,

Christer