diff --git a/xep-0198.xml b/xep-0198.xml index 3d5f2a39..8ab41710 100644 --- a/xep-0198.xml +++ b/xep-0198.xml @@ -7,7 +7,7 @@
Stream Management - This specification defines an XMPP protocol extension for active management of an XML stream between two XMPP entities, including features for stanza acknowledgements, pings, pausing, hushing, resuming, and recovering. + 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. &LEGALNOTICE; 0198 Experimental @@ -18,15 +18,15 @@ None None - NOT YET ASSIGNED + NOT_YET_ASSIGNED &infiniti; &hildjj; &stpeter; 0.4 - 2008-03-11 + 2008-09-08 jjh/jk/psa -

Added pause, hush, resume, and recover actions; re-organized the document; changed name; changed provisional namespace.

 +

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

 0.3 @@ -67,176 +67,149 @@
-

&xmppcore; defines the fundamental streaming XML technology used by XMPP (in particular stream establishment and termination), but does not provide tools for actively managing XML streams after establishment and before termination. In particular, the following management features might improve network reliability and the end-user experience (especially when connectivity is infrequent or power consumption is a key consideration):

+

&xmppcore; 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 or power consumption is a key consideration):

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 &xep0079;, &xep0184;, and &xep0199;. The other 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:".

 - -

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 following series of packets shows a possible session flow for an XML stream that includes stream management, in this case between a client ("C:") and a server ("S:").

-

After negotiating use of TLS and authenticating via SASL, the receiving entity returns stream features to the initiating entity and includes an <sm/> element qualified by the 'urn:xmpp:tmp:sm' namespace &NSNOTE;. If the receiving entity offers stream recover, the <sm/> element includes an 'id' attribute and can include a 'max' attribute that specifies the longest allowable time period for session recover (in minutes).

- +

After negotiating use of TLS and authenticating via SASL, the receiving entity returns a new stream header to the intiating entity (including a namespace declaration for its preferred namespace prefix) along with new stream features, including an <sm/> element qualified by the 'urn:xmpp:tmp:sm' namespace &NSNOTE;.

+

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

+ + S: - + + + ]]> -

In order to enable stream management, the client sends an <enable/> command to the server. If it wants to be allowed to recover when necessary, it includes a boolean 'recover' attribute, which defaults to false &BOOLEANNOTE;.

+

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

+ + + + + + + + + ]]> + + + +

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

+C: ]]> -

The server then informs the client that stream management is enabled, including a notation of whether session recovery is allowed.

+

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:tmp:sm' namespace. The <error/> element indicates that there was a problem enabling the acknowledgement session. The <enabled/> element indicates successful enabling of the acknowledgement session.

+

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

+S: ]]> -

The client can then send use stream management features, such as sending a message and simultaneously requesting an acknowledgement from the server.

+

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

+ + + +

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:tmp:sm' 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 up to that point are now safe 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.

I'll send a friar with speed, to Mantua, with my letters to thy lord. -C: +C: ]]> -

(The ack request should be sent in the same TCP packet as the stanza.)

-

The server then acknowledges receipt.

+

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.

]]> -

The client can also attach a sequence number to the ack.

- - I'll send a friar with speed, to Mantua, with my letters to thy lord. - -C: - ]]> -

The client may want to ping the server in order to test the stream for connectivity.

- - ]]> -

The peer immediately replies with a pong.

- - ]]> -

After a while the client pauses the stream. As a result, the server will not send any stanzas to the client.

- - ]]> -

The server acknowledges the session pause and does not send any stanzas to the client until the client resumes the session.

- - ]]> -

The client then resumes the session.

- - ]]> -

The server acknowledges the session resumption and sends normal XMPP stanzas to the client.

- - -S: - xa - - -[ ... ] - ]]> -

The client may want to hush the session so that it is woken up by the server only if certain kinds of events happen. The desired events can be defined by a &xep0016; rule.

- - - - ]]> -

Now the server sends stanzas to the client only if they delivery is allowed in accordance with the "mobile" privacy list.

-

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 recover its session.

- - ]]> - - ]]> - - -

XMPP includes a method for acknowledging stanza reception between the initiating and receiving entities, to allow for transmission error detection and recovery.

-

The following rules apply:

-
    -
  1. An initiating entity that complies with this specification MUST include the 'version' attribute set to a value of "1.0" in the initial stream header.
    2. -
  2. When a receiving entity that complies with this specification receives an initial stream header that includes the 'version' attribute set to a value of at least "1.0", after sending a stream header in reply (including the version flag), and if the initiating entity has been authenticated, then the receiving entity MUST include an <ack/> element (qualified by the 'urn:xmpp:tmp:sm' namespace) along with the list of other stream features it supports.
    3. -
-

The facilities provided by this specification are different from those provided by &xep0079;, &xep0184;, and &xep0199;. The other 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.

-

There is a lot to be gained by adding this feature to the protocol, such as:

-
    -
  • Ability to take alternate action if the peer has not acknowledged receipt 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.
    • -
  • Clients can determine when they have reached a throughput limitation (such as "karma").
    • -
-

In addition, this specification also provides a way to "ping" the peer, useful to determine if the peer is available without having to send a real stanza.

- - -

When an initiating entity activates the acknowledgement feature with a receiving entity, the steps involved are as follows:

-
    -
  1. The initiating entity opens a TCP connection and initiates the stream by sending the opening XML stream header to the receiving entity, including the 'version' attribute set to a value of at least "1.0".
    2. -
  2. The receiving entity responds by opening a TCP connection and sending an XML stream header to the initiating entity, including the 'version' attribute set to a value of at least "1.0".
    3. -
  3. The initiating entity authenticates itself to the receiving entity.
    4. -
  4. The receiving entity offers the acknowledgement feature to the initiating entity by including it with the list of other supported stream features. The acknowledgement feature MUST NOT be offered unless the initiating entity has been authenticated. The acknowledgement feature element MAY contain an 'id' attribute and a <recover/> child element, and together they indicate support for session recovery (if one is present, the other MUST be present). The 'id' attribute acts as a unique identifier for the acknowledgement session, if the session is enabled (see below). The <recover/> element MAY contain a 'max' attribute, which indicates the number of minutes that a session shall remain recoverable after disconnection.
    5. -
  5. The initiating entity issues the enable command (an <enable/> element qualified by the 'urn:xmpp:tmp:sm' namespace) to instruct the receiving entity that it wishes to enable the acknowledgement feature. The <enable/> element MAY contain a 'recover' attribute with value 'yes', to request that the acknowledgement session be made recoverable. The <enable/> element MAY also contain a 'previd' attribute and a 'b' attribute, if the initiating entity wishes to recover a previously known acknowledgement 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 recovering a past session, the 'previd' and 'b' attributes MUST NOT be included.
    6. -
  6. The receiving entity MUST reply with an <enabled/> element or an <error/> element qualified by the 'urn:xmpp:tmp:sm' namespace. The <error/> element indicates that there was a problem enabling the acknowledgement session. The <enabled/> element indicates successful enabling of the acknowledgement session. If the initiating entity provided a 'recover' attribute in the <enable/> element, and the receiving entity supports session recovery, then the receiving entity MAY provide a 'recover' attribute (with value 'yes') in the <enabled/> element to indicate that the session shall be recoverable. If the initiating entity provided a 'previd' attribute in the <enable/> element, and the receiving entity supports session recovery, 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 recovery, 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 recovery 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.
    7. -
  7. After enabling the feature, the initiating or receiving entity MAY 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:tmp:sm' namespace. Both elements will hereby be referred to as simply "ack elements." An <r/> element MUST contain a 'c' attribute and MAY contain a 'b' attribute. An <a/> element MAY contain a 'c' attribute and/or a 'b' attribute. A 'c' attribute is used to indicate a sequence number. It is an integer value generated by the sender, and MUST be strictly increasing, however the sender MAY choose to reset the integer to a lower value if all stanzas sent have been acknowledged. The 'b' attribute acknowledges a previously-received sequence number from the other entity. Thus, 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 up to that point are now safe 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.
    8. -
  8. 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. As acks indicate stanza acceptance, a server that is throttling stanzas MUST defer the acks until the client is no longer being penalized.
    9. -
  9. 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. Everytime a new sequence number is received, the previous number can be discarded. If a stream ends, and it is not recovered 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.
    10. -
  10. When a session is recovered, 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 recovering, as any changes to the roster while the client was disconnected will be sent to the client after it recovers. 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.
    11. -
-

Examples of stanza acknowledgements are provided in the next section.

- - - - -

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

+ +

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

+ ]]>

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

+ ]]>

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

 + +

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 'yes', to request that the acknowledgement 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 acknowledgement 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.

+ + ]]> + + ]]> +

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 'yes') 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.

+ + ]]> +

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.

+ + ]]> + + ]]> +

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.

+ + -
    -
  • -

    To save bandwidth, it is recommended that implementations specify an XML namespace prefix assignment in the initial <stream> element for the 'urn:xmpp:tmp:sm' namespace.

    - To save bandwidth, it is RECOMMENDED that implementations specify an XML namespace prefix assignment in the initial <stream> element for the 'urn:xmpp:tmp:sm' namespace, and that this prefix be as brief as possible.

    + - ]]> - - ]]> -
    • -
  • Ack elements should ideally be sent in the same TCP packet as other stanzas, to reduce the number of total packets sent. In particular, if a request ack is received, applications may want to wait a short period for something else to send before responding, so that the response ack may share a packet with the other data.
    • -
  • When performing acknowledgement session recovery and also utilizing TLS, it is recommended to take advantage of TLS session resuming to further optimize the stream recovery process.
    • -
+ ]]> + + ]]> +

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.

 -

The Stanza Acknowledgements 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:

+

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:

  • As an initiating entity, send <enable/> with no attributes, and ignore the attributes on the <enabled/> response.
  • As a receiving entity, ignore the attributes on the <enable/> element received, and respond using <enabled/> with no attributes.
    • @@ -274,17 +247,13 @@ C: xmlns='urn:xmpp:tmp:sm' elementFormDefault='qualified'> - - - + @@ -294,32 +263,18 @@ C: - + - - - - - - - - - - - - - -