Re: Format of candidate-attribute string


no, I think that would be the wrong thing because then when the ICE spec changes we need to track that. I think we should say it is the same as as wind is the IETF specs. The issues we are talking about is if we take the inner thing or also add the a= outer wrapper. 


On Jan 13, 2013, at 7:35 PM, Martin Thomson <martin.thomson@gmail.com> wrote:

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

Received on Monday, 14 January 2013 15:40:32 UTC