Re: Data API Proposal aligned to WebSocket

On 2/23/2012 8:27 AM, Adam Bergkvist wrote:
> On 02/23/2012 02:08 PM, Michael Tuexen wrote:
>>
>> On Feb 23, 2012, at 1:39 PM, Adam Bergkvist wrote:
>>> You're right that it's not used in either of the examples given here.
>>> It's a pure API-related property to help the developer identify a
>>> particular DataChannel object if several objects (with the same
>>> transport porperties) are used. E.g. you might have a DataChannel
>>> object with label "chat" and another with the label "game-data" for
>>> different purposes.
>> OK. So if I understand this correctly, it is just a local thing and it
>> is not expected to be on the wire, right?
>
> Yes, it's not intended to be some "channel id" on the wire, but
> it would have to be transported to the other end so that the
> corresponding DataChannel object on the B-side can be initialized with
> the same label.

Correct; the idea discussed (at the Interim, and with Randall) was to 
either use stream 0 as a control channel, or to use PPID values to flag 
a message on a stream containing metadata such as an "open dataChannel" 
message, which would include information needed to open the reverse 
stream (and avoid 'glare' when both sides are opening streams at the 
same time), the label, and the channel options (so it has the same 
attributes in both directions).

>
>>>> What about unordered? When do you expect a message to be abondoned
>>>> when treated unreliable?
>>>
>>> I don't really have an opinion on when to abandon messages in
>>> unreliable mode.
>> OK. But it needs to be specified.

Right.  I was trying to indicate in my response that streams would (at 
open time) have attributes that specify reliable, unreliable, in/out of 
order, and for non-reliable a value to control retry/abandonment (exact 
semantics TBD but should map simply to the SCTP options).  I mistakenly 
added them to the wrong dictionary.

-- 
Randell Jesup
randell-ietf@jesup.org

Received on Thursday, 23 February 2012 14:46:45 UTC