/
xep-0160.xml
140 lines (140 loc) · 8.5 KB
/
xep-0160.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<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>
&LEGALNOTICE;
<number>0160</number>
<status>Active</status>
<type>Informational</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
<spec>XEP-0030</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>msgoffline</shortname>
&stpeter;
<revision>
<version>1.0.1</version>
<date>2016-10-07</date>
<initials>egp</initials>
<remark><p>Use the correct namespace in the Service Discovery examples; fix some formatting.</p></remark>
</revision>
<revision>
<version>1.0</version>
<date>2006-01-24</date>
<initials>psa</initials>
<remark>Per a vote of the Jabber Council, advanced status to Active.</remark>
</revision>
<revision>
<version>0.2</version>
<date>2005-11-15</date>
<initials>psa</initials>
<remark>Added section on handling of each message type.</remark>
</revision>
<revision>
<version>0.1</version>
<date>2005-10-05</date>
<initials>psa</initials>
<remark>Initial version.</remark>
</revision>
<revision>
<version>0.0.1</version>
<date>2005-09-27</date>
<initials>psa</initials>
<remark>First draft.</remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>&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 <cite>RFC 6121</cite>). This document fills the gap by specifying best practices for storage and delivery of so-called "offline messages".</p>
</section1>
<section1 topic='Process Flow' anchor='flow'>
<p>The RECOMMENDED process flow is as follows:</p>
<ol>
<li>Sender generates XMPP message stanza <note>This document does not discuss IQ or presence stanzas, handling of which is described in <cite>RFC 6120</cite> and <cite>RFC 6121</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 6121</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 6121</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>Recipient's server does not return a &unavailable; error but instead stores the message stanza for later delivery.</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>
</ol>
<p>This flow is described more fully below.</p>
<p>First, the sender (in this example, romeo@montague.net) sends a message to an intended recipient (juliet@capulet.com).</p>
<example caption='Sender Generates Message to Recipient'><![CDATA[
<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>
]]></example>
<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>Now the recipient authenticates with the server and sends initial presence (with a non-negative priority) to the server.</p>
<example caption='Recipient Becomes Available'><![CDATA[
<presence from='juliet@capulet.com/balcony'>
<priority>1</priority>
</presence>
]]></example>
<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>
<example caption='Recipient's Server Delivers Message'><![CDATA[
<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>
<delay xmlns='urn:xmpp:delay'
from='capulet.com'
stamp='2002-09-10T23:08:25Z'>Offline Storage</delay>
</message>
]]></example>
</section1>
<section1 topic='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 6121</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>
</ul>
</section1>
<section1 topic='Service Discovery' anchor='disco'>
<p>If a server supports offline message handling as described herein, it SHOULD return a "msgoffline" feature in response to &xep0030; information requests:</p>
<example caption='Recipient Queries Server About Support'><![CDATA[
<iq from='juliet@capulet.com/chamber' to='capulet.com'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
]]></example>
<example caption='Server Returns Information About Support'><![CDATA[
<iq from='capulet.com' to='juliet@capulet.com/chamber'>
<query xmlns='http://jabber.org/protocol/disco#info'>
...
<feature var='msgoffline'/>
...
</query>
</iq>
]]></example>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<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>
<p>See <cite>XEP-0203</cite> for security considerations regarding the inclusion and processing of delayed delivery notations.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>The ®ISTRAR; includes "msgoffline" in its registry of service discovery features (see &DISCOFEATURES;).</p>
</section1>
</xep>