%ents; ]>
Message Receipts This document specifies an XMPP protocol extension for message receipts. &LEGALNOTICE; 0184 Experimental Standards Track Standards JIG Council XMPP Core XEP-0022 (in part) amp-receipts &stpeter; &hildjj; 0.3 2006-11-06 psa

Removed reliability features, which belong at a different level.

0.2 2006-09-21 psa

Added two more scenarios; defined business rule about not sending to bare JIDs; specified security consideration regarding presence leaks.

0.1 2006-04-11 psa

Initial version.

0.0.2 2006-04-07 psa

Added text and examples for service discovery; added text and examples for chat session negotiation; added recommendations regarding message processing, retries, etc.

0.0.1 2006-03-27 psa

First draft.

While &xep0079; provides message acknowledgements at the server level, it does not extend that model all the way to the client. However, sometimes client-level acknowledgements are needed, for example to provide "receipts". This document defines a mechanism for XMPP message receipts, which are functionally equivalent to the "delivered" or "displayed" event in &xep0022;, which this specification in part obsoletes. This specification does not distinguish between delivery and presentation, as was done in the message events protocol, in part because no existing clients make the distinction.

This document addresses the following requirements:

  1. Enable a sender to request notification that an XMPP message stanza has been received.
  2. Enable a recipient to provide message receipts if desired.

Note: This document explicitly does not define a protocol for "guaranteed delivery", since that term (like "security") means different things to different people. Instead, we define a more focused protocol that addresses the need for message receipts, thus solving one problem that falls under the heading of "guaranteed delivery".

In order to make it possible for senders to request and for recipients to generate message receipts, we define a new Advanced Message Processing rule: "receipt". In accordance with XEP-0079, we provide the following information about the receipt rule:

The following is an example of a message that includes a request for return receipt.

My lord, dispatch; read o'er these articles. ]]>

The recipient MUST generate a receipt if and only if it meets all of the following criteria:

  1. It supports Advanced Message Processing.
  2. It supports the "receipt" rule.
  3. It is configured to return receipts, either globally or for this recipient.
]]>

If the recipient does not meet all of the foregoing criteria, it MUST NOT return a receipt and MUST NOT return an error.

The general business rules specified for Advanced Message Processing in XEP-0079 apply to any rule; in addition, the following business rules apply specifically to the receipt rule:

  1. A sender SHOULD NOT include a request for message receipts when sending a message to the bare JID (&BAREJID;) of the recipient, only when sending to a full JID (&FULLJID;).

  2. A sender SHOULD NOT include a request for message receipts unless it knows (via &xep0030; or &xep0115;) that the intended recipient supports the protocol described herein or unless the use of message receipts is negotiated via &xep0155;.

Naturally, the receipt rule can be combined wiith rules specified in XEP-0079 (e.g., the deliver rule) for more complete reporting.

If a sender wishes to request message receipts, it SHOULD first discover whether the intended recipient supports message receipts. Support can be discovered indirectly via Entity Capabilities or directly via Service Discovery.

If an entity supports Advanced Message Processing, it MUST report that by including a service discovery feature of "http://jabber.org/protocol/amp" as described in XEP-0079:

]]> ... ... ]]>

An entity that supports Advanced Message Processing SHOULD also maintain a service discovery node named "http://jabber.org/protocol/amp", at which it advertises the individual actions and conditions it supports. If an entity supports message receipts, it SHOULD respond to service discovery information requests sent to that node with a reply that includes the 'http://jabber.org/protocol/amp?condition=receipt' condition:

]]> ... ... ]]>

Two entities MAY negotiate the use of message receipts for a given session using Chat Session Negotiation. The parameter to be negotiated is named "http://jabber.org/protocol/amp?condition=receipt". Its use is illustrated in the following examples.

ffd7076498744578d10edabfe7f4a866 http://jabber.org/protocol/chatneg true 0 ]]> ffd7076498744578d10edabfe7f4a866 http://jabber.org/protocol/chatneg true 1 ]]>

Although a sender MAY attempt to resend a message if it knows that the recipient supports message receipts and it does not receive a reply within some configurable timeout period, resend logic is out of scope for this specification.

It is possible for a recipient to leak its presence when returning message receipts; therefore, a recipient SHOULD NOT return message receipts to senders who are not otherwise authorized to view its presence.

No interaction with &IANA; is necessary as a result of this document.

The ®ISTRAR; maintains a registry of Advanced Message Processing <rule/> conditions (see &CONDITIONS;). The Registrar shall add the following condition to the registry:

receipt http://jabber.org/protocol/amp?condition=receipt false received The condition is met if a message processing application (client) controlled by the intended recipient has received and processed the message, including presentation to a human user if appropriate. XEP-xxxx ]]>

&xep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace and the XMPP Registrar maintains a registry of such fields (see &FORMTYPES;). The Registrar shall add the following field for use in Chat Session Negotiation forms:

http://jabber.org/protocol/chatneg ]]>

Thanks to Joe Kemp and Kevin Smith for their input.