Re: Format of candidate-attribute string

Yeah, I'm just trying to get input on what was intended here, and what the
actual Right Thing (TM) is, so we can make a decision.


On Tue, Jan 8, 2013 at 7:14 PM, Cullen Jennings (fluffy)
<fluffy@cisco.com>wrote:

>
> 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.
> >
> >
> >
> >
>
>