<title>Best Practices for Handling Offline Messages</title>
<abstract>This document specifies best practices to be followed by Jabber/XMPP servers in handling messages sent to recipients who are offline.</abstract>
<p>&rfc3920; and &rfc3921; specify general rules for handling XML stanzas, but explicitly do not address how to handle message stanzas sent to recipients (e.g., IM users or other nodes) that are offline, except to say that a server MUST return a &unavailable; error if offline message storage or message forwarding is not enabled (see Section 11.1 of <cite>RFC 3921</cite>). This document fills the gap by specifying best practices for storage and delivery of so-called "offline messages".</p>
</section1>
<section1topic='Process Flow'anchor='flow'>
<p>The RECOMMENDED process flow is as follows:</p>
<li>Sender generates XMPP message stanza <note>This document does not discuss IQ or presence stanzas, handling of which is described in <cite>RFC 3920</cite> and <cite>RFC 3921</cite>.</note> for delivery to a recipient such as an IM user or other node, where the 'to' address is of the form <node@domain> or <node@domain/resource> (see <cite>RFC 3921</cite> for rules regarding server handling of such XMPP message stanzas).</li>
<li>Recipient's server determines that the intended recipient has no available resources that have specified non-negative presence priority. <note>As specified in <cite>RFC 3920</cite>, available resources that have specified a negative presence priority shall never receive message stanzas addressed to <node@domain>.</note></li>
<li>Recipient's server determines that if the server can store offline messages on behalf of the intended recipient; if not (e.g., because the recipient's offline message queue is full), the server returns a &unavailable; error to the sender.</li>
<li>When the recipient next sends non-negative available presence to the server, the server delivers the message to the resource that has sent that presence. (Alternatively, the server may support &xep0013;, although that functionality is not described herein.)</li>
<p>Next, the recipient's server determines if there are any available resources that have sent non-negative presence priority. If there are, the server immediately delivers the message stanza to the resource that it determines to be most available (based on its own algorithm).</p>
<p>Next, the recipient's server determines if offline messages can be stored on behalf of the intended recipient. If not (e.g., because the recipient's offline message queue is full), the server returns a &unavailable; error to the sender. If so, the server stores the message for later delivery.</p>
<p>The recipient's server now delivers the offline message to that resource (it is RECOMMENDED for the server to add a &xep0203; extension to indicate that the message was stored offline).</p>
<section1topic='Handling of Message Types'anchor='types'>
<p>Message stanzas SHOULD be handled by a server as follows (based on the values of the 'type' attribute specified in <cite>RFC 3921</cite>):</p>
<ul>
<li><p><strong>normal</strong> -- Messages with a 'type' attribute whose value is "normal" (or messages with no 'type' attribute) SHOULD be stored offline.</p></li>
<li><p><strong>chat</strong> -- Messages with a 'type' attribute whose value is "chat" SHOULD be stored offline, with the exception of messages that contain only &xep0085; content (such messages SHOULD NOT be stored offline).</p></li>
<li><p><strong>groupchat</strong> -- Messages with a 'type' attribute whose value is "groupchat" SHOULD NOT be stored offline, since by definition a user without online presence cannot be in a &xep0045; room.</p></li>
<li><p><strong>headline</strong> -- Messages with a 'type' attribute whose value is "headline" SHOULD NOT be stored offline, since such messages are usually time-sensitive.</p></li>
<li><p><strong>error</strong> -- Messages with a 'type' attribute whose value is "error" SHOULD NOT be stored offline, although a server MAY store &xep0079; error messages offline.</p></li>
<p>If a server supports offline message handling as described herein, it SHOULD return a "msgoffline" feature in response to &xep0030; information requests:</p>
<p>A message stored offline may not be readable by the recipient if the message was encrypted using a session-based encryption method such as &xep0116; or if the key used in object encryption is revoked after the message was sent but before it is read.</p>
<p>In certain countries, offline storage of message stanzas may introduce legal requirements or privacy vulnerabilities that do not apply to messages that are delivered immediately and never stored on an intermediate server.</p>
