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

[Ben Campbell <[e-mail]>]

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