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

Jonathan Lennox <jonathan@vidyo.com> Fri, 02 August 2013 14:00 UTC

Return-Path: <jonathan@vidyo.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E001411E8293 for <rtcweb@ietfa.amsl.com>; Fri, 2 Aug 2013 07:00:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.462
X-Spam-Level:
X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1R5DGrx+icO for <rtcweb@ietfa.amsl.com>; Fri, 2 Aug 2013 07:00:23 -0700 (PDT)
Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.243]) by ietfa.amsl.com (Postfix) with ESMTP id C2A0111E80E7 for <rtcweb@ietf.org>; Fri, 2 Aug 2013 07:00:23 -0700 (PDT)
Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 3B2E87AB8ED for <rtcweb@ietf.org>; Fri, 2 Aug 2013 09:54:58 -0400 (EDT)
X-Virus-Scanned: by SpamTitan at mail.lan
Received: from HUB022.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id E08BC7ABAEE for <rtcweb@ietf.org>; Fri, 2 Aug 2013 09:54:57 -0400 (EDT)
Received: from BE235.mail.lan ([10.110.32.235]) by HUB022.mail.lan ([10.110.17.22]) with mapi; Fri, 2 Aug 2013 09:59:24 -0400
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
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
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
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Aug 2013 14:00:29 -0000

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
jonathan@vidyo.com