Re: Format of candidate-attribute string

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