Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-data-channel-sdpneg-20

[Bo Burman <[e-mail]>]

I think Ben's opinion was that it is OK to stay with FCFS and to use the WebSocket registry, but that the text must then at least not require sub-protocol specification anywhere, which I believe is part of a single option.

I thought a bit more on this, trying to understand what could have been the reasons for the existing formulations that require specification. It seems to me that for any sub-protocol where stand-alone usage of that protocol (that is, not as sub-protocol of data channel) has existing offer/answer specifications, e.g. MSRP or BFCP, it would make sense to require specification also for data channel sub-protocol usage. For other protocols in the WebSocket registry that has no existing offer/answer considerations when used stand-alone, no specification would be required.

This could be achieved by something similar to:
"The detailed offer/answer procedures for the dcsa attribute are
   dependent on the associated sub-protocol.  A sub-protocol
   specification MUST define the offer/answer procedures for the dsca
   attribute (if applicable) associated with the sub-protocol, if the 
   sub-protocol has defined offer/answer procedures when used outside
   of dcsa.  If no offer/answer procedures exist for the sub-protocol when used
   outside of the dcsa attribute, no specification is required for use with dcsa."

/Bo
(as individual)

-----Original Message-----
From: Roni Even (A) <[e-mail]> 
Sent: den 24 december 2018 10:29
To: Bo Burman <[e-mail]>; Ben Campbell <[e-mail]>
Cc: Paul Kyzivat <[e-mail]>; [e-mail]
Subject: RE: [MMUSIC] AD Evaluation of draft-ietf-mmusic-data-channel-sdpneg-20

Hi Bo,
I am not sure what is the suggestion since there are two options.

We can keep the current registration and recommend that a spec with offer answer should be available Is this OK Roni

-----Original Message-----
From: Bo Burman [mailto:[e-mail]]
Sent: Friday, December 14, 2018 4:32 PM
To: Ben Campbell; Roni Even (A)
Cc: Paul Kyzivat; [e-mail]
Subject: RE: [MMUSIC] AD Evaluation of draft-ietf-mmusic-data-channel-sdpneg-20

Roni,

Please go ahead and make the changes suggested by Ben below and submit a new version at your earliest convenience.

Thanks
/Bo
MMUSIC co-chair

-----Original Message-----
From: Ben Campbell <[e-mail]>
Sent: den 11 december 2018 18:25
To: Roni Even (A) <[e-mail]>
Cc: Bo Burman <[e-mail]>; Paul Kyzivat <[e-mail]>; [e-mail]
Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-data-channel-sdpneg-20

As a reminder, my concern was that the draft contains language that assumes a specification will exist. For example, §6 says:

"The detailed offer/answer procedures for the dcsa attribute are
   dependent on the associated sub-protocol.  A sub-protocol
   specification MUST define the offer/answer procedures for the dsca
   attribute (if applicable) associated with the sub-protocol."

If it is possible to register a data-channel sub-protocol without a spec, then the text that assumes a spec will exist needs to be revised. I understand the desire to share the websocket subprotocol registry, but the need for documented offer/answer procedures suggests that FCFS is not the right policy for data-channel subprotocols.

For the record, I would be okay with it if the wg decides to stick with FCFS, but the text would need to change in a few places to remove the assumptions that a spec would exist. We would, of course, have to accept the idea of a data-channel subprotocol with no documented offer/answer considerations. That might be okay if we allow private-use protocols and just want to avoid collisions.

Thanks!

Ben.

> On Dec 11, 2018, at 4:15 AM, Roni Even (A) <[e-mail]> wrote:
> 
> Hi Bo,
> I am not sure I understand the issue. According to section 9.1
> 
> A subprotocol may simultaneously be defined for data channel
>   transport and for Websocket transport.  In such a case the
>   "Subprotocol Definition" and "Reference" cells in the subprotocol's
>   row of the IANA "WebSocket Subprotocol Name Registry" table should
>   contain two entries.  One entry in each of these cells should refer
>   to the Websocket related subprotocol specification, and the other
>   entry should refer to the data channel related subprotocol
>   specification.
> 
> This applies to the msrp case if it was registered also for data channel.
> 
> I am not sure what we will have with a second registry is it only for data channel usage and we will not register it also in the web socket registry?
> 
> 
> 
> Roni
> 
> -----Original Message-----
> From: mmusic [mailto:[e-mail]] On Behalf Of Bo Burman
> Sent: Friday, December 07, 2018 10:55 AM
> To: Ben Campbell; Paul Kyzivat
> Cc: [e-mail]
> Subject: Re: [MMUSIC] AD Evaluation of 
> draft-ietf-mmusic-data-channel-sdpneg-20
> 
> When looking at the now expired draft-ietf-mmusic-msrp-usage-data-channel, I think the content clearly hints that at least for MSRP, a tag without further specification would simply not achieve interoperable implementations. I believe the same would be valid for many other subprotocols. Therefore, I share Ben's concern that FCFS doesn't seem generally sufficient.
> 
> /Bo (as individual)
> 
> -----Original Message-----
> From: mmusic <[e-mail]> On Behalf Of Ben Campbell
> Sent: den 27 november 2018 23:53
> To: Paul Kyzivat <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [MMUSIC] AD Evaluation of 
> draft-ietf-mmusic-data-channel-sdpneg-20
> 
> 
> 
>> On Nov 27, 2018, at 1:40 PM, Paul Kyzivat <[e-mail]> wrote:
>> 
>> On 11/26/18 5:32 PM, Ben Campbell wrote:
>> 
>>>> §9.1: What is the rational for sharing the websocket subprotocol registry rather than creating a new one for data channels? The websocket subprotocol name registry has a policy of “First Come First Served”. This draft seems to state requirements for subprotocol specifications, but FCFS does not require specifications.
>> 
>> IIRC this choice was made by the rtcweb wg. I don't recall how it was made.
>> 
>> It is my impression there is an expectation that many websocket protocols could also be used over data channels in order to get multiplexing of the socket.
> 
> I can accept that the reason might be “because that was what the WG wanted”, but isn’t there still a mismatch with the registration policy? This draft seems to expect subprotocol specifications -- is FCFS acceptable?
> 
>> 
>> 	Thanks,
>> 	Paul
>> 
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic