W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2014

Re: ICECandidate.candidate syntax is wrong in Chrome

From: Emil Ivov <emcho@jitsi.org>
Date: Mon, 23 Jun 2014 18:41:52 +0300
Message-ID: <CAPvvaa+T=H5PJbDuQw1KkjfvnPdrmyD1mHXGrSzMFETQ6bCNqA@mail.gmail.com>
To: Adam Roach <adam@nostrum.com>
Cc: Iñaki Baz Castillo <ibc@aliax.net>, "public-webrtc@w3.org" <public-webrtc@w3.org>
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!

Emil
Received on Monday, 23 June 2014 15:42:40 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:41 UTC