XEP-0198: Stream Management
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 and stream resumption.
Authors
Justin Karneges
Peter Saint-Andre
Joe Hildebrand
Fabio Forno
Dave Cridland
Matthew Wild
Thilo Molitor
SEE LEGAL NOTICES
Status
Stable
NOTICE: The protocol defined herein is a
Stable Standard
of the XMPP Standards Foundation. Implementations are encouraged and the protocol is appropriate for deployment in production systems, but some changes to the protocol are possible before it becomes a Final Standard.
Type
Standards Track
Version
1.6.3 (2025-07-28)
Document Lifecycle
Experimental
Proposed
Stable
Final
1.
Introduction
XMPP Core
] 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.
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. The following stream management features are of particular interest because they are expected to improve network reliability and the end-user experience:
Stanza Acknowledgements -- the ability to know if a stanza or series of stanzas has been received by one's peer.
Stream Resumption -- the ability to quickly resume a stream that has been terminated.
Stream management implements these features using short XML elements at the root stream level. These elements are not "stanzas" in the XMPP sense (i.e., not
RFC 6120
]) and are not counted or acked in stream management, since they exist for the purpose of managing stanzas themselves.
Stream management is used at the level of an XML stream. To check TCP connectivity underneath a given stream, it is RECOMMENDED to use whitespace keepalives (see
RFC 6120
]),
XMPP Ping (XEP-0199)
], or TCP keepalives. By contrast with stream management,
Advanced Message Processing (XEP-0079)
] and
Message Delivery Receipts (XEP-0184)
] 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.
Note: Stream Management can be used for server-to-server streams as well as for client-to-server streams. However, for convenience this specification discusses client-to-server streams only. The same principles apply to server-to-server streams.
2.
Stream Feature
The server returns a stream header to the client along with stream features, where the features include an
Namespace Versioning
regarding the possibility of incrementing the version number).
Note: The client cannot negotiate stream management until it has authenticated with the server and has bound a resource; see below for specific restrictions.
Example 1.
Server sends new stream header along with stream features
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
version='1.0'>
3.
Enabling Stream Management
To enable use of stream management, the client sends an
Example 2.
Client enables stream management
If the client wants to be allowed to resume the stream, it includes a boolean 'resume' attribute, which defaults to false [
]. For information about resuming a previous session, see the
Resumption
section of this document.
The
Upon receiving the enable request, the server MUST reply with an
Example 3.
Server enables stream management
The parties can then the use stream management features defined below.
If the server allows session resumption, it MUST include a 'resume' attribute set to a value of "true" or "1" [
].
Example 4.
Server enables stream management with session resumption
The
The
RFC 6120
] (i.e., "domainpart:port", where IPv6 addresses are enclosed in square brackets "[...]" as described in
RFC 5952
]); if reconnection to that location fails, the standard XMPP connection algorithm specified in
RFC 6120
applies.
The client MUST NOT attempt to negotiate stream management until it is authenticated; i.e., it MUST NOT send an
Non-SASL Authentication (XEP-0078)
] or
Server Dialback (XEP-0220)
]) has been completed successfully.
For client-to-server connections, the client MUST NOT attempt to enable stream management until after it has completed Resource Binding
unless it is resuming a previous session
(see
Resumption
).
The server SHALL enforce this order and return a
Error Handling
).
Example 5.
Server returns error if client attempts to enable stream management before resource binding
Note that a client SHALL only make at most one attempt to enable stream management. If a server receives a second
Example 6.
Server returns error if client attempts to enable stream management more than once
4.
Acks
After enabling stream management, the client or server can send ack elements at any time over the stream. An ack element is one of the following:
The element is used to
answer
a request for acknowledgement or to send an unrequested ack.
The
request
acknowledgement of received stanzas.
The following attribute is defined:
The 'h' attribute identifies the last
handled
stanza (i.e., the last stanza that the server will acknowledge as having received).
An element MUST possess an 'h' attribute.
The
Definition:
Acknowledging a previously-received ack element indicates that the stanza(s) sent since then have been "handled" by the server. By "handled" we mean that the server has accepted responsibility for a stanza or stanzas (e.g., to process the stanza(s) directly, deliver the stanza(s) to a local entity such as another connected client on the same server, or route the stanza(s) to a remote entity at a different server); until a stanza has been affirmed as handled by the server, that stanza is the responsibility of the sender (e.g., to resend it or generate an error if it is never affirmed as handled by the server).
Receipt of an
The value of 'h' starts at zero at the point stream management is enabled or requested to be enabled (see note below). The value of 'h' is then incremented to one for the first stanza handled and incremented by one again with each subsequent stanza handled. In the unlikely case that the number of stanzas handled during a stream management session exceeds the number of digits that can be represented by the unsignedInt datatype as specified in
XML Schema Part 2
] (i.e., 2
32
), the value of 'h' SHALL be reset from 2
32
-1 back to zero (rather than being incremented to 2
32
).
Note: Each entity maintains two counters for any given stream: a counter of stanzas it has sent, and a counter of stanzas it has received and handled ('h'). The counter for an entity's own sent stanzas is set to zero and started after sending either
The following annotated example shows a message sent by the client, a request for acknowledgement, and an ack of the stanza.
Example 7.
Simple stanza acking
xml:lang='en'>
I'll send a friar with speed, to Mantua,
with my letters to thy lord.
When an
Either party MAY send an element at any time (e.g., after it has received a certain number of stanzas, or after a certain period of time), even if it has not received an
It is RECOMMENDED that initiating entities (usually clients) send an element right before they gracefully close the stream, in order to inform the peer about received stanzas. Otherwise it can happen that stanzas are re-sent (usually by the server) although they were actually received.
When a party receives an element, it SHOULD keep a record of the 'h' value returned as the sequence number of the last handled outbound stanza for the current stream (and discard the previous value).
If a stream ends and it is not resumed within the time specified in the original
A server 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, delivery to an alternate resource, or committing the stanza to offline storage. (Note that servers SHOULD add a delay element with the original (failed) delivery timestamp, as per
Delayed Delivery (XEP-0203)
10
]).
A user-oriented client SHOULD try to silently resend the stanzas upon reconnection or inform the user of the failure via appropriate user-interface elements. Clients SHOULD also add a delay element with the original (failed) send timestamp, so that the original send date is preserved. Otherwise receiving clients could only display the reconnection timestamp of the sending client, which may confuse users.
Because unacknowledged stanzas might have been received by the other party, resending them might result in duplicates; there is no way to prevent such a result in this protocol, although use of the XMPP 'id' attribute on all stanzas can at least assist the intended recipients in weeding out duplicate stanzas.
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.
In addition, this protocol exchanges the sequence numbers of the last received stanzas on the previous connection, allowing entities to establish definitively which stanzas require retransmission and which do not, eliminating duplication through replay.
To request that the stream will be resumable, when enabling stream management the client MUST add a 'resume' attribute to the
].
Example 8.
Client enables stream management
If the server will allow the stream to be resumed, it MUST include a 'resume' attribute set to "true" or "1" on the
Example 9.
Server allows stream resumption
Example 10.
Alternative response: Server enables stream management without session resumption
Definition:
The 'id' attribute defines a unique identifier for purposes of stream management (an "SM-ID"). The SM-ID MUST be generated by the server. The client MUST consider the SM-ID to be opaque and therefore MUST NOT assign any semantic meaning to the SM-ID. The server MAY encode any information it deems useful into the SM-ID, such as the full JID
As noted, the
Example 11.
Server prefers reconnection at a particular location
location='[2001:41D0:1:A49b::1]:9222'
resume='true'/>
If the stream is terminated unexpectedly, the client would then open a TCP connection to the server. The order of events is as follows:
After disconnection, the client opens a new TCP connection to the server, preferring the address specified in the 'location' attribute (if any).
Client sends initial stream header.
Server sends response stream header.
Server sends stream features.
Client sends STARTTLS request.
Server informs client to proceed with the TLS negotiation.
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
RFC 5077
11
] to further optimize the resumption of the XML stream.)
Client sends new initial stream header.
Server sends response stream header.
Server 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
12
].)
The parties complete SASL negotiation.
Client sends new initial stream header.
Server sends response stream header.
Server sends stream features, offering the SM feature.
Client requests resumption of the former stream.
Note: The order of events might differ from those shown above, depending on when the server offers the SM feature, whether the client chooses STARTTLS, etc. Furthermore, in practice server-to-server streams often do not complete SASL negotiation or even TLS negotiation. The foregoing text does not modify any rules about the stream negotiation process specified in
RFC 6120
]. However, since stream management applies to the exchange of stanzas (not any other XML elements), it makes sense for the server to offer the SM feature when it will be possible for the other party to start sending stanzas, not before. See also
Recommended Order of Stream Feature Negotiation (XEP-0170)
13
].
To request resumption of the former stream, the client sends a
Example 12.
Stream resumption request
previd='some-long-sm-id'/>
If the server can resume the former stream, it MUST return a
Example 13.
Stream resumed
previd='some-long-sm-id'/>
If the server does not support session resumption, it MUST return a
Example 14.
Stream timed out
In both of these failure cases, the server SHOULD allow the client to bind a resource at this point rather than forcing the client to restart the stream negotiation process and re-authenticate.
If the former stream is resumed and the server still has the stream for the previously-identified session open at this time, the server SHOULD send a 'conflict' stream error and close that stream.
Example 15.
Server closes old stream that was replaced by new
When a session is resumed, the parties proceed as follows:
The sequence values are carried over from the previous session and are not reset for the new stream.
Upon receiving a
Both parties SHOULD retransmit any stanzas that were not handled during the previous session, based on the 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 management session 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.
Both parties SHOULD NOT try to re-establish state information (e.g.,
Service Discovery (XEP-0030)
14
] information).
6.
Error Handling
If an error occurs with regard to an
RFC 6120
].
An example follows.
Example 16.
Server returns error
Stream management errors SHOULD be considered recoverable; however, misuse of stream management MAY result in termination of the stream.
When a remote entity acknowledges that it has handled a number of stanzas that is higher than the amount of stanzas that it was sent (by sending an 'h' value that is too high), the local entity SHOULD generate an undefined-condition stream error that includes a
Example 17.
Entity closes stream because peer acknowledges more stanzas than it was sent
You acknowledged 10 stanzas, but I only sent you 8 so far.
7.
Stream Closure
A cleanly closed stream differs from an unfinished stream. If a client wishes to cleanly close its stream and end its session, it MUST send a so that the server can send unavailable presence on the client's behalf.
If the stream is not cleanly closed then the server SHOULD consider the stream to be unfinished (even if the client closes its TCP connection to the server) and SHOULD maintain the session on behalf of the client for a limited amount of time. The client can send whatever presence it wishes before leaving the stream in an unfinished state.
8.
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.
8.1 Basic Acking Scenario
The Stream Management protocol can be used to improve reliability using acks without the ability to resume a session. A basic implementation would do the following:
As a client, send
As a server, ignore the attributes on the
When receiving an
Keep an integer X for this stream session, initially set to zero. When about to send a stanza, first put the stanza (paired with the current value of X) in an "unacknowleged" queue. Then send the stanza over the wire with
This is enough of an implementation to minimally satisfy the peer, and allows basic tracking of each outbound stanza. If the stream connection is broken, the application has a queue of unacknowledged stanzas that it can choose to handle appropriately (e.g., warn a human user or silently send after reconnecting).
The following examples illustrate basic acking (here the client automatically acks each stanza it has received from the server, without first being prompted via an
First, after authentication and resource binding, the client enables stream management.
Example 18.
Client enables stream management
The server then enables stream management.
Example 19.
Server enables stream management
The client then retrieves its roster and immediately sends an
Example 20.
Client sends a stanza and requests acknowledgement
The server handles the client stanza (here returning the roster) and sends an element to acknowledge handling of the stanza.
Example 21.
Server handles client stanza and acknowledges handling of client stanza
The client then chooses to acknowledge receipt of the server's stanza (although here it is under no obligation to do so, since the server has not requested an ack), sends initial presence, and immediately sends an
Example 22.
Client acks handling of first server stanza, sends a stanza, and requests acknowledgement
The server immediately sends an element to acknowledge handling of the stanza and then broadcasts the user's presence (including to the client itself as shown below).
Example 23.
Server acks handling of second client stanza and sends a stanza
The client then acks the server's second stanza and sends an outbound message followed by an
Example 24.
Client acks receipt of second server stanza, sends a stanza, and requests acknowledgement
ciao!
The server immediately sends an element to acknowledge handling of the third client stanza and then routes the stanza to the remote contact (not shown here because the server does not send a stanza to the client).
Example 25.
Server acknowledges handling of third client stanza
And so on.
8.2 Efficient Acking Scenario
The basic acking scenario is wasteful because the client requested an ack for each stanza. A more efficient approach is to periodically request acks (e.g., every 5 stanzas). This is shown schematically in the following pseudo-XML.
Example 26.
An efficient session
In particular, on mobile networks, it is advisable to only request and/or send acknowledgements when an entity has other data to send, or in lieu of a whitespace keepalive or XMPP ping (XEP-0199).
9.
SASL2 And BIND2 Interaction
This section is about
Extensible SASL Profile (XEP-0388)
15
] (SASL2) and
Bind 2.0 (XEP-0386)
16
] (BIND2) interaction. You don't have to implement this if you don't implement SASL2 and BIND2.
Extensible SASL Profile (XEP-0388)
15
] (SASL2) describes a way of inlining the stream resumption into the authentication process to reduce the round-trips needed for authentication and subsequent stream resumption. Similarly
Bind 2.0 (XEP-0386)
16
] (BIND2) defines a way of inlining the stream management
9.1 Enable Stream Management Inline
To indicate support for inlining the activation of Stream Management into the resource binding process, the server adds a
If the client wishes to begin a new session (i.e. it has no prior session to resume), it simply includes the
Bind 2.0 (XEP-0386)
16
]
9.1.1 Failed To Enable Stream Management
In the unexpected case where the server was able to bind a resource for the client, but unable to enable stream management, it will include a
Bind 2.0 (XEP-0386)
16
].
9.2 Inline Stream Resumption
To indicate support for inlining stream resumption into the authentication process, the server adds a
If the client wishes to resume an existing session it, it simply includes the
Note: If the client included a
Extensible SASL Profile (XEP-0388)
15
] mandates that the
9.2.1 Failed Resumption
Sometimes resumption might fail - for example, because the session has been disconnected longer than the server’s resumption timeout. In this case, the server MUST include the
The client can find details about its new session in the
Bind 2.0 (XEP-0386)
16
]).
9.3 Inlining Examples
Example 27.
Server announces support for inlining activation of stream management and stream resumption
Example 28.
Client tries to resume stream and enables stream management inlined in its bind request
Example 29.
Client failed to enable stream management
Example 30.
Client failed to resume stream
Example 31.
Client failed to resume stream and to enable management of newly bound stream
10.
Security Considerations
As noted, a server MUST NOT allow a client to resume a stream management session until after the client has authenticated (for some value of "authentication"); this helps to prevent session hijacking.
If SASL2 is used to inline stream resumption, implementations must adhere to the security considerations defined in
Extensible SASL Profile (XEP-0388)
15
] regarding the inclusion of SASL2 requests and inline feature negotiation in TLS 0-RTT ("early data") extensions. That is, these elements MUST NOT be sent or processed if the stream would be resumed solely based on 0-RTT data, except when appropriate mitigations are in place (which are beyond the scope of this document, but may be defined by others).
11.
IANA Considerations
This XEP requires no interaction with the
Internet Assigned Numbers Authority (IANA)
17
].
12.
XMPP Registrar Considerations
12.1 Protocol Namespaces
This specification defines the following XML namespace:
urn:xmpp:sm:3
The
XMPP Registrar
18
] includes the foregoing namespace in its registry at <
>, as described in Section 4 of
XMPP Registrar Function (XEP-0053)
19
].
12.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
12.3 Stream Features
The XMPP Registrar includes 'urn:xmpp:sm:3' in its registry of stream features at <
>.
13.
XML Schemas
targetNamespace='urn:xmpp:sm:3'
xmlns='urn:xmpp:sm:3'
elementFormDefault='qualified'>
The protocol documented by this schema is defined in
XEP-0198: http://www.xmpp.org/extensions/xep-0198.html
use='required'/>
use='optional'/>
use='optional'
default='false'/>
use='optional'/>
use='optional'/>
use='optional'/>
use='optional'
default='false'/>
maxOccurs='1'>
use='optional'/>
use='required'/>
use='required'/>
use='optional'/>
use='optional'/>
14.
Acknowledgements
Thanks to Bruce Campbell, Jack Erwin, Philipp Hancke, Curtis King, Tobias Markmann, Alexey Melnikov, Pedro Melo, Robin Redeker, Mickaël Rémond, Florian Schmaus, and Tomasz Sterna for their feedback.
Appendices
Appendix A: Document Information
Series
XEP
Number
0198
Publisher
XMPP Standards Foundation
Status
Stable
Type
Standards Track
Version
1.6.3
2025-07-28
Approving Body
XMPP Council
Dependencies
XMPP Core
Supersedes
None
Superseded By
None
Short Name
sm
Schema
Source Control
HTML
This document in other formats:
XML
PDF
Appendix B: Author Information
Justin Karneges
Email
justin@karneges.com
JabberID
justin@andbit.net
Peter Saint-Andre
Email
stpeter@stpeter.im
JabberID
stpeter@jabber.org
URI
Joe Hildebrand
Email
jhildebr@cisco.com
JabberID
hildjj@jabber.org
Fabio Forno
Email
fabio.forno@gmail.com
JabberID
ff@jabber.bluendo.com
Dave Cridland
Email
dave@hellopando.com
JabberID
dwd@dave.cridland.net
Matthew Wild
Email
mwild1@gmail.com
JabberID
me@matthewwild.co.uk
Thilo Molitor
Email
thilo+xmpp@eightysoft.de
JabberID
thilo.molitor@juforum.de
Appendix C: Legal Notices
This XMPP Extension Protocol is copyright © 1999 – 2024 by the
XMPP Standards Foundation
(XSF).
Permissions
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. ##
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 from, out of, or in connection with the Specification or the implementation, deployment, or other use of 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 can be found at <
> or obtained by writing to XMPP Standards Foundation, P.O. Box 787, Parker, CO 80134 USA).
Visual Presentation
The HTML representation (you are looking at) is maintained by the XSF. It is based on the
YAML CSS Framework
, which is licensed under the terms of the
CC-BY-SA 2.0
license.
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 <
> for a complete list.
Errata can be sent to <
editor@xmpp.org
>.
Appendix F: Requirements Conformance
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in
BCP 14
RFC2119
RFC8174
] when,
and only when, they appear in all capitals, as shown here.
Appendix G: Notes
. RFC 6120: Extensible Messaging and Presence Protocol (XMPP): Core <
>.
. XEP-0199: XMPP Ping <
>.
. XEP-0079: Advanced Message Processing <
>.
. XEP-0184: Message Delivery Receipts <
>.
. In accordance with Section 3.2.2.1 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.
. RFC 5952: A Recommendation for IPv6 Address Text Representation <
>.
. XEP-0078: Non-SASL Authentication <
>.
. XEP-0220: Server Dialback <
>.
. XML Schema Part 2: Datatypes <
>.
10
. XEP-0203: Delayed Delivery <
>.
11
. RFC 5077: Transport Layer Security (TLS) Session Resumption without Server-Side State <
>.
12
. On the use of TLS Session resumption and SASL EXTERNAL <
>. Work in progress.
13
. XEP-0170: Recommended Order of Stream Feature Negotiation <
>.
14
. XEP-0030: Service Discovery <
>.
15
. XEP-0388: Extensible SASL Profile <
>.
16
. XEP-0386: Bind 2.0 <
>.
17
. 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 <
>.
18
. 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 <
>.
19
. XEP-0053: XMPP Registrar Function <
>.
Appendix H: Revision History
Note: Older versions of this specification might be available at
Version
1.6.3
(2025-07-28)
Remove leftover
egp
Version
1.6.2
(2024-09-24)
Clarify server enabling stream management without requested resume functionality.
gk
Version
1.6.1
(2022-10-05)
Clarify SASL2 and BIND2 interaction.
tm
Version
1.6
(2018-07-25)
Specify error conditions.
gdk
Version
1.5.4
(2018-07-19)
Mark 'h' element as xs:unsignedInt in the schema too, it is already specified to be a 32-bit wrapping unsigned integer in the text.
egp
Version
1.5.3
(2018-06-29)
Improve the note about stream management counters in section 4.
fs/mw
Version
1.5.2
(2016-12-08)
Send 'a' element before stream closure.
cs (XEP Editor: ssw)
Version
1.5.1
(2016-09-30)
Fix example syntax highlighting and formatting.
ssw
Version
1.5
(2015-09-13)
Noted that the server MAY include a 'h' attribute when failing to resume a session because it has been timed out
dg
Version
1.4rc1
(2015-07-27)
Expressed how to handle duplicate enable requests.
Noted the use of delay stamping in redelivery/offline messaging by servers.
dc
Version
1.3
(2011-06-29)
Specified that 'h' is REQUIRED when sending
Mentioned the possibility of duplicate stanzas
Clarified terminology to use 'client' and 'server' instead of 'initiating entity' and 'receiving entity'
Added note about the order of events in the stream negotiation process
Corrected the value of 'h' in several examples
Removed an extraneous 'stanzas' attribute from one example
Corrected the schema
psa/mw
Version
1.2
(2011-03-02)
Simplification based on implementation experience: removed acking per number of stanzas exchanged because either entity can request an ack at any time; moved throttling feature to a separate specification; removed 'stanzas' attribute from
psa/dc/mw
Version
1.1
(2010-03-05)
Corrected value of 'h' so that zero means no stanzas have yet been handled; clarified distinction between a cleanly closed stream and an unfinished stream.
psa/jk
Version
1.0
(2009-06-17)
Per a vote of the XMPP Council, advanced specification from Experimental to Draft.
psa
Version
0.10
(2009-06-11)
Editorial review.
psa
Version
0.9
(2009-06-03)
Specified that the value of the 'h' attribute starts at zero, not one.
Specified that the 'h' attribute is an unsignedInt and that it loops back to zero when reaching 2^32.
Added security consideration regarding session resumption and removed security consideration regarding proxies.
Clarified the meaning of handled as defining which entity has responsibility for a stanza.
Corrected schema and examples.
psa
Version
0.8
(2009-04-09)
Added
Simplified protocol by making the sequence number increment per stanza and removing the u attribute (which is now unnecessary).
Removed 'h' attribute from
Added 'max' and 'stanzas' attributes to both
Incremented the protocol version from 1 to 2.
Added in-depth usage scenarios.
ff/jk/jjh/psa
Version
0.7
(2009-03-30)
Removed pings (use XEP-0199, whitespace pings, or TCP keepalives instead); removed section on throttling, since it is unworkable.
jjh/psa
Version
0.6
(2009-03-19)
Incremented protocol version from 0 to 1.
Changed attribute names from c (?) and b (?) to u (unacknowledged) and h (handled).
Added stanzas attribute to specify maximum number of stanzas between acking requests.
More clearly defined error handling using
Defined error handling for
More clearly specified maximum reconnect time.
Added detailed scenarios for basic acking and for outbound and inbound throttling.
psa
Version
0.5
(2008-09-29)
Removed recommendation to use namespace prefixes; modified namespace to incorporate namespace versioning.
psa
Version
0.4
(2008-09-08)
Added support for session resumption; re-organized the document; changed name to stream management; changed provisional namespace.
jjh/jk/psa
Version
0.3
(2007-10-03)
Updates per devcon discussion.
jk
Version
0.2
(2007-04-05)
Require c attribute on
jk
Version
0.1
(2006-11-21)
Initial published version.
psa
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
Appendix I: Bib(La)TeX Entry
@report{karneges2004sm,
title = {Stream Management},
author = {Karneges, Justin and Saint-Andre, Peter and Hildebrand, Joe and Forno, Fabio and Cridland, Dave and Wild, Matthew and Molitor, Thilo},
type = {XEP},
number = {0198},
version = {1.6.3},
institution = {XMPP Standards Foundation},
url = {https://xmpp.org/extensions/xep-0198.html},
date = {2004-08-09/2025-07-28},
END