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

[Jose M Recio <[e-mail]>]

Many thanks for the comments, I have consolidated the following comments 
in an ongoing PR

https://github.com/josemrecio/draft-msrp-data-channel/pull/14:


- Draft states that it updates RFC4975 and adds an IANA consideration to 
update the msrps registration, to include DTLS


- Removed RFC4145 and other dangling references


- Introduction corrected "MSRP is currently defined ... " -> "MSRP was 
initially defined in ..."


- 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


- Simplified SDP session closing section, referring back to 
mmusic-data-channel-sdpneg


- Updated examples removing the port


- Updated introduction to MSRP considerations section "This section 
describes the MSRP ... " -> "The procedures specified in RFC4975 apply 
except ..."


- Clarification on MSRP session closing section, explicitly stating that 
MSRP session should be considered failed when data channels are torn down


Pending:


- Replacing all SHALL with MUST for consistency




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]
>> > https://www.ietf.org/mailman/listinfo/mmusic
>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic