<abstract>This specification defines an XMPP protocol extension that enables entities to request, and servers to perform, advanced processing of XMPP message stanzas, including reliable data transport, time-sensitive delivery, and expiration of transient messages.</abstract>
<remark>Specified that the timestamp for an expire-at condition must be a UTC DateTime per XEP-0082; provided further explanation regarding expire-at and expire-in conditions.</remark>
<remark>Changes to address Council feedback: clarified error handling and provided error examples; specified that server should validate all rule semantics before returning an error; specified that service discovery information can be cached (not necessary to send disco query before dispatching each message); added "forward" and "gateway" to values of "deliver" condition to handle redirection of messages to alternate XMPP addresses and non-XMPP systems respectively; more clearly specified processing rules for "expire-in" condition; changed milliseconds to seconds for "expire-in"; made explicit that partial JID-matching is not included for "match-resource" condition; added clarifying note to security consideration regarding "deliver" condition; corrected values of per-hop from [yes|no] to [true|false]; changed "standard" conditions to "defined" conditions and mandated that they should be supported; changed "http://jabber.org/protocol/amp#std-actions" namespace to "http://jabber.org/protocol/amp#errors".</remark>
<remark>Incorported changes requested from Standards list discussions: Changed entity-to-server discovery behavior; s2s discovery behavior; Expanded application-specific error conditions; Reorganized for better presentation; Changed "per-hop" to apply to the entire ruleset; Fixed minor typos and missteps</remark>
<remark>Changed disco behavior; Changed schema to reflect customizations</remark>
</revision>
<revision>
<version>0.5.1</version>
<date>2003-09-20</date>
<initials>lw</initials>
<remark>Fixed many typos</remark>
</revision>
<revision>
<version>0.5</version>
<date>2003-08-28</date>
<initials>lw</initials>
<remark>Renamed to "amp" (thanks stpeter!); Added information about the original addressing; Added requirement for id attribute in &MESSAGE;; Restricted behavior within the "Security Considerations";</remark>
</revision>
<revision>
<version>0.4</version>
<date>2003-06-23</date>
<initials>lw</initials>
<remark>Completely rewritten to better account for various suggested usage details and requirements; Completely reorganized to better codify the protocol(s) and their possible uses; Added more conditions; Added more actions; Added common usage scenarios</remark>
</revision>
<revision>
<version>0.3</version>
<date>2003-04-21</date>
<initials>lw</initials>
<remark>Clarified client-side processing; Removed semantics scope; Clarified "fail" action; Moved existing "use-cases" into "Usage" section in "Overview"; Added more relevant use cases; Added XMPP-style error conditions</remark>
</revision>
<revision>
<version>0.2</version>
<date>2003-04-15</date>
<initials>psa</initials>
<remark>Added XML Schema (with author's assistance).</remark>
<p>This document defines a protocol that enables an end-point entity to specify additional delivery semantics for an XMPP <message/> stanza. This protocol is typically used by clients to inform the receiving server how to deliver a particular stanza, such as providing an expiration time or a resource-matching strategy.</p>
<p>The built-in delivery semantics for <message/> stanzas (defined in &xmppcore; and, for instant messaging applications, also in &xmppim;) are adequate for most current applications. However, there are various cases where more stringent delivery semantics are necessary. The most common cases discussed in this document are:</p>
<li>Reliable data transport -- the sender requires notification (positive and/or negative) of message delivery.</li>
<li>Time-sensitive messages -- the message is valid only until a certain date and time.</li>
<li>Transient messages -- the message should not be stored offline for later delivery.</li>
</ul>
</section2>
<section2topic='Concepts'anchor='intro-concepts'>
<p>This protocol is mostly handled by the server or servers processing the <message/>. The protocol consists of a list of rules, with conditions and actions for each rule. Upon receipt of an appropriately marked message, the server interprets the rules in the order they are received, looking for met conditions. When a condition is met, the action for that rule is executed, and message processing stops.</p>
<p>Each rule is flagged for the scope it applies to, whether it be the overall route, or for each hop in the route. Additionally, while this document defines a default set of conditions and actions, the protocol is extensible enough to allow for more to be defined in the future.</p>
<p>In order for this protocol to function properly, the containing &MESSAGE; stanza MUST possess an 'id' attribute, and the value of the 'id' attribute MUST NOT be an empty string. The server MUST include this 'id' attribute value with any response back to the sender; this enables servers and clients to properly relate the initial request with any subsequent alert, error, or notification.</p>
<p>The following use case flow describes the interaction between the sender and a server. As illustrated below, this interaction is actually rather simple:</p>
<p>Sending entities that wish to use AMP SHOULD discover support for this protocol (using &xep0030;) along the intended path. Typically, this would involve sending disco#info queries to the sending entity's own server and the server of the intended recipient. The results of these queries MAY be cached for up to 24 hours, unless otherwise expired.</p>
<p>If a server supports Advanced Message Processing, it MUST report that by including a service discovery feature of "http://jabber.org/protocol/amp" in the service discovery information result that it returns to the requesting entity.</p>
<examplecaption="Initial Service Discovery information request"><
