XEP-0198: Stream Management

Abstract:This specification defines an XMPP protocol extension for active management of an XML stream between two XMPP entities, including features for stanza acknowledgements, pings, and stream resumption.
Authors:Justin Karneges, Joe Hildebrand, Peter Saint-Andre
Copyright:(c) 1999 - 2009 XMPP Standards Foundation. SEE LEGAL NOTICES.
Type:Standards Track
Last Updated:2008-09-29

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
2. Stream Feature
3. Enabling a Stream Management Session
4. Stream Acknowledgements
5. Stream Pings
6. Stream Resumption
7. Implementation Notes
8. Minimal Implementation Guideline
9. Security Considerations
10. IANA Considerations
11. Jabber Registrar Considerations
    11.1. Protocol Namespaces
    11.2. Protocol Versioning
    11.3. Stream Features
12. XML Schemas
13. Acknowledgements

    A: Document Information
    B: Author Information
    C: Legal Notices
    D: Relation to XMPP
    E: Discussion Venue
    F: Requirements Conformance
    G: Notes
    H: Revision History

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):

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

The facilities provided by this specification are different from those provided by Advanced Message Processing [2], Message Receipts [3], and XMPP Ping [4]. Those specifications cover end-to-end and multi-hop acks and pings, which are useful in special scenarios, but unnecessary for checking of a single-hop stream. 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.

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. In particular, 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:

Note: In this specification, packets generated by a client are denoted by "C:" and packets generated by a server are denoted by "S:".

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 new stream features, where the features include an <sm/> element qualified by the 'urn:xmpp:sm:0' namespace (see Namespace Versioning regarding the possibility of incrementing the version number).

Note: The stream management feature MUST NOT be offered unless the initiating entity has been authenticated.

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

S: <stream:stream

S: <stream:features>
     <sm xmlns='urn:xmpp:sm:0'>
     <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>

If the receiving entity offers stream resumption, the <sm/> element MUST include an 'id' attribute (a unique identifier for the session) and SHOULD include a 'max' attribute that specifies the longest allowable time period for session resumption (in minutes).

Example 2. Stream features for resumption

S: <stream:features>
     <sm xmlns='urn:xmpp:sm:0' id='some-long-sm-id' max='15'>
     <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>

3. Enabling a Stream Management Session

To enable use of stream management, the client sends an <enable/> command to the server. If it wants to be allowed to resume the stream, it includes a boolean 'resume' attribute, which defaults to false [5].

Example 3. Client enables stream management

C: <enable xmlns='urn:xmpp:sm:0'/>

For information about enabling stream management when resuming a previous session, see the Stream Resumption section of this document.

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

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

Example 4. Server enables stream management

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

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

4. Stream Acknowledgements

After enabling the feature, the initiating or receiving entity can send acknowledgement elements at any time over the stream. An acknowledgement element is either an <r/> element ("request ack") or an <a/> element ("gratuitous ack"), qualified by the 'urn:xmpp:sm:0' namespace. Both elements are referred to here as "ack elements". The syntax is as follows.

Therefore an ack element is used to indicate a sequence number (contains 'c'), to acknowledge a sequence number (contains 'b'), or to do both at once (contains 'c' and contains 'b'). Acknowledging a previously-received ack element indicates stanza acceptance, in that all stanzas received until then are now safely in the receiver's hands and that the receiver will take care of them. Acks do not indicate successful delivery to a remote entity beyond the receiver.

Example 5. A message with an ack request

C: <message from='laurence@example.net/churchyard'
       I'll send a friar with speed, to Mantua, 
       with my letters to thy lord.
   <r xmlns='urn:xmpp:sm:0' c='1'/>

Note: The ack request SHOULD be sent in the same TCP packet as the XMPP stanza.

When an <r/> element ("request ack") is received, the recipient MUST acknowledge it by sending an ack element back to the sender. The sender does not have to wait for an ack to continue sending stanzas. The response ack MUST contain a value of 'b' that is greater than or equal to the 'c' value given in the request ack. Acks 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 defer the acks until the client is no longer being penalized.

When a sequence number is received (via the 'c' 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, then the sequence number and any associated state MAY be discarded. Before the session state is discarded, implementations SHOULD take alternative action with any unacknowledged stanzas (e.g. stanzas sent after the latest sequence number reported by 'b'). 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 6. An ack

S: <a xmlns='urn:xmpp:sm:0' b='1'/>

5. Stream Pings

Either entity can also ping the other. This is useful for ensuring that the TCP connection is still up and working, and also for determining latency. The procedure is intended to replace the legacy behavior of sending whitespace. Pinging is done by sending a 'ping' element:

Example 7. Pinging the Peer

<ping xmlns='urn:xmpp:sm:0'/>

The peer then MUST reply immediately with a 'pong' element.

Example 8. Replying to a Ping

<pong xmlns='urn:xmpp:sm:0'/>

A server that is throttling stanzas (and thus withholding acks until later) SHOULD still immediately reply to pings.

6. Stream Resumption

It can happen that an XML stream is terminated temporarily and involuntarily (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.

The <enable/> element MAY contain a 'resume' attribute with value "true" or "1", to request that the stream management session be made resumable. The <enable/> element MAY also contain a 'previd' attribute and a 'b' attribute, if the initiating entity wishes to resume a previously known stream management session. The value of the 'previd' attribute is set to the same value as the 'id' attribute of the acknowledgement feature element in the previous session. The value of the 'b' attribute, if applicable, is set to the last received sequence number (discussed below) by the initiating entity. If the initiating entity is not resuming a past session, the 'previd' and 'b' attributes MUST NOT be included.

Example 9. Client enables stream management with stream resumption

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

Example 10. Session Resumption Request

<resume xmlns='urn:xmpp:sm:0'/>

If the initiating entity provided a 'resume' attribute in the <enable/> element, and the receiving entity supports session resumption, then the receiving entity MAY provide a 'resume' attribute (with value "true" or "1") in the <enabled/> element to indicate that the session shall be resumable. If the initiating entity provided a 'previd' attribute in the <enable/> element, and the receiving entity supports session resumption, then the receiving entity MAY provide a 'b' attribute in the <enabled/> element. The value of this attribute is set to the last received sequence number (discussed below) by the receiving entity in the previous session. If the receiving entity does not support session resumption, or does not recognize the 'previd' as an earlier session, or there is no known last received sequence number for the session, then the attribute MUST NOT be included. If session resumption is used, and the receiving entity still has the stream for the previously-identified session open at this time, the old stream SHOULD be terminated.

Example 11. Session Resumed

<resumed xmlns='urn:xmpp:sm:0'/>

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.

We then assume that the client gets disconnected (e.g., because it has roamed into an area without connectivity). When the client once again has network connectivity, it attempts to resume its session.

Example 12. Client attempt to resume a previous session:

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

Example 13. Server informs client that session is resumed:

<resume xmlns='urn:xmpp:sm:0' b='7'/>

When a session is resumed, and resource binding is completed (if required), both the initiating entity and the receiving entity SHOULD retransmit any stanzas that were not accepted during the previous session, each based on the last received sequence number reported by the other. A client SHOULD NOT request the roster after resumption, because any changes to the roster while the client was disconnected will be sent to the client after it resumes. Similarly, the client SHOULD NOT resend presence stanzas in an act to restore its original presence state, as this state will have been retained by the server.

7. Implementation Notes

Stream management elements SHOULD be sent in the same TCP packet as XMPP stanzas, to reduce the number of total packets sent. In particular, if a request ack is received, an applications MAY wait a short period for something else to send before responding, so that the response ack can share a TCP packet with the other data.

8. Minimal Implementation Guideline

The Stream Management protocol has a complex appearance, and indeed it is complex to implement if you want to perform all of the optimizations allowed. However, a basic implementation is not very difficult, if you just want simple acking and don't care about sequence numbers too much. Here is what a basic implementation would do:

This is enough of an implementation to minimally satisfy the remote entity, and allows basic tracking of your own stanzas sent. If the stream connection is broken, you have a queue of unacknowledged stanzas that you can choose to handle appropriately (e.g., warned the sending user or send on reconnect).

9. Security Considerations

To follow.

10. IANA Considerations

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

11. Jabber Registrar Considerations

11.1 Protocol Namespaces

This specification defines the following XML namespace:

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

11.2 Protocol Versioning

If the protocol defined in this specification undergoes a revision that is not fully backwards-compatible with an older version, the XMPP Registrar shall increment the protocol version number found at the end of the XML namespaces defined herein, as described in Section 4 of XEP-0053.

11.3 Stream Features

Upon approval of this specification, the XMPP Registrar shall add 'urn:xmpp:sm:0:feature' to its registry of stream features.

12. XML Schemas

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


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

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

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

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

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

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

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

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


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


13. Acknowledgements

Thanks to Dave Cridland for his feedback.


Appendix A: Document Information

Series: XEP
Number: 0198
Publisher: XMPP Standards Foundation
Status: Experimental
Type: Standards Track
Version: 0.5
Last Updated: 2008-09-29
Approving Body: XMPP Council
Dependencies: XMPP Core
Supersedes: None
Superseded By: None
Source Control: HTML  RSS

Appendix B: Author Information

Justin Karneges

Email: justin@affinix.com
JabberID: justin@andbit.net

Joe Hildebrand

Email: jhildebrand@jabber.com
JabberID: hildjj@jabber.org

Peter Saint-Andre

JabberID: stpeter@jabber.org
URI: https://stpeter.im/

Appendix C: Legal Notices


This XMPP Extension Protocol is copyright (c) 1999 - 2009 by the XMPP Standards Foundation (XSF).


Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.

Disclaimer of Warranty

## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. In no event shall the XMPP Standards Foundation or the authors of this Specification be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification. ##

Limitation of Liability

In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising out of the use or inability to use the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.

IPR Conformance

This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which may be found at <http://xmpp.org/extensions/ipr-policy.shtml> or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA).

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

1. RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/rfc3920>.

2. XEP-0079: Advanced Message Processing <http://xmpp.org/extensions/xep-0079.html>.

3. XEP-0184: Message Receipts <http://xmpp.org/extensions/xep-0184.html>.

4. XEP-0199: XMPP Ping <http://xmpp.org/extensions/xep-0199.html>.

5. In accordance with Section of XML Schema Part 2: Datatypes, the allowable lexical representations for the xs:boolean datatype are the strings "0" and "false" for the concept 'false' and the strings "1" and "true" for the concept 'true'; implementations MUST support both styles of lexical representation.

6. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.

7. The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <http://xmpp.org/registrar/>.

8. XEP-0053: XMPP Registrar Function <http://xmpp.org/extensions/xep-0053.html>.

Appendix H: Revision History

Version 0.5 (2008-09-29)

Removed recommendation to use namespace prefixes; modified namespace to incorporate namespace versioning.


Version 0.4 (2008-09-08)

Added support for session resumption; re-organized the document; changed name to stream management; changed provisional namespace.


Version 0.3 (2007-10-03)

Updates per devcon discussion.


Version 0.2 (2007-04-05)

Require c attribute on <r/> element. Describe minimal implementation. Switch to standard temporary namespace.


Version 0.1 (2006-11-21)

Initial published version.


Version 0.0.3 (2006-11-08)

New version, using sequence numbers. (jk)

Version 0.0.2 (2004-12-11)

Further clarification, allow acking many stanzas at once. (jk)

Version 0.0.1 (2004-08-09)

First draft. (jk)