From: Jonathan Lennox <jonathan@vidyo.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Date: Fri, 2 Aug 2013 10:00:21 -0400
Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-00.txt
Thread-Index: Ac6PiH60vezXWYRyQMGvnYW5oIZhXg==
Message-ID: <764EBF44-98C1-425B-B9A4-8A712E884CD1@vidyo.com>
References: <20130715203130.5677.31855.idtracker@ietfa.amsl.com>
 <CAJrXDUFGM9+bw7KcYxwK9s_MbzW2L_1xjshTocgTKxpur345Nw@mail.gmail.com>
 <DD542B20-8EA3-45F8-B9F1-7991F207F2A1@lurchi.franken.de>
 <CAJrXDUG5sB63w3p6kDDuNT=_+Pq_m7ZmH+HdX_9c0sVXYBk2gw@mail.gmail.com>
 <51E85AFF.9090008@jesup.org>
In-Reply-To: <51E85AFF.9090008@jesup.org>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-00.txt
Precedence: list

Hi, all --

I discovered a few issues with the data channel protocol this week that I w=
ould have brought up at the session, had the discussion of the existing ope=
n issues not consumed all available time and more.


The first is that the DATA_CHANNEL_OPEN message's Protocol field is documen=
ted 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 struc=
ture to the protocol strings, e.g., the ability to pass parameters of proto=
cols?  (The use case that inspired these thoughts was the MSRP-over-datacha=
nnel draft; MSRP has a number of protocol parameters.)  This wouldn't neces=
sarily mean making any changes to DATA_CHANNEL_OPEN -- protocols parameters=
 could easily be specified in the protocol string using something like the =
"protocol;param=3Dvalue;param=3Dvalue" syntax.


The second issue is that the data channel protocol chooses its odd/even str=
eam 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 mech=
anisms, 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 possibl=
e 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 as=
sign a stream ID -- it means the exchange of information to set up the exte=
rnally-negotiated data channel can't even begin until the offer/answer exch=
ange is complete.


Thoughts?

--
Jonathan Lennox
jonathan@vidyo.com