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" &BOOLEANNOTE;.

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.

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 &LOCALFULL; 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 (but the server need not ensure that SM-IDs are unique for all time, only for as long as the server is continuously running). 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 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 &sasltls;.)
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:2' namespace. The <resume/> element MUST include a 'previd' attribute whose value is the SM-ID of the former stream and MAY include an 'h' attribute that identifies the sequence number of the last handled stanza sent over the former stream from the receiving entity to the initiating entity (if stream management was being used in both directions); if there is no such sequence number for the former stream, the 'h' attribute MUST NOT be included.

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. The <resumed/> element MAY also include an 'h' attribute set to the sequence number of the last handled stanza sent over the former stream from the initiating entity to the receiving entity; if there is no such sequence number for the former stream, the 'h' attribute MUST NOT be included.

If the receiving entity does not support session resumption, it MUST return a <failed/> element, which SHOULD include an error condition of &feature;. 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 ¬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 negotiation process and re-authenticate.

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.

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

• 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., &xep0030; information).

When a server acts as a receiving entity for an XML stream, it might throttle the stream (i.e., impose rate limiting) if the initiating entity (a client or a server) attempts to send too much traffic over the stream (e.g., a very large number of stanzas, or a lesser number of stanzas that are relatively large). The formulas for determining when rate limiting shall be imposed are implementation-specific; however, nearly all XMPP server implementations include support for such throttling (often called "karma"). Therefore it would be helpful if the receiving entity could inform the initiating entity that the stream has been voluntarily throttled by the receiving entity. Some forms of "throttling" can occur naturally at the TCP layer without being voluntarily imposed by the receiving entity; the receiving entity cannot inform the initiating entity about such throttling. It can do so by sending a <t/> element to the receiving entity:

Note: Sending a throttling notification to the stream peer does not necessarily indicate that the entity is throwing away all stanzas, only that the entity has voluntarily slowed its processing of incoming stanzas.

The throttling notification MAY include a 'stanzas' attribute so that the receiving entity can inform the initiating entity of changes to the maximum number of stanzas between acks. This enables the receiving entity to dynamically adjust stanza acking in response to network conditions or stream usage.

If the number of unacknowledged stanzas is greater than or equal to the value of the 'stanzas' attribute, a throttled peer MUST NOT send any further stanzas.

If an entity sets the value of 'stanzas' to zero, it has stopped reading from the stream entirely.

For as long as the initiating entity is throttled, the receiving entity SHOULD periodically send a throttling notification to the initiating entity (e.g., every 30 seconds) to obviate the need for pings generated by the initating entity (which the receiving entity will ignore because the initiating entity is throttled).

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;.

An example follows.

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

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.