RE: Format of candidate-attribute string

In this case, the right thing would be to make a candidate object with
discrete attributes for ip, port, priority, foundation, base, etc...

We could argue about what then best facilitates ease of use in signaling,
maybe a stringify that produces a=candidate.

 *From:* Cullen Jennings (fluffy)
*Sent:* ‎January‎ ‎9‎, ‎2013 ‎2‎:‎22‎ ‎PM
*To:* Justin Uberti <juberti@google.com>
*CC:* public-webrtc@w3.org
*Subject:* 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.
>
>
>
>