W3C home > Mailing lists > Public > public-webrtc@w3.org > January 2013

Re: Format of candidate-attribute string

From: Cullen Jennings (fluffy) <fluffy@cisco.com>
Date: Wed, 9 Jan 2013 03:14:32 +0000
To: Justin Uberti <juberti@google.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <C5E08FE080ACFD4DAE31E4BDBF944EB11336A58D@xmb-aln-x02.cisco.com>

every rev of the spec breaks all the running code so I am a long ways from worrying about backwards compatibility at this point - lets just do the right things even if that causes some small amount of pain. That said, I don't care much what we do on this but I think it needs to be resolved in the IETF trickily ice draft you and others are writing. 


On Jan 8, 2013, at 5:47 PM, Justin Uberti <juberti@google.com> wrote:

> According to the latest editor's draft, section 4.8.1.1, the candidate field is defined as follows:
> 
>    candidate of type DOMString, nullable
>    This carries the candidate-attribute as defined in section 15.1 of [ICE].
> 
> In other words, candidate-attribute is just "candidate:<blah>", not "a=candidate:<blah>CRLF".
> 
> 
> However, Chrome currently emits and expects to receive candidates of type "a=candidate:<blah>CRLF". Naturally, this is not trivially changeable, although we could transition this over a series of Chrome releases.
> 
> 
> 
> So the question becomes: is this (i.e., no a=) what was originally intended? If so, is this something we want to change?
> Firefox doesn't currently emit trickle candidates, and it could be made to handle either incoming format, so regardless of whether we choose to use a= or not, we have an opportunity to resolve this issue without breaking the world.
> 
> 
> 
> 
Received on Wednesday, 9 January 2013 03:15:08 UTC

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