%ents; ]>
Proposed Resource Binding Improvements This document proposes improvements to the definition of resource binding for inclusion in the specification that supersedes RFC 3920. &LEGALNOTICE; 0193 Proposed Standards Track Standards JIG XMPP Core None None N/A &stpeter; 0.2 2007-01-02 psa

Required client to include from address on every stanza it sends over a stream to which it has bound multiple resources; specified server handling of sessions.

 0.1 2006-08-16 psa

Initial version.

 0.0.2 2006-08-15 psa

Added stream feature for unbind.

 0.0.1 2006-08-15 psa

First draft.
&RFC3920BISNOTE;

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 &xep0078;). 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 daemon process that is used by multiple applications), this document proposes improvements to resource binding in order to address these shortcomings.

Note: The recommendations described herein have been incorporated into rfc3920bis.

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:

someresource ]]>

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 and the unbind functionality by returning an appropriate stream feature as shown below:

]]>

When a client binds multiple resources to the same stream, proper management of 'from' addresses is imperative. In particular, a client MUST specify a 'from' address on every stanza it sends over a stream to which it has bound multiple resources. If a client does not specify a 'from' address on a stanza it sends over a stream to which it has bound multiple resources (or if it specifies as the 'from' address a full JID other than one of the bound resources), the server MUST do one of the following:

  1. Stamp the stanza with the resource that the server considers to be the "default resource" for the stream. The default resource SHOULD be the oldest resource bound to the stream, which typically will be the initial resource but which might be a resource bound later if subsequently the initial resource has been unbound.
  2. Return the stanza to the client with an <unknown-sender/> stanza error. Currently there is no <unknown-sender/> stanza defined in RFC 3920; the author will work to add such an error condition to rfc3920bis.

Which of these a server does is up to the implementation or deployment.

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

In instant messaging and presence applications, an XMPP server manages a session on behalf of a connected client. A server MUST create and manage a separate session for each distinct resource, even if there are multiple resources associated with a given XML stream. In particular:

  1. A server MUST consider each resource to be a distinct source of presence information, both with regard to presence notifications and with regard to presence probes.
  2. A server MUST manage rosters (see RFC 3920) and &xep0016; separately for each resource.

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

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

core juliet@capulet.com/core ]]>

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

]]>

Now the client binds a second resource to the stream.

balcony juliet@capulet.com/balcony ]]>

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.

Wherefore art thou? ]]>

In handling the last stanza shown above, the server will either return a <unknown-sender/> error or stamped the 'from' address <juliet@capulet.com/core> (but in no case will the server stamp the 'from' address as <juliet@capulet.com/balcony>. Here we assume that the server stamps the 'from' address.

Now the client binds a third resource to the stream.

softphone juliet@capulet.com/softphone ]]>

Now the client unbinds its initial resource.

core ]]>

Now the client sends another stanza without a 'from' address, which we assume the server stamps as from the new default resource (note that this is no longer the initial resource):

Art thou not Romeo, and a Montague? ]]> Art thou not Romeo, and a Montague? ]]>

Now the client unbinds another resource.

softphone ]]>

Now the client unbinds its last remaining resource.

balcony ]]>

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.

]]>