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

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Mon, 28 October 2013 12:05 UTC

Return-Path: <Michael.Tuexen@lurchi.franken.de>
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 6D04921F9FBA for <rtcweb@ietfa.amsl.com>; Mon, 28 Oct 2013 05:05:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.499
X-Spam-Level:
X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 N6BAAb3cmnEp for <rtcweb@ietfa.amsl.com>; Mon, 28 Oct 2013 05:05:26 -0700 (PDT)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id E0ADD11E824F for <rtcweb@ietf.org>; Mon, 28 Oct 2013 05:05:21 -0700 (PDT)
Received: from [192.168.1.200] (p508F23F7.dip0.t-ipconnect.de [80.143.35.247]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 598FA1C0C0692; Mon, 28 Oct 2013 13:05:19 +0100 (CET)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F3D86C9A2@US70UWXCHMBA04.zam.alcatel-lucent.com>
Date: Mon, 28 Oct 2013 13:05:18 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <52B42DFC-7A8E-4FD3-9820-F57E4B98ADCA@lurchi.franken.de>
References: <20131021191343.32574.60876.idtracker@ietfa.amsl.com> <03FBA798AC24E3498B74F47FD082A92F3D86C821@US70UWXCHMBA04.zam.alcatel-lucent.com> <A87B4291-FA11-43BB-B8F0-55C59CF63421@lurchi.franken.de> <CAOJ7v-20YkvazNLqmbjQcOkhaedd+MKm8d6x2oeL46imvuLrzA@mail.gmail.com> <03FBA798AC24E3498B74F47FD082A92F3D86C8DB@US70UWXCHMBA04.zam.alcatel-lucent.com> <120FE29C-150E-47BF-951C-B8124EB7A262@lurchi.franken.de> <03FBA798AC24E3498B74F47FD082A92F3D86C9A2@US70UWXCHMBA04.zam.alcatel-lucent.com>
To: "Ejzak, Richard P (Richard)" <richard.ejzak@alcatel-lucent.com>
X-Mailer: Apple Mail (2.1510)
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.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: Mon, 28 Oct 2013 12:05:29 -0000

On Oct 24, 2013, at 10:38 PM, "Ejzak, Richard P (Richard)" <richard.ejzak@alcatel-lucent.com> wrote:

> Hi Michael,
> 
>> From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de]
>> Sent: Thursday, October 24, 2013 2:21 PM
> 
>> On Oct 24, 2013, at 8:36 PM, "Ejzak, Richard P (Richard)"
>> <richard.ejzak@alcatel-lucent.com> wrote:
>> 
>>> Justin, Michael,
>>> Thanks for the clarifications.  One more question.  What happens if
>> the application tries to select a stream id before the DTLS role is
>> known and it ends up selecting an invalid one?
>> I'm not completely familiar with the JS API, but if you want to select
>> a stream, aren't you managing the stream completely on your own. I
>> think the DTLS role stuff is only relevant if the streams are managed
>> by the browser.
> 
> If this is the intent then that clarification would be very useful.  Reading the API text again, it is clear that the browser only manages stream ids that it selects.  Does this mean that the browser stream id selection option is not compatible with the application stream id selection option?  Putting it more precisely, should we require that the application not be allowed to select stream ids prior to determining DTLS role if it expects that either side might use the browser stream id selection option?  It would be easier if the even/odd rule could be determined earlier than DTLS role establishment so that the application could use the same even/odd assignment rule for early data channel creation.
> 
>>> 
>>> Michael,
>>> While it's true that the data channel control protocol cannot open
>> the channel with the peer before the DTLS role is known, the API allows
>> the application to create the data channel before the DTLS role is
>> known, in which case the sending of the Open message must wait until
>> the SCTP association is established.  I want to know what the
>> application is supposed to do it if needs to create data channels with
>> preselected stream ids before the DTLS role is known.  This seems like
>> something that the spec should make clear rather than leaving it to
>> implementation.
>> Can you assign the stream ID in the API? Could you point me to the
>> text?
> 
> http://www.w3.org/TR/webrtc/#methods-1 describes the "id" attribute in the RTCDataChannelInit dictionary that must be the equivalent of the "stream identifier".  No other interpretation makes sense to me but please correct me if I am wrong.  Note in particular the following text within the description of the createDataChannel procedure (my parenthetical): "If the value of the id attribute is null, initialize it to a value generated by the user agent (browser), according to the WebRTC DataChannel Protocol specification, and skip to the next step. Otherwise, if the value of the id attribute is taken by an existing RTCDataChannel, throw a TBD exception and abort these steps."  So "id" must refer to "stream identifier" since there is no other id in your draft that it could refer to.
I don't see in the document a statement that the id corresponds to the stream identifier.
If that is the case, it should be mentioned. The W3C document indicates that the type
of id is unsigned short?. I don't know enough JS to know if this corresponds to uint16_t
or not. If not, there is a problem...
> 
> If I'm right, then it would be good if it were made clear that id refers to "stream identifier", but that is a w3c issue.  Quoting from 5.2.1 (my parentheticals for clarity): "The id was either assigned by the user agent (browser) at channel creation time (not channel opening time) or selected by the script (application). The attribute MUST return the value to which it was set when the RTCDataChannel was created (not opened)."
> 
> I used the wrong terminology in my earlier mail when I referred to "open" of the data channel when I meant "creation".  Since the data channel can be "created" before DTLS role is known and before the data channel can be opened, the quoted text above would seem to indicate that the application can never determine the stream id actually assigned to the data channel if id can't be determined at time of creation.  Justin implied that the chrome behavior does not conform to this description.  Comment, Justin?
> 
> It still seems to me that a change in the rule describing even/odd stream id assignment would be a good idea.
It depends on the restrictions we have for external negotiation...

Best regards
Michael
> 
> BR, Richard
>