XEP-0198: Stanza Acknowledgements

This document defines an XMPP protocol extension for stream-level (single-hop) stanza acknowledgement and pinging.

WARNING: This Standards-Track document is Experimental. Publication as an XMPP Extension Protocol does not imply approval of this proposal by the XMPP Standards Foundation. Implementation of the protocol described herein is encouraged in exploratory implementations, but production systems should not deploy implementations of this protocol until it advances to a status of Draft.

Document Information

Series: XEP
Number: 0198
Publisher: XMPP Standards Foundation
Status: Experimental
Type: Standards Track
Version: 0.1
Last Updated: 2006-11-21
Approving Body: XMPP Council
Dependencies: None
Supersedes: None
Superseded By: None
Short Name: ack
Wiki Page: <http://wiki.jabber.org/index.php/Stanza Acknowledgements (XEP-0198)>

Author Information

Justin Karneges

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

Legal Notice

This XMPP Extension Protocol is copyright 1999 - 2007 by the XMPP Standards Foundation (XSF) and is in full conformance with the XSF's Intellectual Property Rights Policy <http://www.xmpp.org/extensions/ipr-policy.shtml>. This material may be distributed only subject to the terms and conditions set forth in the Creative Commons Attribution License (<http://creativecommons.org/licenses/by/2.5/>).

Discussion Venue

The preferred venue for discussion of this document is the Standards discussion list: <http://mail.jabber.org/mailman/listinfo/standards>.

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.

Conformance Terms

The following 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".

Table of Contents


1. Introduction
2. Stanza Acknowledgements
    2.1. Overview
    2.2. Narrative
3. Examples
4. Pinging
5. Implementation Notes
6. IANA Considerations
7. Jabber Registrar Considerations
    7.1. Stream Features
    7.2. Protocol Namespaces
8. XML Schemas
    8.1. Stream Feature
    8.2. Protocol Namespace
Notes
Revision History

1. Introduction

XMPP Core [1] does not specify a way for entities in a stream (single-hop) to acknowledge successful receipt of a stanza. This specification proposes a mechanism for efficient and flexible acknowledgement of stanzas. The protocol is intended for use with both Client-to-Server and Server-to-Server streams.

It is important not to confuse the facilities provided by this specification with those provided by Message Events [2], Advanced Message Processing [3], and Message Receipts [4]. The other specifications cover end-to-end and multi-hop acknowledgements, which are useful in special scenarios, but unnecessary and overkill for general use. In contrast, this specification proposes a protocol intended for widespread, general use. It is also expected that this protocol will revive interest in AMP, as single-hop acknowledgements 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:

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.

2. Stanza Acknowledgements

2.1 Overview

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. 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 'http://jabber.org/protocol/ack' namespace) along with the list of other stream features it supports.

2.2 Narrative

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. 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. The initiating entity authenticates itself to the receiving entity.
  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.
  5. The initiating entity issues the enable command (an <enable/> element qualified by the 'http://jabber.org/protocol/ack' namespace) to instruct the receiving entity that it wishes to enable the acknowledgement feature. The element MAY 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 <stream> 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. The receiving entity MUST reply with an <enabled/> element qualified by the 'http://jabber.org/protocol/ack' namespace. 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 previously-identified stream open at this time, the old stream SHOULD be terminated.
  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 'http://jabber.org/protocol/ack' namespace. Both elements will hereby be referred to as simply "ack elements." An ack 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. 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'). As a special exception, an <r/> element that does not contain a 'c' attribute can be used to indicate a hard synchronization point. It is acknowledeged by an ack element that does not contain a 'b' attribute. 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. 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. If the element received has a 'c' attribute, then the response ack MUST contain a value of 'b' that is greater than or equal to the 'c' value given. If the element received has no 'c' attribute, then the response ack MUST NOT have a 'b' attribute. Thus, it is possible for ack elements to contain no attributes, if the entities don't wish to track sequence numbers. 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. 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 resumed within a reasonable time (15 minutes is RECOMMENDED), 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. 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.

Examples of stanza acknowledgements are provided in the next section.

3. Examples

Example 1. Server responds by sending a stream header to client:

<stream:features>
  <ack xmlns='http://jabber.org/protocol/ack'/>
  <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
    <required/>
  </bind>
</stream:features>

Example 2. Client enables stanza acknowledgements:

<enable xmlns='http://jabber.org/protocol/ack'/>

Example 3. Server informs client that the feature is enabled:

<enabled xmlns='http://jabber.org/protocol/ack'/>

Example 4. Client sends a message, requesting an ack from the server:

<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>
<r xmlns:ack='http://jabber.org/protocol/ack'/>

Example 5. Server responds with ack:

<a xmlns='http://jabber.org/protocol/ack'/>

Example 6. Client sends a message, requesting an ack from the server using a sequence number:

<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>
<r xmlns:ack='http://jabber.org/protocol/ack' c='1'/>

Example 7. Server responds with sequence number ack:

<a xmlns='http://jabber.org/protocol/ack' b='1'/>

Example 8. Client sends a message, with attached sequence number:

<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>
<a xmlns:ack='http://jabber.org/protocol/ack' c='7'/>

Example 9. Client enables stanza acknowledgements, attempting to recover a previous session:

<enable xmlns='http://jabber.org/protocol/ack' previd='c2s_345'/>

Example 10. Server informs client that the feature is enabled:

<enabled xmlns='http://jabber.org/protocol/ack' b='7'/>

4. Pinging

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:

Example 11. Pinging the Peer

<ping xmlns='http://jabber.org/protocol/ack'/>

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

Example 12. Replying to a Ping

<pong xmlns='http://jabber.org/protocol/ack'/>

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

5. Implementation Notes

6. IANA Considerations

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

7. Jabber Registrar Considerations

7.1 Stream Features

Upon approval of this XEP, the Jabber Registrar shall add 'http://jabber.org/features/ack' to its registry of stream features.

7.2 Protocol Namespaces

Upon approval of this XEP, the XMPP Registrar [6] shall add 'http://jabber.org/protocol/ack' to its registry of protocol namespaces.

8. XML Schemas

8.1 Stream Feature

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

<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='http://jabber.org/features/ack'
    xmlns='http://jabber.org/features/ack'
    elementFormDefault='qualified'>

  <xs:element name='ack'/>

</xs:schema>

8.2 Protocol Namespace

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

<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='http://jabber.org/protocol/ack'
    xmlns='http://jabber.org/protocol/ack'
    elementFormDefault='qualified'>

  <xs:element name='enable' type='empty'/>
  <xs:element name='enabled' type='empty'/>
  <xs:element name='r' type='empty'/>
  <xs:element name='a' type='empty'/>
  <xs:element name='ping' type='empty'/>
  <xs:element name='pong' type='empty'/>

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

</xs:schema>

Notes

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

2. XEP-0022: Message Events <http://www.xmpp.org/extensions/xep-0022.html>.

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

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

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

6. 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://www.xmpp.org/registrar/>.

Revision History

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)

Initial version. (jk)

END