Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage-data-channel-16

[Christer Holmberg <[e-mail]>]

Hi,



>- Added text to make more clear the scope of path and MSRP URI:

>Data channels are negotiated independently of the value of the "path" attribute. This means that when MSRP messages are transported on a data channel, the "path" attribute

>is not used for transport negotiation or routing of the messages. MSRP endpoints using data channels can set the value of the "path" attribute, including the MSRP URI, and use it as described in RFC4975



I think we need to be a little more explicit, so I suggest something like:



"When MSRP messages are transported on a data channel, the "path" attribute is not used for routing of the messages. The MSRP data channel is established using the SDP offer/answer procedures defined in [I-D.ietf-rtcweb-data-channel], and the MSRP messages are then transported on that data channel. Because of that an MSRP endpoint can set the MSRP-URI authority value of the "path" attribute at its own discretion, following the syntax and rules in [RFC4975]."



>- Updated examples removing the port



Actually, I realized that 4975 mandates a port, so I think we should keep it.



>Pending:

>

>- Replacing all SHALL with MUST for consistency

I think we should do it. Currently it’s 50/50, without any logic behind when SHALL or MUST is used.
Regards,
Christer


On 12/05/20 15:58, Jose M Recio wrote:

Agreed, my worry was not being concise enough.

On 10/05/20 21:29, Christer Holmberg wrote:
Hi,

...

>We could even simplify Christer's suggestion:
>
>"The path attribute SHALL NOT be used for transport negotiation. MSRP
>endpoints communicating over a data channel can specify and use path
>attribute for other purposes, as specified by RFC4975."
>
>If that is still confusing, I will take Christer wording.

I would prefer my solution (I have no problem if it can be simplfied), because the problem with "SHALL NOT" is that you CAN NOT use the path for routing - even if you wanted to :)

Usage of the path for routing is simply not defined when using a data channel (as the MSRP messages will be sent over the data channel).

Regards,

Christer



On 08/05/20 03:33, Christer Holmberg wrote:
> Hi Paul,
>
> Thank You for the comments! Please see inline.
>
> ---
>
>>     1) NIT:
>>
>>     In Section 3.1, in the table, the value for Label has a lot of white
>>     space between "See" and "Section 4.3". It would look better with a
>>     single space.
>
> That's a bug. Will be fixed.
>
> ---
>
>>     2) MINOR ISSUE:
>>
>>     In section 4.1, the abnf says:
>>
>>         transport  /= "dc" / 1*ALPHANUM
>>
>>     The /= means this is an added alternative to what is present in RFC4975.
>>     Hence it is equivalent to:
>>
>>         transport = "tcp" / 1*ALPHANUM / "dc" / 1*ALPHANUM
>>
>>     What you should really have is just:
>>
>>         transport  /= "dc"
>
> Will modify as suggested.
>
> ---
>
>>     3) NIT:
>>
>>     Section 4.4 says:
>>
>>         An offerer and answerer MUST include a dcsa attribute for the
>>         following MSRP-specific SDP attributes:
>>
>>     I suggest: s/for the/for each of the/
> Will modify as suggested.
>
>>     Similarly, where it says:
>>
>>         An offerer and answerer MAY include a dcsa attribute for the
>>
>>     I suggest: s/for the/for any of the/
>
> Will modify as suggested.
>
> ---
>
>>     4) QUESTION:
>>
>>     Does section 4.6 this mean it is an error to use SDP to close the
>>     DTLS/SCTP association (via m=0) without all the added SDP attributes to
>>     close each data channel?
>>
>>     Could it not be implied that closing the association implicitly closes
>>     all the data channels?
>
> The procedures follow what is defined in Section 6.6.1 of draft-ietf-mmusic-data-channel-sdpneg.
>
> Whether closing the SCTP association, without explicitly closing the data channel(s) first, is an "error", or just "something one should not do",  I think should have been specified in draft-ietf-mmusic-data-channel-sdpneg.
>
> ---
>
>>     5) QUESTION:
>>
>>     The example in section 4.8 includes use of the "path" attribute. How
>>     does that square with the following in section 4.4:
>>
>>         The path attribute SHALL NOT be used for transport negotiation.
>>
>>     I guess you mean that some usages of path are ok and others are not.
>>     Could you be more explicit about this?
> I have got the same questions from others too, so I guess it needs to be clarified.
>
> As the MSRP messages will be "routed" on the established data channel, the path attribute won't be used for routing.
>
> Maybe something like this:
>
> "When MSRP messages are transported on a data channel, the "path" attribute is not used for routing of the messages. Because of that an MSRP endpoint
> can set the MSRP-URI authority value of the "path" attribute at its own discretion. However, when an MSRP endpoint receives an MSRP message on
> a data channel it MUST still check the MSRP-URI in the To-Path of the MSRP message, as described in [RFC4975]."
>
> ---
>
>>     6) ISSUE:
>>
>>     Section 7.1 registers "MSRP" as if it was a totally new websocket
>>     protocol name, but it isn't. It is already registered as a websocket
>>     protocol referencing RFC7977.
> True.
>
> That shows for how long we have been working on this document, because when we started RFC 7977 didn't exist...
>
>>     I think you instead need to specify that the existing registration be updated.
> Something like:
>
> 7.1.  Subprotocol Identifier MSRP
>
>     NOTE to RFC Editor: Please replace "XXXX" with the number of this
>     RFC.
>
>     This document adds a reference to RFC XXXX for the subprotocol identifier "msrp" in
>     the "WebSocket Subprotocol Name Registry".
>
> ---
>
> Regards,
>
> Christer
>
>
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mmusic





_______________________________________________

mmusic mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/mmusic