JEP-0160: Best Practices for Handling Offline Messages

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


JEP Information

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

Author Information

Peter Saint-Andre

Email: stpeter@jabber.org
JID: stpeter@jabber.org

Legal Notice

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

Discussion Venue

The preferred venue for discussion of this document is the Standards-JIG discussion list: <http://mail.jabber.org/mailman/listinfo/standards-jig>.

Relation to XMPP

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.

Conformance Terms

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.


Table of Contents

1. Introduction
2. Process Flow
3. Handling of Message Types
4. Service Discovery
5. Security Considerations
6. IANA Considerations
7. Jabber Registrar Considerations
Notes
Revision History


1. Introduction

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

2. Process Flow

The RECOMMENDED process flow is as follows:

  1. Sender generates XMPP message stanza [3] 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 3921 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. [4]
  3. Recipient's server does not return a <service-unavailable/> error but instead stores the message stanza for later delivery.
  4. 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 Flexible Offline Message Retrieval [5], 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).

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>
  

3. Handling of Message Types

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

4. Service Discovery

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>
  

5. Security Considerations

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.

6. IANA Considerations

This JEP requires no interaction with the Internet Assigned Numbers Authority (IANA) [12].

7. Jabber Registrar Considerations

This JEP requires no interaction with the Jabber Registrar [13], since the "msgoffline" service discovery feature is already registered.


Notes

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


Revision History

Version 0.2 (2005-11-15)

Added section on handling of each message type. (psa)

Version 0.1 (2005-10-05)

Initial JEP version. (psa)

Version 0.0.1 (2005-09-27)

First draft. (psa)


END