&xmppcore; and &xmppim; 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 RFC 6121). This document fills the gap by specifying best practices for storage and delivery of so-called "offline messages".

The RECOMMENDED process flow is as follows:

1. Sender generates XMPP message stanza This document does not discuss IQ or presence stanzas, handling of which is described in RFC 6120 and RFC 6121. 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 RFC 6121 for rules regarding server handling of such XMPP message stanzas).
2. Recipient's server determines that the intended recipient has no available resources that have specified non-negative presence priority. As specified in RFC 6121, available resources that have specified a negative presence priority shall never receive message stanzas addressed to <node@domain>.
3. 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.
4. Recipient's server does not return a &unavailable; error but instead stores the message stanza for later delivery.
5. 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.)

This flow is described more fully below.

First, the sender (in this example, romeo@montague.net) sends a message to an intended recipient (juliet@capulet.com).

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

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.

Now the recipient authenticates with the server and sends initial presence (with a non-negative priority) to the server.

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

Message stanzas SHOULD be handled by a server as follows (based on the values of the 'type' attribute specified in RFC 6121):

• normal -- Messages with a 'type' attribute whose value is "normal" (or messages with no 'type' attribute) SHOULD be stored offline.

• chat -- 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).

• groupchat -- 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.

• headline -- Messages with a 'type' attribute whose value is "headline" SHOULD NOT be stored offline, since such messages are usually time-sensitive.

• error -- Messages with a 'type' attribute whose value is "error" SHOULD NOT be stored offline, although a server MAY store &xep0079; error messages offline.

If a server supports offline message handling as described herein, it SHOULD return a "msgoffline" feature in response to &xep0030; information requests:

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.

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.

See XEP-0203 for security considerations regarding the inclusion and processing of delayed delivery notations.

This document requires no interaction with &IANA;.

The ®ISTRAR; includes "msgoffline" in its registry of service discovery features (see &DISCOFEATURES;).