xeps/xep-0193.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>Proposed Resource Binding Improvements</title>
  <abstract>This document proposes improvements to the definition of resource binding for inclusion in the specification that supersedes RFC 3920.</abstract>
  &LEGALNOTICE;
  <number>0193</number>
  <status>Proposed</status>
  <type>Standards Track</type>
  <jig>Standards JIG</jig>
  <dependencies>
    <spec>XMPP Core</spec>
  </dependencies>
  <supersedes>None</supersedes>
  <supersededby>None</supersededby>
  <shortname>N/A</shortname>
  &stpeter;
  <revision>
    <version>0.1</version>
    <date>2006-08-16</date>
    <initials>psa</initials>
    <remark><p>Initial version.</p></remark>
  </revision>
  <revision>
    <version>0.0.2</version>
    <date>2006-08-15</date>
    <initials>psa</initials>
    <remark><p>Added stream feature for unbind.</p></remark>
  </revision>
  <revision>
    <version>0.0.1</version>
    <date>2006-08-15</date>
    <initials>psa</initials>
    <remark><p>First draft.</p></remark>
  </revision>
</header>
<section1 topic='Introduction' anchor='proto'>
  &RFC3920BISNOTE;
  <p><cite>RFC 3920</cite> introduced the concept of binding a resource to an XML stream (this concept superseded part of the older jabber:iq:auth protocol described in &xep0078;). As defined in <cite>RFC 3920</cite>, resource binding enables a client to bind one resource to a stream but does not enable a client to unbind a resource and leaves underspecified what a server and client should do if a client binds more than one resource to a stream. Because the ability to bind multiple resources to a stream is desirable in certain environments (e.g., for devices that are unable to open more than one TCP connection or when a machine runs a daemon process that is used by multiple applications), this document proposes improvements to resource binding in order to address these shortcomings.</p>
  <p>Note: The recommendations described herein have been incorporated into <cite>rfc3920bis</cite>.</p>
</section1>
<section1 topic='Unbinding a Resource' anchor='unbind'>
  <p>In order to properly manage the resources associated with an XML stream, a client must be able to unbind resources. This shall be completed by sending an IQ-set with a child element of &lt;unbind/&gt; qualified by the 'urn:ietf:params:xml:ns:xmpp-bind' namespace, which in turn has a child element of &lt;resource/&gt; whose XML character data specifies the resource to be unbound:</p>
  <example caption='Unbind'><![CDATA[
<iq type='set' id='bind_2'>
  <unbind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
    <resource>someresource</resource>
  </unbind>
</iq>
  ]]></example>
  <p>If the server does not understand the &lt;unbind/&gt; element, it MUST return an error of &badrequest;. Otherwise, if there is no such resource, the server MUST return an error of &notfound;. When the client unbinds the only resource associated with the stream, the server SHOULD close the stream and terminate the TCP connection.</p>
  <p>A server SHOULD advertise its support for the 'urn:ietf:params:xml:ns:xmpp-bind' namespace and the unbind functionality by returning an appropriate stream feature as shown below:</p>
  <example caption='Unbind Stream Feature'><![CDATA[
<stream:features>
  <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
    <required/>
  </bind>
  <unbind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
</stream:features>
  ]]></example>
</section1>
<section1 topic='Managing From Addresses' anchor='from'>
  <p>When a client binds multiple resources to a stream, proper management of 'from' addresses is imperative. The following rules apply:</p>
  <ol start='1'>
    <li>A client SHOULD specify a 'from' address on every stanza.</li>
    <li>If a client does not specify a 'from' address, the server MUST stamp a 'from' address, which SHOULD be the "default" resource as specified below.</li>
  </ol>
  <p>The "default" resource SHOULD be the oldest resource bound to the stream; normally that will be the initial resource, but it may be a resource bound later (i.e., if subsequently the initial resource has been unbound).</p>
  <p>Naturally, the existing rules from <cite>RFC 3920</cite> regarding validation of asserted 'from' addresses still apply.</p>
</section1>
<section1 topic='Examples' anchor='examples'>
  <p>The following examples show a possible flow of resource binding and unbinding.</p>
  <p>First, the client binds an initial resource to the stream.</p>
  <example caption='Binding an Initial Resource'><![CDATA[
<iq type='set' id='bind-1'>
  <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
    <resource>core</resource>
  </bind>
</iq>

<iq type='result' id='bind-1'>
  <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
    <jid>juliet@capulet.com/core</jid>
  </bind>
</iq>
  ]]></example>
  <p>Now the client sends some stanzas, making sure to set its 'from' address:</p>
  <example caption='Sending Some Stanzas'><![CDATA[
<iq from='juliet@capulet.com/core' type='get' id='roster-1'>
  <query xmlns='jabber:iq:roster'/>
</iq>

<iq to='juliet@capulet.com/core' type='result' id='roster-1'>
  <query xmlns='jabber:iq:roster'>
    <item jid='romeo@montague.net'/>
  </query>
</iq>

<presence from='juliet@capulet.com/core'/>
  ]]></example>
  <p>Now the client binds a second resource to the stream.</p>
  <example caption='Binding a Second Resource'><![CDATA[
<iq type='set' id='bind-2'>
  <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
    <resource>balcony</resource>
  </bind>
</iq>

<iq type='result' id='bind-2'>
  <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
    <jid>juliet@capulet.com/balcony</jid>
  </bind>
</iq>
  ]]></example>
  <p>If the server does not allow entities to bind multiple resources to the stream, it MUST return a &notallowed; error as described in <cite>RFC 3920</cite>.</p>
  <p>Now the client sends more stanzas.</p>
  <example caption='Sending More Stanzas'><![CDATA[
<iq from='juliet@capulet.com/balcony' type='get' id='roster-2'>
  <query xmlns='jabber:iq:roster'/>
</iq>

<iq to='juliet@capulet.com/balcony' type='result' id='roster-2'>
  <query xmlns='jabber:iq:roster'>
    <item jid='romeo@montague.net'/>
  </query>
</iq>

<presence from='juliet@capulet.com/balcony'/>

<message to='romeo@montague.net'>
  <body>Wherefore art thou?</body>
</message>
  ]]></example>
  <p>Note that the last stanza sent will be stamped by the server as from &lt;juliet@capulet.com/core&gt;, <em>not</em> as from &lt;juliet@capulet.com/balcony&gt;.</p>
  <p>Now the client binds a third resource to the stream.</p>
  <example caption='Binding a Third Resource'><![CDATA[
<iq type='set' id='bind-3'>
  <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
    <resource>softphone</resource>
  </bind>
</iq>

<iq type='result' id='bind-3'>
  <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
    <jid>juliet@capulet.com/softphone</jid>
  </bind>
</iq>
  ]]></example>
  <p>Now the client unbinds its initial resource.</p>
  <example caption='Unbinding a Resource'><![CDATA[
<iq type='set' id='unbind-1'>
  <unbind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
    <resource>core</resource>
  </unbind>
</iq>

<iq type='result' id='unbind-1'/>
  ]]></example>
  <p>Now the client sends another stanza without a 'from' address, which the server stamps as from the new default resource (i.e., no longer the initial resource):</p>
  <example caption='Client Generates Another Stanza'><![CDATA[
<message to='romeo@montague.net'>
  <body>Art thou not Romeo, and a Montague?</body>
</message>
  ]]></example>
  <example caption='Server Stamps Stanza As From (New) Default Resource'><![CDATA[
<message from='juliet@capulet.com/balcony' to='romeo@montague.net'>
  <body>Art thou not Romeo, and a Montague?</body>
</message>
  ]]></example>
  <p>Now the client unbinds another resource.</p>
  <example caption='Unbinding a Resource'><![CDATA[
<iq type='set' id='unbind-2'>
  <unbind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
    <resource>softphone</resource>
  </unbind>
</iq>

<iq type='result' id='unbind-2'/>
  ]]></example>
  <p>Now the client unbinds its last remaining resource.</p>
  <example caption='Unbinding the Final Resource'><![CDATA[
<iq type='set' id='unbind-3'>
  <unbind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
    <resource>balcony</resource>
  </unbind>
</iq>

<iq type='result' id='unbind-3'/>
  ]]></example>
  <p>The server now SHOULD close the stream and terminate the underlying TCP connection.</p>
  <example caption='Server Closes the Stream'><![CDATA[
</stream:stream>
  ]]></example>
</section1>
<section1 topic='Security Considerations' anchor='security'>
  <p>If properly implemented, the modifications described herein do not introduce any new security concerns above and beyond those defined in <cite>RFC 3920</cite>. However, care must be taken to properly manage 'from' addresses in order to avoid the delivery of stanzas from an unintended resource (which may, for example, leak presence information).</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
  <p>No interaction with &IANA; is required as a result of this document.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
  <p>No interaction with the &REGISTRAR; is required as a result of this document.</p>
</section1>
<section1 topic='XML Schema' anchor='schema'>
  <p>Note: The following provisional schema is intended to replace the existing schema for the Resource Binding stream feature.</p>
  <code><![CDATA[
<?xml version='1.0' encoding='UTF-8'?>

<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='urn:ietf:params:xml:ns:xmpp-bind'
    xmlns='urn:ietf:params:xml:ns:xmpp-bind'
    elementFormDefault='qualified'>

  <xs:element name='bind'>
    <xs:complexType>
      <xs:sequence>
        <xs:choice minOccurs='0' maxOccurs='1'>
          <xs:element name='resource' type='resourceType'/>
          <xs:element name='jid' type='fullJIDType'/>
        </xs:choice>
        <xs:element name='required'
                    minOccurs='0'
                    maxOccurs='1'
                    type='empty'/>
        </xs:choice>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

  <xs:element name='unbind'>
    <xs:complexType>
      <xs:sequence minOccurs='0'>
        <xs:element name='resource' type='resourceType'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

  <xs:simpleType name='resourceType'>
    <xs:restriction base='xs:string'>
      <xs:minLength value='1'/>
      <xs:maxLength value='1023'/>
    </xs:restriction>
  </xs:simpleType>

  <xs:simpleType name='fullJIDType'>
    <xs:restriction base='xs:string'>
      <xs:minLength value='8'/>
      <xs:maxLength value='3071'/>
    </xs:restriction>
  </xs:simpleType>

</xs:schema>
  ]]></code>
</section1>
</xep>