Establishing an XMPP session requires a fairly large number of round trips between the initiating entity and the receiving entity. In many deployment scenarios, it would be helpful to reduce the number of round trips and, in general, the time needed to establish a session. This document defines protocols and best practices to do just that.

Note: Various parts of this document might be moved to separate documents at some point.

In accordance with &rfc6120;, before attempting to establish a stream the initiating entity needs to determine the IP address and port at which to connect. Implementations SHOULD cache the results of DNS lookups in order to avoid this step whenever possible.

XMPP clients SHOULD also cache whatever information they can, especially the roster (see &xep0237;) and &xep0030; information. Servers SHOULD support &xep0237; and SHOULD include &xep0115; data in stream features to facilitate such caching. (Caching of service discovery data also applies to server-to-server connections.)

One method of speeding the connection process is pipelining of requests, as in the QUICKSTART extension proposed for SMTP &smtpquickstart;. The application of similar principles to XMPP was originally suggested by Tony Finch.

In essence, pipelining lets an initiating entity assume that the receiving entity supports the same (or almost the same) features it did on the previous connection attempt. As a result, the initiating entity can proactively send multiple XMPP-related "commands" in a single TCP packet, thus reducing the number of round trips.

If an XMPP server supports pipelining, then it MUST advertise a stream feature of <pipelining xmlns='urn:xmpp:pipelining:0'/>.

If both parties support pipelining, they can proceed as follows (the examples use the XML from the client-server stream establishment section of RFC 6120, although the same principles apply to server-to-server streams).

As can be seen, pipelining needs 10 steps to complete session establishment, as opposed to 16 steps for the non-pipelined process described in RFC 6120.

Naturally, additional round trips are needed for XMPP clients to gather service discovery information, retrieve the roster, etc.

The pain of multiple round trips is magnified if the initiating entity needs to reconnect frequently (e.g., because of intermittent network outages). Although &xep0124; can be used to mitigate the pain, BOSH is not appropriate for all scenarios and is not currently used in others (e.g., server-to-server streams).

The minimize the speed of reconnection, implementations are strongly encouraged to support TLS Session Resumption (&rfc5077;) in addition to the technologies already mentioned.

If &xep0198; is used, including support for stream resumption, the server can treat the stream management identifier as a "ticket" for stream resumption (similar to the use of a ticket for TLS session resumption). Here's how.

First, if an XMPP server allows stream management IDs as stream resumption tickets, then it MUST advertise a stream feature of <tickets xmlns='urn:xmpp:sm:tickets:0'/>.

During the stream management negotiation, the server will deliver a stream management ID for stream resumption.

The server SHOULD do send an ID if TLS has already been negotiated, since the SM-ID might be used as a session resumption ticket.

Now, when the client reconnects it includes the SM-ID in its opening stream header.

If the server accepts the SM-ID as a ticket, it MUST echo the identifier in its response stream header.

After the client and server negotiate TLS to protect the stream (preferably using TLS session resumption to reduce the number of round trip), the server SHOULD immediately allow the client to start sending stanzas and SHOULD also immediately send a new SM-ID to the client.

A server MUST NOT treat a stream management identifier as a stream resumption ticket unless the original stream was protected by means of TLS.

A server MUST time out a stream management identifier after a configurable amount of time (typically no more than a few minutes).

This document requires no interaction with &IANA;.

To follow.

Special thanks to Tony Finch for suggesting this work and providing the initial outline of how pipelining would work. Thanks also to Kevin Smith for his early feedback.