<abstract>This document proposes improvements to the definition of resource binding for inclusion in the specification that supersedes RFC 3920.</abstract>
<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 client daemon that is used by multiple applications), this document proposes improvements to resource binding in order to address these shortcomings.</p>
<section1topic='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 <unbind/> qualified by the 'urn:ietf:params:xml:ns:xmpp-bind' namespace, which in turn has a child element of <resource/> whose XML character data specifies the resource to be unbound:</p>
<examplecaption='Unbind'><![CDATA[
<iqtype='set'id='bind_2'>
<unbindxmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<resource>someresource</resource>
</unbind>
</iq>
]]></example>
<p>If the server does not understand the <unbind/> element, it MUST return an error of &badrequest;. Otherwise, if there is no such resource, the server MUST return an error of ¬found;. 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 by returning an appropriate stream feature as shown below:</p>
<examplecaption='Unbind Stream Feature'><![CDATA[
<stream:features>
<bindxmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<required/>
</bind>
<unbindxmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
</stream:features>
]]></example>
</section1>
<section1topic='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>
<olstart='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>
<section1topic='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>
<examplecaption='Binding an Initial Resource'><![CDATA[
<iqtype='set'id='bind-1'>
<bindxmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<resource>core</resource>
</bind>
</iq>
<iqtype='result'id='bind-1'>
<bindxmlns='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>
<p>Now the client binds a second resource to the stream.</p>
<examplecaption='Binding a Second Resource'><![CDATA[
<iqtype='set'id='bind-2'>
<bindxmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<resource>balcony</resource>
</bind>
</iq>
<iqtype='result'id='bind-2'>
<bindxmlns='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 ¬allowed; error as described in <cite>RFC 3920</cite>.</p>
<p>Note that the last stanza sent will be stamped by the server as from <juliet@capulet.com/core>, <em>not</em> as from <juliet@capulet.com/balcony>.</p>
<p>Now the client binds a third resource to the stream.</p>
<examplecaption='Binding a Third Resource'><![CDATA[
<iqtype='set'id='bind-3'>
<bindxmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<resource>softphone</resource>
</bind>
</iq>
<iqtype='result'id='bind-3'>
<bindxmlns='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>
<examplecaption='Unbinding a Resource'><![CDATA[
<iqtype='set'id='unbind-1'>
<unbindxmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<resource>core</resource>
</unbind>
</iq>
<iqtype='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>
<examplecaption='Client Generates Another Stanza'><![CDATA[
<messageto='romeo@montague.net'>
<body>Art thou not Romeo, and a Montague?</body>
</message>
]]></example>
<examplecaption='Server Stamps Stanza As From (New) Default Resource'><![CDATA[
<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>