XEP-0198: Stream Management

WARNING: This Standards-Track document is Experimental. Publication as an XMPP Extension Protocol does not imply approval of this proposal by the XMPP Standards Foundation. Implementation of the protocol described herein is encouraged in exploratory implementations, but production systems should not deploy implementations of this protocol until it advances to a status of Draft.

Table of Contents

1. Introduction

XMPP Core [1] defines the fundamental streaming XML technology used by XMPP (i.e., stream establishment and termination including authentication and encryption). However, the core XMPP specification does not provide tools for actively managing a "live" XML stream. In particular, the following management features might improve network reliability and the end-user experience (especially when connectivity is infrequent):

• Acks -- the ability to know if a stanza or series of stanzas has been received by one's peer.
• Resumption -- the ability to quickly resume a stream that has been terminated.

The basic concept behind stream management is that the initiating entity (either a client or a server) and the receiving entity (a server) can exchange commands for active management of the stream. Instead of using XMPP IQ, message, or presence stanzas (which are relatively verbose), stream management uses a series of short XML elements at the root stream level.

The benefits to be gained from stream management include the following:

• Ability to take alternate action if the peer has not acknowledged handling of a stanza, such as storing and delivering again later.
• Servers can send stanzas with the same to/from JID pair on separate server-to-server TCP channels, as long as the sent stanzas have been acknowledged as handled.

Detailed descriptions of these features are provided in the remainder of this specification.

Note: To check TCP connectivity for a given stream, it is RECOMMENDED to use XMPP Ping [2], whitespace pings (see Section 5.7.3 of rfc3920bis [3]), or TCP keepalives.

Note: This specification applies at the level of an XML stream between a client and a server or between a server and a peer server. By constrast, Advanced Message Processing [4] and Message Receipts [5] define acks that are sent end-to-end over multiple streams; these facilities are useful in special scenarios but are unnecessary for checking of a direct stream between two XMPP entities. (It is also expected that this protocol will revive interest in Advanced Message Processing (AMP), because single-hop acks are necessary for AMP delivery receipts to function properly.)

2. Stream Feature

After negotiating use of TLS and authenticating via SASL, the receiving entity returns a new stream header to the intiating entity along with stream features, where the features include an <sm/> element qualified by the 'urn:xmpp:sm:1' namespace (see Namespace Versioning regarding the possibility of incrementing the version number).

The stream management feature MUST NOT be offered unless the initiating entity has been authenticated via SASL, Non-SASL Authentication [6], or Server Dialback [7].

Example 1. Server sends new stream header along with stream features

<stream:stream
    to='example.com'
    xmlns='jabber:client'
    xmlns:stream='http://etherx.jabber.org/streams'
    version='1.0'>

<stream:features>
  <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
    <required/>
  </bind>
  <sm xmlns='urn:xmpp:sm:1'>
    <optional/>
  </sm>
</stream:features>
  

The <sm/> element MAY include a 'stanzas' attribute whose value indicates the server's preferred maximum number of received stanzas between acks. For example, if the 'stanzas' attribute has a value of "10" then a server would prefer that a connected client request an ack after the client has sent at most ten stanzas to the server.

Example 2. Stream features with stanzas attribute

<stream:features>
  <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
    <required/>
  </bind>
  <sm xmlns='urn:xmpp:sm:1' stanzas='10'>
    <optional/>
  </sm>
</stream:features>
  

If the receiving entity offers stream resumption in addition to stanza acks, the <sm/> element MUST include a 'max' attribute that specifies the longest allowable time period for session resumption (in seconds).

Example 3. Stream features for resumption

<stream:features>
  <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
    <required/>
  </bind>
  <sm xmlns='urn:xmpp:sm:1' max='600' stanzas='10'>
    <optional/>
  </sm>
</stream:features>
  

3. Enabling Stream Management

To enable use of stream management, the client sends an <enable/> command to the server.

Example 4. Client enables stream management

<enable xmlns='urn:xmpp:sm:1'/>
  

If the client wants to be allowed to resume the stream, it includes a boolean 'resume' attribute, which defaults to false [8]. For information about resuming a previous session, see the Resumption section of this document.

Upon receiving the enable request, the receiving entity MUST reply with an <enabled/> element or a <failed/> element qualified by the 'urn:xmpp:sm:1' namespace. The <failed/> element indicates that there was a problem enabling the stream management "session". The <enabled/> element indicates successful enabling of the stream management session.

For client-to-server connections, the client SHOULD NOT attempt to enable stream management until after it has completed Resource Binding. The server MAY enforce this order and return a <failed/> element in response (see Error Handling).

Example 5. Server returns error if client attempts to enable stream management before resource binding

<failed xmlns='urn:xmpp:sm:1'>
  <unexpected-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</failed>
  

If session resumption is allowed, the receiving entity MUST include a 'resume' attribute set to a value of "true" or "1".

Example 6. Server enables stream management

<enabled xmlns='urn:xmpp:sm:1' resume='true'/>
  

The parties can then the use stream management features defined below.

4. Acks

After enabling the feature, the initiating or receiving entity can send ack elements at any time over the stream. An ack element is one of the following:

• The <r/> element is used to request acknowledgement of received stanzas.
• The <a/> element is used to answer a request for acknowledgement.

The <r/> and <a/> elements are qualified by the 'urn:xmpp:sm:1' namespace.

The following attributes are defined:

• The 'u' attribute identifies the last unacknowledged stanza (i.e., the last stanza generated by the sender which has not yet been acknowledged as handled by the peer). It is an integer value generated by the sender and MUST be strictly increasing.
• The 'h' attribute identifies the last handled stanza (i.e., the last stanza that the receiver will acknowledge as having handled). It is an integer value that corresponds to the 'u' attribute of the last received <r/> element.

An <r/> element MUST contain a 'u' attribute and MAY contain an 'h' attribute.

An <a/> element MUST contain an 'h' attribute and MAY contain a 'u' attribute.

Therefore an ack element is used to indicate an unacknowledged sequence number (contains 'u'), to acknowledge a sequence number (contains 'h'), or to do both at once (contains 'u' and contains 'h').

Definition: Acknowledging a previously-received ack element indicates that the stanza(s) sent since then have been "handled" by the receiver. By "handled" we mean that the stanzas have been either processed directly by the receiver, delivered to a local entity such as another connected client on the same server, or routed to a remote entity at a different server. Acking a stanza does not necessarily indicate that the stanza has been successfully delivered to the intended recipient, only that it has been handled by the entity at the other end of an XML stream.

Example 7. A message with a request

<message from='laurence@example.net/churchyard'
         to='juliet@example.com'
         xml:lang='en'>
  <body>
    I'll send a friar with speed, to Mantua, 
    with my letters to thy lord.
  </body>
</message>
<r xmlns='urn:xmpp:sm:1' u='1'/>
  

Note: Ack elements SHOULD be sent immediately after sending an XMPP stanza. In particular, if a request is received, an applications MAY wait a short period for something else to send before responding, so that the response can be sent with the other data.

When an <r/> element ("request") is received, the recipient MUST acknowledge it by sending an ack element (either <a/> or <r/>) to the sender. The sender does not have to wait for an ack to continue sending stanzas. The response MUST contain a value of 'h' that is greater than or equal to the 'u' value given in the request. The response SHOULD be sent as soon as possible, and MUST NOT be withheld for any condition other than a timeout. For example, a client with a slow connection might want to collect many stanzas over a period of time before acking, and a server might want to throttle incoming stanzas. Because acks indicate stanza acceptance, a server that is throttling stanzas MUST delay the response until the client is no longer being penalized.

When a recipient receives a sequence number for unacknowledged stanzas (via the 'u' attribute), the recipient SHOULD keep a record of this value as the last received sequence number for the current stream. Every time a new sequence number is received, the previous number SHOULD be discarded. If a stream ends and it is not resumed within the time specified in the acknowledgement feature element, the sequence number and any associated state MAY be discarded. Before the session state is discarded, implementations SHOULD take alternative action regarding any unacknowledged stanzas (e.g. stanzas sent after the latest sequence number reported by 'h'). A server implementation SHOULD treat unacknowledged stanzas in the same way that it would treat a stanza sent to an unavailable resource, by either returning an error to the sender or committing the stanza to offline storage. A user-oriented client implementation SHOULD inform the user of the failure via appropriate user-interface elements.

Example 8. An ack

<a xmlns='urn:xmpp:sm:1' h='1'/>
  

5. Resumption

It can happen that an XML stream is terminated unexpectedly (e.g., because of network outages). In this case, it is desirable to quickly resume the former stream rather than complete the tedious process of stream establishment, roster retrieval, and presence broadcast.

To request that the stream will be resumable, when enabling stream management the initiating entity MUST add a 'resume' attribute to the <enable/> element with a value of "true" or "1" [9].

Example 9. Client enables stream management

<enable xmlns='urn:xmpp:sm:1' resume='true'/>
  

If the receiving entity will allow the stream to be resumed, it MUST include a 'resume' attribute set to "true" or "1" on the <enabled/> element and MUST include an 'id' attribute that specifies an identifier for the stream.

Example 10. Server allows stream resumption

<enabled xmlns='urn:xmpp:sm:1' id='some-long-sm-id' resume='true'/>
  

Definition: The 'id' attribute defines a unique identifier for purposes of stream management (an "SM-ID"). The SM-ID MUST be generated by the receiving entity (server). The initiating entity MUST consider the SM-ID to be opaque and therefore MUST NOT assign any semantic meaning to the SM-ID. The receiving entity MAY encode any information it deems useful into the SM-ID, such as the full JID <localpart@domain.tld/resource> of a connected client (e.g., the full JID plus a nonce value). Any characters allowed in an XML attribute are allowed. The SM-ID MUST NOT be reused for simultaneous or subsequent sessions (as long as the receiving entity is available). The SM-ID SHOULD NOT be longer than 4000 bytes.

If the stream is terminated unexpectedly, the initiating entity would then open a TCP connection to the receiving entity. The order of events is envisioned to be as follows:

1. Initiating entity sends initial stream header.
2. Receiving entity sends response stream header.
3. Receiving entity sends stream features.
4. Initiating entity sends STARTTLS request.
5. Receiving entity informs initiating entity to proceed with the TLS negotiation.
6. The parties complete a TLS handshake. (Note: When performing session resumption and also utilizing TLS, it is RECOMMENDED to take advantage of TLS session resumption to further optimize the resumption of the XML stream.)
7. Initiating entity sends new initial stream header.
8. Receiving entity sends response stream header.
9. Receiving entity sends stream features, requiring SASL negotiation and offering appropriate SASL mechanisms. (Note: If the server considers the information provided during TLS session resumption to be sufficient authentication, it MAY offer the SASL EXTERNAL mechanism; for details, refer to draft-cridland-sasl-tls-sessions [10].)
10. The parties complete SASL negotiation.
11. Initiating entity sends new initial stream header.
12. Receiving entity sends response stream header.
13. Receiving entity sends stream features, offering the SM feature.
14. Initiating entity requests resumption of the former stream.

To request resumption of the former stream, the initiating entity sends a <resume/> element qualified by the 'urn:xmpp:sm:1' namespace. This element MUST include a 'previd' attribute whose value is the SM-ID of the former stream and SHOULD include an 'h' attribute that identifies the last acknowledged sequence number sent over the former stream from the receiving entity to the initiating entity.

Example 11. Stream resumption request

<resume xmlns='urn:xmpp:sm:1' previd='some-long-sm-id' h='foo'/>
  

If the receiving entity can resume the former stream, it MUST return a <resumed/> element that includes a 'previd' attribute set to the SM-ID of the former stream.

If the receiving entity does not support session resumption, it MUST return a <failed/> element, which SHOULD include an error condition of <feature-not-implemented/>. If the receiving entity does not recognize the 'previd' as an earlier session (e.g., because the former session has timed out), it MUST return a <failed/> element, which SHOULD include an error condition of <item-not-found/>. In both of these failure cases, the receiving entity SHOULD allow the initiating entity to bind a resource at this point rather than forcing the initiating entity to restart the stream and re-authenticate.

The <resumed/> element MAY also include an 'h' attribute set to the last acknowledged sequence number sent over the former stream from the initiating entity to the receiving entity. If there is no known last acknowledged sequence number for the former stream, then the 'h' attribute MUST NOT be included.

If the former stream is resumed and the receiving entity still has the stream for the previously-identified session open at this time, the old stream SHOULD be terminated.

Example 12. Stream resumed

<resumed xmlns='urn:xmpp:sm:1' previd='some-long-sm-id'/>
  

When a session is resumed, the parties SHOULD proceed as follows:

• Both parties SHOULD retransmit any stanzas that were not accepted during the previous session, based on the last acknowledged sequence number reported by the peer.
• A reconnecting client SHOULD NOT request the roster, because any roster changes that occurred while the client was disconnected will be sent to the client after the stream resumes.
• The client SHOULD NOT resend presence stanzas in an attempt to restore its former presence state, since this state will have been retained by the server.

6. Error Handling

If an error occurs with regard to an <enable/> or <resume/> element, the receiving entity MUST return a <failed/> element. This element SHOULD contain an error condition, which MUST be one of the stanza error conditions defined in rfc3920bis [11].

An example follows.

Example 13. Server returns error

<failed xmlns='urn:xmpp:sm:1'>
  <unexpected-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</failed>
  

In addition, the <pong/> element MAY contain an error condition.

Stream management errors SHOULD be considered recoverable; however, misuse of stream management MAY result in termination of the stream.

7. Scenarios

The following scenarios illustrate several different uses of stream management. The examples are that of a client and a server, but stream management can also be used for server-to-server streams.

<enable xmlns='urn:xmpp:sm:1'/>
    

<enabled xmlns='urn:xmpp:sm:1'/>
    

<iq id='ls72g593' type='get'>
  <query xmlns='jabber:iq:roster'/>
</iq>
<r xmlns='urn:xmpp:sm:1' u='1'/>
    

<iq id='ls72g593' type='result'>
  <query xmlns='jabber:iq:roster'>
    <item jid='juliet@capulet.lit'/>
    <item jid='benvolio@montague.lit'/>
  </query>
</iq>
<a xmlns='urn:xmpp:sm:1' u='1'/>
    

<presence/>
<r xmlns='urn:xmpp:sm:1' u='2'/>
    

<presence from='romeo@montague.lit/orchard' to='romeo@montague.lit/orchard'/>
<a xmlns='urn:xmpp:sm:1' u='2'/>
    

<message to='juliet@capulet.lit'>
  <body>ciao!</body>
</message>
<r xmlns='urn:xmpp:sm:1' u='3'/>
    

<a xmlns='urn:xmpp:sm:1' u='3'/>
    

8. Security Considerations

To follow.

9. IANA Considerations

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

10. Jabber Registrar Considerations

11. XML Schemas

<?xml version='1.0' encoding='UTF-8'?>

<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='urn:xmpp:sm:1'
    xmlns='urn:xmpp:sm:1'
    elementFormDefault='qualified'>

  <xs:element name='a' type='ackElementType'/>

  <xs:element name='enable'>
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base='empty'>
          <xs:attribute name='resume' 
                        type='xs:boolean'
                        use='optional'
                        default='false'/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

  <xs:element name='enabled'>
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base='empty'>
          <xs:attribute name='host' 
                        type='xs:string'
                        use='optional'/>
          <xs:attribute name='port' 
                        type='xs:unsignedShort'
                        use='optional'/>
          <xs:attribute name='resume' 
                        type='xs:boolean'
                        use='optional'
                        default='false'/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

  <xs:element name='failed'>
    <xs:complexType>
      <xs:sequence xmlns:err='urn:ietf:params:xml:ns:xmpp-stanzas' minOccurs='0'>
        <xs:group ref='err:stanzaErrorGroup'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

  <xs:element name='r' type='ackElementType'/>

  <xs:element name='resume' type='empty'/>

  <xs:element name='sm'>
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base='empty'>
          <xs:attribute name='id' type='xs:string' use='required'/>
          <xs:attribute name='max' type='xs:positiveInteger' use='optional'/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

  <xs:complexType name='ackElementType'>
    <xs:simpleContent>
      <xs:extension base='empty'>
        <xs:attribute name='h' type='xs:integer' use='optional'/>
        <xs:attribute name='u' type='xs:integer' use='optional'/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>

  <xs:simpleType name='empty'>
    <xs:restriction base='xs:string'>
      <xs:enumeration value=''/>
    </xs:restriction>
  </xs:simpleType>

</xs:schema>
  

12. Acknowledgements

Thanks to Dave Cridland, Philipp Hancke, Curtis King, Tobias Markmann, Pedro Melo, Robin Redeker, and Mickaël Rémond for their feedback.

Appendices

Appendix A: Document Information

Series: XEP
Number: 0198
Publisher: XMPP Standards Foundation
Status: Experimental
Type: Standards Track
Version: 0.7
Last Updated: 2009-03-30
Approving Body: XMPP Council
Dependencies: XMPP Core
Supersedes: None
Superseded By: None
Short Name: NOT_YET_ASSIGNED
Source Control: HTML  RSS

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 3920) and XMPP IM (RFC 3921) 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.

Errata may 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

END