RFC 3920 introduced the concept of binding a resource to an XML stream (this concept superseded part of the older jabber:iq:auth protocol described in &jep0078;). As defined in RFC 3920, 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.

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:

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.

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:

When a client binds multiple resources to a stream, proper management of 'from' addresses is imperative. The following rules apply:

1. A client SHOULD specify a 'from' address on every stanza.
2. 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.

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

Naturally, the existing rules from RFC 3920 regarding validation of asserted 'from' addresses still apply.

The following examples show a possible flow of resource binding and unbinding.

First, the client binds an initial resource to the stream.

Now the client sends some stanzas, making sure to set its 'from' address:

Now the client binds a second resource to the stream.

If the server does not allow entities to bind multiple resources to the stream, it MUST return a ¬allowed; error as described in RFC 3920.

Now the client sends more stanzas.

Note that the last stanza sent will be stamped by the server as from <juliet@capulet.com/core>, not as from <juliet@capulet.com/balcony>.

Now the client binds a third resource to the stream.

Now the client unbinds its initial resource.

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):

Now the client unbinds another resource.

Now the client unbinds its last remaining resource.

The server now SHOULD close the stream and terminate the underlying TCP connection.

If properly implemented, the modifications described herein do not introduce any new security concerns above and beyond those defined in RFC 3920. 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).

No interaction with &IANA; is required as a result of this document.

No interaction with the ®ISTRAR; is required as a result of this document.

Note: The following provisional schema is intended to replace the existing schema for the Resource Binding stream feature.