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, Joe Hildebrand, Peter Saint-Andre, Fabio Forno
Copyright:© 1999 - 2009 XMPP Standards Foundation. SEE LEGAL NOTICES.
Status:Experimental
Type:Standards Track
Version:0.8
Last Updated:2009-04-08

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 are advised to carefully consider whether it is appropriate to deploy implementations of this protocol before it advances to a status of Draft.


Table of Contents


1. Introduction
2. Stream Feature
3. Enabling Stream Management
4. Acks
5. Resumption
6. Throttling
7. Error Handling
8. Scenarios
    8.1. Basic Acking Scenario
    8.2. Efficient Acking Scenario
    8.3. Throttling Scenario
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

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

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, stream management uses a series of short XML elements at the root stream level.) In particular, it is expected that the following stream management features will improve network reliability and the end-user experience:

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

Note: Examples prepended by "C:" are sent by a client and examples prepended by "S:" are sent by a server. Stream management can be used server-to-server but most of the examples in this specification show its use between a client and a server.

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

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

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

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

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

C: <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 establishing the stream management "session". The <enabled/> element indicates successful establishment of the stream management session.

Example 5. Server enables stream management

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

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

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

Example 6. Server enables stream management with session resumption

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

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

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

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

4. Acks

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

The following attribute is defined:

An <r/> element MAY contain an 'h' attribute (if acking is done in both directions).

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

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 accepted by the receiver, not necessarily that they have been fully processed 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.

The following example shows a message sent by the client, a request for acknowledgement, and an ack of the stanza.

Example 8. Simple stanza acking

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

C: <r xmlns='urn:xmpp:sm:1'>

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

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 equal to the number of stanzas handled by the recipient of the <r/> element. The response SHOULD be sent as soon as possible after receiving the <r/> element, 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 (but SHOULD notify the client that it is throttling incoming stanzas, as described under Throttling).

When a party returns an ack in response to an <r/> element or receives such an ack, it SHOULD keep a record of the 'h' value returned as the sequence number of the last handled stanza for the current stream (and discard the previous 'h' value).

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 by both parties. Before the session state is discarded, implementations SHOULD take alternative action regarding any unhandled stanzas (e.g. stanzas sent after the most recent 'h' value):

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

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

S: <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. 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.

Example 11. Stream resumption request

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

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.

Example 12. Stream resumed

S: <resumed xmlns='urn:xmpp:sm:1' previd='some-long-sm-id' h='another-sequence-number'/>
  

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.

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 SHOULD proceed as follows:

6. Throttling

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. [11] It can do so by sending a <t/> element to the receiving entity:

Example 13. Throttling notification

S: <t xmlns='urn:xmpp:sm:1'/>
  

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 a server to dynamically adjust stanza acking in response to network conditions or stream usage.

Example 14. Throttling notification with acking adjustment

S: <t xmlns='urn:xmpp:sm:1' stanzas='5'/>
  

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

7. 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 [12].

An example follows.

Example 15. Server returns error

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

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

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. In fact, a basic implementation might not even care about sequence numbers and therefore would do the following:

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.

First, after authentication and resource binding, the client enables stream management.

Example 16. Client enables stream management

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

The server then enables stream management.

Example 17. Server enables stream management

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

The client then retrieves its roster and immediately sends an <r/> element to request acknowledgement.

Example 18. Client sends a stanza and requests acknowledgement

C: <iq id='ls72g593' type='get'>
     <query xmlns='jabber:iq:roster'/>
   </iq>

C: <r xmlns='urn:xmpp:sm:1'/>
    

The server returns the roster and immediately sends an <a/> element to acknowledge handling of the stanza.

Example 19. Server sends a stanza and acknowledges handling of client stanza

S: <iq id='ls72g593' type='result'>
     <query xmlns='jabber:iq:roster'>
       <item jid='juliet@capulet.lit'/>
       <item jid='benvolio@montague.lit'/>
     </query>
   </iq>

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

The client then sends initial presence and immediately sends an <r/> element to request acknowledgement, incrementing by one its internal representation of how many stanzas have been handled by the server.

Example 20. Client sends a stanza and requests acknowledgement

C: <presence/>

C: <r xmlns='urn:xmpp:sm:1'/>
    

The server handles the stanza by broadcasting the user's presence and immediately sends an <a/> element to acknowledge handling of the stanza.

Example 21. Server sends a stanza and acknowledges handling of client stanza

S: <presence from='romeo@montague.lit/orchard' to='romeo@montague.lit/orchard'/>

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

The client then sends an outbound message and an <r/> element.

Example 22. Client sends a stanza and requests acknowledgement

C: <message to='juliet@capulet.lit'>
     <body>ciao!</body>
   </message>

C: <r xmlns='urn:xmpp:sm:1'/>
    

The server handles the stanza by routing it to the remote contact and immediately sends an <a/> element to acknowledge handling of the stanza.

Example 23. Server acknowledges handling of the stanza

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

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) in accordance with the 'stanzas' attribute value provided by the receiving entity on the <enabled/> element. This is shown schematically in the following pseudo-XML.

Example 24. An efficient session

C: <enable/>
S: <enabled stanzas='5'/>
C: <message/>
C: <message/>
C: <message/>
C: <message/>
C: <message/>
C: <r/>
S: <a h='5'/>
C: <message/>
C: <message/>
C: <message/>
C: <message/>
C: <message/>
C: <r/>
S: <a h='5'/>
    

8.3 Throttling Scenario

As mentioned, many servers will impose rate limiting on clients that send large amounts of traffic. In the following scenario, we assume that the first few messages sent by the client are rather large, so the server voluntarily throttles the client. The server then sends throttling notifications every 30 seconds, dynamically adjusting the maximum number of stanzas between acks as a rough indicator of how serious the throttling is.

Example 25. A session with throttling

C: <enable/>
S: <enabled stanzas='5'/>
C: <message/>
C: <message/>
C: <message/>
[throttling kicks in]
S: <t stanzas='2'/>
[client adjusts its expectations and requests an ack]
C: <r/>
[client still throttled, server ignores <r/> for now]
[30 seconds go by]
S: <t/>
[30 seconds go by]
S: <t/>
C: <message/>
[backlog starts to ease, server adjusts 'stanzas' value]
S: <t stanzas='3'/>
C: <message/>
[server has handled the first 5 messages so it finally replies to <r/>]
S: <a h='5'/>
C: <message/>
C: <message/>
C: <message/>
[client has sent 3 messages so requests an ack]
C: <r/>
[throttling is over, server replies to <r/> and sets 'stanzas' back to 5]
S: <a h='8' stanzas='5'/>
    

9. Security Considerations

To follow.

10. IANA Considerations

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

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 [14] 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 [15].

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:1:feature' to its registry of stream features.

12. 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='id' 
                        type='xs:string'
                        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='resumptionElementType'>

  <xs:element name='resumed' type='resumptionElementType'>

  <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:attribute name='stanzas' 
                        type='xs:unsignedShort' 
                        use='optional'/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

  <xs:element name='t'>
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base='empty'>
          <xs:attribute name='stanzas' 
                        type='xs:unsignedShort' 
                        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='stanzas' 
                        type='xs:unsignedShort' 
                        use='optional'/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>

  <xs:complexType name='resumptionElementType'>
    <xs:simpleContent>
      <xs:extension base='empty'>
        <xs:attribute name='h' 
                      type='xs:positiveInteger' 
                      use='optional'/>
        <xs:attribute name='previd' 
                      type='xs:string' 
                      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>
  

13. 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.8
Last Updated: 2009-04-08
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

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/

Fabio Forno

Email: fabio.forno@gmail.com
JabberID: ff@jabber.bluendo.com


Appendix C: Legal Notices

Copyright

This XMPP Extension Protocol is copyright © 1999 - 2009 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. 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-0199: XMPP Ping <http://xmpp.org/extensions/xep-0199.html>.

3. rfc3920bis: proposed revisions to Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/draft-saintandre-rfc3920bis>. (work in progress)

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

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

6. XEP-0078: Non-SASL Authentication <http://xmpp.org/extensions/xep-0078.html>.

7. XEP-0220: Server Dialback <http://xmpp.org/extensions/xep-0220.html>.

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

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

10. On the use of TLS Session resumption and SASL EXTERNAL <http://tools.ietf.org/html/draft-cridland-sasl-tls-sessions>. Work in progress.

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

12. rfc3920bis: proposed revisions to Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/draft-saintandre-rfc3920bis>. (work in progress)

13. 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/>.

14. 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/>.

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


Appendix H: Revision History

Version 0.8 (2009-04-08)

Simplified protocol by making the sequence number increment per stanza and removing the u attribute (which is now unnecessary); added <t/> element for throttling notifications.

(ff/jk/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)

(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 <r/> element. Describe minimal implementation. Switch to standard temporary namespace.

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

END