<abstract>This document defines methods for speeding the process of connecting or reconnecting to an XMPP.</abstract>
&LEGALNOTICE;
<number>XXXX</number>
<status>ProtoXEP</status>
<type>Standards Track</type>
<sig>Standards</sig>
<dependencies>
<spec>RFC 5077</spec>
<spec>RFC 6120</spec>
<spec>XEP-0115</spec>
<spec>XEP-0198</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>N/A</shortname>
&stpeter;
<revision>
<version>0.0.1</version>
<date>2011-08-10</date>
<initials>psa</initials>
<remark><p>Rough draft.</p></remark>
</revision>
</header>
<section1topic='Introduction'anchor='intro'>
<p>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.</p>
<p>Note: Various parts of this document might be moved to separate documents at some point.</p>
</section1>
<section1topic='Preparing to Connect'anchor='prepare'>
<p>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.</p>
<p>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.)</p>
<p>One method of speeding the connection process is pipelining of requests, as in &rfc2920; and the QUICKSTART extension proposed for SMTP &smtpquickstart;. The application of similar principles to XMPP was originally suggested by Tony Finch in February 2008 <<linkurl='http://mail.jabber.org/pipermail/standards/2008-February/017966.html'>http://mail.jabber.org/pipermail/standards/2008-February/017966.html</link>>..</p>
<p>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.</p>
<p>If an XMPP server supports pipelining, then it MUST advertise a stream feature of <pipelining xmlns='urn:xmpp:pipelining:0'/>.</p>
<p>If both parties support pipelining, they can proceed as follows (the examples use the XML from the client-server stream establishment section of <cite>RFC 6120</cite>, although the same principles apply to server-to-server streams).</p>
<examplecaption='Pipelining for Stream Establishment'><![CDATA[
<p>As can be seen, pipelining needs 10 steps to complete session establishment, as opposed to 16 steps for the non-pipelined process described in <cite>RFC 6120</cite>.</p>
<p>Naturally, additional round trips are needed for XMPP clients to gather service discovery information, retrieve the roster, etc.</p>
<p>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).</p>
<p>The minimize the speed of reconnection, implementations are strongly encouraged to support TLS Session Resumption (&rfc5077;) in addition to the technologies already mentioned.</p>
<p>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.</p>
<p>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'/>.</p>
<p>During the stream management negotiation, the server will deliver a stream management ID for stream resumption.</p>
<examplecaption='Sending a Stream Management ID'><![CDATA[
<p>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.</p>
<examplecaption='Sending a New Stream Management ID'><![CDATA[
<p>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.</p>