Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-00.txt

[Jonathan Lennox <[e-mail]>]

Hi, all --

I discovered a few issues with the data channel protocol this week that I would have brought up at the session, had the discussion of the existing open issues not consumed all available time and more.


The first is that the DATA_CHANNEL_OPEN message's Protocol field is documented as "If used, it SHOULD be an IANA-registered protocol."  However, there's no indication of what IANA registry to use, and no definition of such a registry in the IANA Considerations section.

Is this intended to be a new IANA registry of data channel protocols, or is it re-using some other IANA registry?  If the former, do we want any structure to the protocol strings, e.g., the ability to pass parameters of protocols?  (The use case that inspired these thoughts was the MSRP-over-datachannel draft; MSRP has a number of protocol parameters.)  This wouldn't necessarily mean making any changes to DATA_CHANNEL_OPEN -- protocols parameters could easily be specified in the protocol string using something like the "protocol;param=value;param=value" syntax.


The second issue is that the data channel protocol chooses its odd/even stream identifier parity depending on which side in the initial DTLS handshake was the DTLS client, and which the DTLS server.

The problem is that DTLS roles are negotiated in SDP using the comedia mechanisms, and as a result, the roles aren't determined until the offer/answer that sets up the DTLS/SCTP connection is complete.  Thus, it's not possible to assign a stream ID to a stream until after the initial offer/answer.  This has implications for stream selection, particularly for the case where an application wants to do external negotiation but asks the browser to assign a stream ID -- it means the exchange of information to set up the externally-negotiated data channel can't even begin until the offer/answer exchange is complete.


Thoughts?

--
Jonathan Lennox
[e-mail]