Spec question: Declaration of IceCandidate

[TL;DR - see proposed IceCandidate declaration at end of this email]

An IceCandidate needs to contain an a=candidate line and an indication of
which m= line it should be associated with. The m= indication is needed
when using trickle candidates, so that senders or candidate messages can
construct the proper protocol representation, and receivers of candidate
messages can know which ICE session the ICE candidate should be used in.

For example, see
http://xmpp.org/extensions/xep-0176.html#protocol-renegotiate, where the
following candidate XML stanza is used; it must be possible to generate
this stanza from an IceCandidate.

<content creator='initiator' name='this-is-the-audio-content'>

      <transport xmlns='urn:xmpp:jingle:transports:ice-udp:1'

                 pwd='asd88fgpdd777uzjYhagZg'

                 ufrag='8hhy'>

        <candidate component='1'

                   foundation='1'

                   generation='0'

                   id='m3110wc4nd'

                   ip='2001:db8::9:1'

                   network='0'

                   port='9001'

                   priority='21149780477'

                   protocol='udp'

                   type='host'/>

      </transport>
    </content>

The info in <candidate> will come from the IceCandidate.candidate line, but
content.name and transport.pwd/transport.ufrag will need to come from
elsewhere. If IceCandidate has the a=mid: value that identifies a media
block, this a=mid: value can be used as the content.name, and
transport.pwd/transport.ufrag can be looked up from the a=ice-ufrag, and
a=ice-pwd fields present in the corresponding SessionDescription media
block. (A SessionDescription.mediaBlock(id) method would be very helpful
here).

Not all SessionDescriptions will have a=mid: lines, but those that don't
will not be doing trickle candidates, so we don't need to worry about them
(other than ensuring that implementations require a=mid: in
setLocalDescription).

Therefore, I suggest the following declaration of IceCandidate. I think it
is useful for this to be an object as opposed to a dictionary, since in the
future we could add accessors to get at all the various candidate fields
(component, foundation, etc).

*

[Constructor (DOMString mediaId, DOMString candidate)]

// e.g. ("audio", <a=candidate>)

[Constructor (DOMString json)]

// e.g. ("{ "mediaId": "audio", "candidate": <a=candidate> }")
interface IceCandidate {

   attribute DOMString mediaId; // corresponds to a=mid:
   attribute DOMString
candidate<http://dev.w3.org/2011/webrtc/editor/webrtc.html#widl-IceCandidate-candidate>;
// corresponds to a=candidate:
   stringifier DOMString<http://dev.w3.org/2011/webrtc/editor/webrtc.html#widl-IceCandidate-DOMString-stringifier>();
// to JSON
};



*