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

[Harald Alvestrand <[e-mail]>]

On 10/24/2013 10:38 PM, Ejzak, Richard P (Richard) wrote:
> Hi Michael,
>
>> From: Michael Tuexen [mailto:[e-mail]]
>> Sent: Thursday, October 24, 2013 2:21 PM
>> On Oct 24, 2013, at 8:36 PM, "Ejzak, Richard P (Richard)"
>> <[e-mail]> 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.

My reading has been that once you start selecting IDs, you're 
responsible for making sure those don't collide with platform-generated 
ones, or deal with the result if they do.

The result of

A: pc.createDataChannel(label="foo") -> (channel with ID = 5, open 
message sent)
B: pc.createDataChannel(label="bar", id=5)
<open message arrives at B>

should be well defined. I don't much care what the result is, as long as 
it's well defined; closing the channel and calling the onerror() handler 
with DOMError(error="UsageError", message="Duelling paradigms") is fine 
with me.

I can't see a way to mix the two paradigms that guarantees this never 
happening.

>
>>> 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.
>
> 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.
>
> BR, Richard
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb