Although the XMPP protocol extension defined in &xep0091; provides a way to communicate that an XML stanza (typically a &MESSAGE; or &PRESENCE; stanza) has been delivered with a delay, the timestamp format defined in that document does not adhere to the recommended date and time profiles for XMPP protocols defined in &xep0082;. Therefore, this document defines a replacement for XEP-0091 which enables communication of delayed delivery information while adhering to XEP-0082.

The XML namespace defined herein is used to provide timestamp information about data stored for later delivery. The most common uses of this namespace are to stamp:

• A message that is sent to an offline entity and stored for later delivery (see &xep0160;).
• The last available presence stanza sent by a connected client to a server.
• Messages cached by a &xep0045; room for delivery to new participants when they join the room.

Information about the delivery delay is communicated by adding to the <message/> or <presence/> stanza one and only one <delay/> child qualified by a namespace to be issued when this specification advances to a status of Draft. This information is added by the server or component that delivers the stanza. The following attributes are defined for the <delay/> element:

In addition, the <delay/> element MAY contain XML character data that provides a natural-language description of the reason for the delay.

This protocol was designed in a way that makes migration from XEP-0091 straightforward. All attributes present in the 'jabber:x:delay' namespace are present in the namespace defined herein. However, this document specifies a different format for the value of the <stamp> attribute (compliant with XEP-0082).

Implementations that support XEP-0091 should support the protocol defined herein as soon as possible, but should continue to support the protocol defined in XEP-0091 for backwards compatibility until the status of that specification is changed to Obsolete.

Delayed delivery data can expose information about the sender's presence on the network at some time in the past. However, this introduces no new vulnerabilities, since the same information would have been available in real time.

Absent cryptographic signing of stanzas and parts of stanzas, it is possible for delayed delivery notations to be forged. For example, the originator of a message (or the originator's server) could include a notation that makes it appear as if delivery of the message was delayed by the recipient's server. The same is true of delayed delivery notations putatively added by a Multi-User Chat room, which could be forged by the message originator, the originator's server, the recipient's server, or the server that hosts the chatroom service. Although the recipient's server SHOULD discard a delayed delivery notation whose 'from' attribute matches the server's JabberID (or return a ¬acceptable; error to the originator), this policy does not guard against forging of notations putatively from other entities (such as a chatroom hosted at a different trust domain). Therefore, a recipient SHOULD NOT rely on delayed delivery notations to provide a completely accurate representation of the delivery path or timing of a stanza it has received.

This document requires no interaction with &IANA;.

Thanks to Sergei Golovan for his feedback regarding forged timestamps.