' and
'' lines.
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
-- Looks like a reference, but probably isn't: '43' on line 915
-- Looks like a reference, but probably isn't: '3' on line 5227
** Obsolete normative reference: RFC 4234 (ref. 'ABNF') (Obsoleted by RFC
5234)
** Obsolete normative reference: RFC 2831 (ref. 'DIGEST-MD5') (Obsoleted by
RFC 6331)
** Obsolete normative reference: RFC 3490 (ref. 'IDNA') (Obsoleted by RFC
5890, RFC 5891)
** Obsolete normative reference: RFC 4646 (ref. 'LANGTAGS') (Obsoleted by
RFC 5646)
** Obsolete normative reference: RFC 3491 (ref. 'NAMEPREP') (Obsoleted by
RFC 5891)
** Obsolete normative reference: RFC 2373 (Obsoleted by RFC 3513)
** Obsolete normative reference: RFC 3454 (ref. 'STRINGPREP') (Obsoleted by
RFC 7564)
** Obsolete normative reference: RFC 793 (ref. 'TCP') (Obsoleted by RFC
9293)
** Obsolete normative reference: RFC 4346 (ref. 'TLS') (Obsoleted by RFC
5246)
-- Possible downref: Non-RFC (?) normative reference: ref. 'UCS2'
-- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE'
** Obsolete normative reference: RFC 3280 (ref. 'X509') (Obsoleted by RFC
5280)
-- Possible downref: Non-RFC (?) normative reference: ref. 'XML'
-- Possible downref: Non-RFC (?) normative reference: ref. 'XML-NAMES'
-- Obsolete informational reference (is this intentional?): RFC 2616 (ref.
'HTTP') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234,
RFC 7235)
-- Obsolete informational reference (is this intentional?): RFC 3501 (ref.
'IMAP') (Obsoleted by RFC 9051)
-- Obsolete informational reference (is this intentional?): RFC 3920
(Obsoleted by RFC 6120)
-- Obsolete informational reference (is this intentional?): RFC 3921
(Obsoleted by RFC 6121)
-- Obsolete informational reference (is this intentional?): RFC 2821 (ref.
'SMTP') (Obsoleted by RFC 5321)
-- Duplicate reference: RFC1035, mentioned in 'STD13', was also mentioned
in 'DNS'.
== Outdated reference: A later version (-08) exists of
draft-saintandre-rfc3921bis-03
Summary: 11 errors (**), 0 flaws (~~), 6 warnings (==), 20 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group P. Saint-Andre, Ed.
3 Internet-Draft XMPP Standards Foundation
4 Obsoletes: 3920 (if approved) June 2, 2008
5 Intended status: Standards Track
6 Expires: December 4, 2008
8 Extensible Messaging and Presence Protocol (XMPP): Core
9 draft-saintandre-rfc3920bis-05
11 Status of this Memo
13 By submitting this Internet-Draft, each author represents that any
14 applicable patent or other IPR claims of which he or she is aware
15 have been or will be disclosed, and any of which he or she becomes
16 aware will be disclosed, in accordance with Section 6 of BCP 79.
18 Internet-Drafts are working documents of the Internet Engineering
19 Task Force (IETF), its areas, and its working groups. Note that
20 other groups may also distribute working documents as Internet-
21 Drafts.
23 Internet-Drafts are draft documents valid for a maximum of six months
24 and may be updated, replaced, or obsoleted by other documents at any
25 time. It is inappropriate to use Internet-Drafts as reference
26 material or to cite them other than as "work in progress."
28 The list of current Internet-Drafts can be accessed at
29 http://www.ietf.org/ietf/1id-abstracts.txt.
31 The list of Internet-Draft Shadow Directories can be accessed at
32 http://www.ietf.org/shadow.html.
34 This Internet-Draft will expire on December 4, 2008.
36 Abstract
38 This document defines the core features of the Extensible Messaging
39 and Presence Protocol (XMPP), a technology for streaming Extensible
40 Markup Language (XML) elements in order to exchange structured
41 information in close to real time between any two or more network-
42 aware entities. XMPP provides a generalized, extensible framework
43 for incrementally exchanging XML data, upon which a variety of
44 applications can be built. The framework includes methods for stream
45 setup and teardown, channel encryption, authentication of a client to
46 a server and of one server to another server, and primitives for
47 push-style messages, publication of network availability information
48 ("presence"), and request-response interactions between any two XMPP
49 entities. This document also specifies the format for XMPP
50 addresses, which are fully internationalizable.
52 This document obsoletes RFC 3920.
54 Table of Contents
56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 9
57 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 9
58 1.2. Functional Summary . . . . . . . . . . . . . . . . . . . 10
59 1.3. Conventions . . . . . . . . . . . . . . . . . . . . . . 11
60 1.4. Discussion Venue . . . . . . . . . . . . . . . . . . . . 11
61 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 11
62 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 11
63 2.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 12
64 2.3. Client . . . . . . . . . . . . . . . . . . . . . . . . . 13
65 2.4. Network . . . . . . . . . . . . . . . . . . . . . . . . 13
66 3. Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 13
67 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 13
68 3.2. Domain Identifier . . . . . . . . . . . . . . . . . . . 14
69 3.3. Node Identifier . . . . . . . . . . . . . . . . . . . . 16
70 3.4. Resource Identifier . . . . . . . . . . . . . . . . . . 17
71 3.5. Determination of Addresses . . . . . . . . . . . . . . . 17
72 4. TCP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 18
73 4.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . 18
74 4.2. Hostname Resolution . . . . . . . . . . . . . . . . . . 18
75 4.3. Client-to-Server Communications . . . . . . . . . . . . 19
76 4.4. Server-to-Server Communications . . . . . . . . . . . . 19
77 4.5. Reconnection . . . . . . . . . . . . . . . . . . . . . . 19
78 4.6. Other Bindings . . . . . . . . . . . . . . . . . . . . . 20
79 5. XML Streams . . . . . . . . . . . . . . . . . . . . . . . . . 20
80 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 20
81 5.2. Stream Security . . . . . . . . . . . . . . . . . . . . 22
82 5.3. Stream Attributes . . . . . . . . . . . . . . . . . . . 23
83 5.3.1. from . . . . . . . . . . . . . . . . . . . . . . . . 23
84 5.3.2. to . . . . . . . . . . . . . . . . . . . . . . . . . 24
85 5.3.3. id . . . . . . . . . . . . . . . . . . . . . . . . . 25
86 5.3.4. xml:lang . . . . . . . . . . . . . . . . . . . . . . 26
87 5.3.5. version . . . . . . . . . . . . . . . . . . . . . . 26
88 5.3.6. Summary . . . . . . . . . . . . . . . . . . . . . . 28
89 5.4. Namespace Declarations . . . . . . . . . . . . . . . . . 28
90 5.5. Stream Features . . . . . . . . . . . . . . . . . . . . 28
91 5.6. Closing Streams . . . . . . . . . . . . . . . . . . . . 30
92 5.6.1. With Stream Error . . . . . . . . . . . . . . . . . 30
93 5.6.2. Without Stream Error . . . . . . . . . . . . . . . . 30
94 5.6.3. Handling of Idle Streams . . . . . . . . . . . . . . 31
95 5.7. Stream Errors . . . . . . . . . . . . . . . . . . . . . 31
96 5.7.1. Rules . . . . . . . . . . . . . . . . . . . . . . . 31
97 5.7.1.1. Stream Errors Are Unrecoverable . . . . . . . . . 31
98 5.7.1.2. Stream Errors Can Occur During Setup . . . . . . 32
99 5.7.1.3. Stream Errors When the Host is Unspecified . . . 32
100 5.7.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . 33
101 5.7.3. Defined Stream Error Conditions . . . . . . . . . . 34
102 5.7.3.1. bad-format . . . . . . . . . . . . . . . . . . . 34
103 5.7.3.2. bad-namespace-prefix . . . . . . . . . . . . . . 34
104 5.7.3.3. conflict . . . . . . . . . . . . . . . . . . . . 35
105 5.7.3.4. connection-timeout . . . . . . . . . . . . . . . 36
106 5.7.3.5. host-gone . . . . . . . . . . . . . . . . . . . . 36
107 5.7.3.6. host-unknown . . . . . . . . . . . . . . . . . . 37
108 5.7.3.7. improper-addressing . . . . . . . . . . . . . . . 38
109 5.7.3.8. internal-server-error . . . . . . . . . . . . . . 38
110 5.7.3.9. invalid-from . . . . . . . . . . . . . . . . . . 39
111 5.7.3.10. invalid-id . . . . . . . . . . . . . . . . . . . 39
112 5.7.3.11. invalid-namespace . . . . . . . . . . . . . . . . 40
113 5.7.3.12. invalid-xml . . . . . . . . . . . . . . . . . . . 40
114 5.7.3.13. not-authorized . . . . . . . . . . . . . . . . . 41
115 5.7.3.14. policy-violation . . . . . . . . . . . . . . . . 42
116 5.7.3.15. remote-connection-failed . . . . . . . . . . . . 43
117 5.7.3.16. resource-constraint . . . . . . . . . . . . . . . 43
118 5.7.3.17. restricted-xml . . . . . . . . . . . . . . . . . 44
119 5.7.3.18. see-other-host . . . . . . . . . . . . . . . . . 44
120 5.7.3.19. system-shutdown . . . . . . . . . . . . . . . . . 45
121 5.7.3.20. undefined-condition . . . . . . . . . . . . . . . 46
122 5.7.3.21. unsupported-encoding . . . . . . . . . . . . . . 46
123 5.7.3.22. unsupported-stanza-type . . . . . . . . . . . . . 47
124 5.7.3.23. unsupported-version . . . . . . . . . . . . . . . 47
125 5.7.3.24. xml-not-well-formed . . . . . . . . . . . . . . . 48
126 5.7.4. Application-Specific Conditions . . . . . . . . . . 49
127 5.8. Simplified Stream Examples . . . . . . . . . . . . . . . 49
128 6. STARTTLS Negotiation . . . . . . . . . . . . . . . . . . . . 51
129 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 52
130 6.2. Rules . . . . . . . . . . . . . . . . . . . . . . . . . 52
131 6.2.1. Mechanism Preferences . . . . . . . . . . . . . . . 52
132 6.2.2. Data Formatting . . . . . . . . . . . . . . . . . . 52
133 6.2.3. Order of Negotiation . . . . . . . . . . . . . . . . 52
134 6.3. Process . . . . . . . . . . . . . . . . . . . . . . . . 53
135 6.3.1. Exchange of Stream Headers and Stream Features . . . 53
136 6.3.2. Initiation of STARTTLS Negotiation . . . . . . . . . 54
137 6.3.2.1. STARTTLS Command . . . . . . . . . . . . . . . . 54
138 6.3.2.2. Failure Case . . . . . . . . . . . . . . . . . . 54
139 6.3.2.3. Proceed Case . . . . . . . . . . . . . . . . . . 55
140 6.3.3. TLS Negotiation . . . . . . . . . . . . . . . . . . 55
141 6.3.3.1. Rules . . . . . . . . . . . . . . . . . . . . . . 55
142 6.3.3.2. TLS Failure . . . . . . . . . . . . . . . . . . . 55
143 6.3.3.3. TLS Success . . . . . . . . . . . . . . . . . . . 56
145 7. SASL Negotiation . . . . . . . . . . . . . . . . . . . . . . 57
146 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 57
147 7.2. Rules . . . . . . . . . . . . . . . . . . . . . . . . . 57
148 7.2.1. Data Formatting . . . . . . . . . . . . . . . . . . 57
149 7.2.2. Security Layers . . . . . . . . . . . . . . . . . . 57
150 7.2.3. Simple Usernames . . . . . . . . . . . . . . . . . . 58
151 7.2.4. Authorization Identities . . . . . . . . . . . . . . 58
152 7.2.5. Round Trips . . . . . . . . . . . . . . . . . . . . 58
153 7.3. Process . . . . . . . . . . . . . . . . . . . . . . . . 59
154 7.3.1. Exchange of Stream Headers and Stream Features . . . 59
155 7.3.2. Initiation . . . . . . . . . . . . . . . . . . . . . 61
156 7.3.3. Challenge-Response Sequence . . . . . . . . . . . . 61
157 7.3.4. Abort . . . . . . . . . . . . . . . . . . . . . . . 61
158 7.3.5. Failure . . . . . . . . . . . . . . . . . . . . . . 62
159 7.3.6. Success . . . . . . . . . . . . . . . . . . . . . . 63
160 7.4. SASL Definition . . . . . . . . . . . . . . . . . . . . 64
161 7.5. SASL Errors . . . . . . . . . . . . . . . . . . . . . . 64
162 7.5.1. aborted . . . . . . . . . . . . . . . . . . . . . . 65
163 7.5.2. account-disabled . . . . . . . . . . . . . . . . . . 65
164 7.5.3. credentials-expired . . . . . . . . . . . . . . . . 65
165 7.5.4. encryption-required . . . . . . . . . . . . . . . . 66
166 7.5.5. incorrect-encoding . . . . . . . . . . . . . . . . . 66
167 7.5.6. invalid-authzid . . . . . . . . . . . . . . . . . . 66
168 7.5.7. invalid-mechanism . . . . . . . . . . . . . . . . . 67
169 7.5.8. malformed-request . . . . . . . . . . . . . . . . . 67
170 7.5.9. mechanism-too-weak . . . . . . . . . . . . . . . . . 67
171 7.5.10. not-authorized . . . . . . . . . . . . . . . . . . . 68
172 7.5.11. temporary-auth-failure . . . . . . . . . . . . . . . 68
173 7.5.12. transition-needed . . . . . . . . . . . . . . . . . 68
174 8. Resource Binding . . . . . . . . . . . . . . . . . . . . . . 69
175 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 69
176 8.2. Advertising Support . . . . . . . . . . . . . . . . . . 69
177 8.3. Generation of Resource Identifiers . . . . . . . . . . . 70
178 8.4. Server-Generated Resource Identifier . . . . . . . . . . 71
179 8.4.1. Success Case . . . . . . . . . . . . . . . . . . . . 71
180 8.4.2. Error Case . . . . . . . . . . . . . . . . . . . . . 71
181 8.5. Client-Generated Resource Identifier . . . . . . . . . . 72
182 8.5.1. Success Case . . . . . . . . . . . . . . . . . . . . 72
183 8.5.2. Error Cases . . . . . . . . . . . . . . . . . . . . 72
184 8.5.2.1. Not Allowed . . . . . . . . . . . . . . . . . . . 73
185 8.5.2.2. Bad Request . . . . . . . . . . . . . . . . . . . 73
186 8.5.2.3. Conflict . . . . . . . . . . . . . . . . . . . . 73
187 8.6. Binding Multiple Resources . . . . . . . . . . . . . . . 74
188 8.6.1. Support . . . . . . . . . . . . . . . . . . . . . . 74
189 8.6.2. Binding an Additional Resource . . . . . . . . . . . 74
190 8.6.3. Unbinding a Resource . . . . . . . . . . . . . . . . 75
191 8.6.3.1. Success Case . . . . . . . . . . . . . . . . . . 75
192 8.6.3.2. Error Cases . . . . . . . . . . . . . . . . . . . 75
194 8.6.4. From Addresses . . . . . . . . . . . . . . . . . . . 76
195 9. XML Stanzas . . . . . . . . . . . . . . . . . . . . . . . . . 76
196 9.1. Common Attributes . . . . . . . . . . . . . . . . . . . 77
197 9.1.1. to . . . . . . . . . . . . . . . . . . . . . . . . . 77
198 9.1.1.1. Client-to-Server Streams . . . . . . . . . . . . 77
199 9.1.1.2. Server-to-Server Streams . . . . . . . . . . . . 77
200 9.1.2. from . . . . . . . . . . . . . . . . . . . . . . . . 78
201 9.1.2.1. Client-to-Server Streams . . . . . . . . . . . . 78
202 9.1.2.2. Server-to-Server Streams . . . . . . . . . . . . 79
203 9.1.3. id . . . . . . . . . . . . . . . . . . . . . . . . . 79
204 9.1.4. type . . . . . . . . . . . . . . . . . . . . . . . . 79
205 9.1.5. xml:lang . . . . . . . . . . . . . . . . . . . . . . 80
206 9.2. Basic Semantics . . . . . . . . . . . . . . . . . . . . 81
207 9.2.1. Message Semantics . . . . . . . . . . . . . . . . . 81
208 9.2.2. Presence Semantics . . . . . . . . . . . . . . . . . 81
209 9.2.3. IQ Semantics . . . . . . . . . . . . . . . . . . . . 81
210 9.3. Stanza Errors . . . . . . . . . . . . . . . . . . . . . 83
211 9.3.1. Rules . . . . . . . . . . . . . . . . . . . . . . . 83
212 9.3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . 83
213 9.3.3. Defined Conditions . . . . . . . . . . . . . . . . . 85
214 9.3.3.1. bad-request . . . . . . . . . . . . . . . . . . . 85
215 9.3.3.2. conflict . . . . . . . . . . . . . . . . . . . . 85
216 9.3.3.3. feature-not-implemented . . . . . . . . . . . . . 86
217 9.3.3.4. forbidden . . . . . . . . . . . . . . . . . . . . 86
218 9.3.3.5. gone . . . . . . . . . . . . . . . . . . . . . . 87
219 9.3.3.6. internal-server-error . . . . . . . . . . . . . . 87
220 9.3.3.7. item-not-found . . . . . . . . . . . . . . . . . 88
221 9.3.3.8. jid-malformed . . . . . . . . . . . . . . . . . . 88
222 9.3.3.9. not-acceptable . . . . . . . . . . . . . . . . . 89
223 9.3.3.10. not-allowed . . . . . . . . . . . . . . . . . . . 89
224 9.3.3.11. not-authorized . . . . . . . . . . . . . . . . . 89
225 9.3.3.12. not-modified . . . . . . . . . . . . . . . . . . 90
226 9.3.3.13. payment-required . . . . . . . . . . . . . . . . 91
227 9.3.3.14. recipient-unavailable . . . . . . . . . . . . . . 91
228 9.3.3.15. redirect . . . . . . . . . . . . . . . . . . . . 92
229 9.3.3.16. registration-required . . . . . . . . . . . . . . 92
230 9.3.3.17. remote-server-not-found . . . . . . . . . . . . . 93
231 9.3.3.18. remote-server-timeout . . . . . . . . . . . . . . 93
232 9.3.3.19. resource-constraint . . . . . . . . . . . . . . . 93
233 9.3.3.20. service-unavailable . . . . . . . . . . . . . . . 94
234 9.3.3.21. subscription-required . . . . . . . . . . . . . . 94
235 9.3.3.22. undefined-condition . . . . . . . . . . . . . . . 95
236 9.3.3.23. unexpected-request . . . . . . . . . . . . . . . 96
237 9.3.3.24. unknown-sender . . . . . . . . . . . . . . . . . 97
238 9.3.4. Application-Specific Conditions . . . . . . . . . . 97
239 9.4. Extended Content . . . . . . . . . . . . . . . . . . . . 98
240 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 99
241 10.1. Client-to-Server . . . . . . . . . . . . . . . . . . . . 99
242 10.1.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . 100
243 10.1.2. SASL . . . . . . . . . . . . . . . . . . . . . . . . 101
244 10.1.3. Resource Binding . . . . . . . . . . . . . . . . . . 102
245 10.1.4. Stanza Exchange . . . . . . . . . . . . . . . . . . 103
246 10.1.5. Close . . . . . . . . . . . . . . . . . . . . . . . 104
247 10.2. Server-to-Server Examples . . . . . . . . . . . . . . . 104
248 10.2.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . 104
249 10.2.2. SASL . . . . . . . . . . . . . . . . . . . . . . . . 106
250 10.2.3. Stanza Exchange . . . . . . . . . . . . . . . . . . 107
251 10.2.4. Close . . . . . . . . . . . . . . . . . . . . . . . 108
252 11. Server Rules for Processing XML Stanzas . . . . . . . . . . . 108
253 11.1. No 'to' Address . . . . . . . . . . . . . . . . . . . . 108
254 11.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 108
255 11.1.2. Message . . . . . . . . . . . . . . . . . . . . . . 109
256 11.1.3. Presence . . . . . . . . . . . . . . . . . . . . . . 109
257 11.1.4. IQ . . . . . . . . . . . . . . . . . . . . . . . . . 109
258 11.2. Local Domain . . . . . . . . . . . . . . . . . . . . . . 109
259 11.2.1. Mere Domain . . . . . . . . . . . . . . . . . . . . 110
260 11.2.2. Resource at Domain . . . . . . . . . . . . . . . . . 110
261 11.2.3. Node at Domain . . . . . . . . . . . . . . . . . . . 110
262 11.3. Foreign Domain . . . . . . . . . . . . . . . . . . . . . 110
263 11.3.1. Existing Stream . . . . . . . . . . . . . . . . . . 111
264 11.3.2. No Existing Stream . . . . . . . . . . . . . . . . . 111
265 11.3.3. Error Handling . . . . . . . . . . . . . . . . . . . 111
266 12. XML Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 111
267 12.1. Restrictions . . . . . . . . . . . . . . . . . . . . . . 111
268 12.2. XML Namespace Names and Prefixes . . . . . . . . . . . . 112
269 12.2.1. Streams Namespace . . . . . . . . . . . . . . . . . 112
270 12.2.2. Default Namespace . . . . . . . . . . . . . . . . . 113
271 12.2.3. Extended Namespaces . . . . . . . . . . . . . . . . 114
272 12.3. Well-Formedness . . . . . . . . . . . . . . . . . . . . 115
273 12.4. Validation . . . . . . . . . . . . . . . . . . . . . . . 115
274 12.5. Inclusion of Text Declaration . . . . . . . . . . . . . 115
275 12.6. Character Encoding . . . . . . . . . . . . . . . . . . . 116
276 12.7. White Space . . . . . . . . . . . . . . . . . . . . . . 116
277 13. Compliance Requirements . . . . . . . . . . . . . . . . . . . 116
278 13.1. Servers . . . . . . . . . . . . . . . . . . . . . . . . 116
279 13.2. Clients . . . . . . . . . . . . . . . . . . . . . . . . 117
280 14. Internationalization Considerations . . . . . . . . . . . . . 117
281 15. Security Considerations . . . . . . . . . . . . . . . . . . . 118
282 15.1. High Security . . . . . . . . . . . . . . . . . . . . . 118
283 15.2. Certificates . . . . . . . . . . . . . . . . . . . . . . 118
284 15.2.1. Certificate Generation . . . . . . . . . . . . . . . 118
285 15.2.1.1. Server Certificates . . . . . . . . . . . . . . . 118
286 15.2.1.2. Client Certificates . . . . . . . . . . . . . . . 120
287 15.2.1.3. ASN.1 Object Identifier . . . . . . . . . . . . . 121
288 15.2.2. Certificate Validation . . . . . . . . . . . . . . . 121
289 15.2.2.1. Server Certificates . . . . . . . . . . . . . . . 121
290 15.2.2.2. Client Certificates . . . . . . . . . . . . . . . 123
291 15.3. Client-to-Server Communication . . . . . . . . . . . . . 124
292 15.4. Server-to-Server Communication . . . . . . . . . . . . . 124
293 15.5. Order of Layers . . . . . . . . . . . . . . . . . . . . 125
294 15.6. Lack of SASL Channel Binding to TLS . . . . . . . . . . 125
295 15.7. Mandatory-to-Implement Technologies . . . . . . . . . . 126
296 15.8. Firewalls . . . . . . . . . . . . . . . . . . . . . . . 126
297 15.9. Use of base64 in SASL . . . . . . . . . . . . . . . . . 126
298 15.10. Stringprep Profiles . . . . . . . . . . . . . . . . . . 127
299 15.11. Address Spoofing . . . . . . . . . . . . . . . . . . . . 127
300 15.11.1. Address Forging . . . . . . . . . . . . . . . . . . 128
301 15.11.2. Address Mimicking . . . . . . . . . . . . . . . . . 128
302 15.12. Denial of Service . . . . . . . . . . . . . . . . . . . 129
303 15.13. Presence Leaks . . . . . . . . . . . . . . . . . . . . . 131
304 15.14. Directory Harvesting . . . . . . . . . . . . . . . . . . 131
305 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 131
306 16.1. XML Namespace Name for TLS Data . . . . . . . . . . . . 131
307 16.2. XML Namespace Name for SASL Data . . . . . . . . . . . . 131
308 16.3. XML Namespace Name for Stream Errors . . . . . . . . . . 132
309 16.4. XML Namespace Name for Resource Binding . . . . . . . . 132
310 16.5. XML Namespace Name for Stanza Errors . . . . . . . . . . 132
311 16.6. Nodeprep Profile of Stringprep . . . . . . . . . . . . . 133
312 16.7. Resourceprep Profile of Stringprep . . . . . . . . . . . 133
313 16.8. GSSAPI Service Name . . . . . . . . . . . . . . . . . . 133
314 16.9. Port Numbers . . . . . . . . . . . . . . . . . . . . . . 133
315 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 134
316 17.1. Normative References . . . . . . . . . . . . . . . . . . 134
317 17.2. Informative References . . . . . . . . . . . . . . . . . 136
318 Appendix A. Nodeprep . . . . . . . . . . . . . . . . . . . . . . 139
319 A.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 139
320 A.2. Character Repertoire . . . . . . . . . . . . . . . . . . 140
321 A.3. Mapping . . . . . . . . . . . . . . . . . . . . . . . . 140
322 A.4. Normalization . . . . . . . . . . . . . . . . . . . . . 140
323 A.5. Prohibited Output . . . . . . . . . . . . . . . . . . . 140
324 A.6. Bidirectional Characters . . . . . . . . . . . . . . . . 141
325 Appendix B. Resourceprep . . . . . . . . . . . . . . . . . . . . 141
326 B.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 141
327 B.2. Character Repertoire . . . . . . . . . . . . . . . . . . 142
328 B.3. Mapping . . . . . . . . . . . . . . . . . . . . . . . . 142
329 B.4. Normalization . . . . . . . . . . . . . . . . . . . . . 142
330 B.5. Prohibited Output . . . . . . . . . . . . . . . . . . . 142
331 B.6. Bidirectional Characters . . . . . . . . . . . . . . . . 142
332 Appendix C. XML Schemas . . . . . . . . . . . . . . . . . . . . 143
333 C.1. Streams namespace . . . . . . . . . . . . . . . . . . . 143
334 C.2. Stream error namespace . . . . . . . . . . . . . . . . . 144
335 C.3. STARTTLS namespace . . . . . . . . . . . . . . . . . . . 147
336 C.4. SASL namespace . . . . . . . . . . . . . . . . . . . . . 147
337 C.5. Resource binding namespace . . . . . . . . . . . . . . . 149
338 C.6. Stanza error namespace . . . . . . . . . . . . . . . . . 151
339 Appendix D. Contact Addresses . . . . . . . . . . . . . . . . . 152
340 Appendix E. Account Provisioning . . . . . . . . . . . . . . . . 153
341 Appendix F. Differences From RFC 3920 . . . . . . . . . . . . . 153
342 Appendix G. Copying Conditions . . . . . . . . . . . . . . . . . 154
343 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
344 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 155
345 Intellectual Property and Copyright Statements . . . . . . . . . 156
347 1. Introduction
349 1.1. Overview
351 The Extensible Messaging and Presence Protocol (XMPP) is an
352 application profile of the Extensible Markup Language [XML] for
353 streaming XML data in close to real time between any two (or more)
354 network-aware entities. XMPP is typically used to exchange messages,
355 share presence information, and engage in structured request-response
356 interactions. The basic syntax and semantics of XMPP were developed
357 originally within the Jabber open-source community, mainly in 1999.
358 In late 2002, the XMPP Working Group was chartered with developing an
359 adaptation of the core Jabber protocol that would be suitable as an
360 IETF instant messaging (IM) and presence technology. As a result of
361 work by the XMPP WG, [RFC3920] and [RFC3921] were published in
362 October 2004, representing the most complete definition of XMPP at
363 that time.
365 As a result of extensive implementation and deployment experience
366 with XMPP since 2004, as well as more formal interoperability testing
367 carried out under the auspices of the XMPP Standards Foundation
368 (XSF), this document reflects consensus from the XMPP developer
369 community regarding XMPP's core XML streaming technology. In
370 particular, this document incorporates the following backward-
371 compatible changes from RFC 3920:
373 o Corrections and errata
374 o Additional examples throughout
375 o Clarifications and more complete specification of matters that
376 were underspecified
377 o Modifications to reflect updated technologies for which XMPP is a
378 using protocol, e.g., Transport Layer Security (TLS) and the
379 Simple Authentication and Security Layer (SASL)
380 o Definition of several additional stream, stanza, and SASL error
381 conditions
382 o Addition of TLS plus the SASL PLAIN mechanism [PLAIN] as a
383 mandatory-to-implement technology
384 o Definition of optional support for multiple resources over the
385 same connection
386 o Removal of historical documentation for the server dialback
387 protocol from this specification to a separate specification
389 Therefore, this document defines the core features of XMPP 1.0 and
390 obsoletes RFC 3920.
392 Note: The XMPP extensions required to provide the basic instant
393 messaging and presence functionality defined in [IMP-REQS] are
394 specified in [XMPP-IM].
396 1.2. Functional Summary
398 This non-normative section provides a developer-friendly, functional
399 summary of XMPP; refer to the sections that follow for a normative
400 definition of XMPP.
402 The purpose of XMPP is to enable the exchange of relatively small
403 pieces of structured data (called "XML stanzas") over a network
404 between any two (or more) entities. XMPP is implemented using a
405 client-server architecture, wherein a client must connect to a server
406 in order to gain access to the network and thus be allowed to
407 exchange XML stanzas with other entities. The process whereby a
408 client connects to a server, exchanges XML stanzas, and ends the
409 connection is:
411 1. Determine the hostname and port at which to connect
412 2. Open a TCP connection
413 3. Open an XML stream
414 4. Complete TLS negotiation for channel encryption (recommended)
415 5. Complete SASL negotiation for authentication
416 6. Bind a resource to the stream
417 7. Exchange an unbounded number of XML stanzas with other entities
418 on the network
419 8. Close the XML stream
420 9. Close the TCP connection
422 In the sections following discussion of XMPP architecture and XMPP
423 addresses, this document specifies how clients connect to servers and
424 specifies the basic semantics of XML stanzas. However, this document
425 does not define the "payloads" of the XML stanzas that might be
426 exchanged once a connection is successfully established; instead,
427 definition of such semantics is provided by XMPP extensionsl. For
428 example, [XMPP-IM] defines extensions for basic instant messaging and
429 presence functionality. In addition, various specifications produced
430 in the XSF's XEP series [XEP-0001] define extensions for a wide range
431 of more advanced functionality.
433 Within the client-server architecture used by XMPP, one server may
434 optionally connect to another server to enable inter-domain or inter-
435 server communication. For this to happen, the two servers must
436 negotiate a connection between themselves and then exchange XML
437 stanzas; the process for doing so is:
439 1. Determine the hostname and port at which to connect
440 2. Open a TCP connection
441 3. Open an XML stream
442 4. Complete TLS negotiation for channel encryption (recommended)
443 5. Complete SASL negotiation for authentication
444 6. Exchange an unbounded number of XML stanzas both directly for the
445 servers and indirectly on behalf of entities associated with each
446 server (e.g., connected clients)
447 7. Close the XML stream
448 8. Close the TCP connection
450 Note: Depending on local service policies, a service may wish to use
451 the older server dialback protocol to provide weak identity
452 verification in cases where SASL negotiation would not result in
453 strong authentication (e.g., because the certificate presented by the
454 peer service during TLS negotiation is self-signed and thus provides
455 only weak identity); for details, see [XEP-0220].
457 1.3. Conventions
459 The following keywords are to be interpreted as described in [TERMS]:
460 "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD",
461 "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".
463 In examples, lines have been wrapped for improved readability,
464 "[...]" means elision, and the following prepended strings are used:
466 o C: = client
467 o E: = any XMPP entity
468 o I: = initiating entity
469 o P: = peer server
470 o R: = receiving entity
471 o S: = server
472 o S1: = server1
473 o S2: = server2
475 1.4. Discussion Venue
477 The editor welcomes discussion and comments related to the topics
478 presented in this document. The preferred forum is the
479 mailing list, for which archives and
480 subscription information are available at
481 <>.
483 2. Architecture
485 2.1. Overview
487 XMPP assumes a client-server architecture, wherein a client utilizing
488 XMPP accesses a server (normally over a [TCP] connection) and servers
489 can also communicate with each other over TCP connections.
491 A simplified architectural diagram for a typical deployment is shown
492 here, where the entities have the following significance:
494 o romeo@example.net -- an XMPP user.
495 o example.net -- an XMPP server.
496 o im.example.com -- an XMPP server.
497 o juliet@im.example.com -- an XMPP user.
499 example.net ---------------- im.example.com
500 | |
501 | |
502 romeo@example.net juliet@im.example.com
504 Note: Architectures that employ the syntax of XML stanzas (Section 9)
505 but that establish peer-to-peer connections directly between clients
506 using technologies based on [LINKLOCAL] have been deployed, but such
507 architectures are not XMPP and are best described as "XMPP-like"; for
508 details, see [XEP-0174].
510 2.2. Server
512 A SERVER is an entity whose primary responsibilities are to:
514 o Manage XML streams (Section 5) with local clients and deliver XML
515 stanzas (Section 9) to those clients over the negotiated XML
516 streams.
517 o Subject to local service policies on server-to-server
518 communication, manage XML streams (Section 5) with foreign servers
519 and route XML stanzas (Section 9) to those servers over the
520 negotiated XML streams.
522 Depending on the application, the secondary responsibilities of an
523 XMPP server may include:
525 o Storing XML data that is used by clients (e.g., contact lists for
526 users of XMPP-based instant messaging and presence applications);
527 in this case, the relevant XML stanza is handled directly by the
528 server itself on behalf of the client and is not routed to a
529 foreign server or delivered to a local entity.
530 o Hosting local services that also use XMPP as the basis for
531 communication but that provide additional functionality beyond
532 that defined in this document or in [XMPP-IM]; examples include
533 multi-user conferencing services as specified in [XEP-0045] and
534 publish-subscribe services as specified in [XEP-0060].
536 2.3. Client
538 A CLIENT is an entity that establiishes an XML stream with a server
539 by authenticating using the credentials of a local account and that
540 then completes resource binding (Section 8) in order to enable
541 delivery of XML stanzas via the server to the client. A client then
542 uses XMPP to communicate with its server, other clients, and any
543 other accessible entities on a network. Multiple clients may connect
544 simultaneously to a server on behalf of a local account, where each
545 client is differentiated by the resource identifier portion of an
546 XMPP address (e.g., vs. ), as
547 defined under Section 3 and Section 8. The RECOMMENDED port for TCP
548 connections between a client and a server is 5222, as registered with
549 the IANA (see Section 16.9).
551 2.4. Network
553 Because each server is identified by a network address and because
554 server-to-server communication is a straightforward extension of the
555 client-to-server protocol, in practice the system consists of a
556 network of servers that inter-communicate. Thus, for example,
557 is able to exchange messages, presence, and
558 other information with . This pattern is familiar
559 from messaging protocols (such as [SMTP]) that make use of network
560 addressing standards. Communication between any two servers is
561 OPTIONAL. If enabled, such communication SHOULD occur over XML
562 streams that are bound to [TCP] connections. The RECOMMENDED port
563 for TCP connections between servers is 5269, as registered with the
564 IANA (see Section 16.9).
566 3. Addresses
568 3.1. Overview
570 An ENTITY is anything that is network-addressable and that can
571 communicate using XMPP. For historical reasons, the native address
572 of an XMPP entity is called a JABBER IDENTIFIER or JID. A valid JID
573 contains a set of ordered elements formed of an XMPP domain
574 identifier, node identifier, and resource identifier.
576 The syntax for a JID is defined as follows using the Augmented
577 Backus-Naur Form as specified in [ABNF].
579 jid = [ node "@" ] domain [ "/" resource ]
580 node = 1*(nodepoint)
581 ; a "nodepoint" is a UTF-8 encoded Unicode code
582 ; point that satisfies the Nodeprep profile of
583 ; stringprep
584 domain = fqdn / address-literal / idnlabel
585 fqdn = (idnlabel 1*("." idnlabel))
586 ; an "idnlabel" is an internationalized label
587 ; as described in RFC 3490
588 address-literal = IPv4address / IPv6address
589 ; the "IPv4address" and "IPv6address" rules are
590 ; defined in Appendix B of RFC 2373
591 resource = 1*(resourcepoint)
592 ; a "resourcepoint" is a UTF-8 encoded Unicode
593 ; code point that satisfies the Resourceprep
594 ; profile of stringprep
596 Note: The "IPv4address" and "IPv6address" rules are indeed provided
597 in [RFC2373] and were removed from [IPv6], which supersedes RFC 2373.
599 All JIDs are based on the foregoing structure. One common use of
600 this structure is to identify a messaging and presence account, the
601 server that hosts the account, and a connected resource (e.g., a
602 specific device) in the form of . However,
603 node types other than clients are possible; for example, a specific
604 chat room offered by a multi-user conference service (see [XEP-0045])
605 could be addressed as (where "room" is the name of the
606 chat room and "service" is the hostname of the multi-user conference
607 service) and a specific occupant of such a room could be addressed as
608 (where "nick" is the occupant's room nickname).
609 Many other JID types are possible (e.g., could be a
610 server-side script or service).
612 Each allowable portion of a JID (node identifier, domain identifier,
613 and resource identifier) MUST NOT be more than 1023 bytes in length,
614 resulting in a maximum total size (including the '@' and '/'
615 separators) of 3071 bytes.
617 Note: While the format of a JID is consistent with [URI], an entity's
618 address on an XMPP network MUST be a JID (without a URI scheme) and
619 not a [URI] or [IRI] as specified in [XMPP-URI]; the latter
620 specification is provided only for use by non-XMPP applications.
622 3.2. Domain Identifier
624 The DOMAIN IDENTIFIER portion of a JID is that portion after the '@'
625 character (if any) and before the '/' character (if any); it is the
626 primary identifier and is the only REQUIRED element of a JID (a mere
627 domain identifier is a valid JID). Typically a domain identifier
628 identifies the "home" server to which clients connect for XML routing
629 and data management functionality. (Note: A single server may
630 service multiple domain identifiers, i.e., multiple local domains.)
631 However, it is not necessary for an XMPP domain identifier to
632 identify an entity that provides core XMPP server functionality
633 (e.g., a domain identifier may identity an entity such as a multi-
634 user conference service, a publish-subscribe service, or a user
635 directory).
637 The domain identifier for every server or service that will
638 communicate over a network SHOULD be a fully qualified domain name
639 (see [DNS]); while the domain identifier MAY be either an Internet
640 Protocol (IPv4 or IPv6) address or a text label (commonly called an
641 "unqualified hostname") that is resolvable on a local network, domain
642 identifiers that are IP addresses may not be acceptable to other
643 services for the sake of interdomain communication and domain
644 identifiers that are text labels MUST NOT be used on public networks.
645 If the domain identifier includes a final character considered to be
646 a label separator (dot) by [IDNA] or [STD13], this character MUST be
647 stripped from the domain identifier before the JID of which it is a
648 part is used for the purpose of routing an XML stanza, comparing
649 against another JID, or constructing an [XMPP-URI]; in particular,
650 the character should be stripped before any other canonicalization
651 steps are taken (such as application of the [NAMEPREP] profile of
652 [STRINGPREP] or completion of the ToASCII operation as described in
653 [IDNA]).
655 A domain identifier MUST be an "internationalized domain name" as
656 defined in [IDNA], that is, "a domain name in which every label is an
657 internationalized label". When preparing a text label (consisting of
658 a sequence of Unicode code points) for representation as an
659 internationalized label in the process of constructing an XMPP domain
660 identifier or comparing two XMPP domain identifiers, an application
661 MUST ensure that for each text label it is possible to apply without
662 failing the ToASCII operation specified in [IDNA] with the
663 UseSTD3ASCIIRules flag set (thus forbidding ASCII code points other
664 than letters, digits, and hyphens). If the ToASCII operation can be
665 applied without failing, then the label is an internationalized
666 label. An internationalized domain name (and therefore an XMPP
667 domain identifier) is constructed from its constituent
668 internationalized labels by following the rules specified in [IDNA].
669 (Note: The ToASCII operation includes application of the [NAMEPREP]
670 profile of [STRINGPREP] and encoding using the algorithm specified in
671 [PUNYCODE]; for details, see [IDNA].)
673 3.3. Node Identifier
675 The NODE IDENTIFIER portion of a JID is an optional secondary
676 identifier placed before the domain identifier and separated from the
677 latter by the '@' character. Typically a node identifier uniquely
678 identifies the entity requesting and using network access provided by
679 a server (i.e., a local account), although it can also represent
680 other kinds of entities (e.g., a chat room associated with a multi-
681 user conference service). The entity represented by an XMPP node
682 identifier is addressed within the context of a specific domain.
683 When the domain is an XMPP server and the entity is a local account
684 on the server, the resulting address (of the form ) is
685 called a BARE JID.
687 A node identifier MUST be formatted such that the Nodeprep profile of
688 [STRINGPREP] can be applied without failing (see Appendix A). Before
689 comparing two node identifiers, an application MUST first apply the
690 Nodeprep profile to each identifier.
692 Note: Because the additional characters prohibited by Nodeprep (see
693 Appendix A) are prohibited after normalization, an implementation
694 should not enable a human user to input any Unicode code point whose
695 decomposition includes those characters; such code points include but
696 are not necessarily limited to the following (refer to [UNICODE] for
697 further information).
699 o 2100 (ACCOUNT OF)
700 o 2101 (ADDRESSED TO THE SUBJECT)
701 o 2105 (CARE OF)
702 o 2106 (CADA UNA)
703 o 226E (NOT LESS-THAN)
704 o 226F (NOT GREATER-THAN)
705 o 2A74 (DOUBLE COLON EQUAL)
706 o FE13 (SMALL COLON)
707 o FE60 (SMALL AMPERSAND)
708 o FE64 (SMALL LESS-THAN SIGN)
709 o FE65 (SMALL GREATER-THAN SIGN)
710 o FE6B (SMALL COMMERCIAL AT)
711 o FF02 (FULLWIDTH QUOTATION MARK)
712 o FF06 (FULLWIDTH AMPERSAND)
713 o FF07 (FULLWIDTH APOSTROPHE)
714 o FF0F (FULLWIDTH SOLIDUS)
715 o FF1A (FULLWIDTH COLON)
716 o FF1C (FULLWIDTH LESS-THAN SIGN)
717 o FF1E (FULLWIDTH GREATER-THAN SIGN)
718 o FF20 (FULLWIDTH COMMERCIAL AT)
720 3.4. Resource Identifier
722 The RESOURCE IDENTIFIER portion of a JID is an optional tertiary
723 identifier placed after the domain identifier and separated from the
724 latter by the '/' character. A resource identifier may modify either
725 a address or a mere address. Typically a
726 resource identifier uniquely identifies a specific connection (e.g.,
727 a device or location) or object (e.g., a participant in a multi-user
728 conference room) belonging to the entity associated with an XMPP node
729 identifier at a local domain. XMPP entities SHOULD consider resource
730 identifiers to be opaque strings and SHOULD NOT impute meaning to any
731 given resource identifier. A resource identifier is negotiated
732 between a client and a server during resource binding (Section 8),
733 after which the entity is referred to as a CONNECTED RESOURCE and its
734 address (of the form ) is referred to as a FULL
735 JID. An entity MAY maintain multiple connected resources
736 simultaneously, with each connected resource differentiated by a
737 distinct resource identifier.
739 A resource identifier MUST be formatted such that the Resourceprep
740 profile of [STRINGPREP] can be applied without failing (see
741 Appendix B). Before comparing two resource identifiers, an
742 application MUST first apply the Resourceprep profile to each
743 identifier.
745 3.5. Determination of Addresses
747 After SASL negotiation (Section 7) and, if appropriate, resource
748 binding (Section 8), the receiving entity for a stream MUST determine
749 the initiating entity's JID.
751 For server-to-server communication, the initiating entity's JID
752 SHOULD be the authorization identity (as defined by [SASL]), either
753 (1) as directly communicated by the initiating entity during SASL
754 negotiation (Section 7) or (2) as derived from the authentication
755 identity if no authorization identity was specified during SASL
756 negotiation (Section 7).
758 For client-to-server communication, the client's bare JID
759 () SHOULD be the authorization identity (as defined by
760 [SASL]), either (1) as directly communicated by the initiating entity
761 during SASL negotiation (Section 7) or (2) as derived from the
762 authentication identity if no authorization identity was specified
763 during SASL negotiation (Section 7). The resource identifier portion
764 of the full JID () SHOULD be the resource
765 identifier negotiated by the client and server during resource
766 binding (Section 8).
768 The receiving entity MUST ensure that the resulting JID (including
769 node identifier, domain identifier, resource identifier, and
770 separator characters) conforms to the rules and formats defined
771 earlier in this section; to meet this restriction, the receiving
772 entity may need to replace the JID sent by the initiating entity with
773 the canonicalized JID as determined by the receiving entity.
775 4. TCP Binding
777 4.1. Scope
779 As XMPP is defined in this specification, an initiating entity
780 (client or server) MUST open a Transmission Control Protocol [TCP]
781 connection at the receiving entity (server) before it negotiates XML
782 streams with the receiving entity. The rules specified in the
783 following sections apply to the TCP binding.
785 4.2. Hostname Resolution
787 Before opening the TCP connection, the initiating entity first MUST
788 resolve the Domain Name System (DNS) hostname associated with the
789 receiving entity and determine the appropriate TCP port for
790 communication with the receiving entity. The process is:
792 1. Attempt to resolve the hostname using a [DNS-SRV] Service of
793 "xmpp-client" (for client-to-server connections) or "xmpp-server"
794 (for server-to-server connections) and Proto of "tcp", resulting
795 in resource records such as "_xmpp-client._tcp.xmpp.example.net."
796 or "_xmpp-server._tcp.im.example.com.". The result of the SRV
797 lookup will be one or more combinations of a port and hostname;
798 the initiating entity MUST resolve one of the hostnames in order
799 to determine an IP address at which to connect.
800 2. If the SRV lookup fails, the fallback SHOULD be a normal IPv4 or
801 [IPv6] address record resolution to determine the IP address,
802 where the port used is the "xmpp-client" port of 5222 for client-
803 to-server connections or the "xmpp-server" port 5269 for server-
804 to-server connections.
805 3. For client-to-server connections, the fallback MAY be a [DNS-TXT]
806 lookup for alternative connection methods, for example as
807 described in [XEP-0156].
809 Note: Many XMPP servers are implemented in such a way that they can
810 host additional services (byond those defined in this specification
811 and [XMPP-IM]) at hostnames that are subdomains of the hostname of
812 the main XMPP service (e.g., conference.example.net for a [XEP-0045]
813 service associated with the example.net XMPP service) or subdomains
814 of the first-level domain of the underlying host (e.g.,
815 muc.example.com for a [XEP-0045] service associated with the
816 im.example.com XMPP service). If an entity from a remote domain
817 wishes to use such additional services, it would generate an
818 appropriate XML stanza and the remote domain itself would attempt to
819 resolve the service's hostname via an SRV lookup on resource records
820 such as "_xmpp-server._tcp.conference.example.net." or "_xmpp-
821 server._tcp.muc.example.com.". Therefore if a service wishes to
822 enable entities from remote domains to acess these additional
823 services it should advertise the appropriate "_xmpp-server" SRV
824 records in addition to the "_xmpp-server" record for its main XMPP
825 service.
827 4.3. Client-to-Server Communications
829 Because a client is subordinate to a server and therefore a client
830 authenticates to the server but the server does not authenticate to
831 the client, it is necessary to have only one TCP connection between
832 client and server. Thus the server MUST allow the client to share a
833 single TCP connection for XML stanzas sent from client to server and
834 from server to client (i.e., the inital stream and response stream as
835 specified under Section 5).
837 4.4. Server-to-Server Communications
839 Because two servers are peers and therefore each peer must
840 authenticate with the other, the servers MUST use two TCP
841 connections: one for XML stanzas sent from the first server to the
842 second server and another (initiated by the second server) for XML
843 stanzas from the second server to the first server.
845 This rule applies only to XML stanzas (Section 9). Therefore during
846 STARTTLS negotiation (Section 6) and SASL negotiation (Section 7) the
847 servers would use one TCP connection, but after stream setup that TCP
848 connection would be used only for the initiating server to send XML
849 stanzas to the receiving server. In order for the receiving server
850 to send XML stanzas to the initiating server, the receiving server
851 would need to reverse the roles and negotiate an XML stream from the
852 receiving server to the initiating server.
854 4.5. Reconnection
856 It can happen that an XMPP server goes offline while servicing TCP
857 connections from local clients and from other servers. Because the
858 number of such connections can be quite large, the reconnection
859 algorithm employed by entities that seek to reconnect can have a
860 significant impact on software and network performance. The
861 following guidelines are RECOMMENDED:
863 o The time to live (TTL) specified in Domain Name System records
864 SHOULD be honored, even if DNS results are cached; if the TTL has
865 not expired, an entity that seeks to reconnect SHOULD NOT re-
866 resolve the server hostname before reconnecting.
867 o The time that expires before an entity first seeks to reconnect
868 SHOULD be randomized (e.g., so that all clients do not attempt to
869 reconnect 30 seconds after being disconnected).
870 o If the first reconnection attempt does not succeed, an entity
871 SHOULD back off exponentially on the time between subsequent
872 reconnection attempts.
874 4.6. Other Bindings
876 There is no necessary coupling of an XML stream to a TCP connection.
877 For example, two entities could connect to each other via another
878 transport, such as [HTTP] as specified in [XEP-0124] and [XEP-0206].
879 However, this specification defines a binding of XMPP to TCP only.
881 5. XML Streams
883 5.1. Overview
885 Two fundamental concepts make possible the rapid, asynchronous
886 exchange of relatively small payloads of structured information
887 between presence-aware entities: XML streams and XML stanzas. These
888 terms are defined as follows.
890 Definition of XML Stream: An XML STREAM is a container for the
891 exchange of XML elements between any two entities over a network.
892 The start of an XML stream is denoted unambiguously by an opening
893 STREAM HEADER (i.e., an XML tag with appropriate
894 attributes and namespace declarations), while the end of the XML
895 stream is denoted unambiguously by a closing XML tag.
896 During the life of the stream, the entity that initiated it can
897 send an unbounded number of XML elements over the stream, either
898 elements used to negotiate the stream (e.g., to complete TLS
899 negotiation (Section 6) or SASL negotiation (Section 7)) or XML
900 stanzas. The INITIAL STREAM is negotiated from the initiating
901 entity (typically a client or server) to the receiving entity
902 (typically a server), and can be seen as corresponding to the
903 initiating entity's "connection" or "session" with the receiving
904 entity. The initial stream enables unidirectional communication
905 from the initiating entity to the receiving entity; in order to
906 enable information exchange from the receiving entity to the
907 initiating entity, the receiving entity MUST negotiate a stream in
908 the opposite direction (the RESPONSE STREAM).
910 Definition of XML Stanza: An XML STANZA is a discrete semantic unit
911 of structured information that is sent from one entity to another
912 over an XML stream. An XML stanza is the basic unit of meaning in
913 XMPP. An XML stanza exists at the direct child level of the root
914 ), and the end of any XML stanza
918 is denoted unambiguously by the corresponding close tag at depth=1
919 (e.g., ); a server MUST NOT process a partial stanza
920 and MUST NOT attach meaning to the transmission timing of any part
921 of a stanza (before receipt of the close tag). The only XML
922 stanzas defined herein are the |
951 |--------------------|
952 | |
953 | |
955 |--------------------|
956 | |
957 | |
958 | |
959 |--------------------|
960 | |
961 | |
963 |--------------------|
964 | |
965 | |
967 |--------------------|
968 | [ ... ] |
969 |--------------------|
970 | |
971 +--------------------+
973 Note: Those who are accustomed to thinking of XML in a document-
974 centric manner may wish to view a client's connection to a server as
975 consisting of two open-ended XML documents: one from the client to
976 the server and one from the server to the client. From this
977 perspective, the root ) of the entity
1016 controlling the client.
1018 C:
1019
1027 In server-to-server communication, the 'from' attribute SHOULD be
1028 included in the initial stream header and (if included) MUST be set
1029 to a hostname serviced by the initiating entity.
1031 P:
1032
1040 In both client-to-server and server-to-server communications, the
1041 'from' attribute MUST be included in the response stream header and
1042 MUST be set to a hostname serviced by the receiving entity that is
1043 granting access to the initiating entity.
1045 S:
1046
1055 Note: Each entity MUST verify the identity of the other entity before
1056 exchanging XML stanzas with it (see Section 15.3 and Section 15.4).
1058 5.3.2. to
1060 In both client-to-server and server-to-server communications, the
1061 'to' attribute SHOULD be included in the initial stream header and
1062 (if included) MUST be set to a hostname serviced by the receiving
1063 entity.
1065 C:
1066
1074 In client-to-server communication, if the client included a 'from'
1075 address in the initial stream header then the server SHOULD include a
1076 'to' attribute in the response stream header and (if included) MUST
1077 set the 'to' attribute to the bare JID specified in the 'from'
1078 attribute of the initial stream header.
1080 S:
1081
1090 In server-to-server communication, if the initiating entity included
1091 a 'from' address in the initial stream header then the receiving
1092 entity SHOULD include a 'to' attribute in the response stream header
1093 and (if included) MUST set the 'to' attribute to the hostname
1094 specified in the 'from' attribute of the initial stream header.
1096 S:
1097
1106 Note: Each entity MUST verify the identity of the other entity before
1107 exchanging XML stanzas with it (see Section 15.3 and Section 15.4).
1109 5.3.3. id
1111 There SHOULD NOT be an 'id' attribute in the initial stream header;
1112 however, if an 'id' attribute is included, it SHOULD be silently
1113 ignored by the receiving entity.
1115 C:
1116
1124 The 'id' attribute MUST be included in the response XML stream
1125 header. This attribute is a unique identifier created by the
1126 receiving entity to function as a identifier for the initiating
1127 entity's two streams with the receiving entity, and MUST be unique
1128 within the receiving application (normally a server).
1130 S:
1131
1140 Note: The stream ID may be security-critical and therefore MUST be
1141 both unpredictable and nonrepeating (see [RANDOM] for recommendations
1142 regarding randomness for security purposes).
1144 5.3.4. xml:lang
1146 An 'xml:lang' attribute (as defined in Section 2.12 of [XML]) SHOULD
1147 be included in the initial stream header to specify the default
1148 language of any human-readable XML character data it sends over that
1149 stream.
1151 C:
1152
1160 If the attribute is included, the receiving entity SHOULD remember
1161 that value as the default for both the initial stream and the
1162 response stream; if the attribute is not included, the receiving
1163 entity SHOULD use a configurable default value for both streams,
1164 which it MUST communicate in the response stream header.
1166 S:
1167
1176 For all stanzas sent over the initial stream, if the initiating
1177 entity does not include an 'xml:lang' attribute, the receiving entity
1178 SHOULD apply the default value; if the initiating entity does include
1179 an 'xml:lang' attribute, the receiving entity MUST NOT modify or
1180 delete it (see also Section 9.1.5). The value of the 'xml:lang'
1181 attribute MUST conform to the NMTOKEN datatype (as defined in Section
1182 2.3 of [XML]) and MUST conform to the format defined in [LANGTAGS].
1184 5.3.5. version
1186 The presence of the version attribute set to a value of at least
1187 "1.0" signals support for the stream-related protocols (including
1188 stream features) defined in this specification.
1190 The version of XMPP specified herein is "1.0"; in particular, XMPP
1191 1.0 encapsulates the stream-related protocols (TLS negotiation
1192 (Section 6), SASL negotiation (Section 7), and stream errors
1193 (Section 5.7)), as well as the basic semantics of the three defined
1194 XML stanza types (.". The
1197 major and minor numbers MUST be treated as separate integers and each
1198 number MAY be incremented higher than a single digit. Thus, "XMPP
1199 2.4" would be a lower version than "XMPP 2.13", which in turn would
1200 be lower than "XMPP 12.3". Leading zeros (e.g., "XMPP 6.01") MUST be
1201 ignored by recipients and MUST NOT be sent.
1203 The major version number should be incremented only if the stream and
1204 stanza formats or required actions have changed so dramatically that
1205 an older version entity would not be able to interoperate with a
1206 newer version entity if it simply ignored the elements and attributes
1207 it did not understand and took the actions specified in the older
1208 specification.
1210 The minor version number should be incremented only if significant
1211 new capabilities have been added to the core protocol (e.g., a newly
1212 defined value of the 'type' attribute for message, presence, or IQ
1213 stanzas). The minor version number MUST be ignored by an entity with
1214 a smaller minor version number, but MAY be used for informational
1215 purposes by the entity with the larger minor version number (e.g.,
1216 the entity with the larger minor version number would simply note
1217 that its correspondent would not be able to understand that value of
1218 the 'type' attribute and therefore would not send it).
1220 The following rules apply to the generation and handling of the
1221 'version' attribute within stream headers:
1223 1. The initiating entity MUST set the value of the 'version'
1224 attribute in the initial stream header to the highest version
1225 number it supports (e.g., if the highest version number it
1226 supports is that defined in this specification, it MUST set the
1227 value to "1.0").
1228 2. The receiving entity MUST set the value of the 'version'
1229 attribute in the response stream header to either the value
1230 supplied by the initiating entity or the highest version number
1231 supported by the receiving entity, whichever is lower. The
1232 receiving entity MUST perform a numeric comparison on the major
1233 and minor version numbers, not a string match on
1234 ".".
1235 3. If the version number included in the response stream header is
1236 at least one major version lower than the version number included
1237 in the initial stream header and newer version entities cannot
1238 interoperate with older version entities as described, the
1239 initiating entity SHOULD generate an
1292 S:
1293
1294
1296
1298 Stream features are used mainly to advertise TLS negotiation
1299 (Section 6), SASL negotiation (Section 7), and resource binding
1300 (Section 8); however, stream features also can be used to advertise
1301 features associated with various XMPP extensions. If an entity does
1302 not understand or support a feature, it SHOULD silently ignore the
1303 associated feature.
1305 If one or more security features (e.g., TLS and SASL) need to be
1306 successfully negotiated before a non-security-related feature (e.g.,
1307 resource binding) can be offered, the non-security-related feature
1308 SHOULD NOT be included in the stream features that are advertised
1309 before the relevant security features have been negotiated.
1311 If a feature must be negotiated before the initiating entity may
1312 proceed, that feature SHOULD include a
1337 S:
1359 The entity that sends the closing stream tag SHOULD wait for the
1360 other party to also close its stream:
1362 S:
1364 However, the entity that sends the first closing stream tag MAY
1365 consider both streams to be void if the other party does not send its
1366 closing stream tag within a reasonable amount of time (where the
1367 definition of "reasonable" is left up to the implementation or
1368 deployment).
1370 After an entity sends a closing stream tag, it MUST NOT send further
1371 data over that stream.
1373 After the entity that sent the first closing stream tag receives a
1374 reciprocal closing stream tag from the other party (or if it
1375 considers the stream to be void after a reasonable amount of time),
1376 it MUST terminate the underlying TCP connection or connections.
1378 5.6.3. Handling of Idle Streams
1380 An XML stream can become idle, i.e., neither entity has sent XMPP
1381 traffic over the stream for some period of time (usually at least
1382 several minutes). A server MAY close an idle stream with a local
1383 client or remote server. The idle timeout period is a matter of
1384 implementation and local service policy; however, it is RECOMMENDED
1385 to be liberal in accepting idle streams, since experience has shown
1386 that doing so improves the reliability of communications over XMPP
1387 networks. In particular, it is typically more efficient to maintain
1388 a stream between two servers than it is to aggressively timeout such
1389 a stream, especially with regard to synchronization of presence
1390 information as described in [XMPP-IM], so it is RECOMMENDED to
1391 maintain such a stream since experience has shown that server-to-
1392 server streams are cyclical and typically need to be re-established
1393 every 24 to 48 hours if they are timed out.
1395 An XML stream can appear idle at the XMPP level because the undelying
1396 TCP connection has become idle (e.g., a client's network connection
1397 has been lost). The typical method for detecting an idle TCP
1398 connection is to send a white space character over the TCP connection
1399 between XML stanzas, which is allowed for XML streams as described
1400 under Section 12.7. The time between such "whitespace pings" is a
1401 matter of implementation and local service policy; however, it is
1402 RECOMMENDED that these pings be sent not more than once every 60
1403 seconds.
1405 5.7. Stream Errors
1407 The root stream element MAY contain an
1426
1429
1431 5.7.1.2. Stream Errors Can Occur During Setup
1433 If the error occurs while the stream is being set up, the receiving
1434 entity MUST still send the opening tag, include the
1436 tag, and immediately terminate the underlying TCP connection.
1438 C:
1439
1447 S:
1448
1457
1462 5.7.1.3. Stream Errors When the Host is Unspecified
1464 If the initiating entity provides no 'to' attribute or provides an
1465 unknown host in the 'to' attribute and the error occurs during stream
1466 setup, the receiving entity SHOULD provide its authoritative hostname
1467 in the 'from' attribute of the stream header sent before termination.
1469 C:
1470
1477 S:
1478
1486
1487
1490
1492 5.7.2. Syntax
1494 The syntax for stream errors is as follows, where "defined-condition"
1495 is a placeholder for one of the conditions defined under
1496 Section 5.7.3.
1498
1499
1502 [ ... descriptive text ... ]
1503 ]
1504 [application-specific condition element]
1505
1507 The
1543 No closing body tag!
1544
1546 S:
1547
1550
1552 This error MAY be used instead of the more specific XML-related
1553 errors, such as
1573 S:
1574
1582
1583
1586
1588 5.7.3.3. conflict
1590 The server is either (1) closing the existing stream for this entity
1591 because a new stream has been initiated that conflicts with the
1592 existing stream, or (2) is refusing a new stream for this entity
1593 because allowing the new stream would conflict with an existing
1594 stream (e.g., because the server allows only a certain number of
1595 connections from the same IP address).
1597 C:
1598
1605 S:
1606
1614
1615
1618
1620 5.7.3.4. connection-timeout
1622 The entity has not generated any traffic over the stream for some
1623 period of time (configurable according to a local service policy) and
1624 therefore the connection is being dropped.
1626 P:
1627
1630
1632 5.7.3.5. host-gone
1634 The value of the 'to' attribute provided in the initial stream header
1635 corresponds to a hostname that is no longer hosted by the receiving
1636 entity.
1638 (In the following example, the peer specifies a 'to' address of
1639 "foo.im.example.com" when connecting to the "im.example.com" server,
1640 but the server no longer hosts a service at that address.)
1641 P:
1642
1649 S:
1650
1658
1659
1662
1664 5.7.3.6. host-unknown
1666 The value of the 'to' attribute provided in the initial stream header
1667 does not correspond to a hostname that is hosted by the receiving
1668 entity.
1670 (In the following example, the peer specifies a 'to' address of
1671 "example.org" when connecting to the "im.example.com" server, but the
1672 server knows nothing of that address.)
1673 P:
1674
1681 S:
1682
1690
1691
1694
1696 5.7.3.7. improper-addressing
1698 A stanza sent between two servers lacks a 'to' or 'from' attribute
1699 (or the attribute has no value).
1701 (In the following example, the peer sends a stanza without a 'to'
1702 address.)
1704 P:
1705 Wherefore art thou?
1706
1708 S:
1709
1712
1714 5.7.3.8. internal-server-error
1716 The server has experienced a misconfiguration or an otherwise-
1717 undefined internal error that prevents it from servicing the stream.
1719 S:
1720
1723
1725 5.7.3.9. invalid-from
1727 The JID or hostname provided in a 'from' address does not match an
1728 authorized JID or validated domain negotiated between servers via
1729 SASL, or between a client and a server via authentication and
1730 resource binding.
1732 (In the following example, a peer that has authenticated only as
1733 "example.net" attempts to send a stanza from an address at
1734 "example.org".)
1736 P:
1737 Neither, fair saint, if either thee dislike.
1738
1740 S:
1741
1744
1746 5.7.3.10. invalid-id
1748 The stream ID or server dialback ID is invalid or does not match an
1749 ID previously provided.
1751 (In the following example, the server dialback ID is invalid; see
1752 [XEP-0220].)
1754 P:
1761
1764
1766 5.7.3.11. invalid-namespace
1768 The streams namespace name is something other than
1769 "http://etherx.jabber.org/streams" (see Section 12.2).
1771 (In the following example, the client specifies a streams namespace
1772 of 'http://wrong.namespace.example.org/' instead of the correct
1773 namespace of "http://etherx.jabber.org/streams".)
1775 C:
1776
1783 S:
1784
1792
1793
1796
1798 5.7.3.12. invalid-xml
1800 The entity has sent invalid XML over the stream to a server that
1801 performs validation (see Section 12.4).
1803 (In the following example, the peer attempts to send an IQ stanza of
1804 type "subscribe" but there is no such value for the 'type'
1805 attribute.)
1806 P:
1810
1813 S:
1814
1817
1819 5.7.3.13. not-authorized
1821 The entity has attempted to send XML stanzas before the stream has
1822 been authenticated, or otherwise is not authorized to perform an
1823 action related to stream negotiation; the receiving entity MUST NOT
1824 process the offending stanza before sending the stream error.
1826 (In the following example, the client attempts to send XML stanzas
1827 before authenticating with the server.)
1828 C:
1829
1836 S:
1837
1847 Wherefore art thou?
1848
1850 S:
1851
1854
1856 5.7.3.14. policy-violation
1858 The entity has violated some local service policy (e.g., the stanza
1859 exceeds a configured size limit); the server MAY choose to specify
1860 the policy in the
1867 [ ... the-emacs-manual ... ]
1868
1870 S:
1871
1875 S:
1877 5.7.3.15. remote-connection-failed
1879 The server is unable to properly connect to a remote entity that is
1880 required for authentication or authorization.
1882 C:
1883
1890 S:
1891
1899
1900
1903
1905 5.7.3.16. resource-constraint
1907 The server lacks the system resources necessary to service the
1908 stream.
1910 C:
1911
1918 S:
1919
1927
1928
1931
1933 5.7.3.17. restricted-xml
1935 The entity has attempted to send restricted XML features such as a
1936 comment, processing instruction, DTD, entity reference, or unescaped
1937 character (see Section 12.1).
1939 (In the following example, the client sends an XMPP message
1940 containing an XML comment.)
1942 C:
1943
1944 This message has no subject.
1945
1947 S:
1948
1951
1953 5.7.3.18. see-other-host
1955 The server will not provide service to the initiating entity but is
1956 redirecting traffic to another host; the XML character data of the
1957
1974 S:
1975
1983
1984
1986 im.example.com:9090
1987
1988
1989
1991 5.7.3.19. system-shutdown
1993 The server is being shut down and all active streams are being
1994 closed.
1996 S:
1997
2000
2002 5.7.3.20. undefined-condition
2004 The error condition is not one of those defined by the other
2005 conditions in this list; this error condition SHOULD be used only in
2006 conjunction with an application-specific condition.
2008 S:
2009
2013
2015 5.7.3.21. unsupported-encoding
2017 The initiating entity has encoded the stream in an encoding that is
2018 not supported by the server (see Section 12.6) or has otherwise
2019 improperly encoded the stream (e.g., by violating the rules of the
2020 UTF-8 encoding).
2022 (In the following example, the client attempts to encode data using
2023 UTF-16 instead of UTF-8.)
2025 C:
2026
2033 S:
2034
2043
2048 5.7.3.22. unsupported-stanza-type
2050 The initiating entity has sent a first-level child of the stream that
2051 is not supported by the server or consistent with the default
2052 namespace.
2054 (In the following example, the client attempts to send an XML stanza
2055 of
2058
2059 -
2060
2061 Soliloquy
2062
2063 To be, or not to be: that is the question:
2064 Whether 'tis nobler in the mind to suffer
2065 The slings and arrows of outrageous fortune,
2066 Or to take arms against a sea of troubles,
2067 And by opposing end them?
2068
2069
2071 tag:denmark.lit,2003:entry-32397
2072 2003-12-13T18:30:02Z
2073 2003-12-13T18:30:02Z
2074
2075
2076
2077
2079 S:
2080
2083
2085 5.7.3.23. unsupported-version
2087 The value of the 'version' attribute provided by the initiating
2088 entity in the stream header specifies a version of XMPP that is not
2089 supported by the server; the server MAY specify the version(s) it
2090 supports in the
2102 S:
2103
2112
2115 1.0, 1.1
2116
2117
2118
2120 5.7.3.24. xml-not-well-formed
2122 The initiating entity has sent XML that violates the well-formedness
2123 rules of [XML] or [XML-NAMES].
2125 (In the following example, the client sends an XMPP message that is
2126 not well-formed XML.)
2128 C:
2129 No closing body tag!
2130
2132 S:
2133
2136
2138 5.7.4. Application-Specific Conditions
2140 As noted, an application MAY provide application-specific stream
2141 error information by including a properly-namespaced child in the
2142 error element. The application-specific element SHOULD supplement or
2143 further qualify a defined element. Thus the
2147
2148 My keyboard layout is:
2150 QWERTYUIOP{}|
2151 ASDFGHJKL:"
2152 ZXCVBNM<>?
2153
2154
2156 S:
2157
2160 Some special application diagnostic information!
2161
2162
2164
2166 5.8. Simplified Stream Examples
2168 This section contains two simplified examples of a stream-based
2169 connection of a client on a server; these examples are included for
2170 the purpose of illustrating the concepts introduced thus far.
2172 A basic connection:
2174 C:
2175
2184
2193 [ ... channel encryption ... ]
2195 [ ... authentication ... ]
2197 [ ... resource binding ... ]
2199 C:
2202 Art thou not Romeo, and a Montague?
2203
2205 S:
2208 Neither, fair saint, if either thee dislike.
2209
2211 C:
2213 S:
2214 A connection gone bad:
2216 C:
2217
2225 S:
2226
2235 [ ... channel encryption ... ]
2237 [ ... authentication ... ]
2239 [ ... resource binding ... ]
2241 C:
2244 No closing body tag!
2245
2247 S:
2248
2251
2253 More detailed examples are provided under Section 10.
2255 6. STARTTLS Negotiation
2256 6.1. Overview
2258 XMPP includes a method for securing the stream from tampering and
2259 eavesdropping. This channel encryption method makes use of the
2260 Transport Layer Security [TLS] protocol, specifically a "STARTTLS"
2261 extension that is modelled after similar extensions for the [IMAP],
2262 [POP3], and [ACAP] protocols as described in [USINGTLS]. The XML
2263 namespace name for the STARTTLS extension is
2264 'urn:ietf:params:xml:ns:xmpp-tls'.
2266 Support for STARTTLS is REQUIRED in XMPP client and server
2267 implementations. An administrator of a given deployment may require
2268 the use of TLS for client-to-server communication, server-to-server
2269 communication, or both. A deployed client should use TLS to secure
2270 its stream with a server prior to attempting the completion of SASL
2271 negotiation (Section 7), and deployed servers should use TLS between
2272 two domains for the purpose of securing server-to-server
2273 communication.
2275 6.2. Rules
2277 6.2.1. Mechanism Preferences
2279 Any entity that will act as a SASL client or a SASL server MUST
2280 maintain an ordered list of its preferred SASL mechanisms, where the
2281 list is ordered by the perceived strength of the mechanisms. A
2282 server MUST offer and a client MUST try SASL mechanisms in the order
2283 of their perceived strength. For example, if the server offers the
2284 ordered list "PLAIN DIGEST-MD5 GSSAPI" or "DIGEST-MD5 GSSAPI PLAIN"
2285 but the client's ordered list is "GSSAPI DIGEST-MD5", the client
2286 shall try GSSAPI first and then DIGEST-MD5 but shall never try PLAIN
2287 (since PLAIN is not on its list).
2289 6.2.2. Data Formatting
2291 The entities MUST NOT send any white space characters (matching
2292 production [3] content of [XML]) within the root stream element as
2293 separators between elements (any white space characters shown in the
2294 STARTTLS examples provided in this document are included only for the
2295 sake of readability); this prohibition helps to ensure proper
2296 security layer byte precision.
2298 6.2.3. Order of Negotiation
2300 If the initiating entity chooses to use TLS, STARTTLS negotiation
2301 MUST be completed before proceeding to SASL negotiation (Section 7);
2302 this order of negotiation is required to help safeguard
2303 authentication information sent during SASL negotiation, as well as
2304 to make it possible to base the use of the SASL EXTERNAL mechanism on
2305 a certificate (or other credentials) provided during prior TLS
2306 negotiation.
2308 6.3. Process
2310 6.3.1. Exchange of Stream Headers and Stream Features
2312 The initiating entity resolves the hostname of the receiving entity
2313 as specified under Section 4, opens a TCP connection to the
2314 advertised port at the resolved IP address, and sends an initial
2315 stream header to the receiving entity; if the initiating entity is
2316 capable of STARTTLS negotiation, it MUST include the 'version'
2317 attribute set to a value of at least "1.0" in the initial stream
2318 header.
2320 I:
2328 The receiving entity MUST send a response stream header to the
2329 initiating entity over the TCP connection opened by the initiating
2330 entity; if the receiving entity is capable of STARTTLS negotiation,
2331 it MUST include the 'version' attribute set to a value of at least
2332 "1.0" in the response stream header.
2334 R:
2349
2352 If the receiving entity requires the use of STARTTLS, it SHOULD
2353 include an empty
2357
2358
2360
2362 6.3.2. Initiation of STARTTLS Negotiation
2364 6.3.2.1. STARTTLS Command
2366 In order to begin the STARTTLS negotiation, the initiating entity
2367 issues the STARTTLS command (i.e., a
2396 If the failure case occurs, the initiating entity MAY attempt to
2397 reconnect as explained under Section 4.5.
2399 6.3.2.3. Proceed Case
2401 If the proceed case occurs, the receiving entity MUST return a
2402
2467 Note: The initiating entity MUST NOT send a closing tag
2468 before sending the initial stream header, since the receiving
2469 entity and initiating entity MUST consider the original stream to
2470 be closed upon success of the TLS negotiation.
2471 4. The receiving entity MUST respond with a response stream header.
2473 R:
2488
2489 EXTERNAL
2490 PLAIN
2491
2493
2495 7. SASL Negotiation
2497 7.1. Overview
2499 XMPP includes a method for authenticating a stream by means of an
2500 XMPP-specific profile of the Simple Authentication and Security Layer
2501 protocol (see [SASL]). SASL provides a generalized method for adding
2502 authentication support to connection-based protocols, and XMPP uses
2503 an XML namespace profile of SASL that conforms to the profiling
2504 requirements of [SASL].
2506 Support for SASL negotiation is REQUIRED in XMPP client and server
2507 implementations.
2509 7.2. Rules
2511 7.2.1. Data Formatting
2513 The following data formattting rules apply to the SASL negotiation:
2515 1. As formally specified in the XML schema for the
2516 'urn:ietf:params:xml:ns:xmpp-sasl' namespace under Appendix C.4,
2517 the receiving entity MAY include one or more application-specific
2518 child elements inside the (i.e., an XMPP domain identifier only) for servers and of
2578 the form (i.e., node identifier and domain identifier)
2579 for clients.
2581 7.2.5. Round Trips
2583 [SASL] specifies that a using protocol such as XMPP can define two
2584 methods by which the protocol can save round trips where allowed for
2585 the SASL mechanism:
2587 1. When the SASL client (the XMPP "initiating entity") requests an
2588 authentication exchange, it can include "initial response" data
2589 with its request. In XMPP this is done by including the initial
2590 response as the XML character data of the
2625 The receiving entity MUST send a response stream header to the
2626 initiating entity; if the receiving entity is capable of SASL
2627 negotiation, it MUST include the 'version' attribute set to a value
2628 of at least "1.0" in the response stream header.
2630 R:
2651
2652 EXTERNAL
2653 PLAIN
2654
2655
2657 Note: If during prior TLS negotiation the initiating entity presented
2658 a certificate that is acceptable to the receiving entity for purposes
2659 of strong identity verification in accordance with local service
2660 policies, the receiving entity SHOULD offer the SASL EXTERNAL
2661 mechanism to the initiating entity during SASL negotiation (refer to
2662 [SASL]) and SHOULD prefer that mechanism. However, the EXTERNAL
2663 mechanism MAY be offered under other circumstances as well.
2665 Note: If TLS negotiation (Section 6) needs to be completed before a
2666 particular authentication mechanism may be used, the receiving entity
2667 MUST NOT provide that mechanism in the list of available SASL
2668 authentication mechanisms prior to TLS negotiation.
2670 Note: See Section 15.7 regarding mechanisms that MUST be supported;
2671 naturally, other SASL mechanisms MAY be supported as well (best
2672 practices for the use of several SASL mechanisms in the context of
2673 XMPP are described in [XEP-0175] and [XEP-0178]).
2675 If successful SASL negotiation is required for interaction with the
2676 receiving entity, the receiving entity SHOULD signal that fact by
2677 including a
2681
2682 EXTERNAL
2683 PLAIN
2684
2686
2688 7.3.2. Initiation
2690 In order to begin the SASL negotiation, the initiating entity sends
2691 an R0m30R0cks
2703 7.3.3. Challenge-Response Sequence
2705 If necessary, the receiving entity challenges the initiating entity
2706 by sending a
2775
2778 If the failure case occurs, the receiving entity SHOULD allow a
2779 configurable but reasonable number of retries (at least 2 and no more
2780 than 5); this enables the initiating entity (e.g., an end-user
2781 client) to tolerate incorrectly-provided credentials (e.g., a
2782 mistyped password) without being forced to reconnect.
2784 If the initiating entity exceeds the number of retries, the receiving
2785 entity MUST return a stream error (which SHOULD be tag
2813 before sending the initial stream header, since the receiving entity
2814 and initiating entity MUST consider the original stream to be closed
2815 upon sending or receiving the
2830 The receiving entity MUST also send stream features, containing any
2831 further available features or containing no features (via an empty
2832
2836
2837
2839
2841 7.4. SASL Definition
2843 The profiling requirements of [SASL] require that the following
2844 information be supplied by a protocol definition:
2846 service name: "xmpp"
2847 initiation sequence: After the initiating entity provides an opening
2848 XML stream header and the receiving entity replies in kind, the
2849 receiving entity provides a list of acceptable authentication
2850 methods. The initiating entity chooses one method from the list
2851 and sends it to the receiving entity as the value of the
2852 'mechanism' attribute possessed by an of a client
2871 or the sending of a server; an empty string is equivalent
2872 to an absent authorization identity.
2874 7.5. SASL Errors
2876 The syntax of SASL errors is as follows:
2878
2879
2881 OPTIONAL descriptive text
2882 ]
2883
2885 Where "defined-condition" is one of the SASL-related error conditions
2886 defined in the following sections.
2888 Inclusion of a defined condition is REQUIRED.
2890 Inclusion of the
2903
2906 7.5.2. account-disabled
2908 The account of the initiating entity has been temporarily disabled;
2909 sent in reply to an password
2915 R:
2916 Call 212-555-1212 for assistance.
2918
2920 7.5.3. credentials-expired
2922 The authentication failed because the initiating entity provided
2923 credentials that have expired; sent in reply to a
2927 [ ... ]
2928
2930 R:
2931
2934 7.5.4. encryption-required
2936 The mechanism requested by the initiating entity cannot be used
2937 unless the underlying stream is encrypted; sent in reply to an
2938 password
2944 R:
2945
2948 7.5.5. incorrect-encoding
2950 The data provided by the initiating entity could not be processed
2951 because the [BASE64] encoding is incorrect (e.g., because the
2952 encoding does not adhere to the definition in Section 4 of [BASE64]);
2953 sent in reply to a [ ... ]
2959 R:
2960
2963 7.5.6. invalid-authzid
2965 The authzid provided by the initiating entity is invalid, either
2966 because it is incorrectly formatted or because the initiating entity
2967 does not have permissions to authorize that ID; sent in reply to a
2968
2971 [ ... ]
2972
2974 R:
2975
2978 7.5.7. invalid-mechanism
2980 The initiating entity did not provide a mechanism or requested a
2981 mechanism that is not supported by the receiving entity; sent in
2982 reply to an
2988
2991 7.5.8. malformed-request
2993 The request is malformed (e.g., the [ ... some-long-token ... ]
3006 R:
3007
3010 7.5.9. mechanism-too-weak
3012 The mechanism requested by the initiating entity is weaker than
3013 server policy permits for that initiating entity; sent in reply to an
3014 password
3020 R:
3021
3024 7.5.10. not-authorized
3026 The authentication failed because the initiating entity did not
3027 provide proper credentials; sent in reply to a
3031 [ ... ]
3032
3034 R:
3035
3038 Note: This error condition includes but is not limited to the case of
3039 incorrect credentials or an unknown username. In order to discourage
3040 directory harvest attacks, no differentiation is made between
3041 incorrect credentials and an unknown username.
3043 7.5.11. temporary-auth-failure
3045 The authentication failed because of a temporary error condition
3046 within the receiving entity, and the initiating entity should try
3047 again later; sent in reply to an
3051 [ ... ]
3052
3054 R:
3055
3058 7.5.12. transition-needed
3060 The authentication failed because the mechanism cannot be used until
3061 the initiating entity provides (for one time only) a plaintext
3062 password so that the receiving entity can build a hashed password for
3063 use in future authentication attempts; sent in reply to an [ ... ]
3069 R:
3070
3073 8. Resource Binding
3075 8.1. Overview
3077 After a client authenticates with a server, it MUST bind a specific
3078 resource to the stream so that the server can properly address the
3079 client (see Section 3). That is, there MUST be an XMPP resource
3080 identifier associated with the bare JID () of the
3081 client, with the result that the address for use over that stream is
3082 a full JID of the form . This ensures that the
3083 server can deliver XML stanzas to and receive XML stanzas from the
3084 client (see Section 11). After binding a resource to the stream, the
3085 client is referred to as a connected resource.
3087 If, before completing the resource binding step, the client attempts
3088 to send an outbound XML stanza (i.e., a stanza not directed to the
3089 server itself or to the client's own account), the server MUST NOT
3090 process the stanza and SHOULD return a
3116 S:
3117
3118
3120
3122 Upon being so informed that resource binding is required, the client
3123 MUST bind a resource to the stream as described in the following
3124 sections.
3126 8.3. Generation of Resource Identifiers
3128 A resource identifier MUST at a minimum be unique among the connected
3129 resources for that . Enforcement of this policy is the
3130 responsibility of the server.
3132 A resource identifier may be security-critical. For example, if a
3133 malicious entity can guess a client's resource identifier then it may
3134 be able to determine if the client (and therefore the controlling
3135 principal) is online or offline, thus resulting in a presence leak as
3136 described under Section 15.13. Traditionally, XMPP resource
3137 identifiers have been generated by clients in ways that are not
3138 secure (e.g., hardcoding the resource identifier to the name of the
3139 client or to a common location such as "home" or "work"). However,
3140 for the sake of proper security, a resource identifier SHOULD be
3141 random (see [RANDOM]). A suitably random resource identifier can be
3142 generated by either the client or the server. It is RECOMMENDED that
3143 the resource identifier incorporate a Universally Unique Identifier
3144 (UUID), for which the format specified in [UUID] is RECOMMENDED. One
3145 approach is for the resource idenfitier to incorporate human-friendly
3146 text (if desired) followed by the UUID, such as "home
3147 4db06f061ea411dcaca3000bcd821bfb" instead of simply "home". This can
3148 be accomplished in several ways:
3150 o The client generates such a random resource identifier directly.
3151 o The client asks the server to generate a random resource
3152 identifier.
3154 o The server overrides the client-requested resource identifier by
3155 adding a UUID to the human-friendly text proposed by the client.
3157 8.4. Server-Generated Resource Identifier
3159 A server that supports resource binding MUST be able to generate an
3160 XMPP resource identifier on behalf of a client.
3162 8.4.1. Success Case
3164 A client requests a server-generated resource identifier by sending
3165 an IQ stanza of type "set" (see Section 9.2.3) containing an empty
3166
3170
3173 Once the server has generated an XMPP resource identifier for the
3174 client, it MUST return an IQ stanza of type "result" to the client,
3175 which MUST include a
3179
3180
3181 juliet@im.example.com/4db06f061ea411dcaca3000bcd821bfb
3182
3183
3184
3186 8.4.2. Error Case
3188 It is possible that the client is not allowed to bind a resource to
3189 the stream (e.g., because the node or user has reached a limit on the
3190 number of connected resources allowed). In this case, the server
3191 MUST return a
3194
3195
3197
3199 8.5. Client-Generated Resource Identifier
3201 A client MAY attempt to specify the resource identifier on its own
3202 rather than asking the server to generate a resource identifier on
3203 its behalf.
3205 8.5.1. Success Case
3207 A client asks its server to accept a client-generated resource
3208 identifier by sending an IQ stanza of type "set" containing a
3213
3214 balcony
3215
3216
3218 The server MAY accept the resource identifier provided by the client,
3219 in which case it returns an IQ stanza of type "result" to the client,
3220 including a
3224
3225 juliet@im.example.com/balcony
3226
3227
3229 However, the server MAY instead override the client-generated
3230 resource identifier and generate a resource identifier on behalf of
3231 the client as shown in the previous section, optionally incorporating
3232 the human-friendly text proposed by the client.
3234 S:
3235
3236
3237 juliet@im.example.com/balcony 4db06f061ea411dcaca3000bcd821bfb
3238
3239
3240
3242 8.5.2. Error Cases
3244 When a client attempts to set its own XMPP resource identifier during
3245 resource binding, the following stanza error conditions are possible:
3247 o The client is not allowed to bind a resource to the stream (e.g.,
3248 because the node or user has reached a limit on the number of
3249 connected resources allowed).
3250 o The provided resource identifier cannot be processed by the
3251 server, e.g. because it is not in accordance with the Resourceprep
3252 (Appendix B) profile of [STRINGPREP]).
3253 o The provided resource identifier is already in use.
3255 8.5.2.1. Not Allowed
3257 If the client is not allowed to bind a resource to the stream, the
3258 server MUST return a
3261
3262
3264
3266 8.5.2.2. Bad Request
3268 If the provided resource identifier cannot be processed by the
3269 server, the server MAY return a
3275
3276
3278
3280 8.5.2.3. Conflict
3282 If there is already a connected resource of the same name, the server
3283 MUST do one of the following:
3285 1. Not accept the resource identifier provided by the client but
3286 instead override it with an XMPP resource identifier that the
3287 server generates.
3288 2. Terminate the current resource and allow the newly-requested
3289 resource.
3290 3. Disallow the newly-requested resource and maintain the current
3291 resource.
3293 Which of these the server does is up to the implementation, although
3294 it is RECOMMENDED to implement case #1.
3296 In case #2, the server MUST send a
3325
3326
3328
3331 8.6.2. Binding an Additional Resource
3333 A connected client binds an additional resource by following the
3334 protocol for binding of the original resource, i.e., by sending an IQ
3335 stanza of type "set" containing a
3352
3353 someresource
3354
3355
3357 If no error occurs, the server MUST unbind the resource and no longer
3358 accept stanzas whose 'from' address specifies the full JID associated
3359 with that resource.
3361 S:
3370 8.6.3.2. Error Cases
3372 8.6.3.2.1. Unbind Not Supported
3374 If the server understands the 'urn:ietf:params:xml:ns:xmpp-bind'
3375 namespace but does not understand the
3379
3380
3383
3385 8.6.3.2.2. No Such Resource
3387 If there is no such resource for that stream, the server MUST return
3388 an error of
3391
3392
3394
3396 8.6.4. From Addresses
3398 When a client binds multiple resources to the same stream, proper
3399 management of 'from' addresses is imperative. In particular, a
3400 client MUST specify a 'from' address on every stanza it sends over a
3401 stream to which it has bound multiple resources, where the 'from'
3402 address is the full JID () associated with
3403 the relevant resource. If a client does not specify a 'from' address
3404 on a stanza it sends over a stream to which it has bound multiple
3405 resources, the server MUST return the stanza to the client with an
3406
3409 Wherefore art thou?
3410
3412 S:
3414 Wherefore art thou?
3415
3416
3418
3420 Naturally, the rules regarding validation of asserted 'from'
3421 addresses still apply (see Section 11).
3423 9. XML Stanzas
3425 After a client has connected to a server or two servers have
3426 connected to each other, either party can send XML stanzas over the
3427 negotiated stream. Three kinds of XML stanza are defined for the
3428 'jabber:client' and 'jabber:server' namespaces:
3455 Art thou not Romeo, and a Montague?
3456
3458 For information about server processing of inbound and outbound XML
3459 stanzas based on the nature of the 'to' address, refer to Section 11.
3461 9.1.1.1. Client-to-Server Streams
3463 The following rules apply to inclusion of the 'to' attribute in the
3464 context of XML streams qualified by the 'jabber:client' namespace
3465 (i.e., client-to-server streams).
3467 1. A stanza with a specific intended recipient MUST possess a 'to'
3468 attribute.
3469 2. A stanza sent from a client to a server for direct processing by
3470 the server on behalf of the client (e.g., presence sent to the
3471 server for broadcasting to other entities) MUST NOT possess a
3472 'to' attribute.
3474 9.1.1.2. Server-to-Server Streams
3476 The following rules apply to inclusion of the 'to' attribute in the
3477 context of XML streams qualified by the 'jabber:server' namespace
3478 (i.e., server-to-server streams).
3480 1. A stanza MUST possess a 'to' attribute; if a server receives a
3481 stanza that does not meet this restriction, it MUST generate an
3482
3492 Art thou not Romeo, and a Montague?
3493
3495 9.1.2.1. Client-to-Server Streams
3497 The following rules apply to the 'from' attribute in the context of
3498 XML streams qualified by the 'jabber:client' namespace (i.e., client-
3499 to-server streams).
3501 1. When the server receives an XML stanza from a client and the
3502 stanza does not include a 'from' attribute, the server MUST add a
3503 'from' attribute to the stanza, where the value of the 'from'
3504 attribute is the full JID () determined by
3505 the server for the connected resource that generated the stanza
3506 (see Section 3.5), or the bare JID () in the case of
3507 subscription-related presence stanzas (see [XMPP-IM]); the only
3508 exception to this rule occurs when multiple resources are bound
3509 to the same stream as described under Section 8.6.
3510 2. When the server receives an XML stanza from a client and the
3511 stanza includes a 'from' attribute, the server MUST either (a)
3512 validate that the value of the 'from' attribute provided by the
3513 client is that of a connected resource for the associated entity
3514 or (b) override the provided 'from' attribute by adding a 'from'
3515 attribute as specified under Rule #1.
3516 3. When the server generates a stanza from the server for delivery
3517 to the client on behalf of the account of the connected client
3518 (e.g., in the context of data storage services provided by the
3519 server on behalf of the client), the stanza MUST either (a) not
3520 include a 'from' attribute or (b) include a 'from' attribute
3521 whose value is the account's bare JID ().
3522 4. When the server generates a stanza from the server itself for
3523 delivery to the client, the stanza MUST include a 'from'
3524 attribute whose value is the mere domain () of the
3525 server.
3527 5. A server MUST NOT send to the client a stanza without a 'from'
3528 attribute if the stanza was not generated by the server (e.g., if
3529 it was generated by another client or another server); therefore,
3530 when a client receives a stanza that does not include a 'from'
3531 attribute, it MUST assume that the stanza is from the server to
3532 which the client is connected.
3534 9.1.2.2. Server-to-Server Streams
3536 The following rules apply to the 'from' attribute in the context of
3537 XML streams qualified by the 'jabber:server' namespace (i.e., server-
3538 to-server streams).
3540 1. A stanza MUST possess a 'from' attribute; if a server receives a
3541 stanza that does not meet this restriction, it MUST generate an
3542
3587 dnd
3588 Wooing Juliet
3589
3591 The value of the 'xml:lang' attribute MAY be overridden by the 'xml:
3592 lang' attribute of a specific child element.
3594
3595 dnd
3596 Wooing Juliet
3597 Dvořím se Julii
3598
3606 dnd
3607 Wooing Juliet
3608
3610 S:
3613 dnd
3614 Wooing Juliet
3615
3617 If an inbound stanza received received by a client or server does not
3618 possess an 'xml:lang' attribute, an implementation MUST assume that
3619 the default language is that specified for the stream as defined
3620 under Section 5.3.
3622 The value of the 'xml:lang' attribute MUST conform to the NMTOKEN
3623 datatype (as defined in Section 2.3 of [XML]) and MUST conform to the
3624 format defined in [LANGTAGS].
3626 A server MUST NOT modify or delete 'xml:lang' attributes on stanzas
3627 it receives from other entities.
3629 9.2. Basic Semantics
3631 9.2.1. Message Semantics
3633 The |
3675 | [ ... payload ... ] |
3676 | |
3677 | -------------------------> |
3678 | |
3679 | |
3680 | [ ... payload ... ] |
3681 | |
3682 | <------------------------- |
3683 | |
3684 | |
3685 | [ ... payload ... ] |
3686 | |
3687 | -------------------------> |
3688 | |
3689 | |
3690 | [ ... condition ... ] |
3691 | |
3692 | <------------------------- |
3693 | |
3695 In order to enforce these semantics, the following rules apply:
3697 1. The 'id' attribute is REQUIRED for IQ stanzas.
3698 2. The 'type' attribute is REQUIRED for IQ stanzas. The value MUST
3699 be one of the following (if the value is other than one of the
3700 following strings, the recipient or an intermediate router MUST
3701 return a stanza error of
3764 [OPTIONAL to include sender XML here]
3765
3766
3769 OPTIONAL descriptive text
3770 ]
3771 [OPTIONAL application-specific condition element]
3772
3773
3775 The "stanza-kind" MUST be one of message, presence, or iq.
3777 The "error-type MUST be one of the following:
3779 o cancel -- do not retry (the error cannot be remedied)
3780 o continue -- proceed (the condition was only a warning)
3781 o modify -- retry after changing the data sent
3782 o auth -- retry after providing credentials
3783 o wait -- retry after waiting (the error is temporary)
3785 The
3825
3828 S:
3832
3833
3835
3837 9.3.3.2. conflict
3839 Access cannot be granted because an existing resource exists with the
3840 same name or address; the associated error type SHOULD be "cancel".
3842 C:
3843
3844 balcony
3845
3846
3848 S:
3849
3850
3852
3854 9.3.3.3. feature-not-implemented
3856 The feature represented in the XML stanza is not implemented by the
3857 intended recipient or an intermediate server and therefore the stanza
3858 cannot be processed (e.g., the entity understands the namespace but
3859 does not recognize the element name); the associated error type
3860 SHOULD be "cancel" or "modify".
3862 C:
3866
3867
3869
3871 E:
3875
3876
3882
3884 9.3.3.4. forbidden
3886 The requesting entity does not possess the required permissions to
3887 perform the action; the associated error type SHOULD be "auth".
3889 C:
3892
3895 E:
3899
3900
3903
3905 9.3.3.5. gone
3907 The recipient or server can no longer be contacted at this address,
3908 typically on a permanent basis; the associated error type SHOULD be
3909 "cancel" or "modify" and the error stanza SHOULD include a new
3910 address as the XML character data of the
3917
3920 E:
3924
3925
3926 xmpp:conference.example.com
3927
3928
3929
3931 9.3.3.6. internal-server-error
3933 The server could not process the stanza because of a misconfiguration
3934 or an otherwise-undefined internal server error; the associated error
3935 type SHOULD be "wait" or "cancel".
3937 C:
3940
3943 E:
3947
3948
3952
3954 9.3.3.7. item-not-found
3956 The addressed JID or item requested cannot be found; the associated
3957 error type SHOULD be "cancel" or "modify".
3959 C:
3960
3961 someresource
3962
3963
3965 S:
3966
3967
3969
3971 Note: An application MUST NOT return this error if doing so would
3972 provide information about the intended recipient's network
3973 availability to an entity that is not authorized to know such
3974 information; instead it SHOULD return a
3986
3989 E:
3993
3994
3997
3999 9.3.3.9. not-acceptable
4001 The recipient or server understands the request but is refusing to
4002 process it because it does not meet criteria defined by the recipient
4003 or server (e.g., a local policy regarding stanza size limits or
4004 acceptable words in messages); the associated error type SHOULD be
4005 "modify".
4007 C:
4008 [ ... the-emacs-manual ... ]
4009
4011 S:
4012
4013
4016
4018 9.3.3.10. not-allowed
4020 The recipient or server does not allow any entity to perform the
4021 action (e.g., sending to entities at a blacklisted domain); the
4022 associated error type SHOULD be "cancel".
4024 C:
4027
4030 E:
4033
4034
4036
4038 9.3.3.11. not-authorized
4040 The sender must provide proper credentials before being allowed to
4041 perform the action, or has provided improper credentials; the
4042 associated error type SHOULD be "auth".
4044 C:
4047
4050 E:
4053
4054
4056
4058 9.3.3.12. not-modified
4060 The item requested has not changed since it was last requested; the
4061 associated error type SHOULD be "continue".
4063 C:
4066
4067
4068
4069 some-long-opaque-string
4070
4071
4072
4073
4075 S:
4078
4079
4080
4081 some-long-opaque-string
4082
4083
4084
4085
4086
4088
4090 9.3.3.13. payment-required
4092 The requesting entity is not authorized to access the requested
4093 service because payment is required; the associated error type SHOULD
4094 be "auth".
4096 C:
4100
4101
4103
4105 E:
4109
4110
4113
4115 9.3.3.14. recipient-unavailable
4117 The intended recipient is temporarily unavailable; the associated
4118 error type SHOULD be "wait".
4120 C:
4123
4126 E:
4129
4130
4133
4135 Note: An application MUST NOT return this error if doing so would
4136 provide information about the intended recipient's network
4137 availability to an entity that is not authorized to know such
4138 information; instead it SHOULD return a
4152
4155 E:
4159
4160
4161 xmpp:characters@conference.example.org
4162
4163
4164
4166 9.3.3.16. registration-required
4168 The requesting entity is not authorized to access the requested
4169 service because prior registration is required; the associated error
4170 type SHOULD be "auth".
4172 C:
4175
4178 E:
4181
4182
4185
4187 9.3.3.17. remote-server-not-found
4189 A remote server or service specified as part or all of the JID of the
4190 intended recipient does not exist; the associated error type SHOULD
4191 be "cancel".
4193 C:
4196
4199 E:
4202
4203
4206
4208 9.3.3.18. remote-server-timeout
4210 A remote server or service specified as part or all of the JID of the
4211 intended recipient (or required to fulfill a request) could not be
4212 contacted within a reasonable amount of time; the associated error
4213 type SHOULD be "wait".
4215 C:
4218
4221 E:
4224
4225
4228
4230 9.3.3.19. resource-constraint
4232 The server or recipient lacks the system resources necessary to
4233 service the request; the associated error type SHOULD be "wait".
4235 C:
4239
4240
4242
4244 E:
4248
4249
4252
4254 9.3.3.20. service-unavailable
4256 The server or recipient does not currently provide the requested
4257 service; the associated error type SHOULD be "cancel".
4259 C:
4261 Hello?
4262
4264 S:
4266
4267
4270
4272 An application SHOULD return a help
4288
4290 E:
4294
4295
4298
4300 9.3.3.22. undefined-condition
4302 The error condition is not one of those defined by the other
4303 conditions in this list; any error type may be associated with this
4304 condition, and it SHOULD be used only in conjunction with an
4305 application-specific condition.
4307 C:
4311 My lord, dispatch; read o'er these articles.
4312
4313
4318 S:
4322
4326
4330
4331
4334
4338
4339
4341 9.3.3.23. unexpected-request
4343 The recipient or server understood the request but was not expecting
4344 it at this time (e.g., the request was out of order); the associated
4345 error type SHOULD be "wait" or "modify".
4347 C:
4351
4352
4356
4358 E:
4362
4363
4368
4370 9.3.3.24. unknown-sender
4372 The stanza 'from' address specified by a connected client is not
4373 valid for the stream (e.g., the stanza does not include a 'from'
4374 address when multiple resources are bound to the stream as described
4375 under Section 8.6.4); the associated error type SHOULD be "modify".
4377 C:
4378 Wherefore art thou?
4379
4381 S:
4383 Wherefore art thou?
4384
4385
4387
4389 9.3.4. Application-Specific Conditions
4391 As noted, an application MAY provide application-specific stanza
4392 error information by including a properly-namespaced child in the
4393 error element. The application-specific element SHOULD supplement or
4394 further qualify a defined element. Thus, the
4398
4399
4402
4404
4405
4406
4410 [ ... application-specific information ... ]
4411
4412
4414
4416 9.4. Extended Content
4418 While the message, presence, and IQ stanzas provide basic semantics
4419 for messaging, availability, and request-response interactions, XMPP
4420 uses XML namespaces (see [XML-NAMES] to extend the basic stanza
4421 syntax for the purpose of providing additional functionality. Thus a
4422 message or presence stanza MAY contain one or more optional child
4423 elements specifying content that extends the meaning of the message
4424 (e.g., an XHTML-formatted version of the message body as described in
4425 [XEP-0071]), and an IQ stanza of type "get" or "set" MUST contain one
4426 such child element. This child element MAY have any name and MUST
4427 possess a namespace declaration (other than "jabber:client", "jabber:
4428 server", or "http://etherx.jabber.org/streams") that defines all data
4429 contained within the child element. Such a child element is said to
4430 be EXTENDED CONTENT and its namespace name is said to be an EXTENDED
4431 NAMESPACE.
4433 Support for any given extended namespace is OPTIONAL on the part of
4434 any implementation. If an entity does not understand such a
4435 namespace, the entity's expected behavior depends on whether the
4436 entity is (1) the recipient or (2) an entity that is routing the
4437 stanza to the recipient.
4439 Recipient: If a recipient receives a stanza that contains a child
4440 element it does not understand, it SHOULD silently ignore that
4441 particular XML data, i.e., it SHOULD not process it or present it
4442 to a user or associated application (if any). In particular:
4443 * If an entity receives a message or presence stanza that
4444 contains XML data qualified by a namespace it does not
4445 understand, the portion of the stanza that qualified by the
4446 unknown namespace SHOULD be ignored.
4447 * If an entity receives a message stanza whose only child element
4448 is qualified by a namespace it does not understand, it MUST
4449 ignore the entire stanza.
4450 * If an entity receives an IQ stanza of type "get" or "set"
4451 containing a child element qualified by a namespace it does not
4452 understand, the entity SHOULD return an IQ stanza of type
4453 "error" with an error condition of
4489 Step 2: Server responds by sending a response stream header to
4490 client:
4492 S:
4505
4506
4508
4510 Step 4: Client sends STARTTLS command to server:
4512 C:
4524 Step 6: Client and server attempt to complete TLS negotiation over
4525 the existing TCP connection (see [TLS] for details).
4527 Step 7: If TLS negotiation is successful, client initiates a new
4528 stream to server:
4530 C:
4538 Step 7 (alt): If TLS negotiation is unsuccessful, server closes TCP
4539 connection.
4541 10.1.2. SASL
4543 Step 8: Server responds by sending a stream header to client along
4544 with any available stream features:
4546 S:
4556
4557 DIGEST-MD5
4558 PLAIN
4559
4561
4563 Step 9: Client selects an authentication mechanism, in this case
4564 [DIGEST-MD5] with an empty authorization identity ("="):
4566 C: R0m30R0cks
4569 Step 10: Server informs client of success and includes [BASE64]
4570 encoded value for subsequent authentication:
4572 S:
4577
4580 Step 11: Client initiates a new stream to server:
4582 C:
4604 S:
4605
4606
4608
4611 Upon being so informed that resource binding is required, the client
4612 MUST bind a resource to the stream; here we assume that the client
4613 asks the server to generate a resource identifier on its behalf.
4615 Step 13: Client binds a resource:
4617 C:
4618
4621 Step 14: Server generates resource identifier and informs client of
4622 successful resource binding:
4624 S:
4625
4626
4627 juliet@im.example.com/4db06f061ea411dcaca3000bcd821bfb
4628
4629
4630
4632 10.1.4. Stanza Exchange
4634 Now the client is allowed to send XML stanzas over the negotiated
4635 stream.
4637 C:
4641 Art thou not Romeo, and a Montague?
4642
4644 If necessary, sender's server negotiates XML streams with intended
4645 recipient's server (see Section 10.2).
4647 The intended recipient replies and the message is delivered to the
4648 client.
4650 E:
4654 Neither, fair saint, if either thee dislike.
4655
4657 The client may send and receive an unbounded number of subsequent XML
4658 stanzas over the stream.
4660 10.1.5. Close
4662 Desiring to send no further messages, the client closes the stream.
4664 C:
4666 Consistent with the recommended stream closing handshake, server
4667 closes stream as well:
4669 S:
4671 Client now terminates the underlying TCP connection.
4673 10.2. Server-to-Server Examples
4675 The following examples show the data flow for a server negotiating an
4676 XML stream with another server, exchanging XML stanzas, and closing
4677 the negotiated stream. The initiating server ("Server1") is
4678 example.com; the receiving server ("Server2") is example.net and it
4679 requires use of TLS; example.com presents a certificate and
4680 authenticates via the SASL EXTERNAL mechanism. It is assumed that
4681 before sending the initial stream header, Server1 has already
4682 resolved an SRV record of _xmpp-server._tcp.example.net and has
4683 opened a TCP connection to the advertised port at the resolved IP
4684 address.
4686 Note: The alternate steps shown are provided only to illustrate the
4687 protocol for failure cases; they are not exhaustive and would not
4688 necessarily be triggered by the data sent in the examples.
4690 10.2.1. TLS
4692 Step 1: Server1 initiates stream to Server2:
4694 S1:
4701 Step 2: Server2 responds by sending a response stream header to
4702 Server1:
4704 S2:
4712 Step 3: Server2 sends stream features to Server1:
4714 S2:
4715
4716
4718
4720 Step 4: Server1 sends the STARTTLS command to Server2:
4722 S1:
4735 Step 6: Server1 and Server2 attempt to complete TLS negotiation via
4736 TCP.
4738 Step 7: If TLS negotiation is successful, Server1 initiates a new
4739 stream to Server2:
4741 S1:
4748 Step 7 (alt): If TLS negotiation is unsuccessful, Server2 closes TCP
4749 connection.
4751 10.2.2. SASL
4753 Step 8: Server2 sends a response stream header to Server1 along with
4754 available stream features (including a preference for the SASL
4755 EXTERNAL mechanism):
4757 S2:
4765 S2:
4766
4767 EXTERNAL
4768
4770
4772 Step 9: Server1 selects the EXTERNAL mechanism, in this case with an
4773 authorization identity encoded according to [BASE64]:
4775 S1:
4789
4792 S2:
4793 Step 12: Server1 initiates a new stream to Server2:
4795 S1:
4802 Step 13: Server2 responds by sending a stream header to Server1 along
4803 with any additional features (or, in this case, an empty features
4804 element):
4806 S2:
4814 S2:
4827 Art thou not Romeo, and a Montague?
4828
4830 The intended recipient replies and the message is delivered from
4831 Server2 to Server1.
4833 Server2 sends XML stanza to Server1:
4835 S2:
4838 Neither, fair saint, if either thee dislike.
4839
4841 10.2.4. Close
4843 Desiring to send no further messages, Server1 closes the stream. (In
4844 practice, the stream would most likely remain open for some time,
4845 since Server1 and Server2 do not immediately know if the stream will
4846 be needed for further communication.)
4848 S1:
4850 Consistent with the recommended stream closing handshake, Server2
4851 closes stream as well:
4853 S2:
4855 Server1 now terminates the underlying TCP connection.
4857 11. Server Rules for Processing XML Stanzas
4859 An XMPP server MUST ensure in-order processing of XML stanzas between
4860 any two entities. This includes stanzas sent by a client to its
4861 server for direct processing by the server (e.g., in-order processing
4862 of a roster get and initial presence as described in [XMPP-IM]).
4864 Beyond the requirement for in-order processing, each server
4865 implementation will contain its own logic for processing stanzas it
4866 receives. Such logic determines whether the server needs to ROUTE a
4867 given stanza to another domain, DELIVER it to a local entity
4868 (typically a connected client associated with a local account), or
4869 HANDLE it directly within the server itself. The following rules
4870 apply.
4872 Note: Particular XMPP applications MAY specify delivery rules that
4873 modify or supplement the following rules; for example, a set of
4874 delivery rules for instant messaging and presence applications is
4875 defined in [XMPP-IM].
4877 11.1. No 'to' Address
4879 11.1.1. Overview
4881 If the stanza possesses no 'to' attribute, the server SHOULD handle
4882 it directly on behalf of the entity that sent it, where the meaning
4883 of "handle it directly" depends on whether the stanza is message,
4884 presence, or IQ. Because all stanzas received from other servers
4885 MUST possess a 'to' attribute, this rule applies only to stanzas
4886 received from a local entity (such as a client) that is connected to
4887 the server.
4889 11.1.2. Message
4891 If the server receives a message stanza with no 'to' attribute, it
4892 SHOULD treat the message as if the 'to' address were the bare JID
4893 of the sending entity.
4895 11.1.3. Presence
4897 If the server receives a presence stanza with no 'to' attribute, it
4898 SHOULD broadcast it to the entities that are subscribed to the
4899 sending entity's presence, if applicable (the semantics of presence
4900 broadcast for presence applications are defined in [XMPP-IM]).
4902 11.1.4. IQ
4904 If the server receives an IQ stanza with no 'to' attribute, it MUST
4905 process the stanza on behalf of the account from which received the
4906 stanza, as follows:
4908 1. If the IQ stanza is of type "get" or "set" and the server
4909 understands the namespace that qualifies the payload, the server
4910 MUST handle the stanza on behalf of the sending entity or return
4911 an appropriate error to the sending entity. While the meaning of
4912 "handle" is determined by the semantics of the qualifying
4913 namespace, in general the server shall respond to the IQ stanza
4914 of type "get" or "set" by returning an appropriate IQ stanza of
4915 type "result" or "error", responding as if the server were the
4916 bare JID of the sending entity. As an example, if the sending
4917 entity sends an IQ stanza of type "get" where the payload is
4918 qualified by the 'jabber:iq:roster' namespace (as described in
4919 [XMPP-IM]), then the server shall return the roster associated
4920 with the sending entity's bare JID to the particular resource of
4921 the sending entity that requested the roster.
4922 2. If the IQ stanza is of type "get" or "set" and the server does
4923 not understand the namespace that qualifies the payload, the
4924 server MUST return an error to the sending entity, which MUST be
4925 ,
4942 then the server MUST either handle the stanza as appropriate for the
4943 stanza kind or return an error stanza to the sender.
4945 11.2.2. Resource at Domain
4947 If the JID contained in the 'to' attribute is of the form , then the server MUST either handle the stanza as
4949 appropriate for the stanza kind or return an error stanza to the
4950 sender.
4952 11.2.3. Node at Domain
4954 If the JID contained in the 'to' attribute is of the form
4955 (bare JID) or (full JID), then
4956 the server SHOULD deliver the stanza to the intended recipient. The
4957 following rules apply:
4959 1. If the JID contains an XMPP resource identifier (i.e., is of the
4960 form ) and there exists a connected
4961 resource that exactly matches the full JID, the recipient's
4962 server SHOULD deliver the stanza to that connection.
4963 2. If the JID contains an XMPP resource identifier and there exists
4964 no connected resource that exactly matches the full JID, the
4965 recipient's server SHOULD return a and there exists at least
4968 one connected resource for the node, (1) if the stanza is a
4969 message or presence stanza then the recipient's server SHOULD
4970 deliver the stanza to at least one of the connected resources and
4971 (2) if the stanza is an IQ stanza then the recipient's server
4972 MUST handle it directly on behalf of the node (and if the sender
4973 has generated an IQ stanza for which the bare JID matches that of
4974 the connected user itself then the recipient's server MUST treat
4975 the IQ stanza as if it included no 'to' address).
4977 Note: More detailed rules in the context of instant messaging and
4978 presence applications are provided in [XMPP-IM].
4980 11.3. Foreign Domain
4982 If the hostname of the domain identifier portion of the JID contained
4983 in the 'to' attribute does not match one of the configured hostnames
4984 of the server itself, the server SHOULD attempt to route the stanza
4985 to the foreign domain (subject to local service provisioning and
4986 security policies regarding inter-domain communication, since such
4987 communication is optional for any given deployment). There are two
4988 possible cases.
4990 11.3.1. Existing Stream
4992 If a server-to-server stream already exists between the two domains,
4993 the sender's server shall attempt to route the stanza to the
4994 authoritative server for the foreign domain over the existing stream.
4996 11.3.2. No Existing Stream
4998 If there exists no server-to-server stream between the two domains,
4999 the sender's server shall proceed as follows:
5001 1. Resolve the hostname of the foreign domain (as defined under
5002 Section 15.4).
5003 2. Negotiate a server-to-server stream between the two domains (as
5004 defined under Section 6 and Section 7).
5005 3. Route the stanza to the authoritative server for the foreign
5006 domain over the newly-established stream.
5008 11.3.3. Error Handling
5010 If routing to the intended recipient's server is unsuccessful, the
5011 sender's server MUST return an error to the sender, which SHOULD be
5012
5142
5145 An XML stanza MAY contain XML data qualified by more than one
5146 extended namespace, either at the direct child level of the stanza
5147 (for presence and message stanzas) or in any mix of levels (for all
5148 stanzas).
5150
5151
5155 sha1-hash-of-image
5156
5157
5159
5160 Hello?
5161
5162
5163 Hello?
5164
5165
5166
5167
5170
5171
5172 some-long-opaque-string
5173
5174
5175
5177 An implementation SHOULD NOT generate namespace prefixes for elements
5178 qualified by content (as opposed to stream) namespaces other than the
5179 default namespace. However, if included, the namespace declarations
5180 for those prefixes MUST be included on the stanza root or a child
5181 thereof, not at the level of the stream element (this helps to ensure
5182 that any such namespace declaration is routed and delivered with the
5183 stanza, instead of assumed from the stream).
5185 12.3. Well-Formedness
5187 A XMPP entity MUST NOT accept XML data from another entity if that
5188 data is not well-formed in accordance with both the definition of
5189 "well-formed" in Section 2.1 of [XML] and the definition of
5190 "namespace-well-formed" in Section 7 of [XML-NAMES]. In an XMPP
5191 entity receives XML data that is not so well-formed, it MUST return
5192 an ) or full JID
5934 ().
5936 15.14. Directory Harvesting
5938 To help prevent directory harvesting attacks, a server MUST NOT
5939 return different stanza errors if a potential attacker sends XML
5940 stanzas to an existing entity or a nonexistent entity. The stanza
5941 error returned in both cases SHOULD be
5961 16.2. XML Namespace Name for SASL Data
5963 A URN sub-namespace for SASL negotiation data in the Extensible
5964 Messaging and Presence Protocol (XMPP) is defined as follows. (This
5965 namespace name adheres to the format defined in [XML-REG].)
5967 URI: urn:ietf:params:xml:ns:xmpp-sasl
5968 Specification: XXXX
5969 Description: This is the XML namespace name for SASL negotiation
5970 data in the Extensible Messaging and Presence Protocol (XMPP) as
5971 defined by XXXX.
5972 Registrant Contact: IETF, XMPP Working Group,
5974 16.3. XML Namespace Name for Stream Errors
5976 A URN sub-namespace for stream error data in the Extensible Messaging
5977 and Presence Protocol (XMPP) is defined as follows. (This namespace
5978 name adheres to the format defined in [XML-REG].)
5980 URI: urn:ietf:params:xml:ns:xmpp-streams
5981 Specification: XXXX
5982 Description: This is the XML namespace name for stream error data in
5983 the Extensible Messaging and Presence Protocol (XMPP) as defined
5984 by XXXX.
5985 Registrant Contact: IETF, XMPP Working Group,
5987 16.4. XML Namespace Name for Resource Binding
5989 A URN sub-namespace for resource binding in the Extensible Messaging
5990 and Presence Protocol (XMPP) is defined as follows. (This namespace
5991 name adheres to the format defined in [XML-REG].)
5993 URI: urn:ietf:params:xml:ns:xmpp-bind
5994 Specification: XXXX
5995 Description: This is the XML namespace name for resource binding in
5996 the Extensible Messaging and Presence Protocol (XMPP) as defined
5997 by XXXX.
5998 Registrant Contact: IETF, XMPP Working Group,
6000 16.5. XML Namespace Name for Stanza Errors
6002 A URN sub-namespace for stanza error data in the Extensible Messaging
6003 and Presence Protocol (XMPP) is defined as follows. (This namespace
6004 name adheres to the format defined in [XML-REG].)
6006 URI: urn:ietf:params:xml:ns:xmpp-stanzas
6007 Specification: XXXX
6008 Description: This is the XML namespace name for stanza error data in
6009 the Extensible Messaging and Presence Protocol (XMPP) as defined
6010 by XXXX.
6012 Registrant Contact: IETF, XMPP Working Group,
6014 16.6. Nodeprep Profile of Stringprep
6016 The Nodeprep profile of stringprep is defined under Nodeprep
6017 (Appendix A). The IANA has registered Nodeprep in the stringprep
6018 profile registry.
6020 Name of this profile:
6022 Nodeprep
6024 RFC in which the profile is defined:
6026 XXXX
6028 Indicator whether or not this is the newest version of the profile:
6030 This is the first version of Nodeprep
6032 16.7. Resourceprep Profile of Stringprep
6034 The Resourceprep profile of stringprep is defined under Resourceprep
6035 (Appendix B). The IANA has registered Resourceprep in the stringprep
6036 profile registry.
6038 Name of this profile:
6040 Resourceprep
6042 RFC in which the profile is defined:
6044 XXXX
6046 Indicator whether or not this is the newest version of the profile:
6048 This is the first version of Resourceprep
6050 16.8. GSSAPI Service Name
6052 The IANA has registered "xmpp" as a GSSAPI [GSS-API] service name, as
6053 defined under Section 7.4.
6055 16.9. Port Numbers
6057 The IANA has registered "xmpp-client" and "xmpp-server" as keywords
6058 for [TCP] ports 5222 and 5269 respectively.
6060 These ports SHOULD be used for client-to-server and server-to-server
6061 communications respectively, but other ports MAY be used.
6063 17. References
6065 17.1. Normative References
6067 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
6068 Specifications: ABNF", RFC 4234, October 2005.
6070 [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data
6071 Encodings", RFC 4648, October 2006.
6073 [CHARSET] Alvestrand, H., "IETF Policy on Character Sets and
6074 Languages", BCP 18, RFC 2277, January 1998.
6076 [DIGEST-MD5]
6077 Leach, P. and C. Newman, "Using Digest Authentication as a
6078 SASL Mechanism", RFC 2831, May 2000.
6080 [DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
6081 specifying the location of services (DNS SRV)", RFC 2782,
6082 February 2000.
6084 [DNS] Mockapetris, P., "Domain names - implementation and
6085 specification", STD 13, RFC 1035, November 1987.
6087 [IDNA] Faltstrom, P., Hoffman, P., and A. Costello,
6088 "Internationalizing Domain Names in Applications (IDNA)",
6089 RFC 3490, March 2003.
6091 [IPv6] Hinden, R. and S. Deering, "IP Version 6 Addressing
6092 Architecture", RFC 4291, February 2006.
6094 [LANGTAGS]
6095 Phillips, A. and M. Davis, "Tags for Identifying
6096 Languages", BCP 47, RFC 4646, September 2006.
6098 [NAMEPREP]
6099 Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
6100 Profile for Internationalized Domain Names (IDN)",
6101 RFC 3491, March 2003.
6103 [PLAIN] Zeilenga, K., "The PLAIN Simple Authentication and
6104 Security Layer (SASL) Mechanism", RFC 4616, August 2006.
6106 [RANDOM] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
6107 Requirements for Security", BCP 106, RFC 4086, June 2005.
6109 [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
6110 Architecture", RFC 2373, July 1998.
6112 [SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and
6113 Security Layer (SASL)", RFC 4422, June 2006.
6115 [STRINGPREP]
6116 Hoffman, P. and M. Blanchet, "Preparation of
6117 Internationalized Strings ("stringprep")", RFC 3454,
6118 December 2002.
6120 [TCP] Postel, J., "Transmission Control Protocol", STD 7,
6121 RFC 793, September 1981.
6123 [TERMS] Bradner, S., "Key words for use in RFCs to Indicate
6124 Requirement Levels", BCP 14, RFC 2119, March 1997.
6126 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security
6127 (TLS) Protocol Version 1.1", RFC 4346, April 2006.
6129 [UCS2] International Organization for Standardization,
6130 "Information Technology - Universal Multiple-octet coded
6131 Character Set (UCS) - Amendment 2: UCS Transformation
6132 Format 8 (UTF-8)", ISO Standard 10646-1 Addendum 2,
6133 October 1996.
6135 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version
6136 3.2.0", 2000.
6138 The Unicode Standard, Version 3.2.0 is defined by The
6139 Unicode Standard, Version 3.0 (Reading, MA, Addison-
6140 Wesley, 2000. ISBN 0-201-61633-5), as amended by the
6141 Unicode Standard Annex #27: Unicode 3.1
6142 (http://www.unicode.org/reports/tr27/) and by the Unicode
6143 Standard Annex #28: Unicode 3.2
6144 (http://www.unicode.org/reports/tr28/).
6146 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
6147 10646", STD 63, RFC 3629, November 2003.
6149 [UUID] Leach, P., Mealling, M., and R. Salz, "A Universally
6150 Unique IDentifier (UUID) URN Namespace", RFC 4122,
6151 July 2005.
6153 [X509] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
6154 X.509 Public Key Infrastructure Certificate and
6155 Certificate Revocation List (CRL) Profile", RFC 3280,
6156 April 2002.
6158 [X509-SRV]
6159 Santesson, S., "Internet X.509 Public Key Infrastructure
6160 Subject Alternative Name for Expression of Service Name",
6161 RFC 4985, August 2007.
6163 [XML] Paoli, J., Maler, E., Sperberg-McQueen, C., Yergeau, F.,
6164 and T. Bray, "Extensible Markup Language (XML) 1.0 (Fourth
6165 Edition)", World Wide Web Consortium Recommendation REC-
6166 xml-20060816, August 2006,
6167 .
6169 [XML-NAMES]
6170 Bray, T., Hollander, D., and A. Layman, "Namespaces in
6171 XML", W3C REC-xml-names, January 1999,
6172 .
6174 17.2. Informative References
6176 [ACAP] Newman, C. and J. Myers, "ACAP -- Application
6177 Configuration Access Protocol", RFC 2244, November 1997.
6179 [ANONYMOUS]
6180 Zeilenga, K., "Anonymous Simple Authentication and
6181 Security Layer (SASL) Mechanism", RFC 4505, June 2006.
6183 [ASN.1] CCITT, "Recommendation X.208: Specification of Abstract
6184 Syntax Notation One (ASN.1)", 1988.
6186 [CHANNEL] Williams, N., "On the Use of Channel Bindings to Secure
6187 Channels", RFC 5056, November 2007.
6189 [DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S.
6190 Rose, "DNS Security Introduction and Requirements",
6191 RFC 4033, March 2005.
6193 [DNS-TXT] Rosenbaum, R., "Using the Domain Name System To Store
6194 Arbitrary String Attributes", RFC 1464, May 1993.
6196 [DOS] Handley, M., Rescorla, E., and IAB, "Internet Denial-of-
6197 Service Considerations", RFC 4732, December 2006.
6199 [GSS-API] Linn, J., "Generic Security Service Application Program
6200 Interface Version 2, Update 1", RFC 2743, January 2000.
6202 [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
6203 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
6204 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
6206 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
6207 4rev1", RFC 3501, March 2003.
6209 [IMP-REQS]
6210 Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging
6211 / Presence Protocol Requirements", RFC 2779,
6212 February 2000.
6214 [IRI] Duerst, M. and M. Suignard, "Internationalized Resource
6215 Identifiers (IRIs)", RFC 3987, January 2005.
6217 [LINKLOCAL]
6218 Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
6219 Configuration of IPv4 Link-Local Addresses", RFC 3927,
6220 May 2005.
6222 [MAILBOXES]
6223 Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND
6224 FUNCTIONS", RFC 2142, May 1997.
6226 [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
6227 STD 53, RFC 1939, May 1996.
6229 [PUNYCODE]
6230 Costello, A., "Punycode: A Bootstring encoding of Unicode
6231 for Internationalized Domain Names in Applications
6232 (IDNA)", RFC 3492, March 2003.
6234 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence
6235 Protocol (XMPP): Core", RFC 3920, October 2004.
6237 [RFC3921] Saint-Andre, P., Ed., "Extensible Messaging and Presence
6238 Protocol (XMPP): Instant Messaging and Presence",
6239 RFC 3921, October 2004.
6241 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
6242 April 2001.
6244 [STD13] Mockapetris, P., "Domain names - implementation and
6245 specification", STD 13, RFC 1035, November 1987.
6247 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
6248 Resource Identifier (URI): Generic Syntax", STD 66,
6249 RFC 3986, January 2005.
6251 [URN-OID] Mealling, M., "A URN Namespace of Object Identifiers",
6252 RFC 3061, February 2001.
6254 [USINGTLS]
6255 Newman, C., "Using TLS with IMAP, POP3 and ACAP",
6256 RFC 2595, June 1999.
6258 [XEP-0001]
6259 Saint-Andre, P., "XMPP Extension Protocols", XSF XEP 0001,
6260 December 2006.
6262 [XEP-0045]
6263 Saint-Andre, P., "Multi-User Chat", XSF XEP 0045,
6264 April 2007.
6266 [XEP-0060]
6267 Millard, P., Saint-Andre, P., and R. Meijer, "Publish-
6268 Subscribe", XSF XEP 0060, September 2007.
6270 [XEP-0071]
6271 Saint-Andre, P., "XHTML-IM", XSF XEP 0071, August 2007.
6273 [XEP-0077]
6274 Saint-Andre, P., "In-Band Registration", XSF XEP 0077,
6275 January 2006.
6277 [XEP-0124]
6278 Paterson, I., Smith, D., and P. Saint-Andre,
6279 "Bidirectional-streams Over Synchronous HTTP (BOSH)", XSF
6280 XEP 0124, February 2007.
6282 [XEP-0156]
6283 Hildebrand, J. and P. Saint-Andre, "Discovering
6284 Alternative XMPP Connection Methods", XSF XEP 0156,
6285 June 2007.
6287 [XEP-0157]
6288 Saint-Andre, P. and J. Konieczny, "Contact Addresses for
6289 XMPP Services", XSF XEP 0157, January 2007.
6291 [XEP-0165]
6292 Saint-Andre, P., "Best Practices to Prevent JID
6293 Mimicking", XSF XEP 0165, July 2007.
6295 [XEP-0174]
6296 Saint-Andre, P., "Link-Local Messaging", XSF XEP 0174,
6297 June 2007.
6299 [XEP-0175]
6300 Saint-Andre, P., "Best Practices for Use of SASL
6301 ANONYMOUS", XSF XEP 0175, September 2006.
6303 [XEP-0178]
6304 Saint-Andre, P. and P. Millard, "Best Practices for Use of
6305 SASL EXTERNAL with Certificates", XSF XEP 0178,
6306 February 2007.
6308 [XEP-0205]
6309 Saint-Andre, P., "Best Practices to Discourage Denial of
6310 Service Attacks", XSF XEP 0205, July 2007.
6312 [XEP-0206]
6313 Paterson, I., "XMPP Over BOSH", XSF XEP 0206, June 2007.
6315 [XEP-0220]
6316 Saint-Andre, P. and J. Miller, "Server Dialback", XSF
6317 XEP 0220, July 2007.
6319 [XML-REG] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
6320 January 2004.
6322 [XML-SCHEMA]
6323 Thompson, H., Maloney, M., Mendelsohn, N., and D. Beech,
6324 "XML Schema Part 1: Structures Second Edition", World Wide
6325 Web Consortium Recommendation REC-xmlschema-1-20041028,
6326 October 2004,
6327 .
6329 [XMPP-IM] Saint-Andre, P., "Extensible Messaging and Presence
6330 Protocol (XMPP): Instant Messaging and Presence",
6331 draft-saintandre-rfc3921bis-03 (work in progress),
6332 July 2007.
6334 [XMPP-URI]
6335 Saint-Andre, P., "Internationalized Resource Identifiers
6336 (IRIs) and Uniform Resource Identifiers (URIs) for the
6337 Extensible Messaging and Presence Protocol (XMPP)",
6338 RFC 5122, February 2008.
6340 Appendix A. Nodeprep
6342 A.1. Introduction
6344 This appendix defines the "Nodeprep" profile of stringprep. As such,
6345 it specifies processing rules that will enable users to enter
6346 internationalized node identifiers in the Extensible Messaging and
6347 Presence Protocol (XMPP) and have the highest chance of getting the
6348 content of the strings correct. (An XMPP node identifier is the
6349 optional portion of an XMPP address that precedes an XMPP domain
6350 identifier and the '@' separator; it is often but not exclusively
6351 associated with an instant messaging username.) These processing
6352 rules are intended only for XMPP node identifiers and are not
6353 intended for arbitrary text or any other aspect of an XMPP address.
6355 This profile defines the following, as required by [STRINGPREP]:
6357 o The intended applicability of the profile: internationalized node
6358 identifiers within XMPP
6359 o The character repertoire that is the input and output to
6360 stringprep: Unicode 3.2, specified in Section 2 of this Appendix
6361 o The mappings used: specified in Section 3
6362 o The Unicode normalization used: specified in Section 4
6363 o The characters that are prohibited as output: specified in Section
6364 5
6365 o Bidirectional character handling: specified in Section 6
6367 A.2. Character Repertoire
6369 This profile uses Unicode 3.2 with the list of unassigned code points
6370 being Table A.1, both defined in Appendix A of [STRINGPREP].
6372 A.3. Mapping
6374 This profile specifies mapping using the following tables from
6375 [STRINGPREP]:
6377 Table B.1
6378 Table B.2
6380 A.4. Normalization
6382 This profile specifies the use of Unicode normalization form KC, as
6383 described in [STRINGPREP].
6385 A.5. Prohibited Output
6387 This profile specifies the prohibition of using the following tables
6388 from [STRINGPREP].
6390 Table C.1.1
6391 Table C.1.2
6392 Table C.2.1
6393 Table C.2.2
6394 Table C.3
6395 Table C.4
6396 Table C.5
6397 Table C.6
6398 Table C.7
6399 Table C.8
6400 Table C.9
6402 In addition, the following Unicode characters are also prohibited:
6404 #x22 (QUOTATION MARK)
6405 #x26 (AMPERSAND)
6406 #x27 (APOSTROPHE)
6407 #x2F (SOLIDUS)
6408 #x3A (COLON)
6409 #x3C (LESS-THAN SIGN)
6410 #x3E (GREATER-THAN SIGN)
6411 #x40 (COMMERCIAL AT)
6413 A.6. Bidirectional Characters
6415 This profile specifies checking bidirectional strings, as described
6416 in Section 6 of [STRINGPREP].
6418 Appendix B. Resourceprep
6420 B.1. Introduction
6422 This appendix defines the "Resourceprep" profile of stringprep. As
6423 such, it specifies processing rules that will enable users to enter
6424 internationalized resource identifiers in the Extensible Messaging
6425 and Presence Protocol (XMPP) and have the highest chance of getting
6426 the content of the strings correct. (An XMPP resource identifier is
6427 the optional portion of an XMPP address that follows an XMPP domain
6428 identifier and the '/' separator.) These processing rules are
6429 intended only for XMPP resource identifiers and are not intended for
6430 arbitrary text or any other aspect of an XMPP address.
6432 This profile defines the following, as required by [STRINGPREP]:
6434 o The intended applicability of the profile: internationalized
6435 resource identifiers within XMPP
6437 o The character repertoire that is the input and output to
6438 stringprep: Unicode 3.2, specified in Section 2 of this Appendix
6439 o The mappings used: specified in Section 3
6440 o The Unicode normalization used: specified in Section 4
6441 o The characters that are prohibited as output: specified in Section
6442 5
6443 o Bidirectional character handling: specified in Section 6
6445 B.2. Character Repertoire
6447 This profile uses Unicode 3.2 with the list of unassigned code points
6448 being Table A.1, both defined in Appendix A of [STRINGPREP].
6450 B.3. Mapping
6452 This profile specifies mapping using the following tables from
6453 [STRINGPREP]:
6455 Table B.1
6457 B.4. Normalization
6459 This profile specifies the use of Unicode normalization form KC, as
6460 described in [STRINGPREP].
6462 B.5. Prohibited Output
6464 This profile specifies the prohibition of using the following tables
6465 from [STRINGPREP].
6467 Table C.1.2
6468 Table C.2.1
6469 Table C.2.2
6470 Table C.3
6471 Table C.4
6472 Table C.5
6473 Table C.6
6474 Table C.7
6475 Table C.8
6476 Table C.9
6478 B.6. Bidirectional Characters
6480 This profile specifies checking bidirectional strings, as described
6481 in Section 6 of [STRINGPREP].
6483 Appendix C. XML Schemas
6485 Because validation of XML streams and stanzas is optional, the
6486 following XML schemas are provided for descriptive purposes only.
6487 These schemas are not normative.
6489 The following schemas formally define various XML namespaces used in
6490 the core XMPP protocols, in conformance with [XML-SCHEMA]. For
6491 schemas defining the 'jabber:client' and 'jabber:server' namespaces,
6492 refer to [XMPP-IM].
6494 C.1. Streams namespace
6496
6498
6504
6512
6513
6515
6523
6524
6528
6529
6535
6536
6538
6544
6546
6547
6548
6550
6552
6553
6554
6555
6563
6564
6566
6568 C.2. Stream error namespace
6570
6572
6578
6604
6605
6630
6632
6633
6634
6635
6636
6638
6639
6640
6642
6643
6644
6646
6648
6650 C.3. STARTTLS namespace
6652
6654
6660
6661
6662
6663
6667
6668
6670
6674
6675
6677
6679
6681 C.4. SASL namespace
6683
6685
6691
6692
6693
6694
6707
6708
6710
6711
6712
6713
6714
6718
6719
6720
6722
6728
6729
6730
6731
6744
6746
6748
6750
6751
6752
6753
6754
6756
6757
6758
6760
6761
6762
6764
6766
6768 C.5. Resource binding namespace
6769
6771
6777
6778
6779
6780
6781
6784
6789
6790
6792
6793
6794
6795
6797
6798
6800
6801
6802
6805
6807
6808
6809
6812
6814
6816 C.6. Stanza error namespace
6817
6819
6825
6850
6851
6876
6878
6879
6880
6881
6882
6884
6885
6886
6888
6889
6890
6892
6894
6896 Appendix D. Contact Addresses
6898 Consistent with [MAILBOXES], an organization that offers an XMPP
6899 service should provide an Internet mailbox of "XMPP" for inquiries
6900 related to that service, where the host portion of the resulting
6901 mailto URI should be the organization's domain, not necessarily the
6902 domain of the XMPP service itself (e.g., the XMPP service might be
6903 offered at im.example.com but the Internet mailbox should be
6904 ).
6906 In addition, the XMPP service should provide a way to discover the
6907 XMPP contact address(es) of the service administrator(s), as
6908 specified in [XEP-0157].
6910 Appendix E. Account Provisioning
6912 Account provisioning is out of scope for this specification.
6913 Possible methods for account provisioning include account creation by
6914 a server administrator and in-band account registration using the
6915 'jabber:iq:register' namespace as documented in [XEP-0077].
6917 Appendix F. Differences From RFC 3920
6919 Based on consensus derived from implementation and deployment
6920 experience as well as formal interoperability testing, the following
6921 substantive modifications were made from RFC 3920.
6923 o Corrected the ABNF syntax for JIDs to prevent zero-length node
6924 identifiers, domain identifiers, and resource identifiers.
6925 o Corrected the nameprep processing rules to require use of the
6926 UseSTD3ASCIIRules flag.
6927 o Encouraged use of the 'from' and 'to' attributes on stream
6928 headers.
6929 o More fully specified stream closing handshake.
6930 o Specified recommended stream reconnection algorithm.
6931 o Specified return of