Re: [rtcweb] Data Channel Negotiation and reopening of decisions

[Randell Jesup <[e-mail]>]

On 2/13/2013 5:03 PM, Martin Thomson wrote:
> None of what I suggest would change the API.  At most, it would have
> removed the in-band handshake messages in exchange for loosening some
> of the guarantees.  And I've been trained to value the deletion of
> code highly.  That seemed like a good trade.

I think the no-negotiation proposal would require various API changes if 
you work out the details.

I understand the wish to reduce code.  (You do realize we're running 
over a lightweight stack like SCTP over DTLS over ICE/TURN over UDP, 
right?  ;-)

However, I'm not sure that you're actually reducing code by shifting to 
SDP (I think you're just moving the code/complexity, as the existing 
structures for negotiating m= lines can't be reused here I believe).  
And I think the SDP+no-negotiation-open proposal ends up with yet more 
complexity (and importantly, more application (JS) complexity).

The least complex IMHO is the 0-RTT in-band option, though it's similar 
in complexity to the current "pure" inband (without accelerated 
call-start creation via SDP - i.e. 1.5RTT for all opens).

> And timing?  It wasn't until you presented at the interim that I
> realized just how little value the in-band handshake was adding.

Which Interim?  This one (where I wasn't presenting the in-band 
protocol, though discussion moved there), or Stockholm, where it was 
presented (and again at Atlanta where we added the 'protocol' field, 
which was about the only major commentary).   I realize someone can (and 
will) object at any stage; I just wish objections of this fundamental 
nature were made (a lot) earlier.

> In terms of the specifics of your fast open proposal, what do you do
> with the message(s) that arrive on channels that you reject?  How does
> this surface in the API?

There is no rejection.  Creation of DataChannels (per the JS API) is 
purely declarative.  If you (as an application) wish to 'reject' a 
channel, either throw the object away or call .close() on it if you want 
to be nice to the sender.

> I'll do a blow-by-blow on your points below, if you want to continue
> the conversation.  If we're exchanging rhetoric bombs, I see little
> point.

No, I'm quite willing to continue the conversation; to an extent (how 
much to be determined by the WG) the snake has snuck out of the bag and 
we now have to deal with the comments (both yours and Justin/Peter's).  
I will concede I have an interest in retaining a solution similar to the 
one I've proposed (in-band or preferably 0-RTT), as I have it coded in 
Firefox, used in applications and largely debugged and on-track for 
release to production in 12-18 weeks or so (and major changes might 
cause problems with that and/or future version incompatibilities).  
That's the impact of revisiting issues; we considered DataChannels a 
critical component to have from the start of WebRTC and put a lot of 
effort into first discussing it on the lists and then implementing it.  
We began implementation a year ago, and have tracked changes from the 
lists and drafts since then.   But that isn't the only consideration.

Partly my comments were aimed at all instances where we go back (and go 
back again) with progress being elusive, not just this one issue.

-- 
Randell Jesup
[e-mail]