This document specifies best practices to be followed by Jabber/XMPP servers in handling messages sent to recipients who are offline.
NOTICE: This JEP is currently within Last Call or under consideration by the Jabber Council for advancement to the next stage in the JSF standards process. For further details, visit <http://www.jabber.org/council/queue.shtml>.
Status: Proposed
Type: Informational
Number: 0160
Version: 0.2
Last Updated: 2005-11-15
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: XMPP Core, XMPP IM, JEP-0030
Supersedes: None
Superseded By: None
Short Name: msgoffline
Wiki Page: <http://wiki.jabber.org/index.php/Best Practices for Handling Offline Messages (JEP-0160)>
Email: stpeter@jabber.org
JID: stpeter@jabber.org
This Jabber Enhancement Proposal is copyright 1999 - 2005 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy <http://www.jabber.org/jsf/ipr-policy.shtml>. This material may be distributed only subject to the terms and conditions set forth in the Creative Commons Attribution License (<http://creativecommons.org/licenses/by/2.5/>).
The preferred venue for discussion of this document is the Standards-JIG discussion list: <http://mail.jabber.org/mailman/listinfo/standards-jig>.
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the Jabber Software 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 JEP 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.
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
RFC 3920 [1] and RFC 3921 [2] 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 <service-unavailable/> error if offline message storage or message forwarding is not enabled (see Section 11.1 of RFC 3921). 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:
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).
Example 1. Sender Generates Message to Recipient
<message from='romeo@montague.net/orchard' to='juliet@capulet.com'>
<body>
O blessed, blessed night! I am afeard.
Being in night, all this is but a dream,
Too flattering-sweet to be substantial.
</body>
</message>
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). If there are not, 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.
Example 2. Recipient Becomes Available
<presence from='juliet@capulet.com/balcony'> <priority>1</priority> </presence>
The recipient's server now delivers the offline message to that resource (it is RECOMMENDED for the server to add a Delayed Delivery [6] extension to indicate that the message was stored offline).
Example 3. Recipient's Server Delivers Message
<message from='romeo@montague.net/orchard' to='juliet@capulet.com'>
<body>
O blessed, blessed night! I am afeard.
Being in night, all this is but a dream,
Too flattering-sweet to be substantial.
</body>
<x from='capulet.com' stamp='20020910T23:08:25' xmlns='jabber:x:delay'>
Offline Storage
</x>
</message>
Message stanzas SHOULD be handled by a server as follows (based on the values of the 'type' attribute specified in RFC 3921):
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 Chat State Notifications [7] 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 Multi-User Chat [8] 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 Advanced Message Processing [9] error messages offline.
If a server supports offline message handling as described herein, it SHOULD return a "msgoffline" feature in response to Service Discovery [10] information requests:
Example 4. Recipient Queries Server About Support
<iq from='juliet@capulet.com/chamber' to='capulet.com'> <query xmlns='http://jabber.org/disco#info'/> </iq>
Example 5. Server Returns Information About Support
<iq from='capulet.com' to='juliet@capulet.com/chamber'>
<query xmlns='http://jabber.org/disco#info'>
...
<feature var='msgoffline'/>
</query>
</iq>
A message stored offline may not be readable by the recipient if the message was encrypted using a session-based encryption method such as Encrypted Sessions [11] 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.
This JEP requires no interaction with the Internet Assigned Numbers Authority (IANA) [12].
This JEP requires no interaction with the Jabber Registrar [13], since the "msgoffline" service discovery feature is already registered.
1. RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://www.ietf.org/rfc/rfc3920.txt>.
2. RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://www.ietf.org/rfc/rfc3921.txt>.
3. This JEP does not discuss IQ or presence stanzas, handling of which is described in RFC 3920 and RFC 3921.
4. As specified in RFC 3920, available resources that have specified a negative presence priority shall never receive message stanzas addressed to <node@domain>.
5. JEP-0013: Flexible Offline Message Retrieval <http://www.jabber.org/jeps/jep-0013.html>.
6. JEP-0091: Delayed Delivery <http://www.jabber.org/jeps/jep-0091.html>.
7. JEP-0085: Chat State Notifications <http://www.jabber.org/jeps/jep-0085.html>.
8. JEP-0045: Multi-User Chat <http://www.jabber.org/jeps/jep-0045.html>.
9. JEP-0079: Advanced Message Processing <http://www.jabber.org/jeps/jep-0079.html>.
10. JEP-0030: Service Discovery <http://www.jabber.org/jeps/jep-0030.html>.
11. JEP-0116: Encrypted Sessions <http://www.jabber.org/jeps/jep-0116.html>.
12. 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/>.
13. The Jabber Registrar maintains a list of reserved Jabber protocol namespaces as well as registries of parameters used in the context of protocols approved by the Jabber Software Foundation. For further information, see <http://www.jabber.org/registrar/>.
END