XEP-0079: Advanced Message Processing

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.
Authors:Matthew Miller, Peter Saint-Andre
Copyright:© 1999 - 2010 XMPP Standards Foundation. SEE LEGAL NOTICES.
Status:Draft
Type:Standards Track
Version:1.2
Last Updated:2005-11-30

NOTICE: The protocol defined herein is a Draft Standard of the XMPP Standards Foundation. Implementations are encouraged and the protocol is appropriate for deployment in production systems, but some changes to the protocol are possible before it becomes a Final Standard.

Table of Contents


1. Introduction
    1.1. Motivation
    1.2. Concepts
    1.3. Prerequisites
2. Process Flows
    2.1. Sender-to-Server
       2.1.1. Discovery
       2.1.2. Specifying Semantics
    2.2. Server Processing
       2.2.1. Validating Semantics
       2.2.2. Determine Default Action
       2.2.3. Process Rules
       2.2.4. Execute Determined Action
       2.2.5. Return Event
3. Conditions and Actions
    3.1. Rule Condition Guidelines
    3.2. Rule Action Guidelines
    3.3. Defined Conditions
       3.3.1. deliver
       3.3.2. expire-at
       3.3.3. match-resource
    3.4. Defined Actions
       3.4.1. alert
       3.4.2. drop
       3.4.3. error
       3.4.4. notify
    3.5. Description of Condition/Action Combinations
       3.5.1. Deliver Rules
       3.5.2. Expire-at Rules
       3.5.3. Match-resource Rules
4. Formal Description
    4.1. <amp/> Root Element
    4.2. <rule/> Element
5. Example Scenarios
    5.1. Reliable Data Transport
    5.2. Time-Sensitive Messages
    5.3. Transient Messages
6. Error Handling
    6.1. Conditions
    6.2. Examples
       6.2.1. Unsupported Action
       6.2.2. Unsupported Condition
       6.2.3. Not Acceptable
       6.2.4. Service Unavailable
       6.2.5. Undefined Condition
7. Implementation Notes
8. Stream Feature
9. Security Considerations
10. IANA Considerations
11. XMPP Registrar Considerations
    11.1. Protocol Namespaces
    11.2. Stream Features
    11.3. Well-Known Service Discovery Nodes
    11.4. Registries
       11.4.1. Rule Conditions Registry
         11.4.1.1. Process
         11.4.1.2. Initial Submission
       11.4.2. Rule Actions Registry
         11.4.2.1. Process
         11.4.2.2. Initial Submission
12. XML Schemas
    12.1. AMP
    12.2. Errors
    12.3. Stream Feature
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

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.

1.1 Motivation

The built-in delivery semantics for <message/> stanzas (defined in XMPP Core [1] and, for instant messaging applications, also in XMPP IM [2]) 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:

1.2 Concepts

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.

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.

The namespace for the protocol is "http://jabber.org/protocol/amp".

1.3 Prerequisites

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.

2. Process Flows

2.1 Sender-to-Server

The following use case flow describes the interaction between the sender and a server. As illustrated below, this interaction is actually rather simple:

  1. Sender determines support (E1)
  2. Sender specifies appropriate rules and sends message to server (E1,E2)
  3. Sender awaits any protocol-specific responses (UCE)

2.1.1 Discovery

Sending entities that wish to use AMP SHOULD discover support for this protocol (using Service Discovery [3]) 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.

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.

Example 1. Initial Service Discovery information request

<iq from='northumberland@shakespeare.lit/westminster'
    to='shakespeare.lit'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

Example 2. Service Discovery information response

<iq from='shakespeare.lit'
    to='northumberland@shakespeare.lit/westminster'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <identity name='Shakespeare IM' category='im' type='server'/>
    ...
    <feature var='http://jabber.org/protocol/amp'/>
    ...
  </query>
</iq>

A server 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 needs to determine whether the server supports individual actions and conditions, it SHOULD send a service discovery information request to that node; the server then MUST either return the list of supported actions and conditions or return an error such as <feature-not-implemented/>. (Note: If the server does not provide information for this disco node, the requesting entity MUST assume that all actions and conditons are supported for each reported action set or condition set.)

Each supported action shall be reported as a feature using the following format:

http://jabber.org/protocol/amp?action={action}

Each supported condition shall be reported as a feature using the following format:

http://jabber.org/protocol/amp?condition={condition}

The following examples show the request-response flow for information about individual actions and conditions (note the inclusion of the 'node' attribute).

Example 3. Request for information about individual actions and conditions

<iq from='northumberland@shakespeare.lit/westminster'
    to='shakespeare.lit'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#info'
         node='http://jabber.org/protocol/amp'/>
</iq>

Example 4. Response for individual actions and conditions

<iq from='shakespeare.lit'
    to='northumberland@shakespeare.lit/westminster'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'
         node='http://jabber.org/protocol/amp'>
    <identity name='Shakespeare IM AMP Support' category='im' type='server'/>
    ...
    <feature var='http://jabber.org/protocol/amp'/>
    <feature var='http://jabber.org/protocol/amp?action=drop'/>
    <feature var='http://jabber.org/protocol/amp?action=error'/>
    <feature var='http://jabber.org/protocol/amp?action=notify'/>
    <feature var='http://jabber.org/protocol/amp?condition=deliver'/>
    <feature var='http://jabber.org/protocol/amp?condition=expire-at'/>
    <feature var='http://jabber.org/protocol/amp?condition=match-resource'/>
    ...
  </query>
</iq>

2.1.2 Specifying Semantics

Once support is determined, the sender can attach the desired delivery semantics to the message:

Example 5. A message with AMP semantics

<message
    from='northumberland@shakespeare.lit'
    id='richard2-4.1.247'
    to='kingrichard@royalty.england.lit'>
  <body>My lord, dispatch; read o'er these articles.</body>
  <amp xmlns='http://jabber.org/protocol/amp'>
    <rule condition='expire-at'
          action='drop'
          value='2004-01-01T00:00:00Z'/>
  </amp>
</message>

The semantics are defined as a set of <rule/> elements within the <amp/> root element. Each <rule/> declares the condition to trigger on and the action to execute if triggered.

By default, the ruleset applies only to the "edge servers": those servers to which the sending and receiving entities are connected. (Note: For the purposes of Advanced Message Processing, "server" is defined as in XMPP Core and does not include any internal components, such as connection managers, that may provide functionality within a server implementation or installation.)

The ruleset MAY be applied to all server-to-server "hops" along the route from the sending and receiving entities by adding the "per-hop' attribute to the <amp/> element. The value of this attribute is either "true" (apply rules to all hops) or "false" (follow default behavior, i.e., apply rules at the edge servers only).

Example 6. Another message with AMP semantics

<message
    from='northumberland@shakespeare.lit'
    id='richard2-4.1.247'
    to='kingrichard@royalty.england.lit'>
  <body>My lord, dispatch; read o'er these articles.</body>
  <amp xmlns='http://jabber.org/protocol/amp'
       per-hop='true'>
    <rule condition='expire-at'
          action='drop'
          value='2004-01-01T00:00:00Z'/>
  </amp>
</message>

For examples of validation failure, refer to the Error Handling section of this document.

Note: Even if "per-hop" processing is requested, each server in the route MUST ignore rules that cannot apply to it; the Defined Conditions outline if they can be applied per-hop.

2.2 Server Processing

Server operation is where the bulk of the work is performed. Upon receiving a message with an AMP extension, the server performs the following flow:

  1. Validate the semantics (E1, E2).
  2. Determine the default behavior.
  3. Process rules until condition is met.
    • If a condition is met, execute that rule's action
    • If no conditions are met, perform "default" behavior for message
  4. Execute determined action (UCE) (E3).

2.2.1 Validating Semantics

Validation can take many forms, but at the very least the server MUST verify that it understands each of the rule conditions and actions, and that the condition contents are appropriate. The server MAY also refuse to accept certain combinations of conditions and actions, for example if they present a risk of violating security policies. If the semantics are not valid, supported, or acceptable, the server MUST reply with an error specifying the rule(s) that are at issue. The server SHOULD validate all the semantics before returning an error. For syntax and examples of error handling related to validation failure, refer to the Error Handling section of this document.

2.2.2 Determine Default Action

This step is essentially what a server normally does, except that it does not actually perform the action. This determines what would happen to the message if there were no semantics attached (such as dispatch to another server or store offline). At this point, the server SHOULD also calculate any timing or calendar requirements (if applicable).

2.2.3 Process Rules

At this step, the server processes the attached semantics. The server MUST process the rules serially, and in the order they are presented within the <amp/> element. As soon as a rule's condition is met, processing ends with that action overriding the default action determined earlier (unless the action permits continued processing).

2.2.4 Execute Determined Action

Once all rules have been processed or otherwise accounted for, the server executes the action determined at this point.

A server SHOULD NOT dispatch a <message/> stanza with AMP semantics to another server unless it knows that the next server supports AMP (this SHOULD be discovered via Service Discovery and MAY be cached to avoid delivery delays). If the next server does not support AMP, the current server replies to the original sender with a <service-unavailable/> error condition. Otherwise this flow starts again for the server to which the message has been dispatched.

2.2.5 Return Event

If the determined action involves returning an event (alert, error, or notification) to the sender, a server MUST send a <message/> stanza to the sender containing the rule that was met. This <message/> stanza MUST include the original value of the 'id' attribute and SHOULD NOT contain the non-AMP contents (e.g., <body/> child) originally included by the sender.

3. Conditions and Actions

The preceding sections of this document define the general behavior regarding AMP. This section outlines how <rule/> action and condition sets are specified. It also provides defined action and condition sets; these action and condition sets SHOULD be supported by any implementation of Advanced Message Processing, but support for any given action or condition set it not required. (Note: The action and condition sets defined herein may be supplemented in the future via registration of additional action and condition sets with the XMPP Registrar.)

3.1 Rule Condition Guidelines

The definition of a <rule/> condition MUST provide the following information:

3.2 Rule Action Guidelines

The definition of a <rule/> action MUST provide the following information:

3.3 Defined Conditions

The condition defines how or when a particular rule is triggered. The value of the condition attribute determines what the contents of the <rule/> mean.

The following conditions are defined by this document and SHOULD be supported by any implementation.

In the following sections, the terms "content" and "contents" refers to the XML character data contained by the <rule/> element.

3.3.1 deliver

The "deliver" condition is used to ensure delivery (or non-delivery) in one of five ways:

  1. Directly to the specified address or account over XMPP
  2. Delayed to offline storage (for later delivery via XMPP)
  3. Forwarded to an alternate address or account over XMPP
  4. Indirectly to an alternate address or account through a gateway to a non-XMPP system

This condition is met based on what the processor would do with the message at the moment of receipt, as follows:

Table 1: "deliver" values

Value Description
direct The message would be immediately delivered to the intended recipient or routed to the next hop.
forward The message would be forwarded to another XMPP address or account.
gateway The message would be sent through a gateway to an address or account on a non-XMPP system.
none The message would not be delivered at all (e.g., because the intended recipient is offline and message storage is not enabled).
stored The message would be stored offline for later delivery to the intended recipient.

This condition MAY be applied to each "hop" in the server route.

3.3.2 expire-at

The "expire-at" condition is used to ensure delivery before an absolute point in time. Naturally, this does not guarantee [4] that the message will not be delivered after that time from the sender's perspective, since this document does not assume that all machine clocks (e.g., for all servers along the delivery route) are synchronized. However, in order to help ensure that this condition is met correctly, servers that implement this document (or the machines that host such servers) SHOULD use the Network Time Protocol (RFC 1305 [5]) to keep in sync with established time authorities. Note also that expire-at functionality becomes less reliable the closer the expire-at time is to the present (e.g., the sender will receive less reliable delivery of a message speciifying an expire-at time two seconds in the future than of a message specifying an expire-at time two hours or two days in the future).

The content of the 'value' attribute specifies some point after the exact moment the message is sent; the content MUST be a DateTime as specified in XMPP Date and Time Profiles [6], and the timezone MUST be UTC.

The condition is met if the message would be delivered to the recipient after the specified datetime. To determine the datetime to compare to, the processor first determines if and when a message can be dispatched (e.g. not stored offline). The processor then records this datetime, and compares it with the specified datetime. If the current datetime is on or after that specified, the condition is met.

This condition MAY be applied to each "hop" in the server route.

3.3.3 match-resource

The "match-resource" condition is used to restrict delivery based on the resource identifier of the recipient JID.

The defined values for this condition are:

Table 2: "match-resource" values

Value Description Example
any Destination resource matches any value, effectively ignoring the intended resource. "home/laptop" matches "home", "home/desktop" or "work/desktop"
exact Destination resource exactly matches the intended resource. "home/laptop" only matches "home/laptop" and not "home/desktop" or "work/desktop"
other Destination resource matches any value except for the intended resource. "home/laptop" matches "work/desktop", "home" or "home/desktop", but not "home/laptop"

The condition is met if the resource for the actual destination JID matches the intended JID using the above rules. For instance, if a message is intended for "romeo@montague.net/work" with the "match-resource" condition of "exact", the condition is met if the message can be immediately delivered only to "romeo@montague.net/work".

For purposes of this condition, an intended JID with no resource has the following behavior:

This condition MUST NOT be applied to each "hop" in the server route, only at the edge servers. If an <amp/> element includes this condition and also indicates that it should be processed per hop, this <rule/> shall be ignored.

Note: By design, this protocol does not include support for partial resource matching (which would stipulate, for example, that the resource identifiers "home/laptop" and "homeboy" both match "home").

3.4 Defined Actions

The action defines what occurs when a particular rule is triggered. The value of the action attribute determines the behavior if the rule's condition is met.

The following actions are defined by this document.

3.4.1 alert

The "alert" action triggers a reply <message/> stanza to the sending entity. This <message/> stanza MUST contain the element <amp status='alert'/>, which itself contains the <rule/> that triggered this action. In all other respects, this action behaves as "drop".

Example 7. Alert Response

  <message from='hamlet.lit'
           to='bernardo@hamlet.lit/elsinore'
           id='chatty2'>
    <amp xmlns='http://jabber.org/protocol/amp'
         status='alert'
         from='bernardo@hamlet.lit/elsinore'
         to='francisco@hamlet.lit'>
      <rule action='alert' condition='deliver' value='stored'/>
    </amp>
  </message>

3.4.2 drop

The "drop" action silently discards the message from any further delivery attempts and ensures that it is not placed into offline storage. The drop MUST NOT result in other responses.

3.4.3 error

The "error" action triggers a reply <message/> stanza of type "error" to the sending entity. The <message/> stanza's <error/> child MUST contain a <failed-rules xmlns='http://jabber.org/protocol/amp#errors'/> error condition, which itself contains the rules that triggered this action.

Example 8. Error Response

  <message from='hamlet.lit'
           to='bernardo@hamlet.lit/elsinore'
           type='error'
           id='chatty2'>
    <amp xmlns='http://jabber.org/protocol/amp'
         status='error'
         to='bernardo@hamlet.lit/elsinore'
         from='francisco@hamlet.lit'>
      <rule action='error' condition='deliver' value='stored'/>
    </amp>
    <error type='modify' code='500'>
      <undefined-condition xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
      <failed-rules xmlns='http://jabber.org/protocol/amp#errors'>
        <rule action='error' condition='deliver' value='stored'/>
      </failed-rules>
    </error>
  </message>

Note that the error SHOULD be of type "modify", and the general error condition SHOULD be <undefined-condition xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>.

3.4.4 notify

The "notify" action triggers a reply <message/> stanza to the sending entity. This <message/> stanza MUST contain the element <amp status='notify'/>, which itself contains the <rule/> that triggered this action. Unlike the other actions, this action does not override the default behavior for a server. Instead, the server then executes its default behavior after sending the notify.

Example 9. Notify Response

  <message from='hamlet.lit'
           to='bernardo@hamlet.lit/elsinore'
           id='chatty2'>
    <amp xmlns='http://jabber.org/protocol/amp'
         status='notify'
         to='bernardo@hamlet.lit/elsinore'
         from='francisco@hamlet.lit'>
      <rule action='notify' condition='deliver' value='stored'/>
    </amp>
  </message>

3.5 Description of Condition/Action Combinations

In general, a rule can be read as "do {action} if {condition} is true for {value}"; however, to facilitate understanding, this section describes the various condition/action combinations in plain English.

3.5.1 Deliver Rules

When the condition is "deliver", the rules can be described as follows:

Table 3: Deliver Rules

Action Value Description
alert direct Return an alert if the message would be delivered directly.
alert forward Return an alert if the message would be forwarded to another XMPP address.
alert gateway Return an alert if the message would be delivered to a non-XMPP address through a gateway.
alert none Return an alert if no delivery is possible.
alert stored Return an alert if the message would be stored offline for later delivery via XMPP.
drop direct Drop the message if it would be delivered directly.
drop forward Drop the message if it would be forwarded to another XMPP address.
drop gateway Drop the message if it would be delivered to a non-XMPP address through a gateway.
drop none Drop the message if no delivery is possible.
drop stored Drop the message if it would be stored offline for later delivery via XMPP.
error direct Return an error if the message would be delivered directly.
error forward Return an error if the message would be forwarded to another XMPP address.
error gateway Return an error if the message would be delivered to a non-XMPP address through a gateway.
error none Return an error if no delivery is possible.
error stored Return an error if the message would be stored offline for later delivery via XMPP.
notify direct Return a notification if the message would be delivered directly.
notify forward Return a notification if the message would be forwarded to another XMPP address.
notify gateway Return a notification if the message would be delivered to a non-XMPP address through a gateway.
notify none Return a notification if no delivery is possible.
notify stored Return a notification if the message would be stored offline for later delivery via XMPP.

3.5.2 Expire-at Rules

When the condition is "expire-at", the rules can be described as follows:

Table 4: Expiration Rules

Action Description
alert Return an alert if the message would be delivered after the specified timestamp.
drop Drop the message if it would be delivered after the specified timestamp.
error Return an error if the message would be delivered after the specified timestamp.
notify Return a notification if the message would be delivered after the specified timestamp.

3.5.3 Match-resource Rules

When the condition is "match-resource", the rules can be described as follows:

Table 5: Resource Matching Rules

Action Value Description
alert any Return an alert if the message would be delivered to any resource.
alert exact Return an alert if the message would be delivered to the exact resource.
alert other Return an alert if the message would be delivered to a resource other than that specified.
drop any Drop the message if it would be delivered to any resource.
drop exact Drop the message if it would be delivered to the exact resource.
drop other Drop the message if it would be delivered to a resource other than that specified.
error any Return an error if the message would be delivered to any resource.
error exact Return an error if the message would be delivered to the exact resource.
error other Return an error if the message would be delivered to a resource other than that specified.
notify any Return a notification if the message would be delivered to any resource.
notify exact Return a notification if the message would be delivered to the exact resource.
notify other Return a notification if the message would be delivered to a resource other than that specified.

4. Formal Description

4.1 <amp/> Root Element

All delivery semantics are encapsulated in the <amp/> element. This element contains one or more <rule/> elements specifying the specific rules to process. It can optionally possess attributes about the current status, the original sender and recipient, and route applicability.

The 'status' attribute specifies the reason for this <amp/> element. When specifying semantics to be applied (client to server), this attribute MUST NOT be present. When replying to a sending entity regarding a met condition, this attribute MUST be present and SHOULD be the value of the 'action' attribute for the triggered rule. (Note: Individual action definitions MAY provide their own requirements.)

The 'from' attribute specifies the original sender of the containing <message/> stanza. This attribute MUST be specified for any <message/> stanza sent from a supporting server, regardless of the recipient. It SHOULD NOT be specified otherwise. The value of the 'from' attribute MUST be the full JID (node@domain/resource) of the sender for the original <message/> stanza.

The 'to' attribute specifies the original (intended) recipient of the containing <message/> stanza. This attribute MUST be specified for any <message/> stanza sent from a supporting server, regardless of the recipient. It SHOULD NOT be specified otherwise. The value of the 'to' attribute MUST be the full JID (node@domain/resource) of the intended recipient for the original <message/> stanza.

The 'per-hop' attribute flags the contained ruleset for processing at each server in the route between the original sender and original intended recipient. This attribute MAY be present, and MUST be either "true" or "false". If not present, the default is "false".

4.2 <rule/> Element

Each semantic rule is specified with a <rule/> element. This element possesses attributes for the condition, value, and action.

The 'action' attribute defines the result for this rule. This attribute MUST be present, and MUST be either a value defined in the Defined Actions section, or one registered with the XMPP Registrar.

The 'condition' attribute defines the overall condition this rule applies to. This attribute MUST be present, and MUST be either a value defined in the Defined Conditions section, or one registered with the XMPP Registrar.

The 'value' attribute defines how the condition is matched. This attribute MUST be present, and MUST NOT be an empty string (""). The interpretation of this attribute's value is determined by the 'condition' attribute.

5. Example Scenarios

5.1 Reliable Data Transport

The <message/> stanza is nearly ideal for data transport, but to ensure reliability it is often desirable that such messages not be delivered to any resource but that specified. To facilitate this, the sending entity includes a <rule action='drop' condition='match-resource' value='other'/> (if failure notification is unnecessary) or <rule action='error' condition='match-resource' value='other'/> (if failure notification is required). The following example illustrates this using In-Band Bytestreams [8]:

Example 10. Sending a message for reliable data transport

<message to='francisco@hamlet.lit/pda'
         from='bernardo@hamlet.lit/elsinore'
         id='ibb1'>
  <data xmlns='http://jabber.org/protocol/ibb' sid='mySID' seq='0'>
    qANQR1DBwU4DX7jmYZnncmUQB/9KuKBddzQH+tZ1ZywKK0yHKnq57kWq+RFtQdCJ
    WpdWpR0uQsuJe7+vh3NWn59/gTc5MDlX8dS9p0ovStmNcyLhxVgmqS8ZKhsblVeu
    IpQ0JgavABqibJolc3BKrVtVV1igKiX/N7Pi8RtY1K18toaMDhdEfhBRzO/XB0+P
    AQhYlRjNacGcslkhXqNjK5Va4tuOAPy2n1Q8UUrHbUd0g+xJ9Bm0G0LZXyvCWyKH
    kuNEHFQiLuCY6Iv0myq6iX6tjuHehZlFSh80b5BVV9tNLwNR5Eqz1klxMhoghJOA
  </data>
  <amp xmlns='http://jabber.org/protocol/amp' per-hop='true'>
    <rule action='error' condition='expire-at' value='2004-09-10T08:33:14Z'/>
    <rule action='error' condition='match-resource' value='other'/>
  </amp>
</message>

In the above case, the sender would receive an error reply if the message could not be delivered specifically to "francisco@hamlet.lit/pda" by the specified time. For example, if the intended resource went offline before the message could be delivered, the processing server would return the following error:

Example 11. Failed reliable data transport message

<message from='hamlet.lit'
         to='bernardo@hamlet.lit/elsinore'
         id='ibb1'>
  <amp xmlns='http://jabber.org/protocol/amp'
      from='bernardo@hamlet.lit/elsinore'
      to='francisco@hamlet.lit/pda'>
    <rule action='error' condition='match-resource' value='other'/>
  </amp>
  <error type='modify' code='500'>
    <undefined-condition xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
    <failed-rules xmlns='http://jabber.org/protocol/amp#errors'>
      <rule action='error' condition='match-resource' value='other'/>
    </failed-rules>
  </error>
</message>

5.2 Time-Sensitive Messages

Time-sensitive messages are a frequent occurrence in some environments (e.g., front-office personnel routinely notify others of "events" such as guests, unexpected refreshments, and ad-hoc gatherings). To send a time-sensitive message, the sending entity includes a <rule action='drop' condition='expire-at'/> with the time when the event is to occur:

Example 12. Sending a time-sensitive message

<message to='linuxwolf@outer-planes.net'
         from='receptionist@outer-planes.net'
         id='alert849'>
  <subject>Guest Alert!</subject>
  <body>
    There will be clients in the conference room today around 1 PM!
    As always, be courteous and quiet nearby...
  </body>
  <amp xmlns='http://jabber.org/protocol/amp'>
    <rule action='drop' condition='expire-at' value='2003-06-23T23:00:00Z'/>
  </amp>
</message>

In the above case, the server for "linuxwolf@outer-planes.net" would not deliver the message once 23:00 UTC (3:00 PM Pacific Daylight Time) has passed.

5.3 Transient Messages

Transient messages are messages that should never be stored offline. To send a transient message, the sending entity includes a <rule action='drop' condition='deliver' value='stored'/>:

Example 13. Sending a transient message

<message to='francisco@hamlet.lit'
         from='bernardo@hamlet.lit/elsinore'
         type='chat'
         id='chatty1'>
  <body>Who&apos;s there?</body>
  <amp xmlns='http://jabber.org/protocol/amp'>
    <rule action='drop' condition='deliver' value='stored'/>
  </amp>
</message>

Alternatively, the sending entity includes a <rule action='alert' condition='deliver' value='stored'/> to be alerted instead of having the message silently dropped:

Example 14. Sending a transient message (requesting alert)

<message to='francisco@hamlet.lit'
         from='bernardo@hamlet.lit/elsinore'
         type='chat'
         id='chatty2'>
  <body>Who&apos;s there?</body>
  <amp xmlns='http://jabber.org/protocol/amp'>
    <rule action='alert' condition='deliver' value='stored'/>
  </amp>
</message>

Example 15. Sender alerted regarding transient message

<message from='hamlet.lit'
         to='bernardo@hamlet.lit/elsinore'
         id='chatty2'>
  <amp xmlns='http://jabber.org/protocol/amp'
       action='alert'
       from='bernardo@hamlet.lit/elsinore'
       to='francisco@hamlet.lit'>
    <rule action='alert' condition='deliver' value='stored'/>
  </amp>
</message>

6. Error Handling

6.1 Conditions

To simplify the discussion of error conditions, this document uses the following mappings between namespace URIs and namespace prefixes (note: this mapping is provided only for the purpose of simplifying the discussion and is not intended for use within the protocol itself).

Table 6: Namespace Mappings

Prefix URI
xmpp urn:ietf:params:xml:ns:xmpp-stanzas
msg http://jabber.org/protocol/amp
err http://jabber.org/protocol/amp#errors

The following table shows the possible error conditions in relation to general AMP rules and conditions as well as the Defined Actions.

Table 7: Error conditions

General Condition Error Type Specific Condition Description
<xmpp:bad-request/> modify <msg:unsupported-actions/> One or more rule's specified actions are not supported. The element <msg:unsupported-actions/> contains the <rule/> elements that specify the unsupported actions.
<xmpp:bad-request/> modify <msg:unsupported-conditions/> One or more rule's specified conditions are not supported. The element <msg:unsupported-conditions/> contains the <rule/> elements that specify the unsupported conditions.
<xmpp:not-acceptable/> modify <msg:invalid-rules/> One or more rules are not acceptable by this server, usually because the condition/action combination is restricted. The element <msg:invalid-rules/> contains the <rule/> elements that are not acceptable.
<xmpp:service-unavailable/> cancel NONE This protocol is not supported. This error is returned to the sending entity if a server along the route to the recipient does not implement this protocol.
<xmpp:undefined-condition/> modify <err:failed-rules/> One or more <rule/> elements triggered the "error" action. This condition contains the triggered <rule/> elements.

6.2 Examples

This section shows examples of the error conditions described in the previous section (for information regarding mapping of XMPP error conditions to Jabber error codes, refer to Error Condition Mappings [9]).

6.2.1 Unsupported Action

Example 16. A message with AMP semantics

<message
    from='northumberland@shakespeare.lit'
    id='richard2-4.1.247'
    to='kingrichard@royalty.england.lit'>
  <body>My lord, dispatch; read o'er these articles.</body>
  <amp xmlns='http://jabber.org/protocol/amp'>
    <rule action='drop' condition='expire-at' value='2004-01-01T00:00:00Z'/>
  </amp>
</message>

Example 17. Server does not support action

<message
    from='shakespeare.lit'
    id='richard2-4.1.247'
    to='northumberland@shakespeare.lit'
    type='error'>
  <amp xmlns='http://jabber.org/protocol/amp'>
    <rule action='drop' condition='expire-at' value='2004-01-01T00:00:00Z'/>
  </amp>
  <error type='modify' code='400'>
    <bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
    <unsupported-actions xmlns='http://jabber.org/protocol/amp'>
      <rule condition='expire-at'
            action='drop'
            value='2004-01-01T00:00:00Z'/>
    </unsupported-actions>
  </error>
</message>

6.2.2 Unsupported Condition

Example 18. A message with AMP semantics

<message
    from='shakespeare.lit'
    id='richard2-4.1.247'
    to='kingrichard@royalty.england.lit'>
  <body>My lord, dispatch; read o'er these articles.</body>
  <amp xmlns='http://jabber.org/protocol/amp'>
    <rule action='drop' condition='expire-at' value='2004-01-01T00:00:00Z'/>
  </amp>
</message>

Example 19. Server does not support condition

<message
    from='shakespeare.lit'
    id='richard2-4.1.247'
    to='northumberland@shakespeare.lit'
    type='error'>
  <amp xmlns='http://jabber.org/protocol/amp'>
    <rule action='drop' condition='expire-at' value='2004-01-01T00:00:00Z'/>
  </amp>
  <error type='modify' code='400'>
    <bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
    <unsupported-conditions xmlns='http://jabber.org/protocol/amp'>
      <rule action='drop' condition='expire-at' value='2004-01-01T00:00:00Z'/>
    </unsupported-conditions>
  </error>
</message>

6.2.3 Not Acceptable

Example 20. A message with AMP semantics

<message
    from='northumberland@shakespeare.lit'
    id='richard2-4.1.247'
    to='kingrichard@royalty.england.lit'>
  <body>My lord, dispatch; read o'er these articles.</body>
  <amp xmlns='http://jabber.org/protocol/amp'>
    <rule action='drop' condition='expire-at' value='2004-01-01T00:00:00Z'/>
  </amp>
</message>

Example 21. The rule is not acceptable to the server

<message
    from='shakespeare.lit'
    id='richard2-4.1.247'
    to='northumberland@shakespeare.lit'
    type='error'>
  <amp xmlns='http://jabber.org/protocol/amp'>
    <rule action='drop' condition='expire-at' value='2004-01-01T00:00:00Z'/>
  </amp>
  <error type='modify' code='405'>
    <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
    <invalid-rules xmlns='http://jabber.org/protocol/amp'>
      <rule action='drop' condition='expire-at' value='2004-01-01T00:00:00Z'/>
    </invalid-rules>
  </error>
</message>

6.2.4 Service Unavailable

Example 22. A message with AMP semantics

<message
    from='northumberland@shakespeare.lit'
    id='richard2-4.1.247'
    to='kingrichard@royalty.england.lit'>
  <body>My lord, dispatch; read o'er these articles.</body>
  <amp xmlns='http://jabber.org/protocol/amp'>
    <rule action='drop' condition='expire-at' value='2004-01-01T00:00:00Z'/>
  </amp>
</message>

Example 23. AMP service is unavailable

<message
    from='royalty.england.lit'
    id='richard2-4.1.247'
    to='northumberland@shakespeare.lit'
    type='error'>
  <amp xmlns='http://jabber.org/protocol/amp'>
    <rule action='drop' condition='expire-at' value='2004-01-01T00:00:00Z'/>
  </amp>
  <error type='cancel' code='503'>
    <service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</message>

6.2.5 Undefined Condition

Example 24. A message with AMP semantics

  <message from='hamlet.lit'
           to='bernardo@hamlet.lit/elsinore'
           id='chatty2'>
    <body>Who&apos;s there?</body>
    <amp xmlns='http://jabber.org/protocol/amp'
         status='error'
         from='francisco@hamlet.lit'
         to='bernardo@hamlet.lit/elsinore'>
      <rule action='error' condition='deliver' value='stored'/>
    </amp>
  </message>

Example 25. Failed rules

  <message from='hamlet.lit'
           to='bernardo@hamlet.lit/elsinore'
           type='error'
           id='chatty2'>
    <amp xmlns='http://jabber.org/protocol/amp'
         status='error'
         from='francisco@hamlet.lit'
         to='bernardo@hamlet.lit/elsinore'>
      <rule action='error' condition='deliver' value='stored'/>
    </amp>
    <error type='modify' code='500'>
      <undefined-condition xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
      <failed-rules xmlns='http://jabber.org/protocol/amp#errors'>
        <rule action='error' condition='deliver' value='stored'/>
      </failed-rules>
    </error>
  </message>

7. Implementation Notes

If the recipient's server implements "offline storage", it will need to keep track of which offline messages are subject to expiration and not deliver those which have expired. Exactly how to do so is a matter of implementation. One possible implementation is for the server to maintain a separate database of expirable messages and periodically scan it; upon discovering an expired message, it could flag the message as eligible for discarding and inform the sender, but not discard the message until the intended recipient next becomes available.

8. Stream Feature

XMPP Core [10] defines methods for advertising feature support during stream negotiation. For the sake of efficiency, it may be desirable for a server to advertise support for Advanced Message Processing as a stream feature. The namespace for reporting support within <stream:features/> is "http://jabber.org/features/amp". Upon receiving a stream header from the initiating entity, the receiving entity (usually a server) returns a stream header to initiating entity and MAY announce support for Advanced Message Processing registration by including the relevant stream feature:

Example 26. Advertising Advanced Message Processing as a stream feature

  <stream:features>
    <amp xmlns='http://jabber.org/features/amp'/>
  </stream:features>

9. Security Considerations

Most AMP conditions could be used by unauthorized individuals to gain access to presence information about users of IM servers and other presence-based messaging systems. For example, consider the following scenario: the user <romeo@montague.net> is not an authorized subscriber to the presence of the user <nurse@capulet.com>, but sends a <message/> stanza with a "deliver" rule of "stored" and an action of "alert" to that address; if the Nurse is not online, Romeo would receive an AMP alert that the message has been stored offline, in the process discovering that the Nurse is offline. Similar scenarios are possible with the "match-resource" rule (send to the user's usual resource) and the "expire-at" rule (send messages every minute to poll for presence). If a server implements presence subscriptions as specified in RFC 3921 [11], it SHOULD NOT return alerts, errors, or other AMP notifications to senders who are not authorized to view the recipient's presence information (via a subscription of "both" or "from") if the notification would reveal the recipient's status as online or offline. [12] ).

There are several directions server implementors can follow in this regard:

10. IANA Considerations

No interaction with the Internet Assigned Numbers Authority (IANA) [13] is necessary as a result of this document.

11. XMPP Registrar Considerations

11.1 Protocol Namespaces

The XMPP Registrar [14] includes 'http://jabber.org/protocol/amp' and 'http://jabber.org/protocol/amp#errors' in its registry of protocol namespaces.

11.2 Stream Features

The XMPP Registrar includes the 'http://jabber.org/features/amp' namespace in its registry of stream feature namespaces.

11.3 Well-Known Service Discovery Nodes

The XMPP Registrar includes 'http://jabber.org/protocol/amp' in its registry of well-known Service Discovery nodes.

11.4 Registries

11.4.1 Rule Conditions Registry

The XMPP Registrar maintains a registry of AMP <rule/> conditions at <http://xmpp.org/registrar/amp-conditions.html>.

11.4.1.1 Process

In order to submit new values to this registry, the registrant shall define an XML fragment of the following form and either include it in the relevant XMPP Extension Protocol or send it to the email address <registrar@xmpp.org>:

<condition>
  <name>the value of the 'condition' attribute</name>
  <ns>the namespace to be used as a service discovery feature</ns>
  <per-hop>does the "per-hop" flag apply? [true|false]</per-hop>
  <value>
     The syntax (e.g., datatype or allowable values) of the
     'value' attribute.
  </value>
  <processing>values that result in message processing</processing>
  <doc>the document (e.g., XEP) in which this condition is specified</doc>
</condition>

The registrant may register more than one condition at a time, each contained in a separate <condition/> element.

Note: The namespace for the condition set shall be included in the Service Discovery features registry.

11.4.1.2 Initial Submission

<condition>
  <name>deliver</name>
  <ns>http://jabber.org/protocol/amp?condition=deliver</ns>
  <per-hop>true</per-hop>
  <value>[direct|forward|gateway|none|stored]</value>
  <processing>
    The condition is met if (1) the value is "direct" and the message
    can be immediately delivered or further dispatched, (2) the value
    is "forward" and the message can be forwarded to another XMPP
    address, (3) the value is "gateway" and the message can be sent
    to a non-XMPP address via a gateway, (4) the value is "none" and
    the message cannot be delivered at all, or (5) the value is 
    "stored" and the message can be stored for later delivery.
  </processing>
  <doc>XEP-0079</doc>
</condition>

<condition>
  <name>expire-at</name>
  <ns>http://jabber.org/protocol/amp?condition=expire-at</ns>
  <per-hop>true</per-hop>
  <value>DateTime per XEP-0082</value>
  <processing>
    The condition is met if the message would be delivered after
    the specified DateTime.
  </processing>
  <doc>XEP-0079</doc>
</condition>

<condition>
  <name>match-resource</name>
  <ns>http://jabber.org/protocol/amp?condition=match-resource</ns>
  <per-hop>false</per-hop>
  <value>[any|exact|other]</value>
  <processing>
    The condition is met if (1) the value is "any" and the intended
    recipient has at least one available resource (as defined in the
    XMPP IM specification); (2) the value "exact" and the intended
    recipient has an available resource that exactly matches the JID
    specified in the 'to' address; (3) the value is "other" and the
    intended recipient has an available resource whose full JID is
    other than that specified in the 'to' address.
  </processing>
  <doc>XEP-0079</doc>
</condition>

11.4.2 Rule Actions Registry

The XMPP Registrar maintains a registry of AMP <rule/> actions at <http://xmpp.org/registrar/amp-actions.html>.

11.4.2.1 Process

In order to submit new values to this registry, the registrant shall define an XML fragment of the following form and either include it in the relevant XMPP Extension Protocol or send it to the email address <registrar@xmpp.org>:

<action>
  <name>the value of the 'action' attribute</name>
  <ns>the namespace to be used as a service discovery feature</ns>
  <behavior>the expected behavior if the rule is triggered</behavior>
  <doc>the document (e.g., XEP) in which this action is specified</doc>
</action>

The registrant may register more than one action at a time, each contained in a separate <action/> element.

Note: The namespace for the action set shall be included in the Service Discovery features registry.

11.4.2.2 Initial Submission

<action>
  <name>alert</name>
  <ns>http://jabber.org/protocol/amp?action=drop</ns>
  <behavior>
    The message is silently discarded but an alert is returned to the
    sender.
  </behavior>
  <doc>XEP-0079</doc>
</action>

<action>
  <name>drop</name>
  <ns>http://jabber.org/protocol/amp?action=drop</ns>
  <behavior>
    The message is silently discarded.
  </behavior>
  <doc>XEP-0079</doc>
</action>

<action>
  <name>error</name>
  <ns>http://jabber.org/protocol/amp?action=error</ns>
  <behavior>
    The message is not processed and an error is returned to the sender,
    specifying which rule resulted in failed processing.
  </behavior>
  <doc>XEP-0079</doc>
</action>

<action>
  <name>notify</name>
  <ns>http://jabber.org/protocol/amp?action=notify</ns>
  <behavior>
    The message is processed and a notification message is returned to
    the sender, specifying which rule was processed.
  </behavior>
  <doc>XEP-0079</doc>
</action>

12. XML Schemas

12.1 AMP

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

<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='http://jabber.org/protocol/amp'
    xmlns='http://jabber.org/protocol/amp'
    elementFormDefault='qualified'>
 
  <xs:annotation>
    <xs:documentation>
      The protocol documented by this schema is defined in
      XEP-0079: http://www.xmpp.org/extensions/xep-0079.html
    </xs:documentation>
  </xs:annotation>

  <xs:element name='amp'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='rule' minOccurs='1' maxOccurs='unbounded'/>
      </xs:sequence>
      <xs:attribute name='from' use='optional' type='xs:string'/>
      <xs:attribute name='per-hop' use='optional' type='xs:boolean' default='false'/>
      <xs:attribute name='status' use='optional' type='xs:NCName'/>
      <xs:attribute name='to' use='optional' type='xs:string'/>
    </xs:complexType>
  </xs:element>
 
  <xs:element name='invalid-rules'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='rule' minOccurs='1' maxOccurs='unbounded'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

  <xs:element name='unsupported-actions'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='rule' minOccurs='1' maxOccurs='unbounded'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

  <xs:element name='unsupported-conditions'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='rule' minOccurs='1' maxOccurs='unbounded'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

  <xs:element name='rule'>
    <xs:complexType>
      <xs:attribute name='action' use='required' type='xs:NCName'/>
      <xs:attribute name='condition' use='required' type='xs:NCName'/>
      <xs:attribute name='value' use='required' type='xs:string'/>
    </xs:complexType>
  </xs:element>

</xs:schema>

12.2 Errors

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

<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='http://jabber.org/protocol/amp#errors'
    xmlns='http://jabber.org/protocol/amp#errors'
    elementFormDefault='qualified'>
 
  <xs:annotation>
    <xs:documentation>
      The protocol documented by this schema is defined in
      XEP-0079: http://www.xmpp.org/extensions/xep-0079.html
    </xs:documentation>
  </xs:annotation>

  <xs:element name='failed-rules'>
    <xs:complexType>
      <xs:sequence>
        <xs:element ref='rule' minOccurs='1' maxOccurs='unbounded'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

  <xs:element name='rule'>
    <xs:complexType>
      <xs:attribute name='action' use='required' type='xs:NCName'/>
      <xs:attribute name='condition' use='required' type='xs:NCName'/>
      <xs:attribute name='value' use='required' type='xs:string'/>
    </xs:complexType>
  </xs:element>

</xs:schema>

12.3 Stream Feature

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

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

  <xs:annotation>
    <xs:documentation>
      The protocol documented by this schema is defined in
      XEP-0079: http://www.xmpp.org/extensions/xep-0079.html
    </xs:documentation>
  </xs:annotation>

  <xs:element name='amp' type='empty'/>

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

</xs:schema>

13. Acknowledgements

Thanks to Marshall Rose and Craig Kaes for their comments.

Appendices

Appendix A: Document Information

Series: XEP
Number: 0079
Publisher: XMPP Standards Foundation
Status: Draft
Type: Standards Track
Version: 1.2
Last Updated: 2005-11-30
Approving Body: XMPP Council
Dependencies: XMPP Core, XEP-0030, XEP-0082
Supersedes: XEP-0023
Superseded By: None
Short Name: amp
XML Schema for amp namespace: <http://www.xmpp.org/schemas/amp.xsd>
XML Schema for amp#errors namespace: <http://www.xmpp.org/schemas/amp-errors.xsd>
XML Schema for feature namespace: <http://www.xmpp.org/schemas/amp-feature.xsd>
Registry: <http://xmpp.org/registrar/amp.html>
Source Control: HTML  RSS
This document in other formats: XML  PDF

Appendix B: Author Information

Matthew Miller

Email: linuxwolf@outer-planes.net
JabberID: linuxwolf@outer-planes.net

Peter Saint-Andre

Email: stpeter@jabber.org
JabberID: stpeter@jabber.org
URI: https://stpeter.im/

Appendix C: Legal Notices

Copyright

This XMPP Extension Protocol is copyright © 1999 - 2010 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. ##

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 from, out of, or in connection with the Specification or the implementation, deployment, or other use of 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 can be found at <http://xmpp.org/extensions/ipr-policy.shtml> or obtained by writing to XMPP Standards Foundation, 1899 Wynkoop Street, Suite 600, Denver, CO 80202 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 can 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. RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://tools.ietf.org/html/rfc3921>.

3. XEP-0030: Service Discovery <http://xmpp.org/extensions/xep-0030.html>.

4. Guarantee is a strong word. This document defines methods for making message delivery more reliable within certain bounds, but does not pretend that such methods provide any form of guaranteed delivery.

5. RFC 1305: Network Time Protocol (Version 3) <http://tools.ietf.org/html/rfc1305>.

6. XEP-0082: XMPP Date and Time Profiles <http://xmpp.org/extensions/xep-0082.html>.

7. XEP-0045: Multi-User Chat <http://xmpp.org/extensions/xep-0045.html>.

8. XEP-0047: In-Band Bytestreams <http://xmpp.org/extensions/xep-0047.html>.

9. XEP-0086: Error Condition Mappings <http://xmpp.org/extensions/xep-0086.html>.

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

11. RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://tools.ietf.org/html/rfc3921>.

12. An exception might be fully-trusted or closed networks.

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

Appendix H: Revision History

Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/

Version 1.2 (2005-11-30)

Consolidated and generalized security considerations. (psa)

Version 1.1 (2005-10-19)

Reversed the meaning of conditions other than expire-at (per list discussion); correctly specified stream feature. (psa)

Version 1.0 (2004-10-11)

Per a vote of the Jabber Council, advanced to a status of Draft. (psa)

Version 0.12 (2004-09-09)

Relaxed server-to-server requirements; clarified discovery rules; removed expire-in condition. (lw)

Version 0.11 (2004-08-25)

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. (lw/psa)

Version 0.10 (2004-07-14)

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". (lw/psa)

Version 0.9 (2004-04-25)

Editorial review: clarified some matters in the text; fully defined the XMPP Registrar Considerations. (psa)

Version 0.8 (2004-01-20)

Reorganized for Editorial preferences; revised error conditions to properly align with XMPP-Core (lw)

Version 0.7 (2003-12-10)

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

Version 0.6 (2003-10-15)

Changed disco behavior; Changed schema to reflect customizations (lw)

Version 0.5.1 (2003-09-20)

Fixed many typos (lw)

Version 0.5 (2003-08-28)

Renamed to "amp" (thanks stpeter!); Added information about the original addressing; Added requirement for id attribute in <message/>; Restricted behavior within the "Security Considerations"; (lw)

Version 0.4 (2003-06-23)

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

Version 0.3 (2003-04-21)

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

Version 0.2 (2003-04-15)

Added XML Schema (with author's assistance). (psa)

Version 0.1 (2003-04-15)

Initial version. (lw)

END