xeps/xep-0338.xml

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
  <!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
  <title>Jingle Grouping Framework</title>
  <abstract>This specification provides an XML mapping for translating the RFC 5888 SDP Grouping Framework to Jingle</abstract>
  &LEGALNOTICE;
  <number>0338</number>
  <status>Experimental</status>
  <type>Standards Track</type>
  <sig>Standards</sig>
  <approver>Council</approver>
  <dependencies>
    <spec>XEP-0166</spec>
  </dependencies>
  <supersedes/>
  <supersededby/>
  <shortname>NOT_YET_ASSIGNED</shortname>
  &fippo;
  <revision>
    <version>0.1</version>
    <date>2014-01-08</date>
    <initials>psa</initials>
    <remark><p>Initial published version approved by the XMPP Council.</p></remark>
  </revision>
  <revision>
    <version>0.0.1</version>
    <date>2013-11-25</date>
    <initials>ph</initials>
    <remark><p>First draft.</p></remark>
  </revision>
</header>
<section1 topic="Introduction" anchor="intro">
  <p>&rfc5888; defines a framework to group SDP 'm' lines for different purposes. A mapping to Jingle as an extension to &xep0166; is defined in this document.</p>
  <p>It is anticipated that the primary use of this is with the &bundle; framework used in WebRTC.</p>
</section1>
<section1 topic='Mapping to Session Description Protocol' anchor='sdp'>
  <p>The SDP format defined in <cite>RFC 5888</cite> is shown below.</p>
  <code>
a=group:semantics identification-tag
  </code>
  <p>An example follows.</p>
  <code>
a=group:LS voice webcam
  </code>
  <p>This SDP attribute is translated to Jingle as a &lt;group/&gt; element qualified by the 'urn:xmpp:jingle:apps:grouping:0' namespace, as shown below. The semantics is mapped to a 'semantics' attribute. The identification-tags are mapped to content elements whose name attribute is set to the identification-tag.</p>
  <code><![CDATA[
<group xmlns='urn:xmpp:jingle:apps:grouping:0' semantics='semantics'>
  <content name='identification-tag 1'/>
  <content name='identification-tag 2'/>
</group>
  ]]></code>
  <p>An example follows.</p>
  <code><![CDATA[
<group xmlns='urn:xmpp:jingle:apps:grouping:0' semantics='LS'>
  <content name='voice'/>
  <content name='webcam'/>
</group>
  ]]></code>
  <p>The &lt;group/&gt; element is included as child of the &lt;jingle/&gt; element.</p>
  <code><![CDATA[
<iq from='romeo@montague.lit/orchard'
    id='rg6s5134'
    to='juliet@capulet.lit/balcony'
    type='set'>
  <jingle xmlns='urn:xmpp:jingle:1'
          action='session-initiate'
          initiator='romeo@montague.lit/orchard'
          sid='a73sjjvkla37jfea'>
    <group xmlns='urn:xmpp:jingle:apps:grouping:0' semantics='BUNDLE'>
      <content name='voice'/>
      <content name='webcam'/>
    </group>
    <content creator='initiator' name='voice'>
      [ ... ]
    </content>
    <content creator='initiator' name='webcam'>
      [ ... ]
    </content>
  </jingle>
</iq>
  ]]></code>
  <p>Note: the identification-tags correspond to the &lt;content/&gt; 'name' attributes. These in turn map to the 'mid' attribute in SDP.</p>
</section1>
<section1 topic='Determining Support' anchor='disco'>
  <p>If an entity supports the grouping framework described in <cite>RFC 5888</cite>, it MUST advertise that fact in its responses to &xep0030; information ("disco#info") requests by returning a feature of 'urn:ietf:rfc:5888':</p>
  <example caption='A disco#info query'><![CDATA[
<iq type='get' 
    from='calvin@usrobots.lit/lab'
    to='herbie@usrobots.lit/home'
    id='disco1'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
  ]]></example>
  <example caption='A disco#info response'><![CDATA[
<iq type='result' 
    from='herbie@usrobots.lit/home'
    to='calvin@usrobots.lit/lab'
    id='disco1'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <feature var='urn:xmpp:jingle:1'/>
    <feature var='urn:ietf:rfc:5888'/>
  </query>
</iq>
  ]]></example>
  <p>In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.</p>
</section1>
<section1 topic='Acknowledgements' anchor='acks'>
  <p>Thanks to Emil Ivov and Lance Stout for their feedback.</p>
  <p>The XML format for this specification originates from <cite>libjingle</cite><note>libjingle is now part of the WebRTC Native Code Package available from <link url='http://webrtc.org'>webrtc.org</link>.</note>.</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
  <p>This document introduces no additional security considerations above and beyond those defined in the documents on which it depends.</p>
</section1>

<section1 topic='IANA Considerations' anchor='iana'>
  <p>This document requires no interaction with &IANA;.</p>
</section1>

<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
  <section2 topic='Protocol Namespaces' anchor='registrar-ns'>
    <p>This specification defines the following XML namespace:</p>
    <ul>
      <li>urn:xmpp:jingle:apps:grouping:0</li>
    </ul>
    <p>The &REGISTRAR; includes the foregoing namespace to the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.</p>
  </section2>
  <section2 topic='Protocol Versioning' anchor='registrar-versioning'>
    &NSVER;
  </section2>
</section1>
<section1 topic='XML Schema' anchor='schema'>
  <p>TODO</p>
</section1>
</xep>