<remark><p>Added two more scenarios; defined business rule about not sending to bare JIDs; specified security consideration regarding presence leaks.</p></remark>
<remark><p>Added text and examples for service discovery; added text and examples for chat session negotiation; added recommendations regarding message processing, retries, etc.</p></remark>
<p>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. <note>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.</note>
<p>This document addresses the following requirements:</p>
<ol>
<li>Enable a sender to request notification that an XMPP message stanza has been received.</li>
<li>Enable a recipient to provide message receipts if desired.</li>
</ol>
<p>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".</p>
<p>In order to make it possible for senders to request and for recipients to generate message receipts, we define a new <cite>Advanced Message Processing</cite> rule: "receipt". In accordance with <cite>XEP-0079</cite>, we provide the following information about the receipt rule:</p>
<li>This condition is met if a message processing application (client) controlled by the intended recipient has received and processed the message; the term "processed" is understood to include presentation to a human user if appropriate or any other application-specific client-side processing, including generation of an error response if the application determines that the message contents cannot be handled.</li>
<p>The general business rules specified for Advanced Message Processing in <cite>XEP-0079</cite> apply to any rule; in addition, the following business rules apply specifically to the receipt rule:</p>
<li><p>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;).</p></li>
<li><p>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;.</p></li>
<p>Naturally, the receipt rule can be combined wiith rules specified in <cite>XEP-0079</cite> (e.g., the deliver rule) for more complete reporting.</p>
<p>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 <cite>Entity Capabilities</cite> or directly via <cite>Service Discovery</cite>.</p>
<p>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 <cite>XEP-0079</cite>:</p>
<p>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:</p>
<examplecaption="Request for information about individual actions and conditions"><