XEP-0305: XMPP Quickstart

WARNING: Consideration of this document has been Deferred by the XMPP Standards Foundation. Implementation of the protocol described herein is not recommended.

Table of Contents

1. Introduction

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.

2. Preparing to Connect

In accordance with RFC 6120 [1], before attempting to establish a stream the initiating entity needs to determine the IP address and port at which to connect, usually by means of DNS lookups as described in Section 3.2 of RFC 6120. Implementations SHOULD cache the results of DNS lookups in order to avoid this step whenever possible.

XMPP applications SHOULD cache whatever information they can about the peer, especially stream features data and Service Discovery [2] information. To facilitate such caching, servers SHOULD include Entity Capabilities [3] data in stream features as shown in Section 6.3 of XEP-0115. Note that for maximum benefit the server MUST include all of the stream features it supports in its replies to "disco#info" queries (i.e., not advertise such features only during stream establishment).

XMPP clients SHOULD cache roster information, and servers SHOULD make such caching possible, using Roster Versioning [4] as subsequently included in Section 2.1.1 of RFC 6121 [5].

3. Pipelining

One method of speeding the connection process is pipelining of requests, as in RFC 2920 [6] and the QUICKSTART extension proposed for SMTP (The QUICKSTART SMTP service extension [7]). The application of similar principles to XMPP was originally suggested by Tony Finch in February 2008 <http://mail.jabber.org/pipermail/standards/2008-February/017966.html>.

In essence, pipelining relies on two assumptions:

1. The parties to a stream can proactively send multiple XMPP-related "commands" in a single TCP packet (as one simple example, the receiving entity can send both the response stream header and stream features in a single packet).
2. The features that the receiving entity supports (e.g., stream features and SASL mechanisms) are stable over time, which means the initiating entity can assume support for certain features and send certain XMPP-related commands without discovering again that the receiving entity supports them.

Together, these assumptions enable the parties to reduce the number of round trips needed to complete the stream negotiation process.

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

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

In Step 1, the client assumes that the server supports the XMPP STARTTLS extension so it pipelines its initial stream header, the <starttls/> command, and the TLS ClientHello message.

Example 1. Step 1: Client Initiation

<stream:stream
  from='juliet@im.example.com'
  to='im.example.com'
  version='1.0'
  xml:lang='en'
  xmlns='jabber:client'
  xmlns:stream='http://etherx.jabber.org/streams'>
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
TLS ClientHello
  

In Step 2, the server pipelines its response stream header, stream features advertisement, STARTTLS <proceed/> response, and TLS ServerHello messages (which might include ServerHello, Certificate, ServerKeyExchange, CertificateRequest, and ServerHelloDone -- see RFC 5246 [8] for details).

Example 2. Step 2: Server Response to Initiation

<stream:stream
  from='im.example.com'
  id='t7AMCin9zjMNwQKDnplntZPIDEI='
  to='juliet@im.example.com'
  version='1.0'
  xml:lang='en'
  xmlns='jabber:client'
  xmlns:stream='http://etherx.jabber.org/streams'>
<stream:features>
  <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
    <required/>
  </starttls>
  <pipelining xmlns='urn:xmpp:features:pipelining'/>
  <c xmlns='http://jabber.org/protocol/caps'
     hash='sha-1'
     node='http://prosody.im/'
     ver='ItBTI0XLDFvVxZ72NQElAzKS9sU='/>
</stream:features>
<proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
TLS ServerHello
  

In Step 3, the parties complete the TLS negotiation.

Example 3. Step 3: TLS Handshake

Client might send some combination of Certificate, ClientKeyExchange, 
CertificateVerify, ChangeCipherSpec, and Finished (see RFC 5246)
  

In Step 4, the server knows that the client will need to restart the stream so it proactively attaches its response stream header and stream features after the TLS Finished message.

Example 4. Step 4: Server Proactively Restarts Stream

TLS Finished
<stream:stream
  from='im.example.com'
  id='vgKi/bkYME8OAj4rlXMkpucAqe4='
  to='juliet@im.example.com'
  version='1.0'
  xml:lang='en'
  xmlns='jabber:client'
  xmlns:stream='http://etherx.jabber.org/streams'>
<stream:features>
  <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
    <mechanism>SCRAM-SHA-1-PLUS</mechanism>
    <mechanism>SCRAM-SHA-1</mechanism>
    <mechanism>PLAIN</mechanism>
  </mechanisms>
  <pipelining xmlns='urn:xmpp:features:pipelining'/>
  <c xmlns='http://jabber.org/protocol/caps'
     hash='sha-1'
     node='http://prosody.im/'
     ver='ItBTI0XLDFvVxZ72NQElAzKS9sU='/>
</stream:features>
  

In Step 5, the client pipelines its initial stream header with the command for initiating the SASL authentication process (including SASL "initial response" data as explained in Section 6.3.10 of RFC 6120 to reduce the number of round trips).

Example 5. Step 5: Client Initiates SASL Authentication

<stream:stream
  from='juliet@im.example.com'
  to='im.example.com'
  version='1.0'
  xml:lang='en'
  xmlns='jabber:client'
  xmlns:stream='http://etherx.jabber.org/streams'>
<auth xmlns="urn:ietf:params:xml:ns:xmpp-sasl"
      mechanism="SCRAM-SHA-1">
  biwsbj1qdWxpZXQscj1vTXNUQUF3QUFBQU1BQUFBTlAwVEFBQUFBQUJQVTBBQQ==
</auth>
  

At this point the client and server might exchange multiple SASL-related messages, depending on the SASL mechanism in use. This specification does not attempt to reduce the number of round trips involved in the challenge-response sequence.

Example 6. Step 6: Server Sends SASL Challenge

<challenge xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
  cj1vTXNUQUF3QUFBQU1BQUFBTlAwVEFBQUFBQUJQVTBBQWUxMjQ2OTViLTY5Y
  TktNGRlNi05YzMwLWI1MWIzODA4YzU5ZSxzPU5qaGtZVE0wTURndE5HWTBaaT
  AwTmpkbUxUa3hNbVV0TkRsbU5UTm1ORE5rTURNeixpPTQwOTY=
</challenge>
  

When the client suspects that it is sending its final SASL response, it SHOULD append an initial stream header and resource binding request.

Example 7. Step 7: Client Sends Final SASL Response with Stream Header and Bind Request

<response xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
  Yz1iaXdzLHI9b01zVEFBd0FBQUFNQUFBQU5QMFRBQUFBQUFCUFUwQUFlMTI0N
  jk1Yi02OWE5LTRkZTYtOWMzMC1iNTFiMzgwOGM1OWUscD1VQTU3dE0vU3ZwQV
  RCa0gyRlhzMFdEWHZKWXc9
</response>
<stream:stream
  from='juliet@im.example.com'
  to='im.example.com'
  version='1.0'
  xml:lang='en'
  xmlns='jabber:client'
  xmlns:stream='http://etherx.jabber.org/streams'>
<iq id='yhc13a95' type='set'>
  <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
    <resource>balcony</resource>
  </bind>
</iq>
  

In Step 8, the server informs the client of SASL success (including "additional data with success" as explained in Section 6.3.10 of RFC 6120 to reduce the number of round trips), sends a response stream header and stream features, and informs the client of successful resource binding.

Example 8. Step 8: Server Accepts Bind Request

<success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
  dj1wTk5ERlZFUXh1WHhDb1NFaVc4R0VaKzFSU289
</success>
<stream:stream
  from='im.example.com'
  id='gPybzaOzBmaADgxKXu9UClbprp0='
  to='juliet@im.example.com'
  version='1.0'
  xml:lang='en'
  xmlns='jabber:client'
  xmlns:stream='http://etherx.jabber.org/streams'>
<stream:features>
  <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
  <sm xmlns='urn:xmpp:sm:3'/>
  <pipelining xmlns='urn:xmpp:features:pipelining'/>
  <c xmlns='http://jabber.org/protocol/caps'
     hash='sha-1'
     node='http://prosody.im/'
     ver='ItBTI0XLDFvVxZ72NQElAzKS9sU='/>
</stream:features>
<iq id='yhc13a95' type='result'>
  <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
    <jid>
      juliet@im.example.com/balcony
    </jid>
  </bind>
</iq>
  

The XMPP stream negotiation process in RFC 6120 required at least 19 round trips (including 4 for TLS negotiation). With pipelining, the number of round trips is reduced to 8.

Naturally, for typical client-to-server sessions, additional round trips are needed so that the client can gather service discovery information, retrieve the roster, etc. As noted, these steps can be reduced or eliminated by using entity capabilities and roster versioning.

4. Reconnection

The pain of multiple round trips is magnified if the initiating entity needs to reconnect frequently (e.g., because of intermittent network outages). Although BOSH [9] 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 (RFC 5077 [10]) in addition to the technologies already mentioned.

Reconnection can be further enhanced by using the stream resumption feature described in Stream Management [11]. XEP-0198 does not legislate exactly when it is safe for the server to allow the client to send the <resume/> request. Clearly, sending it before the stream is encrypted would increase the possibility of replay attacks. However, sending it after TLS negotiation (Step 4 above) but before SASL authentication and resource binding (Steps 5 through 8) would enable the client to begin sending stanzas more quickly. It is a matter of server policy whether to advertise the SM feature after TLS negotiation or only after SASL negotiation.

5. Security Considerations

To follow.

6. IANA Considerations

This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [12].

7. XMPP Registrar Considerations

This specification defines the following XML namespace:

• urn:xmpp:features:pipelining

Upon advancement of this specification from a status of Experimental to a status of Draft, the XMPP Registrar [13] shall add the foregoing namespace to the registry located at <http://xmpp.org/registrar/stream-features.html>, as described in Section 4 of XMPP Registrar Function [14].

8. Acknowledgements

Special thanks to Tony Finch for suggesting this work and for providing the initial outline of how pipelining would work. Thanks also to Waqas Hussain, Jehan Pagès, and Kevin Smith for their feedback.

Appendices

Appendix A: Document Information

Series: XEP
Number: 0305
Publisher: XMPP Standards Foundation
Status: Deferred
Type: Standards Track
Version: 0.1
Last Updated: 2011-08-25
Approving Body: XMPP Council
Dependencies: RFC 5077, RFC 6120, XEP-0115, XEP-0198
Supersedes: None
Superseded By: None
Short Name: N/A
Source Control: HTML
This document in other formats: XML  PDF

Appendix B: Author Information

Appendix C: Legal Notices

Appendix D: Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Appendix E: Discussion Venue

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.

Given that this XMPP Extension Protocol normatively references IETF technologies, discussion on the <xsf-ietf@xmpp.org> list might also be appropriate.

Errata can be sent to <editor@xmpp.org>.

Appendix F: Requirements Conformance

The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

Appendix G: Notes

Appendix H: Revision History

Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/

END