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

[Christer Holmberg <[e-mail]>]

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