Re: New editor's draft (v20130603)

On 6/13/2013 11:31 PM, Adam Bergkvist wrote:
> On 2013-06-13 18:56, Randell Jesup wrote:
>> On 6/5/2013 4:59 AM, Adam Bergkvist wrote:
>>> On 2013-06-04 16:34, Randell Jesup wrote:
>>>>
>>>> One issue:   In RTCDataChannelInit:
>>>>
>>>>      boolean          negotiated
>>>> <http://dev.w3.org/2011/webrtc/editor/webrtc.html#widl-RTCDataChannelInit-negotiated> 
>>>>
>>>> =true;
>>>>
>>>> The default should be false - it should be set to true on any
>>>> externally-negotiated channel.
>>>

>> I'm ok with the name and description, so long as the default changes to
>> 'false', which is what I implemented and landed.  We should just comment
>> in the IDL file that this should be set to true if the application is
>> using external negotiation.   I believe Peter Thatcher was also assuming
>> the default would be false.
>>
>
> So I interpret what you're saying as that "negotiated" will be 
> released in firefox, but with the opposite meaning from spec is saying 
> currently (spec says "negotiated" != "externally negotiated"). I'm bit 
> confused since you say that you're ok with the name and description.

Sorry if I wasn't clear.  Let me try again:

Currently it says "negotiated=true;", and in the descriptive part it says:

|    negotiated| of type boolean, defaulting to |true|

    The default value of true tells the user agent to negotiate the
    channel and instruct the other peer to dispatch a corresponding
    ||RTCDataChannel|
    <http://dev.w3.org/2011/webrtc/editor/webrtc.html#idl-def-RTCDataChannel>|
    object. If set to false, the negotiation is omitted and it is up to
    the script to create the corresponding ||RTCDataChannel|
    <http://dev.w3.org/2011/webrtc/editor/webrtc.html#idl-def-RTCDataChannel>|
    object at the other peer.

||Re-reading this carefully, I myself may have been confused when I 
quickly read it (the draft came out the same day I had to get changes 
in).  I probably could have implemented it as written, because *both* 
the meaning and the default were flipped from what I expected (and thus 
"createDataChannel("",{})" would have indeed still caused in-channel 
Open messages to occur).

The current definition confused me on the first read, because when we 
send Open messages, there is no negotiation, they're declarative.  So 
"negotiated=true" as the definition was confusing, since it said we were 
negotiating when in fact we're not.  This is reflected in my rewording 
below to use the word "notify".

So, again to be clear, this is what we'll be shipping in Fx 22, and I 
would suggest we change the definition to match this:

|    negotiated| of type boolean, defaulting to |false|

    The default value of false tells the user agent to create the
    channel and notify the other peer to create the channel and fire an
    event named datachannel to the peer's corresponding
    ||RTCDataChannel|
    <http://dev.w3.org/2011/webrtc/editor/webrtc.html#idl-def-RTCDataChannel>|
    object. If set to true, then no channel creation notification will
    be sent to the other peer, and it is up to the script to ensure
    creation of the corresponding ||RTCDataChannel|
    <http://dev.w3.org/2011/webrtc/editor/webrtc.html#idl-def-RTCDataChannel>|
    object at the other peer.

||This also changes the wording to use 'fire an event named datachannel' 
to match usage elsewhere in the draft for events.

This definition means "createDataChannel("",{})" will send an Open and 
cause ondatachannel, and "createDataChannel("",{negotiated=true})" will 
not send an Open, and will assume that the application has either 
pre-defined a channel or is negotiating the channel itself (externally).

-- 
Randell Jesup
randell-ietf@jesup.org