Re: ICECandidate.candidate syntax is wrong in Chrome

On Mon, Jun 23, 2014 at 8:41 AM, Emil Ivov <emcho@jitsi.org> wrote:

> On Mon, Jun 23, 2014 at 6:20 PM, Adam Roach <adam@nostrum.com> wrote:
> > On 6/23/14 09:32, Emil Ivov wrote:
> >>
> >> Personally I thought it was an oversight in the FF implementation
> >
> >
> > No; starting with the W3C spec (because we're talking about a JS API
> here),
> > we reached the same conclusion as Iñaki did, using the same (rather
> obvious)
> > chain of logic. It is most assuredly not an oversight, as we've had to
> take
> > extra steps to process the candidates that Chrome generates:
> >
> >
> http://dxr.mozilla.org/mozilla-central/source/media/webrtc/signaling/src/sipcc/core/gsm/fsmdef.c#4148
> >
> >> There were discussions about that at the interim in Boston and then
> >> again in Orlando...
> >
> >
> > Orlando? Ah, I see the confusion here. Iñaki is talking about a W3C API.
> > You're talking about... actually, wait. I don't know what you're talking
> > about.
>
> Oh, but you were almost there! ;)
>
> > The W3C didn't meet in Orlando, and the IETF doesn't specify
> > Javascript APIs.
>
> I am talking about the interface to implementations of a mechanism
> defined at the IETF. (Which the one incumbent implementation was
> using)
>
> Obviously the W3C can override that with whatever JS interface would
> come to mind! And actually why not do that? Obviously caring about
> breaking existing code is silly and compromising is for noobs ... so,
> forget I spoke!


I honestly have no idea what you are talking about here. The W3C API
has had things this way since early 2013 and we discussed it here:

http://lists.w3.org/Archives/Public/public-webrtc/2013Jan/0018.html

And Firefox has been behaving this way since trickle ICE landed around
6 months ago.

Given this, I'm not sure really in what you're talking about with
"incumbent"
implementations.

-Ekr