This document describes a general request redirection mechanism for Jabber queries.

There are cases where only the receiver of a query, e.g. the receiver of <iq type='get'/> requests, knows the real location of the targeted data object. Reasons might be load balancing, changes in the protocol and/or usage patterns, or an additional level of indirection for improved flexibility. The possible reasons are very similar to reasons for (temporary) HTTP redirection.

Redirection adds an additional feature to the protocol. But it also adds also a small amount of complexity to implementations. The mechanism has been designed in a way such that it affects implementations only minimally while providing maximum flexibility.

For security reasons the redirection mechanism is only valid for <iq type='get'/> packets.

A client sends a query to a server. The server may well be an other client acting as a server for this transaction. The server decides that it can not serve the original request. It redirects the request to an other server. In order to do so, it sends a redirection query to the client. The redirection query informs the client about the modified query including the new destination. The client then repeats the request by sending the redirected query to other server.

The meaning of <iq/> queries is specified by multiple parameters, i.e. JID, <query/> namespace, and namespace specific tags and attributes. Many of these parameters may change during the redirection. To allow for maximum flexibility, the redirection query contains the complete redirected query.

The redirection query is identified by the "type" attribute and by the code of an embedded <error/> tag. The code is "302". The redirection is meant to be temporary, not permanent.

The original query is returned as a child of the <iq type='error'/>.

The redirected query sent from the server back to the client is embedded into the <error/> tag.

The envelope of the redirected query must preserve all attributes of the initial query except for the destination JID ("to" attribute). In particular, it must preserve the "id" attribute.

The must not redirect any query other than <iq type='get'/>.

The redirected query may target a different entity than the original query and it may have different parameters. But the redirected query must be manufactured in such a way that the result returned from the redirected query is compatible with the original query.

The client must check the redirected query. The redirected query is valid only if all three of the following conditions are met:

1. the original query is <iq type='get'/>
2. the redirected query is <iq type='get'/>
3. the <iq/> envelope of the redirected query has all attributes of the original query except for the "to" attribute

If redirections are cascaded then the client should stop the sequence after a reasonable number of redirections. Three consecutive redirects, which make a total of four trials, should be enough.

Applications must not rely on more than three consecutive redirections for a single query.

The redirection mechanism can be implemented transparently for the protocol engine. The client should unwrap the redirected query, check for validity, and send the data to the connection.

Protocol implementations do not have to create a new request context. The request context of the original query will still be valid since the redirector must preserve the query id.

The query id is often used by the protocol engine to relate queries sent and queries received in order to form request-response pairs. Using the query id the client can find the related original query when the result of the redirected query returns.

However, the client must check the validity before re-sending the redirected query.

This document describes a connection transfer mechanism for telling clients (or others) to reconnect to a different address.

This is useful for transfering people to a different server in a cluster if it is going down for maintenance or during login to transfer the person to a certain server in a cluster.

The transfer packet is addressed to the user from the domain they are logged into, it contains the server address to connect to which can be domain name or ip address, it can also contain an optional port number. There is also the domain specified just in case they have to use a different domain name when they log in or to maintain the original domain.