<abstract>This specification defines an XMPP protocol extension for communicating the fact that an XML stanza has been delivered with a delay, for example because a message has been stored on a server while the intended recipient was offline or because a message is contained in the history of a multi-user chat room.</abstract>
<remark><p>Per a vote of the XMPP Council, advanced specification from Draft to Final; also addressed a security concern about forged timestamps that was provided during the Call for Experience.</p></remark>
<p>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 <cite>XEP-0091</cite> which enables communication of delayed delivery information while adhering to <cite>XEP-0082</cite>.</p>
<p>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:</p>
<ul>
<li>A message that is sent to an offline entity and stored for later delivery (see &xep0160;).</li>
<li>The last available presence stanza sent by a connected client to a server.</li>
<li>Messages cached by a &xep0045; room for delivery to new participants when they join the room.</li>
</ul>
<p>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:</p>
<td>The Jabber ID of the entity that originally sent the XML stanza or that delayed the delivery of the stanza (e.g., the address of a multi-user chat room).</td>
<td>The time when the XML stanza was originally sent. The format MUST adhere to the dateTime format specified in <cite>XEP-0082</cite> and MUST be expressed in UTC.</td>
<td>REQUIRED</td>
</tr>
</table>
<p>In addition, the <delay/> element MAY contain XML character data that provides a natural-language description of the reason for the delay.</p>
</section1>
<section1topic='Examples'anchor='examples'>
<examplecaption='Receiving a Message Sent While Offline'><![CDATA[
<p>This protocol was designed in a way that makes migration from <cite>XEP-0091</cite> 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 <cite>XEP-0082</cite>).</p>
<p>Implementations that support <cite>XEP-0091</cite> should support the protocol defined herein as soon as possible, but should continue to support the protocol defined in <cite>XEP-0091</cite> for backwards compatibility until the status of that specification is changed to Obsolete.</p>
<p>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.</p>
<p>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.</p>