' 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 830
-- Looks like a reference, but probably isn't: '3' on line 5078
** 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 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'
** 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 2818 (ref.
'HTTP-TLS') (Obsoleted by RFC 9110)
-- 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: 10 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) October 5, 2007
5 Intended status: Standards Track
6 Expires: April 7, 2008
8 Extensible Messaging and Presence Protocol (XMPP): Core
9 draft-saintandre-rfc3920bis-04
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 April 7, 2008.
36 Copyright Notice
38 Copyright (C) The IETF Trust (2007).
40 Abstract
42 This document defines the core features of the Extensible Messaging
43 and Presence Protocol (XMPP), a technology for streaming Extensible
44 Markup Language (XML) elements in order to exchange structured
45 information in close to real time between any two or more network-
46 aware entities. XMPP provides a generalized, extensible framework
47 for incrementally exchanging XML data, upon which a variety of
48 applications can be built. The framework includes methods for stream
49 setup and teardown, channel encryption, authentication of a client to
50 a server and of one server to another server, and primitives for
51 push-style messages, publication of network availability information
52 ("presence"), and request-response interactions between any two XMPP
53 entities. This document also specifies the format for XMPP
54 addresses, which are fully internationalizable.
56 This document obsoletes RFC 3920.
58 Table of Contents
60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8
61 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 8
62 1.2. Functional Summary . . . . . . . . . . . . . . . . . . . 9
63 1.3. Conventions . . . . . . . . . . . . . . . . . . . . . . 10
64 1.4. Discussion Venue . . . . . . . . . . . . . . . . . . . . 10
65 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 10
66 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 10
67 2.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 11
68 2.3. Client . . . . . . . . . . . . . . . . . . . . . . . . . 12
69 2.4. Network . . . . . . . . . . . . . . . . . . . . . . . . 12
70 3. Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 12
71 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 12
72 3.2. Domain Identifier . . . . . . . . . . . . . . . . . . . 13
73 3.3. Node Identifier . . . . . . . . . . . . . . . . . . . . 14
74 3.4. Resource Identifier . . . . . . . . . . . . . . . . . . 15
75 3.5. Determination of Addresses . . . . . . . . . . . . . . . 15
76 4. TCP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 16
77 4.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . 16
78 4.2. Hostname Resolution . . . . . . . . . . . . . . . . . . 16
79 4.3. Client-to-Server Communications . . . . . . . . . . . . 17
80 4.4. Server-to-Server Communications . . . . . . . . . . . . 17
81 4.5. Other Bindings . . . . . . . . . . . . . . . . . . . . . 17
82 5. XML Streams . . . . . . . . . . . . . . . . . . . . . . . . . 17
83 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 17
84 5.2. Stream Security . . . . . . . . . . . . . . . . . . . . 19
85 5.3. Stream Attributes . . . . . . . . . . . . . . . . . . . 20
86 5.3.1. from . . . . . . . . . . . . . . . . . . . . . . . . 20
87 5.3.2. to . . . . . . . . . . . . . . . . . . . . . . . . . 21
88 5.3.3. id . . . . . . . . . . . . . . . . . . . . . . . . . 22
89 5.3.4. xml:lang . . . . . . . . . . . . . . . . . . . . . . 23
90 5.3.5. version . . . . . . . . . . . . . . . . . . . . . . 24
91 5.3.6. Summary . . . . . . . . . . . . . . . . . . . . . . 25
92 5.4. Namespace Declarations . . . . . . . . . . . . . . . . . 25
93 5.5. Stream Features . . . . . . . . . . . . . . . . . . . . 26
94 5.6. Closing Streams . . . . . . . . . . . . . . . . . . . . 27
95 5.7. Reconnection . . . . . . . . . . . . . . . . . . . . . . 27
96 5.8. Stream Errors . . . . . . . . . . . . . . . . . . . . . 28
97 5.8.1. Rules . . . . . . . . . . . . . . . . . . . . . . . 28
98 5.8.1.1. Stream Errors Are Unrecoverable . . . . . . . . . 28
99 5.8.1.2. Stream Errors Can Occur During Setup . . . . . . 28
100 5.8.1.3. Stream Errors When the Host is Unspecified . . . 29
101 5.8.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . 30
102 5.8.3. Defined Stream Error Conditions . . . . . . . . . . 31
103 5.8.3.1. bad-format . . . . . . . . . . . . . . . . . . . 31
104 5.8.3.2. bad-namespace-prefix . . . . . . . . . . . . . . 31
105 5.8.3.3. conflict . . . . . . . . . . . . . . . . . . . . 32
106 5.8.3.4. connection-timeout . . . . . . . . . . . . . . . 33
107 5.8.3.5. host-gone . . . . . . . . . . . . . . . . . . . . 33
108 5.8.3.6. host-unknown . . . . . . . . . . . . . . . . . . 34
109 5.8.3.7. improper-addressing . . . . . . . . . . . . . . . 35
110 5.8.3.8. internal-server-error . . . . . . . . . . . . . . 35
111 5.8.3.9. invalid-from . . . . . . . . . . . . . . . . . . 36
112 5.8.3.10. invalid-id . . . . . . . . . . . . . . . . . . . 36
113 5.8.3.11. invalid-namespace . . . . . . . . . . . . . . . . 37
114 5.8.3.12. invalid-xml . . . . . . . . . . . . . . . . . . . 37
115 5.8.3.13. not-authorized . . . . . . . . . . . . . . . . . 38
116 5.8.3.14. policy-violation . . . . . . . . . . . . . . . . 39
117 5.8.3.15. remote-connection-failed . . . . . . . . . . . . 40
118 5.8.3.16. resource-constraint . . . . . . . . . . . . . . . 40
119 5.8.3.17. restricted-xml . . . . . . . . . . . . . . . . . 41
120 5.8.3.18. see-other-host . . . . . . . . . . . . . . . . . 41
121 5.8.3.19. system-shutdown . . . . . . . . . . . . . . . . . 42
122 5.8.3.20. undefined-condition . . . . . . . . . . . . . . . 43
123 5.8.3.21. unsupported-encoding . . . . . . . . . . . . . . 43
124 5.8.3.22. unsupported-stanza-type . . . . . . . . . . . . . 44
125 5.8.3.23. unsupported-version . . . . . . . . . . . . . . . 44
126 5.8.3.24. xml-not-well-formed . . . . . . . . . . . . . . . 45
127 5.8.4. Application-Specific Conditions . . . . . . . . . . 46
128 5.9. Simplified Stream Examples . . . . . . . . . . . . . . . 46
129 6. STARTTLS Negotiation . . . . . . . . . . . . . . . . . . . . 48
130 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 49
131 6.2. Rules . . . . . . . . . . . . . . . . . . . . . . . . . 49
132 6.2.1. Data Formatting . . . . . . . . . . . . . . . . . . 49
133 6.2.2. Order of Negotiation . . . . . . . . . . . . . . . . 49
134 6.3. Process . . . . . . . . . . . . . . . . . . . . . . . . 49
135 6.3.1. Exchange of Stream Headers and Stream Features . . . 49
136 6.3.2. Initiation of STARTTLS Negotiation . . . . . . . . . 51
137 6.3.2.1. STARTTLS Command . . . . . . . . . . . . . . . . 51
138 6.3.2.2. Failure Case . . . . . . . . . . . . . . . . . . 51
139 6.3.2.3. Proceed Case . . . . . . . . . . . . . . . . . . 51
140 6.3.3. TLS Negotiation . . . . . . . . . . . . . . . . . . 52
141 6.3.3.1. Rules . . . . . . . . . . . . . . . . . . . . . . 52
142 6.3.3.2. TLS Failure . . . . . . . . . . . . . . . . . . . 52
143 6.3.3.3. TLS Success . . . . . . . . . . . . . . . . . . . 52
145 6.4. Representation of JIDs in Certificates . . . . . . . . . 54
146 6.4.1. Client Certificates . . . . . . . . . . . . . . . . 54
147 6.4.2. Server Certificates . . . . . . . . . . . . . . . . 54
148 6.4.3. ASN.1 Object Identifier . . . . . . . . . . . . . . 54
149 7. SASL Negotiation . . . . . . . . . . . . . . . . . . . . . . 55
150 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 55
151 7.2. Rules . . . . . . . . . . . . . . . . . . . . . . . . . 55
152 7.2.1. Data Formatting . . . . . . . . . . . . . . . . . . 55
153 7.2.2. Security Layers . . . . . . . . . . . . . . . . . . 56
154 7.2.3. Simple Usernames . . . . . . . . . . . . . . . . . . 56
155 7.2.4. Authorization Identities . . . . . . . . . . . . . . 56
156 7.3. Process . . . . . . . . . . . . . . . . . . . . . . . . 57
157 7.3.1. Exchange of Stream Headers and Stream Features . . . 57
158 7.3.2. Initiation . . . . . . . . . . . . . . . . . . . . . 59
159 7.3.3. Challenge-Response Sequence . . . . . . . . . . . . 59
160 7.3.4. Abort . . . . . . . . . . . . . . . . . . . . . . . 60
161 7.3.5. Failure . . . . . . . . . . . . . . . . . . . . . . 61
162 7.3.6. Success . . . . . . . . . . . . . . . . . . . . . . 61
163 7.4. SASL Definition . . . . . . . . . . . . . . . . . . . . 62
164 7.5. SASL Errors . . . . . . . . . . . . . . . . . . . . . . 63
165 7.5.1. aborted . . . . . . . . . . . . . . . . . . . . . . 63
166 7.5.2. incorrect-encoding . . . . . . . . . . . . . . . . . 63
167 7.5.3. invalid-authzid . . . . . . . . . . . . . . . . . . 64
168 7.5.4. invalid-mechanism . . . . . . . . . . . . . . . . . 64
169 7.5.5. malformed-request . . . . . . . . . . . . . . . . . 64
170 7.5.6. mechanism-too-weak . . . . . . . . . . . . . . . . . 65
171 7.5.7. not-authorized . . . . . . . . . . . . . . . . . . . 65
172 7.5.8. temporary-auth-failure . . . . . . . . . . . . . . . 65
173 8. Resource Binding . . . . . . . . . . . . . . . . . . . . . . 66
174 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 66
175 8.2. Advertising Support . . . . . . . . . . . . . . . . . . 66
176 8.3. Server-Generated Resource Identifier . . . . . . . . . . 67
177 8.3.1. Success Case . . . . . . . . . . . . . . . . . . . . 67
178 8.3.2. Error Case . . . . . . . . . . . . . . . . . . . . . 68
179 8.4. Client-Generated Resource Identifier . . . . . . . . . . 68
180 8.4.1. Success Case . . . . . . . . . . . . . . . . . . . . 68
181 8.4.2. Error Cases . . . . . . . . . . . . . . . . . . . . 69
182 8.4.2.1. Not Allowed . . . . . . . . . . . . . . . . . . . 69
183 8.4.2.2. Bad Request . . . . . . . . . . . . . . . . . . . 69
184 8.4.2.3. Conflict . . . . . . . . . . . . . . . . . . . . 69
185 8.5. Binding Multiple Resources . . . . . . . . . . . . . . . 70
186 8.5.1. Support . . . . . . . . . . . . . . . . . . . . . . 70
187 8.5.2. Binding an Additional Resource . . . . . . . . . . . 70
188 8.5.3. Unbinding a Resource . . . . . . . . . . . . . . . . 71
189 8.5.3.1. Success Case . . . . . . . . . . . . . . . . . . 71
190 8.5.3.2. Error Cases . . . . . . . . . . . . . . . . . . . 71
191 8.5.4. From Addresses . . . . . . . . . . . . . . . . . . . 72
192 9. XML Stanzas . . . . . . . . . . . . . . . . . . . . . . . . . 72
193 9.1. Common Attributes . . . . . . . . . . . . . . . . . . . 73
194 9.1.1. to . . . . . . . . . . . . . . . . . . . . . . . . . 73
195 9.1.1.1. Client-to-Server Streams . . . . . . . . . . . . 73
196 9.1.1.2. Server-to-Server Streams . . . . . . . . . . . . 73
197 9.1.2. from . . . . . . . . . . . . . . . . . . . . . . . . 74
198 9.1.2.1. Client-to-Server Streams . . . . . . . . . . . . 74
199 9.1.2.2. Server-to-Server Streams . . . . . . . . . . . . 75
200 9.1.3. id . . . . . . . . . . . . . . . . . . . . . . . . . 75
201 9.1.4. type . . . . . . . . . . . . . . . . . . . . . . . . 75
202 9.1.5. xml:lang . . . . . . . . . . . . . . . . . . . . . . 76
203 9.2. Basic Semantics . . . . . . . . . . . . . . . . . . . . 77
204 9.2.1. Message Semantics . . . . . . . . . . . . . . . . . 77
205 9.2.2. Presence Semantics . . . . . . . . . . . . . . . . . 77
206 9.2.3. IQ Semantics . . . . . . . . . . . . . . . . . . . . 77
207 9.3. Stanza Errors . . . . . . . . . . . . . . . . . . . . . 79
208 9.3.1. Rules . . . . . . . . . . . . . . . . . . . . . . . 79
209 9.3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . 79
210 9.3.3. Defined Conditions . . . . . . . . . . . . . . . . . 81
211 9.3.3.1. bad-request . . . . . . . . . . . . . . . . . . . 81
212 9.3.3.2. conflict . . . . . . . . . . . . . . . . . . . . 81
213 9.3.3.3. feature-not-implemented . . . . . . . . . . . . . 82
214 9.3.3.4. forbidden . . . . . . . . . . . . . . . . . . . . 82
215 9.3.3.5. gone . . . . . . . . . . . . . . . . . . . . . . 83
216 9.3.3.6. internal-server-error . . . . . . . . . . . . . . 83
217 9.3.3.7. item-not-found . . . . . . . . . . . . . . . . . 84
218 9.3.3.8. jid-malformed . . . . . . . . . . . . . . . . . . 84
219 9.3.3.9. not-acceptable . . . . . . . . . . . . . . . . . 85
220 9.3.3.10. not-allowed . . . . . . . . . . . . . . . . . . . 85
221 9.3.3.11. not-authorized . . . . . . . . . . . . . . . . . 85
222 9.3.3.12. not-modified . . . . . . . . . . . . . . . . . . 86
223 9.3.3.13. payment-required . . . . . . . . . . . . . . . . 87
224 9.3.3.14. recipient-unavailable . . . . . . . . . . . . . . 87
225 9.3.3.15. redirect . . . . . . . . . . . . . . . . . . . . 88
226 9.3.3.16. registration-required . . . . . . . . . . . . . . 88
227 9.3.3.17. remote-server-not-found . . . . . . . . . . . . . 89
228 9.3.3.18. remote-server-timeout . . . . . . . . . . . . . . 89
229 9.3.3.19. resource-constraint . . . . . . . . . . . . . . . 89
230 9.3.3.20. service-unavailable . . . . . . . . . . . . . . . 90
231 9.3.3.21. subscription-required . . . . . . . . . . . . . . 90
232 9.3.3.22. undefined-condition . . . . . . . . . . . . . . . 91
233 9.3.3.23. unexpected-request . . . . . . . . . . . . . . . 92
234 9.3.3.24. unknown-sender . . . . . . . . . . . . . . . . . 93
235 9.3.4. Application-Specific Conditions . . . . . . . . . . 93
236 9.4. Extended Content . . . . . . . . . . . . . . . . . . . . 94
237 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 95
238 10.1. Client-to-Server . . . . . . . . . . . . . . . . . . . . 95
239 10.1.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . 96
240 10.1.2. SASL . . . . . . . . . . . . . . . . . . . . . . . . 97
241 10.1.3. Resource Binding . . . . . . . . . . . . . . . . . . 99
242 10.1.4. Stanza Exchange . . . . . . . . . . . . . . . . . . 100
243 10.1.5. Close . . . . . . . . . . . . . . . . . . . . . . . 100
244 10.2. Server-to-Server Examples . . . . . . . . . . . . . . . 101
245 10.2.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . 101
246 10.2.2. SASL . . . . . . . . . . . . . . . . . . . . . . . . 103
247 10.2.3. Stanza Exchange . . . . . . . . . . . . . . . . . . 104
248 10.2.4. Close . . . . . . . . . . . . . . . . . . . . . . . 105
249 11. Server Rules for Processing XML Stanzas . . . . . . . . . . . 105
250 11.1. No 'to' Address . . . . . . . . . . . . . . . . . . . . 105
251 11.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 105
252 11.1.2. Message . . . . . . . . . . . . . . . . . . . . . . 106
253 11.1.3. Presence . . . . . . . . . . . . . . . . . . . . . . 106
254 11.1.4. IQ . . . . . . . . . . . . . . . . . . . . . . . . . 106
255 11.2. Local Domain . . . . . . . . . . . . . . . . . . . . . . 106
256 11.2.1. Mere Domain . . . . . . . . . . . . . . . . . . . . 106
257 11.2.2. Resource at Domain . . . . . . . . . . . . . . . . . 106
258 11.2.3. Node at Local Domain . . . . . . . . . . . . . . . . 107
259 11.3. Foreign Domain . . . . . . . . . . . . . . . . . . . . . 107
260 11.3.1. Existing Stream . . . . . . . . . . . . . . . . . . 107
261 11.3.2. No Existing Stream . . . . . . . . . . . . . . . . . 107
262 11.3.3. Error Handling . . . . . . . . . . . . . . . . . . . 108
263 12. XML Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 108
264 12.1. Restrictions . . . . . . . . . . . . . . . . . . . . . . 108
265 12.2. XML Namespace Names and Prefixes . . . . . . . . . . . . 109
266 12.2.1. Streams Namespace . . . . . . . . . . . . . . . . . 109
267 12.2.2. Default Namespace . . . . . . . . . . . . . . . . . 109
268 12.2.3. Extended Namespaces . . . . . . . . . . . . . . . . 110
269 12.3. Validation . . . . . . . . . . . . . . . . . . . . . . . 112
270 12.4. Inclusion of Text Declaration . . . . . . . . . . . . . 112
271 12.5. Character Encoding . . . . . . . . . . . . . . . . . . . 112
272 12.6. White Space . . . . . . . . . . . . . . . . . . . . . . 112
273 13. Compliance Requirements . . . . . . . . . . . . . . . . . . . 112
274 13.1. Servers . . . . . . . . . . . . . . . . . . . . . . . . 113
275 13.2. Clients . . . . . . . . . . . . . . . . . . . . . . . . 113
276 14. Internationalization Considerations . . . . . . . . . . . . . 114
277 15. Security Considerations . . . . . . . . . . . . . . . . . . . 114
278 15.1. High Security . . . . . . . . . . . . . . . . . . . . . 114
279 15.2. Certificate Validation . . . . . . . . . . . . . . . . . 115
280 15.3. Client-to-Server Communication . . . . . . . . . . . . . 115
281 15.4. Server-to-Server Communication . . . . . . . . . . . . . 116
282 15.5. Order of Layers . . . . . . . . . . . . . . . . . . . . 116
283 15.6. Lack of SASL Channel Binding to TLS . . . . . . . . . . 117
284 15.7. Mandatory-to-Implement Technologies . . . . . . . . . . 117
285 15.8. Firewalls . . . . . . . . . . . . . . . . . . . . . . . 118
286 15.9. Use of base64 in SASL . . . . . . . . . . . . . . . . . 118
287 15.10. Stringprep Profiles . . . . . . . . . . . . . . . . . . 118
288 15.11. Address Spoofing . . . . . . . . . . . . . . . . . . . . 119
289 15.11.1. Address Forging . . . . . . . . . . . . . . . . . . 119
290 15.11.2. Address Mimicking . . . . . . . . . . . . . . . . . 119
291 15.12. Denial of Service . . . . . . . . . . . . . . . . . . . 121
292 15.13. Presence Leaks . . . . . . . . . . . . . . . . . . . . . 122
293 15.14. Directory Harvesting . . . . . . . . . . . . . . . . . . 122
294 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 122
295 16.1. XML Namespace Name for TLS Data . . . . . . . . . . . . 123
296 16.2. XML Namespace Name for SASL Data . . . . . . . . . . . . 123
297 16.3. XML Namespace Name for Stream Errors . . . . . . . . . . 123
298 16.4. XML Namespace Name for Resource Binding . . . . . . . . 123
299 16.5. XML Namespace Name for Stanza Errors . . . . . . . . . . 124
300 16.6. Nodeprep Profile of Stringprep . . . . . . . . . . . . . 124
301 16.7. Resourceprep Profile of Stringprep . . . . . . . . . . . 124
302 16.8. GSSAPI Service Name . . . . . . . . . . . . . . . . . . 125
303 16.9. Port Numbers . . . . . . . . . . . . . . . . . . . . . . 125
304 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 125
305 17.1. Normative References . . . . . . . . . . . . . . . . . . 125
306 17.2. Informative References . . . . . . . . . . . . . . . . . 127
307 Appendix A. Nodeprep . . . . . . . . . . . . . . . . . . . . . . 130
308 A.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 130
309 A.2. Character Repertoire . . . . . . . . . . . . . . . . . . 131
310 A.3. Mapping . . . . . . . . . . . . . . . . . . . . . . . . 131
311 A.4. Normalization . . . . . . . . . . . . . . . . . . . . . 131
312 A.5. Prohibited Output . . . . . . . . . . . . . . . . . . . 131
313 A.6. Bidirectional Characters . . . . . . . . . . . . . . . . 132
314 Appendix B. Resourceprep . . . . . . . . . . . . . . . . . . . . 132
315 B.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 132
316 B.2. Character Repertoire . . . . . . . . . . . . . . . . . . 133
317 B.3. Mapping . . . . . . . . . . . . . . . . . . . . . . . . 133
318 B.4. Normalization . . . . . . . . . . . . . . . . . . . . . 133
319 B.5. Prohibited Output . . . . . . . . . . . . . . . . . . . 133
320 B.6. Bidirectional Characters . . . . . . . . . . . . . . . . 133
321 Appendix C. XML Schemas . . . . . . . . . . . . . . . . . . . . 133
322 C.1. Streams namespace . . . . . . . . . . . . . . . . . . . 134
323 C.2. Stream error namespace . . . . . . . . . . . . . . . . . 135
324 C.3. STARTTLS namespace . . . . . . . . . . . . . . . . . . . 137
325 C.4. SASL namespace . . . . . . . . . . . . . . . . . . . . . 137
326 C.5. Resource binding namespace . . . . . . . . . . . . . . . 139
327 C.6. Stanza error namespace . . . . . . . . . . . . . . . . . 141
328 Appendix D. Contact Addresses . . . . . . . . . . . . . . . . . 142
329 Appendix E. Account Provisioning . . . . . . . . . . . . . . . . 143
330 Appendix F. Differences From RFC 3920 . . . . . . . . . . . . . 143
331 Appendix G. Copying Conditions . . . . . . . . . . . . . . . . . 144
332 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
333 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 145
334 Intellectual Property and Copyright Statements . . . . . . . . . 146
336 1. Introduction
338 1.1. Overview
340 The Extensible Messaging and Presence Protocol (XMPP) is an
341 application profile of the Extensible Markup Language [XML] for
342 streaming XML data in close to real time between any two (or more)
343 network-aware entities. XMPP is typically used to exchange messages,
344 share presence information, and engage in structured request-response
345 interactions. The basic syntax and semantics of XMPP were developed
346 originally within the Jabber open-source community, mainly in 1999.
347 In late 2002, the XMPP Working Group was chartered with developing an
348 adaptation of the core Jabber protocol that would be suitable as an
349 IETF instant messaging (IM) and presence technology. As a result of
350 work by the XMPP WG, [RFC3920] and [RFC3921] were published in
351 October 2004, representing the most complete definition of XMPP at
352 that time.
354 As a result of extensive implementation and deployment experience
355 with XMPP since 2004, as well as more formal interoperability testing
356 carried out under the auspices of the XMPP Standards Foundation
357 (XSF), this document reflects consensus from the XMPP developer
358 community regarding XMPP's core XML streaming technology. In
359 particular, this document incorporates the following backward-
360 compatible changes from RFC 3920:
362 o Corrections and errata
363 o Additional examples throughout
364 o Clarifications and more complete specification of matters that
365 were underspecified
366 o Modifications to reflect updated technologies for which XMPP is a
367 using protocol, e.g., Transport Layer Security (TLS) and the
368 Simple Authentication and Security Layer (SASL)
369 o Definition of several additional error conditions
370 o Addition of TLS plus SASL PLAIN as a mandatory-to-implement
371 technology
372 o Definition of optional support for multiple resources over the
373 same connection
374 o Removal of historical documentation for the server dialback
375 protocol from this specification to a separate specification
377 Therefore, this document defines the core features of XMPP 1.0 and
378 obsoletes RFC 3920.
380 Note: The XMPP extensions required to provide the basic instant
381 messaging and presence functionality defined in [IMP-REQS] are
382 specified in [XMPP-IM].
384 1.2. Functional Summary
386 This non-normative section provides a developer-friendly, functional
387 summary of XMPP; refer to the sections that follow for a normative
388 definition of XMPP.
390 The purpose of XMPP is to enable the exchange of relatively small
391 pieces of structured data (called "XML stanzas") over a network
392 between any two (or more) entities. XMPP is implemented using a
393 client-server architecture, wherein a client must connect to a server
394 in order to gain access to the network and thus be allowed to
395 exchange XML stanzas with other entities. The process whereby a
396 client connects to a server, exchanges XML stanzas, and ends the
397 connection is:
399 1. Determine the hostname and port at which to connect
400 2. Open a TCP connection
401 3. Open an XML stream
402 4. Complete TLS negotiation for channel encryption (recommended)
403 5. Complete SASL negotiation for authentication
404 6. Bind a resource to the stream
405 7. Exchange an unbounded number of XML stanzas with other entities
406 on the network
407 8. Close the XML stream
408 9. Close the TCP connection
410 In the sections following discussion of XMPP architecture and XMPP
411 addresses, this document specifies how clients connect to servers and
412 specifies the basic semantics of XML stanzas. However, this document
413 does not define the "payloads" of the XML stanzas that might be
414 exchanged once a connection is successfully established; instead,
415 definition of such semantics is provided by XMPP extensionsl. For
416 example, [XMPP-IM] defines extensions for basic instant messaging and
417 presence functionality. In addition, various specifications produced
418 in the XSF's XEP series [XEP-0001] define extensions for a wide range
419 of more advanced functionality.
421 Within the client-server architecture used by XMPP, one server may
422 optionally connect to another server to enable inter-domain or inter-
423 server communication. For this to happen, the two servers must
424 negotiate a connection between themselves and then exchange XML
425 stanzas; the process for doing so is:
427 1. Determine the hostname and port at which to connect
428 2. Open a TCP connection
429 3. Open an XML stream
430 4. Complete TLS negotiation for channel encryption (recommended)
431 5. Complete SASL negotiation for authentication
432 6. Exchange an unbounded number of XML stanzas both directly for the
433 servers and indirectly on behalf of entities associated with each
434 server (e.g., connected clients)
435 7. Close the XML stream
436 8. Close the TCP connection
438 Note: Depending on local service policies, a service may wish to use
439 the older server dialback protocol to provide weak identity
440 verification in cases where SASL negotiation would not result in
441 strong authentication (e.g., because the certificate presented by the
442 peer service during TLS negotiation is self-signed and thus provides
443 only weak identity); for details, see [XEP-0220].
445 1.3. Conventions
447 The following keywords are to be interpreted as described in [TERMS]:
448 "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD",
449 "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".
451 In examples, lines have been wrapped for improved readability,
452 "[...]" means elision, and the following prepended strings are used:
454 o C: = client
455 o E: = any XMPP entity
456 o I: = initiating entity
457 o P: = peer server
458 o R: = receiving entity
459 o S: = server
460 o S1: = server1
461 o S2: = server2
463 1.4. Discussion Venue
465 The editor welcomes discussion and comments related to the topics
466 presented in this document. The preferred forum is the
467 mailing list, for which archives and
468 subscription information are available at
469 <>.
471 2. Architecture
473 2.1. Overview
475 XMPP assumes a client-server architecture, wherein a client utilizing
476 XMPP accesses a server (normally over a [TCP] connection) and servers
477 can also communicate with each other over TCP connections.
479 A simplified architectural diagram for a typical deployment is shown
480 here, where the entities have the following significance:
482 o romeo@example.net -- an XMPP user.
483 o example.net -- an XMPP server.
484 o example.com -- an XMPP server.
485 o juliet@example.com -- an XMPP user.
487 example.net -------------------- example.com
488 | |
489 | |
490 romeo@example.net juliet@example.com
492 Note: Architectures that employ the syntax of XML stanzas (Section 9)
493 but that establish peer-to-peer connections directly between clients
494 using technologies based on [LINKLOCAL] have been deployed, but such
495 architectures are not XMPP and are best described as "XMPP-like"; for
496 details, see [XEP-0174].
498 2.2. Server
500 A SERVER is an entity whose primary responsibilities are to:
502 o Manage XML streams (Section 5) with local clients and deliver XML
503 stanzas (Section 9) to those clients over the negotiated XML
504 streams.
505 o Subject to local service policies on server-to-server
506 communication, manage XML streams (Section 5) with foreign servers
507 and route XML stanzas (Section 9) to those servers over the
508 negotiated XML streams.
510 Depending on the application, the secondary responsibilities of an
511 XMPP server may include:
513 o Storing XML data that is used by clients (e.g., contact lists for
514 users of XMPP-based instant messaging and presence applications);
515 in this case, the relevant XML stanza is handled directly by the
516 server itself on behalf of the client and is not routed to a
517 foreign server or delivered to a local entity.
518 o Hosting local services that also use XMPP as the basis for
519 communication but that provide additional functionality beyond
520 that defined in this document or in [XMPP-IM]; examples include
521 multi-user conferencing services as specified in [XEP-0045] and
522 publish-subscribe services as specified in [XEP-0060].
524 2.3. Client
526 A CLIENT is an entity that establiishes an XML stream with a server
527 by authenticating using the credentials of a local account and that
528 then completes resource binding (Section 8) in order to enable
529 delivery of XML stanzas via the server to the client. A client then
530 uses XMPP to communicate with its server, other clients, and any
531 other accessible entities on a network. Multiple clients may connect
532 simultaneously to a server on behalf of a local account, where each
533 client is differentiated by the resource identifier portion of an
534 XMPP address (e.g., vs. ), as
535 defined under Section 3 and Section 8. The RECOMMENDED port for TCP
536 connections between a client and a server is 5222, as registered with
537 the IANA (see Section 16.9).
539 2.4. Network
541 Because each server is identified by a network address and because
542 server-to-server communication is a straightforward extension of the
543 client-to-server protocol, in practice the system consists of a
544 network of servers that inter-communicate. Thus, for example,
545 is able to exchange messages, presence, and
546 other information with . This pattern is familiar
547 from messaging protocols (such as [SMTP]) that make use of network
548 addressing standards. Communication between any two servers is
549 OPTIONAL. If enabled, such communication SHOULD occur over XML
550 streams that are bound to [TCP] connections. The RECOMMENDED port
551 for TCP connections between servers is 5269, as registered with the
552 IANA (see Section 16.9).
554 3. Addresses
556 3.1. Overview
558 An ENTITY is anything that is network-addressable and that can
559 communicate using XMPP. For historical reasons, the native address
560 of an XMPP entity is called a JABBER IDENTIFIER or JID. A valid JID
561 contains a set of ordered elements formed of an XMPP domain
562 identifier, node identifier, and resource identifier.
564 The syntax for a JID is defined as follows using the Augmented
565 Backus-Naur Form as specified in [ABNF].
567 jid = [ node "@" ] domain [ "/" resource ]
568 node = 1*(nodepoint)
569 ; a "nodepoint" is a UTF-8 encoded Unicode code
570 ; point that satisfies the Nodeprep profile of
571 ; stringprep
572 domain = fqdn / address-literal / idnlabel
573 fqdn = (idnlabel 1*("." idnlabel))
574 ; an "idnlabel" is an internationalized label
575 ; as described in RFC 3490
576 address-literal = IPv4address / IPv6address
577 ; the "IPv4address" and "IPv6address" rules are
578 ; defined in Appendix B of RFC 3513
579 resource = 1*(resourcepoint)
580 ; a "resourcepoint" is a UTF-8 encoded Unicode
581 ; code point that satisfies the Resourceprep
582 ; profile of stringprep
584 All JIDs are based on the foregoing structure. One common use of
585 this structure is to identify a messaging and presence account, the
586 server that hosts the account, and a connected resource (e.g., a
587 specific device) in the form of . However,
588 node types other than clients are possible; for example, a specific
589 chat room offered by a multi-user conference service (see [XEP-0045])
590 could be addressed as (where "room" is the name of the
591 chat room and "service" is the hostname of the multi-user conference
592 service) and a specific occupant of such a room could be addressed as
593 (where "nick" is the occupant's room nickname).
594 Many other JID types are possible (e.g., could be a
595 server-side script or service).
597 Each allowable portion of a JID (node identifier, domain identifier,
598 and resource identifier) MUST NOT be more than 1023 bytes in length,
599 resulting in a maximum total size (including the '@' and '/'
600 separators) of 3071 bytes.
602 Note: While the format of a JID is consistent with [URI], an entity's
603 address on an XMPP network MUST be a JID (without a URI scheme) and
604 not a [URI] or [IRI] as specified in [XMPP-URI]; the latter
605 specification is provided only for use by non-XMPP applications.
607 3.2. Domain Identifier
609 The DOMAIN IDENTIFIER portion of a JID is that portion after the '@'
610 character (if any) and before the '/' character (if any); it is the
611 primary identifier and is the only REQUIRED element of a JID (a mere
612 domain identifier is a valid JID). Typically a domain identifier
613 identifies the "home" server to which clients connect for XML routing
614 and data management functionality. (Note: A single server may
615 service multiple domain identifiers, i.e., multiple local domains.)
616 However, it is not necessary for an XMPP domain identifier to
617 identify an entity that provides core XMPP server functionality
618 (e.g., a domain identifier may identity an entity such as a multi-
619 user conference service, a publish-subscribe service, or a user
620 directory).
622 The domain identifier for every server or service that will
623 communicate over a network SHOULD be a fully qualified domain name
624 (see [DNS]) but MAY be either an IPv4 or IPv6 address or a text label
625 (commonly called an "unqualified hostname") that is resolvable on a
626 local network. If the domain identifier includes a final character
627 considered to be a label separator (dot) by [IDNA] or [STD13], this
628 character MUST be stripped from the domain identifier before the JID
629 of which it is a part is used for the purpose of routing an XML
630 stanza, comparing against another JID, or constructing an [XMPP-URI];
631 in particular, the character should be stripped before any other
632 canonicalization steps are taken (such as application of the
633 [NAMEPREP] profile of [STRINGPREP] or completion of the ToASCII
634 operation as described in [IDNA]).
636 A domain identifier MUST be an "internationalized domain name" as
637 defined in [IDNA], that is, "a domain name in which every label is an
638 internationalized label". When preparing a text label (consisting of
639 a sequence of Unicode code points) for representation as an
640 internationalized label in the process of constructing an XMPP domain
641 identifier or comparing two XMPP domain identifiers, an application
642 MUST ensure that for each text label it is possible to apply without
643 failing the ToASCII operation specified in [IDNA] with the
644 UseSTD3ASCIIRules flag set (thus forbidding ASCII code points other
645 than letters, digits, and hyphens). If the ToASCII operation can be
646 applied without failing, then the label is an internationalized
647 label. An internationalized domain name (and therefore an XMPP
648 domain identifier) is constructed from its constituent
649 internationalized labels by following the rules specified in [IDNA].
650 (Note: The ToASCII operation includes application of the [NAMEPREP]
651 profile of [STRINGPREP] and encoding using the algorithm specified in
652 [PUNYCODE]; for details, see [IDNA].)
654 3.3. Node Identifier
656 The NODE IDENTIFIER portion of a JID is an optional secondary
657 identifier placed before the domain identifier and separated from the
658 latter by the '@' character. Typically a node identifier uniquely
659 identifies the entity requesting and using network access provided by
660 a server (i.e., a local account), although it can also represent
661 other kinds of entities (e.g., a chat room associated with a multi-
662 user conference service). The entity represented by an XMPP node
663 identifier is addressed within the context of a specific domain.
664 When the domain is an XMPP server and the entity is a local account
665 on the server, the resulting address (of the form ) is
666 called a BARE JID.
668 A node identifier MUST be formatted such that the Nodeprep profile of
669 [STRINGPREP] can be applied without failing (see Appendix A). Before
670 comparing two node identifiers, an application MUST first apply the
671 Nodeprep profile to each identifier.
673 3.4. Resource Identifier
675 The RESOURCE IDENTIFIER portion of a JID is an optional tertiary
676 identifier placed after the domain identifier and separated from the
677 latter by the '/' character. A resource identifier may modify either
678 a address or a mere address. Typically a
679 resource identifier uniquely identifies a specific connection (e.g.,
680 a device or location) or object (e.g., a participant in a multi-user
681 conference room) belonging to the entity associated with an XMPP node
682 identifier at a local domain. XMPP entities SHOULD consider resource
683 identifiers to be opaque strings and SHOULD NOT impute meaning to any
684 given resource identifier. A resource identifier is negotiated
685 between a client and a server during resource binding (Section 8),
686 after which the entity is referred to as a CONNECTED RESOURCE and its
687 address (of the form ) is referred to as a FULL
688 JID. An entity MAY maintain multiple connected resources
689 simultaneously, with each connected resource differentiated by a
690 distinct resource identifier.
692 A resource identifier MUST be formatted such that the Resourceprep
693 profile of [STRINGPREP] can be applied without failing (see
694 Appendix B). Before comparing two resource identifiers, an
695 application MUST first apply the Resourceprep profile to each
696 identifier.
698 3.5. Determination of Addresses
700 After SASL negotiation (Section 7) and, if appropriate, resource
701 binding (Section 8), the receiving entity for a stream MUST determine
702 the initiating entity's JID.
704 For server-to-server communication, the initiating entity's JID
705 SHOULD be the authorization identity (as defined by [SASL]), either
706 (1) as directly communicated by the initiating entity during SASL
707 negotiation (Section 7) or (2) as derived from the authentication
708 identity if no authorization identity was specified during SASL
709 negotiation (Section 7).
711 For client-to-server communication, the client's bare JID
712 () SHOULD be the authorization identity (as defined by
713 [SASL]), either (1) as directly communicated by the initiating entity
714 during SASL negotiation (Section 7) or (2) as derived from the
715 authentication identity if no authorization identity was specified
716 during SASL negotiation (Section 7). The resource identifier portion
717 of the full JID () SHOULD be the resource
718 identifier negotiated by the client and server during resource
719 binding (Section 8).
721 The receiving entity MUST ensure that the resulting JID (including
722 node identifier, domain identifier, resource identifier, and
723 separator characters) conforms to the rules and formats defined
724 earlier in this section; to meet this restriction, the receiving
725 entity may need to replace the JID sent by the initiating entity with
726 the canonicalized JID as determined by the receiving entity.
728 4. TCP Binding
730 4.1. Scope
732 As XMPP is defined in this specification, an initiating entity
733 (client or server) MUST open a Transmission Control Protocol [TCP]
734 connection at the receiving entity (server) before it negotiates XML
735 streams with the receiving entity. The rules specified in the
736 following sections apply to the TCP binding.
738 4.2. Hostname Resolution
740 Before opening the TCP connection, the initiating entity first MUST
741 resolve the Domain Name System (DNS) hostname associated with the
742 receiving entity and determine the appropriate TCP port for
743 communication with the receiving entity. The process is:
745 1. Attempt to resolve the hostname using a [DNS-SRV] Service of
746 "xmpp-client" (for client-to-server connections) or "xmpp-server"
747 (for server-to-server connections) and Proto of "tcp", resulting
748 in resource records such as "_xmpp-client._tcp.example.com." or
749 "_xmpp-server._tcp.example.com.". The result of the SRV lookup
750 will be one or more combinations of a port and hostname; the
751 initiating entity MUST resolve one of the hostnames in order to
752 determine an IP address at which to connect.
753 2. If the SRV lookup fails, the fallback SHOULD be a normal IPv4 or
754 [IPv6] address record resolution to determine the IP address,
755 where the port used is the "xmpp-client" port of 5222 for client-
756 to-server connections or the "xmpp-server" port 5269 for server-
757 to-server connections.
759 3. For client-to-server connections, the fallback MAY be a [DNS-TXT]
760 lookup for alternative connection methods, for example as
761 described in [XEP-0156].
763 4.3. Client-to-Server Communications
765 Because a client is subordinate to a server and therefore a client
766 authenticates to the server but the server does not authenticate to
767 the client, it is necessary to have only one TCP connection between
768 client and server. Thus the server MUST allow the client to share a
769 single TCP connection for XML stanzas sent from client to server and
770 from server to client (i.e., the inital stream and response stream as
771 specified under Section 5).
773 4.4. Server-to-Server Communications
775 Because two servers are peers and therefore each peer must
776 authenticate with the other, the servers MUST use two TCP
777 connections: one for XML stanzas sent from the first server to the
778 second server and another (initiated by the second server) for XML
779 stanzas from the second server to the first server.
781 This rule applies only to XML stanzas (Section 9). Therefore during
782 STARTTLS negotiation (Section 6) and SASL negotiation (Section 7) the
783 servers would use one TCP connection, but after stream setup that TCP
784 connection would be used only for the initiating server to send XML
785 stanzas to the receiving server. In order for the receiving server
786 to send XML stanzas to the initiating server, the receiving server
787 would need to reverse the roles and negotiate an XML stream from the
788 receiving server to the initiating server.
790 4.5. Other Bindings
792 There is no necessary coupling of an XML stream to a TCP connection.
793 For example, two entities could connect to each other via another
794 transport, such as [HTTP] as specified in [XEP-0124] and [XEP-0206].
795 However, this specification defines a binding of XMPP to TCP only.
797 5. XML Streams
799 5.1. Overview
801 Two fundamental concepts make possible the rapid, asynchronous
802 exchange of relatively small payloads of structured information
803 between presence-aware entities: XML streams and XML stanzas. These
804 terms are defined as follows.
806 Definition of XML Stream: An XML STREAM is a container for the
807 exchange of XML elements between any two entities over a network.
808 The start of an XML stream is denoted unambiguously by an opening
809 STREAM HEADER (i.e., an XML tag with appropriate
810 attributes and namespace declarations), while the end of the XML
811 stream is denoted unambiguously by a closing XML tag.
812 During the life of the stream, the entity that initiated it can
813 send an unbounded number of XML elements over the stream, either
814 elements used to negotiate the stream (e.g., to complete TLS
815 negotiation (Section 6) or SASL negotiation (Section 7)) or XML
816 stanzas. The INITIAL STREAM is negotiated from the initiating
817 entity (typically a client or server) to the receiving entity
818 (typically a server), and can be seen as corresponding to the
819 initiating entity's "connection" or "session" with the receiving
820 entity. The initial stream enables unidirectional communication
821 from the initiating entity to the receiving entity; in order to
822 enable information exchange from the receiving entity to the
823 initiating entity, the receiving entity MUST negotiate a stream in
824 the opposite direction (the RESPONSE STREAM).
825 Definition of XML Stanza: An XML STANZA is a discrete semantic unit
826 of structured information that is sent from one entity to another
827 over an XML stream. An XML stanza is the basic unit of meaning in
828 XMPP. An XML stanza exists at the direct child level of the root
829 ), and the end of any XML stanza
833 is denoted unambiguously by the corresponding close tag at depth=1
834 (e.g., ); a server MUST NOT process a partial stanza
835 and MUST NOT attach meaning to the transmission timing of any part
836 of a stanza (before receipt of the close tag). The only XML
837 stanzas defined herein are the |
866 |--------------------|
867 | |
868 | |
870 |--------------------|
871 | |
872 | |
873 | |
874 |--------------------|
875 | |
876 | |
878 |--------------------|
879 | |
880 | |
882 |--------------------|
883 | [ ... ] |
884 |--------------------|
885 | |
886 +--------------------+
888 Note: Those who are accustomed to thinking of XML in a document-
889 centric manner may wish to view a client's connection to a server as
890 consisting of two open-ended XML documents: one from the client to
891 the server and one from the server to the client. From this
892 perspective, the root ) of the entity
930 controlling the client.
932 C:
933
941 In server-to-server communication, the 'from' attribute SHOULD be
942 included in the initial stream header and (if included) MUST be set
943 to a hostname serviced by the initiating entity.
945 P:
946
954 In both client-to-server and server-to-server communications, the
955 'from' attribute MUST be included in the response stream header and
956 MUST be set to a hostname serviced by the receiving entity that is
957 granting access to the initiating entity.
959 S:
960
969 Note: Each entity MUST verify the identity of the other entity before
970 exchanging XML stanzas with it (see Section 15.3 and Section 15.4).
972 5.3.2. to
974 In both client-to-server and server-to-server communications, the
975 'to' attribute SHOULD be included in the initial stream header and
976 (if included) MUST be set to a hostname serviced by the receiving
977 entity.
979 C:
980
988 In client-to-server communication, if the client included a 'from'
989 address in the initial stream header then the server SHOULD include a
990 'to' attribute in the response stream header and (if included) MUST
991 set the 'to' attribute to the bare JID specified in the 'from'
992 attribute of the initial stream header.
994 S:
995
1004 In server-to-server communication, if the initiating entity included
1005 a 'from' address in the initial stream header then the receiving
1006 entity SHOULD include a 'to' attribute in the response stream header
1007 and (if included) MUST set the 'to' attribute to the hostname
1008 specified in the 'from' attribute of the initial stream header.
1010 S:
1011
1020 Note: Each entity MUST verify the identity of the other entity before
1021 exchanging XML stanzas with it (see Section 15.3 and Section 15.4).
1023 5.3.3. id
1025 There SHOULD NOT be an 'id' attribute in the initial stream header;
1026 however, if an 'id' attribute is included, it SHOULD be silently
1027 ignored by the receiving entity.
1029 C:
1030
1038 The 'id' attribute MUST be included in the response XML stream
1039 header. This attribute is a unique identifier created by the
1040 receiving entity to function as a identifier for the initiating
1041 entity's two streams with the receiving entity, and MUST be unique
1042 within the receiving application (normally a server).
1044 S:
1045
1054 Note: The stream ID may be security-critical and therefore MUST be
1055 both unpredictable and nonrepeating (see [RANDOM] for recommendations
1056 regarding randomness for security purposes).
1058 5.3.4. xml:lang
1060 An 'xml:lang' attribute (as defined in Section 2.12 of [XML]) SHOULD
1061 be included in the initial stream header to specify the default
1062 language of any human-readable XML character data it sends over that
1063 stream.
1065 C:
1066
1074 If the attribute is included, the receiving entity SHOULD remember
1075 that value as the default for both the initial stream and the
1076 response stream; if the attribute is not included, the receiving
1077 entity SHOULD use a configurable default value for both streams,
1078 which it MUST communicate in the response stream header.
1080 S:
1081
1090 For all stanzas sent over the initial stream, if the initiating
1091 entity does not include an 'xml:lang' attribute, the receiving entity
1092 SHOULD apply the default value; if the initiating entity does include
1093 an 'xml:lang' attribute, the receiving entity MUST NOT modify or
1094 delete it (see also Section 9.1.5). The value of the 'xml:lang'
1095 attribute MUST conform to the NMTOKEN datatype (as defined in Section
1096 2.3 of [XML]) and MUST conform to the format defined in [LANGTAGS].
1098 5.3.5. version
1100 The presence of the version attribute set to a value of at least
1101 "1.0" signals support for the stream-related protocols (including
1102 stream features) defined in this specification.
1104 The version of XMPP specified herein is "1.0"; in particular, XMPP
1105 1.0 encapsulates the stream-related protocols (TLS negotiation
1106 (Section 6), SASL negotiation (Section 7), and stream errors
1107 (Section 5.8)), as well as the basic semantics of the three defined
1108 XML stanza types (.". The
1111 major and minor numbers MUST be treated as separate integers and each
1112 number MAY be incremented higher than a single digit. Thus, "XMPP
1113 2.4" would be a lower version than "XMPP 2.13", which in turn would
1114 be lower than "XMPP 12.3". Leading zeros (e.g., "XMPP 6.01") MUST be
1115 ignored by recipients and MUST NOT be sent.
1117 The major version number should be incremented only if the stream and
1118 stanza formats or required actions have changed so dramatically that
1119 an older version entity would not be able to interoperate with a
1120 newer version entity if it simply ignored the elements and attributes
1121 it did not understand and took the actions specified in the older
1122 specification.
1124 The minor version number should be incremented only if significant
1125 new capabilities have been added to the core protocol (e.g., a newly
1126 defined value of the 'type' attribute for message, presence, or IQ
1127 stanzas). The minor version number MUST be ignored by an entity with
1128 a smaller minor version number, but MAY be used for informational
1129 purposes by the entity with the larger minor version number (e.g.,
1130 the entity with the larger minor version number would simply note
1131 that its correspondent would not be able to understand that value of
1132 the 'type' attribute and therefore would not send it).
1134 The following rules apply to the generation and handling of the
1135 'version' attribute within stream headers:
1137 1. The initiating entity MUST set the value of the 'version'
1138 attribute in the initial stream header to the highest version
1139 number it supports (e.g., if the highest version number it
1140 supports is that defined in this specification, it MUST set the
1141 value to "1.0").
1142 2. The receiving entity MUST set the value of the 'version'
1143 attribute in the response stream header to either the value
1144 supplied by the initiating entity or the highest version number
1145 supported by the receiving entity, whichever is lower. The
1146 receiving entity MUST perform a numeric comparison on the major
1147 and minor version numbers, not a string match on
1148 ".".
1149 3. If the version number included in the response stream header is
1150 at least one major version lower than the version number included
1151 in the initial stream header and newer version entities cannot
1152 interoperate with older version entities as described, the
1153 initiating entity SHOULD generate an
1206 S:
1207
1208
1210
1212 Stream features are used mainly to advertise TLS negotiation
1213 (Section 6), SASL negotiation (Section 7), and resource binding
1214 (Section 8); however, stream features also can be used to advertise
1215 features associated with various XMPP extensions. If an entity does
1216 not understand or support a feature, it SHOULD silently ignore the
1217 associated feature.
1219 If one or more security features (e.g., TLS and SASL) need to be
1220 successfully negotiated before a non-security-related feature (e.g.,
1221 resource binding) can be offered, the non-security-related feature
1222 SHOULD NOT be included in the stream features that are advertised
1223 before the relevant security features have been negotiated.
1225 If a feature must be negotiated before the initiating entity may
1226 proceed, that feature SHOULD include a
1243 S:
1253 The entity that sends the closing stream tag SHOULD wait for the
1254 other entity to also close its stream:
1256 S:
1258 However, the entity that sends the first closing stream tag MAY
1259 consider both streams to be void if the other entity does not send
1260 its closing stream tag within a reasonable amount of time (where the
1261 definition of "reasonable" is left up to the implementation or
1262 deployment).
1264 After an entity sends a closing stream tag, it MUST NOT send further
1265 data over that stream.
1267 After the entity that sent the first closing stream tag receives a
1268 reciprocal closing stream tag from the other entity, it MUST
1269 terminate the underlying TCP connection or connections.
1271 Note: Closing of XML streams is handled differently in the case of a
1272 stream error; see Section 5.8.1.1.
1274 5.7. Reconnection
1276 It can happen that an XMPP server goes offline while servicing
1277 connections from local clients and from other servers. Because the
1278 number of such connections can be quite large, the reconnection
1279 algorithm employed by entities that seek to reconnect can have a
1280 significant impact on software and network performance. The
1281 following guidelines are RECOMMENDED:
1283 o The time to live (TTL) specified in Domain Name System records
1284 SHOULD be honored, even if DNS results are cached; if the TTL has
1285 not expired, an entity that seeks to reconnect SHOULD NOT re-
1286 resolve the server hostname before reconnecting.
1287 o The time that expires before an entity first seeks to reconnect
1288 SHOULD be randomized (e.g., so that all clients do not attempt to
1289 reconnect 30 seconds after being disconnected).
1290 o If the first reconnection attempt does not succeed, an entity
1291 SHOULD back off exponentially on the time between subsequent
1292 reconnection attempts.
1294 5.8. Stream Errors
1296 The root stream element MAY contain an
1315
1318
1320 5.8.1.2. Stream Errors Can Occur During Setup
1322 If the error occurs while the stream is being set up, the receiving
1323 entity MUST still send the opening tag, include the
1325 tag, and immediately terminate the underlying TCP connection.
1327 C:
1328
1336 S:
1337
1346
1351 5.8.1.3. Stream Errors When the Host is Unspecified
1353 If the initiating entity provides no 'to' attribute or provides an
1354 unknown host in the 'to' attribute and the error occurs during stream
1355 setup, the receiving entity SHOULD provide its authoritative hostname
1356 in the 'from' attribute of the stream header sent before termination.
1358 C:
1359
1366 S:
1367
1375
1376
1379
1381 5.8.2. Syntax
1383 The syntax for stream errors is as follows, where "defined-condition"
1384 is a placeholder for one of the conditions defined under
1385 Section 5.8.3.
1387
1388
1391 [ ... descriptive text ... ]
1392 ]
1393 [application-specific condition element]
1394
1396 The
1432 No closing body tag!
1433
1435 S:
1436
1439
1441 This error MAY be used instead of the more specific XML-related
1442 errors, such as
1462 S:
1463
1471
1472
1475
1477 5.8.3.3. conflict
1479 The server is either (1) closing the existing stream for this entity
1480 because a new stream has been initiated that conflicts with the
1481 existing stream, or (2) is refusing a new stream for this entity
1482 because allowing the new stream would conflict with an existing
1483 stream (e.g., because the server allows only a certain number of
1484 connections from the same IP address).
1486 C:
1487
1494 S:
1495
1503
1504
1507
1509 5.8.3.4. connection-timeout
1511 The entity has not generated any traffic over the stream for some
1512 period of time (configurable according to a local service policy) and
1513 therefore the connection is being dropped.
1515 P:
1516
1519
1521 5.8.3.5. host-gone
1523 The value of the 'to' attribute provided in the initial stream header
1524 corresponds to a hostname that is no longer hosted by the receiving
1525 entity.
1527 (In the following example, the peer specifies a 'to' address of
1528 "foo.example.com" when connecting to the "example.com" server, but
1529 the server no longer hosts a service at that address.)
1530 P:
1531
1538 S:
1539
1547
1548
1551
1553 5.8.3.6. host-unknown
1555 The value of the 'to' attribute provided by in the initial stream
1556 header does not correspond to a hostname that is hosted by the
1557 receiving entity.
1559 (In the following example, the peer specifies a 'to' address of
1560 "example.org" when connecting to the "example.com" server, but the
1561 server knows nothing of that address.)
1562 P:
1563
1570 S:
1571
1579
1580
1583
1585 5.8.3.7. improper-addressing
1587 A stanza sent between two servers lacks a 'to' or 'from' attribute
1588 (or the attribute has no value).
1590 (In the following example, the peer sends a stanza without a 'to'
1591 address.)
1593 P:
1594 Wherefore art thou?
1595
1597 S:
1598
1601
1603 5.8.3.8. internal-server-error
1605 The server has experienced a misconfiguration or an otherwise-
1606 undefined internal error that prevents it from servicing the stream.
1608 S:
1609
1612
1614 5.8.3.9. invalid-from
1616 The JID or hostname provided in a 'from' address does not match an
1617 authorized JID or validated domain negotiated between servers via
1618 SASL, or between a client and a server via authentication and
1619 resource binding.
1621 (In the following example, a peer that has authenticated only as
1622 "example.net" attempts to send a stanza from an address at
1623 "example.org".)
1625 P:
1626 Neither, fair saint, if either thee dislike.
1627
1629 S:
1630
1633
1635 5.8.3.10. invalid-id
1637 The stream ID or server dialback ID is invalid or does not match an
1638 ID previously provided.
1640 (In the following example, the server dialback ID is invalid; see
1641 [XEP-0220].)
1643 P:
1650
1653
1655 5.8.3.11. invalid-namespace
1657 The streams namespace name is something other than
1658 "http://etherx.jabber.org/streams" (see Section 12.2).
1660 (In the following example, the client specifies a streams namespace
1661 of 'http://wrong.namespace.example.org/' instead of the correct
1662 namespace of "http://etherx.jabber.org/streams".)
1664 C:
1665
1672 S:
1673
1681
1682
1685
1687 5.8.3.12. invalid-xml
1689 The entity has sent invalid XML over the stream to a server that
1690 performs validation (see Section 12.3).
1692 (In the following example, the peer attempts to send an IQ stanza of
1693 type "subscribe" but there is no such value for the 'type'
1694 attribute.)
1695 P:
1699
1702 S:
1703
1706
1708 5.8.3.13. not-authorized
1710 The entity has attempted to send XML stanzas before the stream has
1711 been authenticated, or otherwise is not authorized to perform an
1712 action related to stream negotiation; the receiving entity MUST NOT
1713 process the offending stanza before sending the stream error.
1715 (In the following example, the client attempts to send XML stanzas
1716 before authenticating with the server.)
1717 C:
1718
1725 S:
1726
1736 Wherefore art thou?
1737
1739 S:
1740
1743
1745 5.8.3.14. policy-violation
1747 The entity has violated some local service policy (e.g., the stanza
1748 exceeds a configured size limit); the server MAY choose to specify
1749 the policy in the
1756 [ ... the-emacs-manual ... ]
1757
1759 S:
1760
1764 S:
1766 5.8.3.15. remote-connection-failed
1768 The server is unable to properly connect to a remote entity that is
1769 required for authentication or authorization.
1771 C:
1772
1779 S:
1780
1788
1789
1792
1794 5.8.3.16. resource-constraint
1796 The server lacks the system resources necessary to service the
1797 stream.
1799 C:
1800
1807 S:
1808
1816
1817
1820
1822 5.8.3.17. restricted-xml
1824 The entity has attempted to send restricted XML features such as a
1825 comment, processing instruction, DTD, entity reference, or unescaped
1826 character (see Section 12.1).
1828 (In the following example, the client sends an XMPP message
1829 containing an XML comment.)
1831 C:
1832
1833 This message has no subject.
1834
1836 S:
1837
1840
1842 5.8.3.18. see-other-host
1844 The server will not provide service to the initiating entity but is
1845 redirecting traffic to another host; the XML character data of the
1846
1863 S:
1864
1872
1873
1875 xmpp.example.com:9090
1876
1877
1878
1880 5.8.3.19. system-shutdown
1882 The server is being shut down and all active streams are being
1883 closed.
1885 S:
1886
1889
1891 5.8.3.20. undefined-condition
1893 The error condition is not one of those defined by the other
1894 conditions in this list; this error condition SHOULD be used only in
1895 conjunction with an application-specific condition.
1897 S:
1898
1902
1904 5.8.3.21. unsupported-encoding
1906 The initiating entity has encoded the stream in an encoding that is
1907 not supported by the server (see Section 12.5).
1909 (In the following example, the client attempts to encode data using
1910 UTF-16 instead of UTF-8.)
1912 C:
1913
1920 S:
1921
1930
1935 5.8.3.22. unsupported-stanza-type
1937 The initiating entity has sent a first-level child of the stream that
1938 is not supported by the server or consistent with the default
1939 namespace.
1941 (In the following example, the client attempts to send an XML stanza
1942 of
1945
1946 -
1947
1948 Soliloquy
1949
1950 To be, or not to be: that is the question:
1951 Whether 'tis nobler in the mind to suffer
1952 The slings and arrows of outrageous fortune,
1953 Or to take arms against a sea of troubles,
1954 And by opposing end them?
1955
1956
1958 tag:denmark.lit,2003:entry-32397
1959 2003-12-13T18:30:02Z
1960 2003-12-13T18:30:02Z
1961
1962
1963
1964
1966 S:
1967
1970
1972 5.8.3.23. unsupported-version
1974 The value of the 'version' attribute provided by the initiating
1975 entity in the stream header specifies a version of XMPP that is not
1976 supported by the server; the server MAY specify the version(s) it
1977 supports in the
1989 S:
1990
1999
2002 1.0, 1.1
2003
2004
2005
2007 5.8.3.24. xml-not-well-formed
2009 The initiating entity has sent XML that is not well-formed as defined
2010 by [XML].
2012 (In the following example, the client sends an XMPP message that is
2013 not well-formed XML.)
2015 C:
2016 No closing body tag!
2017
2019 S:
2020
2023
2025 5.8.4. Application-Specific Conditions
2027 As noted, an application MAY provide application-specific stream
2028 error information by including a properly-namespaced child in the
2029 error element. The application-specific element SHOULD supplement or
2030 further qualify a defined element. Thus the
2034
2035 My keyboard layout is:
2037 QWERTYUIOP{}|
2038 ASDFGHJKL:"
2039 ZXCVBNM<>?
2040
2041
2043 S:
2044
2047 Some special application diagnostic information!
2048
2049
2051
2053 5.9. Simplified Stream Examples
2055 This section contains two simplified examples of a stream-based
2056 connection of a client on a server; these examples are included for
2057 the purpose of illustrating the concepts introduced thus far.
2059 A basic connection:
2061 C:
2062
2071
2080 [ ... channel encryption ... ]
2082 [ ... authentication ... ]
2084 [ ... resource binding ... ]
2086 C:
2089 Art thou not Romeo, and a Montague?
2090
2092 S:
2095 Neither, fair saint, if either thee dislike.
2096
2098 C:
2100 S:
2101 A connection gone bad:
2103 C:
2104
2112 S:
2113
2122 [ ... channel encryption ... ]
2124 [ ... authentication ... ]
2126 [ ... resource binding ... ]
2128 C:
2131 No closing body tag!
2132
2134 S:
2135
2138
2140 More detailed examples are provided under Section 10.
2142 6. STARTTLS Negotiation
2143 6.1. Overview
2145 XMPP includes a method for securing the stream from tampering and
2146 eavesdropping. This channel encryption method makes use of the
2147 Transport Layer Security [TLS] protocol, specifically a "STARTTLS"
2148 extension that is modelled after similar extensions for the [IMAP],
2149 [POP3], and [ACAP] protocols as described in [USINGTLS]. The XML
2150 namespace name for the STARTTLS extension is
2151 'urn:ietf:params:xml:ns:xmpp-tls'.
2153 Support for STARTTLS is REQUIRED in XMPP client and server
2154 implementations. An administrator of a given deployment may require
2155 the use of TLS for client-to-server communication, server-to-server
2156 communication, or both. A deployed client should use TLS to secure
2157 its stream with a server prior to attempting the completion of SASL
2158 negotiation (Section 7), and deployed servers should use TLS between
2159 two domains for the purpose of securing server-to-server
2160 communication.
2162 6.2. Rules
2164 6.2.1. Data Formatting
2166 The entities MUST NOT send any white space characters (matching
2167 production [3] content of [XML]) within the root stream element as
2168 separators between elements (any white space characters shown in the
2169 STARTTLS examples provided in this document are included only for the
2170 sake of readability); this prohibition helps to ensure proper
2171 security layer byte precision.
2173 6.2.2. Order of Negotiation
2175 If the initiating entity chooses to use TLS, STARTTLS negotiation
2176 MUST be completed before proceeding to SASL negotiation (Section 7);
2177 this order of negotiation is required to help safeguard
2178 authentication information sent during SASL negotiation, as well as
2179 to make it possible to base the use of the SASL EXTERNAL mechanism on
2180 a certificate (or other credentials) provided during prior TLS
2181 negotiation.
2183 6.3. Process
2185 6.3.1. Exchange of Stream Headers and Stream Features
2187 The initiating entity resolves the hostname of the receiving entity
2188 as specified under Section 4, opens a TCP connection to the
2189 advertised port at the resolved IP address, and sends an initial
2190 stream header to the receiving entity; if the initiating entity is
2191 capable of STARTTLS negotiation, it MUST include the 'version'
2192 attribute set to a value of at least "1.0" in the initial stream
2193 header.
2195 I:
2203 The receiving entity MUST send a response stream header to the
2204 initiating entity over the TCP connection opened by the initiating
2205 entity; if the receiving entity is capable of STARTTLS negotiation,
2206 it MUST include the 'version' attribute set to a value of at least
2207 "1.0" in the response stream header.
2209 R:
2224
2227 If the receiving entity requires the use of STARTTLS, it SHOULD
2228 include an empty
2232
2233
2235
2237 6.3.2. Initiation of STARTTLS Negotiation
2239 6.3.2.1. STARTTLS Command
2241 In order to begin the STARTTLS negotiation, the initiating entity
2242 issues the STARTTLS command (i.e., a
2271 If the failure case occurs, the initiating entity MAY attempt to
2272 reconnect as explained under Section 5.7.
2274 6.3.2.3. Proceed Case
2276 If the proceed case occurs, the receiving entity MUST return a
2277
2349 Note: The initiating entity MUST NOT send a closing tag
2350 before sending the initial stream header, since the receiving
2351 entity and initiating entity MUST consider the original stream to
2352 be closed upon success of the TLS negotiation.
2353 4. The receiving entity MUST respond with a response stream header.
2355 R:
2370
2371 EXTERNAL
2372 DIGEST-MD5
2373 PLAIN
2374
2376
2378 6.4. Representation of JIDs in Certificates
2380 TLS negotiation is commonly based on a digital certificate presented
2381 by the receiving entity (or, in the case of mutual authentication,
2382 both the receiving entity and the initiating entity).
2384 6.4.1. Client Certificates
2386 In a certificate to be presented by an XMPP client, it is RECOMMENDED
2387 for the certificate to include one or more JIDs associated with an
2388 XMPP user. If included, a JID MUST be represented as a UTF8String
2389 within an otherName entity inside the subjectAltName, using the
2390 [ASN.1] Object Identifier "id-on-xmppAddr" specified under
2391 Section 6.4.3.
2393 6.4.2. Server Certificates
2395 In a certificate to be presented by an XMPP server, it is RECOMMENDED
2396 for the certificate to include one or more JIDs associated with
2397 domains serviced at the server. If included, the following
2398 representation is RECOMMENDED:
2400 1. A JID MUST be represented as a subjectAltName extension of type
2401 dNSName. This dNSName MAY contain the wildcard character '*',
2402 which applies only to the left-most domain name component or
2403 component fragment and is considered to match any single
2404 component or component fragment (e.g., *.example.com matches
2405 foo.example.com but not bar.foo.example.com, and im*.example.net
2406 matches im1.example.net and im2.example.net but not
2407 chat.example.net).
2408 2. A JID SHOULD be represented as a UTF8String within an otherName
2409 entity inside the subjectAltName, using the [ASN.1] Object
2410 Identifier "id-on-xmppAddr" specified under Section 6.4.3.
2412 6.4.3. ASN.1 Object Identifier
2414 The [ASN.1] Object Identifier "id-on-xmppAddr" is defined as follows.
2416 id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
2417 dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
2419 id-on OBJECT IDENTIFIER ::= { id-pkix 8 } -- other name forms
2421 id-on-xmppAddr OBJECT IDENTIFIER ::= { id-on 5 }
2423 XmppAddr ::= UTF8String
2425 As an alternative to the "id-on-xmppAddr" notation, this Object
2426 Identifier MAY be represented in dotted display format (i.e.,
2427 "1.3.6.1.5.5.7.8.5") or in the Uniform Resource Name notation
2428 specified in [URN-OID] (i.e., "urn:oid:1.3.6.1.5.5.7.8.5").
2430 Thus for example the JID "juliet@example.com" as included in a
2431 certificate could be formatted in any of the following three ways:
2433 id-on-xmppAddr:
2434 subjectAltName=otherName:id-on-xmppAddr;UTF8:juliet@example.com
2435 dotted display format:
2436 subjectAltName=otherName:1.3.6.1.5.5.7.8.5;UTF8:juliet@example.com
2437 URN notation: subjectAltName=otherName:urn:oid:
2438 1.3.6.1.5.5.7.8.5;UTF8:juliet@example.com
2440 7. SASL Negotiation
2442 7.1. Overview
2444 XMPP includes a method for authenticating a stream by means of an
2445 XMPP-specific profile of the Simple Authentication and Security Layer
2446 protocol (see [SASL]). SASL provides a generalized method for adding
2447 authentication support to connection-based protocols, and XMPP uses
2448 an XML namespace profile of SASL that conforms to the profiling
2449 requirements of [SASL].
2451 Support for SASL negotiation is REQUIRED in XMPP client and server
2452 implementations.
2454 7.2. Rules
2456 7.2.1. Data Formatting
2458 The following formatting rules apply to the data sent during SASL
2459 negotiation:
2461 1. The entities MUST NOT send any white space characters (matching
2462 production [3] content of [XML]) within the root stream element
2463 as separators between elements (any white space characters shown
2464 in the SASL examples provided in this document are included for
2465 the sake of readability only); this prohibition helps to ensure
2466 proper security layer byte precision.
2467 2. Any XML character data contained within the XML elements MUST be
2468 encoded using base64, where the encoding adheres to the
2469 definition in Section 4 of [BASE64] and where the padding bits
2470 are set to zero.
2472 7.2.2. Security Layers
2474 Upon successful SASL negotiation that involves negotiation of a
2475 security layer, the initiating entity MUST discard any knowledge
2476 obtained from the receiving entity that was not obtained via the SASL
2477 negotiation.
2479 Upon successful SASL negotiation that involves negotiation of a
2480 security layer, the receiving entity MUST discard any knowledge
2481 obtained from the initiating entity that was not obtained via the
2482 SASL negotiation. The receiving entity SHOULD also include an
2483 updated list of SASL mechanisms with the stream features so that the
2484 initiating entity is able to detect any changes to the list of
2485 mechanisms supported by the receiving entity.
2487 7.2.3. Simple Usernames
2489 Provision of a "simple username" may be supported by the selected
2490 SASL mechanism (e.g., this is supported by the DIGEST-MD5 and CRAM-
2491 MD5 mechanisms but not by the EXTERNAL and GSSAPI mechanisms). The
2492 simple username provided during authentication SHOULD be as follows:
2494 Client-to-server communication: The initiating entity's registered
2495 account name, i.e., user name or node name as contained in an XMPP
2496 node identifier. The simple username MUST adhere to the Nodeprep
2497 (Appendix A) profile of [STRINGPREP].
2498 Server-to-server communication: The initiating entity's sending
2499 domain, i.e., IP address or fully qualified domain name as
2500 contained in an XMPP domain identifier. The simple username MUST
2501 adhere to the [NAMEPREP] profile of [STRINGPREP].
2503 7.2.4. Authorization Identities
2505 If the initiating entity wishes to act on behalf of another entity
2506 and the selected SASL mechanism supports transmission of an
2507 authorization identity, the initiating entity MUST provide an
2508 authorization identity during SASL negotiation. If the initiating
2509 entity does not wish to act on behalf of another entity, it MUST NOT
2510 provide an authorization identity. As specified in [SASL], the
2511 initiating entity MUST NOT provide an authorization identity unless
2512 the authorization identity is different from the default
2513 authorization identity derived from the authentication identity. If
2514 provided, the value of the authorization identity MUST be of the form
2515 (i.e., an XMPP domain identifier only) for servers and of
2516 the form (i.e., node identifier and domain identifier)
2517 for clients.
2519 7.3. Process
2521 The process for SASL negotiation is as follows.
2523 7.3.1. Exchange of Stream Headers and Stream Features
2525 If SASL negotiation follows successful STARTTLS negotation
2526 (Section 6), then the SASL negotiation occurs over the existing
2527 stream. If not, the initiating entity resolves the hostname of the
2528 receiving entity as specified under Section 4, opens a TCP connection
2529 to the advertised port at the resolved IP address, and sends an
2530 initial stream header to the receiving entity; if the initiating
2531 entity is capable of STARTTLS negotiation, it MUST include the
2532 'version' attribute set to a value of at least "1.0" in the initial
2533 stream header.
2535 I:
2543 The receiving entity MUST send a response stream header to the
2544 initiating entity; if the receiving entity is capable of SASL
2545 negotiation, it MUST include the 'version' attribute set to a value
2546 of at least "1.0" in the response stream header.
2548 R:
2567
2568 EXTERNAL
2569 DIGEST-MD5
2570 PLAIN
2571
2572
2574 Note: If the initiating entity presents a valid certificate during
2575 prior TLS negotiation, the receiving entity SHOULD offer the SASL
2576 EXTERNAL mechanism to the initiating entity during SASL negotiation
2577 (refer to [SASL]) and SHOULD prefer that mechanism. However, the
2578 EXTERNAL mechanism MAY be offered under other circumstances as well.
2580 Note: If TLS negotiation (Section 6) needs to be completed before a
2581 particular authentication mechanism may be used, the receiving entity
2582 MUST NOT provide that mechanism in the list of available SASL
2583 authentication mechanisms prior to TLS negotiation.
2585 Note: See Section 15.7 regarding mechanisms that MUST be supported;
2586 naturally, other SASL mechanisms MAY be supported as well (best
2587 practices for the use of several SASL mechanisms in the context of
2588 XMPP are described in [XEP-0175] and [XEP-0178]).
2590 If successful SASL negotiation is required for interaction with the
2591 receiving entity, the receiving entity SHOULD signal that fact by
2592 including a
2596
2597 EXTERNAL
2598 DIGEST-MD5
2599 PLAIN
2600
2602
2604 Note: As formally specified in the XML schema for the
2605 'urn:ietf:params:xml:ns:xmpp-sasl' namespace, the receiving entity
2606 MAY include an application-specific child element inside the
2607 =
2628 7.3.3. Challenge-Response Sequence
2630 If necessary, the receiving entity challenges the initiating entity
2631 by sending a
2638 cmVhbG09ImV4YW1wbGUuY29tIixub25jZT0iT0E2TUc5dEVRR20yaGgiLHFvcD0i
2639 YXV0aCIsY2hhcnNldD11dGYtOCxhbGdvcml0aG09bWQ1LXNlc3MK
2640
2642 The decoded challenge is:
2644 realm="example.com",nonce="OA6MG9tEQGm2hh",
2645 qop="auth",charset=utf-8,algorithm=md5-sess
2647 Note: If the receiving entity does not specify a 'realm' value, the
2648 initiating entity MUST default it to the domain identifier portion of
2649 the receiving entity's JID.
2651 The initiating entity responds to the challenge by sending a
2652
2659 dXNlcm5hbWU9Imp1bGlldCIscmVhbG09ImV4YW1wbGUuY29tIixub25jZT0iT0E2
2660 TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5jPTAwMDAwMDAx
2661 LHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5jb20iLHJlc3BvbnNl
2662 PWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNoYXJzZXQ9dXRmLTgK
2663
2665 The decoded response is:
2667 username="juliet",realm="example.com",
2668 nonce="OA6MG9tEQGm2hh",cnonce="OA6MHXh6VqTrRk",
2669 nc=00000001,qop=auth,digest-uri="xmpp/example.com",
2670 response=d388dad90d4bbd760a152321f2143af7,charset=utf-8
2672 If necessary, the receiving entity sends more challenges and the
2673 initiating entity sends more responses.
2675 This series of challenge/response pairs continues until one of three
2676 things happens:
2678 o The initiating entity aborts the handshake.
2679 o The receiving entity reports failure of the handshake.
2680 o The receiving entity reports success of the handshake.
2682 These scenarios are described in the following sections.
2684 7.3.4. Abort
2686 The initiating entity aborts the handshake by sending an
2717
2720 If the failure case occurs, the receiving entity SHOULD allow a
2721 configurable but reasonable number of retries (at least 2 and no more
2722 than 5); this enables the initiating entity (e.g., an end-user
2723 client) to tolerate incorrectly-provided credentials (e.g., a
2724 mistyped password) without being forced to reconnect.
2726 If the initiating entity exceeds the number of retries, the receiving
2727 entity MUST return a stream error (which SHOULD be
2741 cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo=
2742
2744 The decoded value for subsequent authentication is:
2746 rspauth=ea40f60335c427b5527b84dbabcdfffd
2748 Upon receiving the tag
2761 before sending the initial stream header, since the receiving entity
2762 and initiating entity MUST consider the original stream to be closed
2763 upon sending or receiving the
2778 The receiving entity MUST also send stream features, containing any
2779 further available features or containing no features (via an empty
2780
2784
2785
2787
2789 7.4. SASL Definition
2791 The profiling requirements of [SASL] require that the following
2792 information be supplied by a protocol definition:
2794 service name: "xmpp"
2795 initiation sequence: After the initiating entity provides an opening
2796 XML stream header and the receiving entity replies in kind, the
2797 receiving entity provides a list of acceptable authentication
2798 methods. The initiating entity chooses one method from the list
2799 and sends it to the receiving entity as the value of the
2800 'mechanism' attribute possessed by an of a client
2819 or the sending of a server; an empty string is equivalent
2820 to an absent authorization identity.
2822 7.5. SASL Errors
2824 The following SASL-related error conditions are defined.
2826 7.5.1. aborted
2828 The receiving entity acknowledges an
2834
2837 7.5.2. incorrect-encoding
2839 The data provided by the initiating entity could not be processed
2840 because the [BASE64] encoding is incorrect (e.g., because the
2841 encoding does not adhere to the definition in Section 4 of [BASE64]);
2842 sent in reply to a [ ... ]
2848 R:
2849
2852 7.5.3. invalid-authzid
2854 The authzid provided by the initiating entity is invalid, either
2855 because it is incorrectly formatted or because the initiating entity
2856 does not have permissions to authorize that ID; sent in reply to a
2857
2860 [ ... ]
2861
2863 R:
2864
2867 7.5.4. invalid-mechanism
2869 The initiating entity did not provide a mechanism or requested a
2870 mechanism that is not supported by the receiving entity; sent in
2871 reply to an
2877
2880 7.5.5. malformed-request
2882 The request is malformed (e.g., the [ ... ]
2889 R:
2890
2893 7.5.6. mechanism-too-weak
2895 The mechanism requested by the initiating entity is weaker than
2896 server policy permits for that initiating entity; sent in reply to an
2897
2904
2907 7.5.7. not-authorized
2909 The authentication failed because the initiating entity did not
2910 provide proper credentials; sent in reply to a
2914 [ ... ]
2915
2917 R:
2918
2921 Note: This error condition includes but is not limited to the case of
2922 incorrect credentials or an unknown username. In order to discourage
2923 directory harvest attacks, no differentiation is made between
2924 incorrect credentials and an unknown username.
2926 7.5.8. temporary-auth-failure
2928 The authentication failed because of a temporary error condition
2929 within the receiving entity, and the initiating entity should try
2930 again later; sent in reply to an
2934 [ ... ]
2935
2937 R:
2938
2941 8. Resource Binding
2943 8.1. Overview
2945 After a client authenticates with a server, it MUST bind a specific
2946 resource to the stream so that the server can properly address the
2947 client (see Section 3). That is, there MUST be an XMPP resource
2948 identifier associated with the bare JID () of the
2949 client, with the result that the address for use over that stream is
2950 a full JID of the form . This ensures that the
2951 server can deliver XML stanzas to and receive XML stanzas from the
2952 client (see Section 11). After binding a resource to the stream, the
2953 client is referred to as a connected resource.
2955 If, before completing the resource binding step, the client attempts
2956 to send an outbound XML stanza (i.e., a stanza not directed to the
2957 server itself or to the client's own account), the server MUST NOT
2958 process the stanza and SHOULD return a
2985 S:
2986
2987
2990
2992 Upon being so informed that resource binding is required, the client
2993 MUST bind a resource to the stream as described in the following
2994 sections.
2996 8.3. Server-Generated Resource Identifier
2998 A server that supports resource binding MUST be able to generate an
2999 XMPP resource identifier on behalf of a client. The resource
3000 identifier generated by the server MUST at a minimum be unique among
3001 the connected resources for that and SHOULD be random
3002 since the resource identifier may be security-critical. It is
3003 RECOMMENDED that the server-generated resource identifier be a
3004 Universally Unique Identifier (UUID), for which the format specified
3005 in [UUID] is RECOMMENDED.
3007 It is RECOMMENDED for the client to ask its server to generate an
3008 appropriate resource identifier on its behalf, rather than generating
3009 a resource on its own and requesting that the server accept the
3010 client-generated resource identifer.
3012 8.3.1. Success Case
3014 A client requests a server-generated resource identifier by sending
3015 an IQ stanza of type "set" (see Section 9.2.3) containing an empty
3016
3020
3023 Once the server has generated an XMPP resource identifier for the
3024 client, it MUST return an IQ stanza of type "result" to the client,
3025 which MUST include a
3029
3030
3031 juliet@example.com/4db06f06-1ea4-11dc-aca3-000bcd821bfb
3032
3033
3034
3036 8.3.2. Error Case
3038 It is possible that the client is not allowed to bind a resource to
3039 the stream (e.g., because the node or user has reached a limit on the
3040 number of connected resources allowed). In this case, the server
3041 MUST return a
3044
3045
3047
3049 8.4. Client-Generated Resource Identifier
3051 A client MAY attempt to specify the resource identifier on its own
3052 rather than asking the server to generate a resource identifier on
3053 its behalf.
3055 8.4.1. Success Case
3057 A client asks its server to accept a client-generated resource
3058 identifier by sending an IQ stanza of type "set" containing a
3063
3064 balcony
3065
3066
3068 The server MAY accept the resource identifier provided by the client,
3069 in which case it returns an IQ stanza of type "result" to the client,
3070 including a
3074
3075 juliet@example.com/balcony
3076
3077
3079 However, the server MAY instead override the client-generated
3080 resource identifier and generate a resource identifier on behalf of
3081 the client, as shown in the previous section.
3083 8.4.2. Error Cases
3085 When a client attempts to set its own XMPP resource identifier during
3086 resource binding, the following stanza error conditions are possible:
3088 o The client is not allowed to bind a resource to the stream (e.g.,
3089 because the node or user has reached a limit on the number of
3090 connected resources allowed).
3091 o The provided resource identifier cannot be processed by the
3092 server, e.g. because it is not in accordance with the Resourceprep
3093 (Appendix B) profile of [STRINGPREP]).
3094 o The provided resource identifier is already in use but the server
3095 does not allow binding of multiple connected resources with the
3096 same identifier.
3098 8.4.2.1. Not Allowed
3100 If the client is not allowed to bind a resource to the stream, the
3101 server MUST return a
3104
3105
3107
3109 8.4.2.2. Bad Request
3111 If the provided resource identifier cannot be processed by the
3112 server, the server MAY return a
3118
3119
3121
3123 8.4.2.3. Conflict
3125 If there is already a connected resource of the same name, the server
3126 MUST do one of the following:
3128 1. Not accept the resource identifier provided by the client but
3129 instead override it with an XMPP resource identifier that the
3130 server generates.
3132 2. Terminate the current resource and allow the newly-requested
3133 resource.
3134 3. Disallow the newly-requested resource and maintain the current
3135 resource.
3137 Which of these the server does is up to the implementation, although
3138 it is RECOMMENDED to implement case #1.
3140 In case #2, the server MUST send a
3169
3170
3172
3175 8.5.2. Binding an Additional Resource
3177 A connected client binds an additional resource by following the
3178 protocol for binding of the original resource, i.e., by sending an IQ
3179 stanza of type "set" containing a
3196
3197 someresource
3198
3199
3201 If no error occurs, the server MUST unbind the resource and no longer
3202 accept stanzas whose 'from' address specifies the full JID associated
3203 with that resource.
3205 S:
3214 8.5.3.2. Error Cases
3216 8.5.3.2.1. Unbind Not Supported
3218 If the server does not understand the
3223
3224
3226
3228 8.5.3.2.2. No Such Resource
3230 If there is no such resource for that stream, the server MUST return
3231 an error of
3234
3235
3237
3239 8.5.4. From Addresses
3241 When a client binds multiple resources to the same stream, proper
3242 management of 'from' addresses is imperative. In particular, a
3243 client MUST specify a 'from' address on every stanza it sends over a
3244 stream to which it has bound multiple resources, where the 'from'
3245 address is the full JID () associated with
3246 the relevant resource. If a client does not specify a 'from' address
3247 on a stanza it sends over a stream to which it has bound multiple
3248 resources, the server MUST return the stanza to the client with an
3249
3252 Wherefore art thou?
3253
3255 S:
3257 Wherefore art thou?
3258
3259
3261
3263 Naturally, the rules regarding validation of asserted 'from'
3264 addresses still apply (see Section 11).
3266 9. XML Stanzas
3268 After a client has connected to a server or two servers have
3269 connected to each other, either party can send XML stanzas over the
3270 negotiated stream. Three kinds of XML stanza are defined for the
3271 'jabber:client' and 'jabber:server' namespaces:
3298 Art thou not Romeo, and a Montague?
3299
3301 For information about server processing of inbound and outbound XML
3302 stanzas based on the nature of the 'to' address, refer to Section 11.
3304 9.1.1.1. Client-to-Server Streams
3306 The following rules apply to the 'to' attribute in the context of XML
3307 streams qualified by the 'jabber:client' namespace (i.e., client-to-
3308 server streams).
3310 1. A stanza with a specific intended recipient MUST possess a 'to'
3311 attribute.
3312 2. A stanza sent from a client to a server for direct processing by
3313 the server (e.g., presence sent to the server for broadcasting to
3314 other entities) SHOULD NOT possess a 'to' attribute.
3316 9.1.1.2. Server-to-Server Streams
3318 The following rules apply to the 'to' attribute in the context of XML
3319 streams qualified by the 'jabber:server' namespace (i.e., server-to-
3320 server streams).
3322 1. A stanza MUST possess a 'to' attribute; if a server receives a
3323 stanza that does not meet this restriction, it MUST generate an
3324
3334 Art thou not Romeo, and a Montague?
3335
3337 9.1.2.1. Client-to-Server Streams
3339 The following rules apply to the 'from' attribute in the context of
3340 XML streams qualified by the 'jabber:client' namespace (i.e., client-
3341 to-server streams).
3343 1. When the server receives an XML stanza from a client and the
3344 stanza does not include a 'from' attribute, the server MUST add a
3345 'from' attribute to the stanza, where the value of the 'from'
3346 attribute is the full JID () determined by
3347 the server for the connected resource that generated the stanza
3348 (see Section 3.5), or the bare JID () in the case of
3349 subscription-related presence stanzas (see [XMPP-IM]); the only
3350 exception to this rule occurs when multiple resources are bound
3351 to the same stream as described under Section 8.5.
3352 2. When the server receives an XML stanza from a client and the
3353 stanza includes a 'from' attribute, the server MUST either (a)
3354 validate that the value of the 'from' attribute provided by the
3355 client is that of a connected resource for the associated entity
3356 or (b) override the provided 'from' attribute by adding a 'from'
3357 attribute as specified under Rule #1.
3358 3. When the server generates a stanza from the server for delivery
3359 to the client on behalf of the account of the connected client
3360 (e.g., in the context of data storage services provided by the
3361 server on behalf of the client), the stanza MUST either (a) not
3362 include a 'from' attribute or (b) include a 'from' attribute
3363 whose value is the account's bare JID ().
3364 4. When the server generates a stanza from the server itself for
3365 delivery to the client, the stanza MUST include a 'from'
3366 attribute whose value is the mere domain () of the
3367 server.
3369 5. A server MUST NOT send to the client a stanza without a 'from'
3370 attribute if the stanza was not generated by the server (e.g., if
3371 it was generated by another client or another server); therefore,
3372 when a client receives a stanza that does not include a 'from'
3373 attribute, it MUST assume that the stanza is from the server to
3374 which the client is connected.
3376 9.1.2.2. Server-to-Server Streams
3378 The following rules apply to the 'from' attribute in the context of
3379 XML streams qualified by the 'jabber:server' namespace (i.e., server-
3380 to-server streams).
3382 1. A stanza MUST possess a 'from' attribute; if a server receives a
3383 stanza that does not meet this restriction, it MUST generate an
3384
3429 dnd
3430 Wooing Juliet
3431
3433 The value of the 'xml:lang' attribute MAY be overridden by the 'xml:
3434 lang' attribute of a specific child element.
3436
3437 dnd
3438 Wooing Juliet
3439 Dvořím se Julii
3440
3448 dnd
3449 Wooing Juliet
3450
3452 S:
3455 dnd
3456 Wooing Juliet
3457
3459 If an inbound stanza received received by a client or server does not
3460 possess an 'xml:lang' attribute, an implementation MUST assume that
3461 the default language is that specified for the stream as defined
3462 under Section 5.3.
3464 The value of the 'xml:lang' attribute MUST conform to the NMTOKEN
3465 datatype (as defined in Section 2.3 of [XML]) and MUST conform to the
3466 format defined in [LANGTAGS].
3468 A server MUST NOT modify or delete 'xml:lang' attributes on stanzas
3469 it receives from other entities.
3471 9.2. Basic Semantics
3473 9.2.1. Message Semantics
3475 The |
3517 | [ ... payload ... ] |
3518 | |
3519 | -------------------------> |
3520 | |
3521 | |
3522 | [ ... payload ... ] |
3523 | |
3524 | <------------------------- |
3525 | |
3526 | |
3527 | [ ... payload ... ] |
3528 | |
3529 | -------------------------> |
3530 | |
3531 | |
3532 | [ ... condition ... ] |
3533 | |
3534 | <------------------------- |
3535 | |
3537 In order to enforce these semantics, the following rules apply:
3539 1. The 'id' attribute is REQUIRED for IQ stanzas.
3540 2. The 'type' attribute is REQUIRED for IQ stanzas. The value MUST
3541 be one of the following:
3542 * get -- The stanza is a request for information or
3543 requirements.
3544 * set -- The stanza provides required data, sets new values, or
3545 replaces existing values.
3546 * result -- The stanza is a response to a successful get or set
3547 request.
3548 * error -- An error has occurred regarding processing or
3549 delivery of a previously-sent get or set request (see
3550 Section 9.3).
3551 3. An entity that receives an IQ request of type "get" or "set" MUST
3552 reply with an IQ response of type "result" or "error". The
3553 response MUST preserve the 'id' attribute of the request.
3554 4. An entity that receives a stanza of type "result" or "error" MUST
3555 NOT respond to the stanza by sending a further IQ response of
3556 type "result" or "error"; however, the requesting entity MAY send
3557 another request (e.g., an IQ of type "set" in order to provide
3558 required information discovered through a get/result pair).
3560 5. An IQ stanza of type "get" or "set" MUST contain one and only one
3561 child element, which specifies the semantics of the particular
3562 request.
3563 6. An IQ stanza of type "result" MUST include zero or one child
3564 elements.
3565 7. An IQ stanza of type "error" MAY include the child element
3566 contained in the associated "get" or "set" and MUST include an
3567
3605 [OPTIONAL to include sender XML here]
3606
3607
3610 OPTIONAL descriptive text
3611 ]
3612 [OPTIONAL application-specific condition element]
3613
3614
3616 The "stanza-kind" MUST be one of message, presence, or iq.
3618 The "error-type MUST be one of the following:
3620 o cancel -- do not retry (the error cannot be remedied)
3621 o continue -- proceed (the condition was only a warning)
3622 o modify -- retry after changing the data sent
3623 o auth -- retry after providing credentials
3624 o wait -- retry after waiting (the error is temporary)
3626 The
3664
3667 S:
3671
3672
3674
3676 9.3.3.2. conflict
3678 Access cannot be granted because an existing resource exists with the
3679 same name or address; the associated error type SHOULD be "cancel".
3681 C:
3682
3683 balcony
3684
3685
3687 S:
3688
3689
3691
3693 9.3.3.3. feature-not-implemented
3695 The feature represented in the XML stanza is not implemented by the
3696 intended recipient or an intermediate server and therefore the stanza
3697 cannot be processed; the associated error type SHOULD be "cancel" or
3698 "modify".
3700 C:
3704
3705
3707
3709 E:
3713
3714
3720
3722 9.3.3.4. forbidden
3724 The requesting entity does not possess the required permissions to
3725 perform the action; the associated error type SHOULD be "auth".
3727 C:
3730
3733 E:
3737
3738
3740
3742 9.3.3.5. gone
3744 The recipient or server can no longer be contacted at this address
3745 (the error stanza MAY contain a new address in the XML character data
3746 of the
3752
3755 E:
3759
3760
3761 conference.example.com
3762
3763
3764
3766 9.3.3.6. internal-server-error
3768 The server could not process the stanza because of a misconfiguration
3769 or an otherwise-undefined internal server error; the associated error
3770 type SHOULD be "wait" or "cancel".
3772 C:
3775
3778 E:
3782
3783
3786
3788 9.3.3.7. item-not-found
3790 The addressed JID or item requested cannot be found; the associated
3791 error type SHOULD be "cancel" or "modify".
3793 C:
3794
3795 someresource
3796
3797
3799 S:
3800
3801
3803
3805 Note: An application MUST NOT return this error if doing so would
3806 provide information about the intended recipient's network
3807 availability to an entity that is not authorized to know such
3808 information; instead it SHOULD return a
3820
3823 E:
3827
3828
3831
3833 9.3.3.9. not-acceptable
3835 The recipient or server understands the request but is refusing to
3836 process it because it does not meet criteria defined by the recipient
3837 or server (e.g., a local policy regarding stanza size limits or
3838 acceptable words in messages); the associated error type SHOULD be
3839 "modify".
3841 C:
3842 [ ... the-emacs-manual ... ]
3843
3845 S:
3846
3847
3850
3852 9.3.3.10. not-allowed
3854 The recipient or server does not allow any entity to perform the
3855 action (e.g., sending to entities at a blacklisted domain); the
3856 associated error type SHOULD be "cancel".
3858 C:
3861
3864 E:
3867
3868
3870
3872 9.3.3.11. not-authorized
3874 The sender must provide proper credentials before being allowed to
3875 perform the action, or has provided improper credentials; the
3876 associated error type SHOULD be "auth".
3878 C:
3881
3884 E:
3887
3888
3890
3892 9.3.3.12. not-modified
3894 The item requested has not changed since it was last requested; the
3895 associated error type SHOULD be "continue".
3897 C:
3900
3901
3902
3903 some-long-opaque-string
3904
3905
3906
3907
3909 S:
3912
3913
3914
3915 some-long-opaque-string
3916
3917
3918
3919
3920
3922
3924 9.3.3.13. payment-required
3926 The requesting entity is not authorized to access the requested
3927 service because payment is required; the associated error type SHOULD
3928 be "auth".
3930 C:
3934
3935
3937
3939 E:
3943
3944
3947
3949 9.3.3.14. recipient-unavailable
3951 The intended recipient is temporarily unavailable; the associated
3952 error type SHOULD be "wait".
3954 C:
3957
3960 E:
3963
3964
3967
3969 Note: An application MUST NOT return this error if doing so would
3970 provide information about the intended recipient's network
3971 availability to an entity that is not authorized to know such
3972 information; instead it SHOULD return a
3985
3988 E:
3992
3993
3994 characters@conference.example.org
3995
3996
3997
3999 9.3.3.16. registration-required
4001 The requesting entity is not authorized to access the requested
4002 service because prior registration is required; the associated error
4003 type SHOULD be "auth".
4005 C:
4008
4011 E:
4014
4015
4018
4020 9.3.3.17. remote-server-not-found
4022 A remote server or service specified as part or all of the JID of the
4023 intended recipient does not exist; the associated error type SHOULD
4024 be "cancel".
4026 C:
4029
4032 E:
4035
4036
4039
4041 9.3.3.18. remote-server-timeout
4043 A remote server or service specified as part or all of the JID of the
4044 intended recipient (or required to fulfill a request) could not be
4045 contacted within a reasonable amount of time; the associated error
4046 type SHOULD be "wait".
4048 C:
4051
4054 E:
4057
4058
4061
4063 9.3.3.19. resource-constraint
4065 The server or recipient lacks the system resources necessary to
4066 service the request; the associated error type SHOULD be "wait".
4068 C:
4072
4073
4075
4077 E:
4081
4082
4085
4087 9.3.3.20. service-unavailable
4089 The server or recipient does not currently provide the requested
4090 service; the associated error type SHOULD be "cancel".
4092 C:
4094 Hello?
4095
4097 S:
4099
4100
4103
4105 An application SHOULD return a help
4121
4123 E:
4127
4128
4131
4133 9.3.3.22. undefined-condition
4135 The error condition is not one of those defined by the other
4136 conditions in this list; any error type may be associated with this
4137 condition, and it SHOULD be used only in conjunction with an
4138 application-specific condition.
4140 C:
4144 My lord, dispatch; read o'er these articles.
4145
4146
4151 S:
4155
4159
4163
4164
4167
4171
4172
4174 9.3.3.23. unexpected-request
4176 The recipient or server understood the request but was not expecting
4177 it at this time (e.g., the request was out of order); the associated
4178 error type SHOULD be "wait" or "modify".
4180 C:
4184
4185
4189
4191 E:
4195
4196
4201
4203 9.3.3.24. unknown-sender
4205 The stanza 'from' address specified by a connected client is not
4206 valid for the stream (e.g., the stanza does not include a 'from'
4207 address when multiple resources are bound to the stream as described
4208 under Section 8.5.4); the associated error type SHOULD be "modify".
4210 C:
4211 Wherefore art thou?
4212
4214 S:
4216 Wherefore art thou?
4217
4218
4220
4222 9.3.4. Application-Specific Conditions
4224 As noted, an application MAY provide application-specific stanza
4225 error information by including a properly-namespaced child in the
4226 error element. The application-specific element SHOULD supplement or
4227 further qualify a defined element. Thus, the
4231
4232
4235
4237
4238
4239
4243 [ ... application-specific information ... ]
4244
4245
4247
4249 9.4. Extended Content
4251 While the message, presence, and IQ stanzas provide basic semantics
4252 for messaging, availability, and request-response interactions, XMPP
4253 uses XML namespaces (see [XML-NAMES] to extend the basic stanza
4254 syntax for the purpose of providing additional functionality. Thus a
4255 message or presence stanza MAY contain one or more optional child
4256 elements specifying content that extends the meaning of the message
4257 (e.g., an XHTML-formatted version of the message body as described in
4258 [XEP-0071]), and an IQ stanza of type "get" or "set" MUST contain one
4259 such child element. This child element MAY have any name and MUST
4260 possess a namespace declaration (other than "jabber:client", "jabber:
4261 server", or "http://etherx.jabber.org/streams") that defines all data
4262 contained within the child element. Such a child element is said to
4263 be EXTENDED CONTENT and its namespace name is said to be an EXTENDED
4264 NAMESPACE.
4266 Support for any given extended namespace is OPTIONAL on the part of
4267 any implementation. If an entity does not understand such a
4268 namespace, the entity's expected behavior depends on whether the
4269 entity is (1) the recipient or (2) an entity that is routing the
4270 stanza to the recipient.
4272 Recipient: If a recipient receives a stanza that contains a child
4273 element it does not understand, it SHOULD silently ignore that
4274 particular XML data, i.e., it SHOULD not process it or present it
4275 to a user or associated application (if any). In particular:
4276 * If an entity receives a message or presence stanza that
4277 contains XML data qualified by a namespace it does not
4278 understand, the portion of the stanza that qualified by the
4279 unknown namespace SHOULD be ignored.
4280 * If an entity receives a message stanza whose only child element
4281 is qualified by a namespace it does not understand, it MUST
4282 ignore the entire stanza.
4283 * If an entity receives an IQ stanza of type "get" or "set"
4284 containing a child element qualified by a namespace it does not
4285 understand, the entity SHOULD return an IQ stanza of type
4286 "error" with an error condition of
4322 Step 2: Server responds by sending a response stream header to
4323 client:
4325 S:
4338
4339
4341
4343 Step 4: Client sends STARTTLS command to server:
4345 C:
4357 Step 6: Client and server attempt to complete TLS negotiation over
4358 the existing TCP connection (see [TLS] for details).
4360 Step 7: If TLS negotiation is successful, client initiates a new
4361 stream to server:
4363 C:
4371 Step 7 (alt): If TLS negotiation is unsuccessful, server closes TCP
4372 connection.
4374 10.1.2. SASL
4376 Step 8: Server responds by sending a stream header to client along
4377 with any available stream features:
4379 S:
4389
4390 DIGEST-MD5
4391 PLAIN
4392
4394
4396 Step 9: Client selects an authentication mechanism, in this case
4397 [DIGEST-MD5] with an empty authorization identity ("="):
4399 C: =
4402 Step 10: Server sends a [BASE64] encoded challenge to client:
4404 S:
4405 cmVhbG09ImV4YW1wbGUuY29tIixub25jZT0iT0E2TUc5dEVRR20yaGgiLHFvcD0i
4406 YXV0aCIsY2hhcnNldD11dGYtOCxhbGdvcml0aG09bWQ1LXNlc3MK
4407
4409 The decoded challenge is:
4411 realm="example.com",nonce="OA6MG9tEQGm2hh",
4412 qop="auth",charset=utf-8,algorithm=md5-sess
4414 Step 10 (alt): Server returns error to client:
4416 S:
4417
4420 S:
4422 Step 11: Client sends a [BASE64] encoded response to the challenge:
4424 C:
4425 dXNlcm5hbWU9Imp1bGlldCIscmVhbG09ImV4YW1wbGUuY29tIixub25jZT0iT0E2
4426 TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5jPTAwMDAwMDAx
4427 LHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5jb20iLHJlc3BvbnNl
4428 PWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNoYXJzZXQ9dXRmLTgK
4429
4431 The decoded response is:
4433 username="juliet",realm="example.com",
4434 nonce="OA6MG9tEQGm2hh",cnonce="OA6MHXh6VqTrRk",
4435 nc=00000001,qop=auth,digest-uri="xmpp/example.com",
4436 response=d388dad90d4bbd760a152321f2143af7,charset=utf-8
4438 Step 12: Server informs client of success and includes [BASE64]
4439 encoded value for subsequent authentication:
4441 S:
4442 cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo=
4443
4445 The decoded value for subsequent authentication is:
4447 rspauth=ea40f60335c427b5527b84dbabcdfffd
4448 Step 12 (alt): Server returns error to client:
4450 S:
4451
4454 Step 13: Client initiates a new stream to server:
4456 C:
4478 S:
4479
4480
4482
4485 Upon being so informed that resource binding is required, the client
4486 MUST bind a resource to the stream; here we assume that the client
4487 asks the server to generate a resource identifier on its behalf.
4489 Step 15: Client binds a resource:
4491 C:
4492
4495 Step 16: Server generates resource identifier and informs client of
4496 successful resource binding:
4498 S:
4499
4500
4501 juliet@example.com/4db06f06-1ea4-11dc-aca3-000bcd821bfb
4502
4503
4504
4506 10.1.4. Stanza Exchange
4508 Now the client is allowed to send XML stanzas over the negotiated
4509 stream.
4511 C:
4515 Art thou not Romeo, and a Montague?
4516
4518 If necessary, sender's server negotiates XML streams with intended
4519 recipient's server (see Section 10.2).
4521 The intended recipient replies and the message is delivered to the
4522 client.
4524 E:
4528 Neither, fair saint, if either thee dislike.
4529
4531 The client may send and receive an unbounded number of subsequent XML
4532 stanzas over the stream.
4534 10.1.5. Close
4536 Desiring to send no further messages, the client closes the stream.
4538 C:
4540 Consistent with the recommended stream closing handshake, server
4541 closes stream as well:
4543 S:
4545 Client now terminates the underlying TCP connection.
4547 10.2. Server-to-Server Examples
4549 The following examples show the data flow for a server negotiating an
4550 XML stream with another server, exchanging XML stanzas, and closing
4551 the negotiated stream. The initiating server ("Server1") is
4552 example.com; the receiving server ("Server2") is example.net and it
4553 requires use of TLS; example.com presents a certificate and
4554 authenticates via the SASL EXTERNAL mechanism. It is assumed that
4555 before sending the initial stream header, Server1 has already
4556 resolved an SRV record of _xmpp-server._tcp.example.net and has
4557 opened a TCP connection to the advertised port at the resolved IP
4558 address.
4560 Note: The alternate steps shown are provided only to illustrate the
4561 protocol for failure cases; they are not exhaustive and would not
4562 necessarily be triggered by the data sent in the examples.
4564 10.2.1. TLS
4566 Step 1: Server1 initiates stream to Server2:
4568 S1:
4575 Step 2: Server2 responds by sending a response stream header to
4576 Server1:
4578 S2:
4586 Step 3: Server2 sends stream features to Server1:
4588 S2:
4589
4590
4592
4594 Step 4: Server1 sends the STARTTLS command to Server2:
4596 S1:
4609 Step 6: Server1 and Server2 attempt to complete TLS negotiation via
4610 TCP.
4612 Step 7: If TLS negotiation is successful, Server1 initiates a new
4613 stream to Server2:
4615 S1:
4622 Step 7 (alt): If TLS negotiation is unsuccessful, Server2 closes TCP
4623 connection.
4625 10.2.2. SASL
4627 Step 8: Server2 sends a response stream header to Server1 along with
4628 available stream features (including a preference for the SASL
4629 EXTERNAL mechanism):
4631 S2:
4639 S2:
4640
4641 EXTERNAL
4642 DIGEST-MD5
4643
4645
4647 Step 9: Server1 selects the EXTERNAL mechanism, in this case with an
4648 authorization identity encoded according to [BASE64]:
4650 S1:
4664
4667 S2:
4668 Step 12: Server1 initiates a new stream to Server2:
4670 S1:
4677 Step 13: Server2 responds by sending a stream header to Server1 along
4678 with any additional features (or, in this case, an empty features
4679 element):
4681 S2:
4689 S2:
4702 Art thou not Romeo, and a Montague?
4703
4705 The intended recipient replies and the message is delivered from
4706 Server2 to Server1.
4708 Server2 sends XML stanza to Server1:
4710 S2:
4713 Neither, fair saint, if either thee dislike.
4714
4716 10.2.4. Close
4718 Desiring to send no further messages, Server1 closes the stream. (In
4719 practice, the stream would most likely remain open for some time,
4720 since Server1 and Server2 do not immediately know if the stream will
4721 be needed for further communication.)
4723 S1:
4725 Consistent with the recommended stream closing handshake, Server2
4726 closes stream as well:
4728 S2:
4730 Server1 now terminates the underlying TCP connection.
4732 11. Server Rules for Processing XML Stanzas
4734 An XMPP server MUST ensure in-order processing of XML stanzas between
4735 any two entities. This includes stanzas sent by a client to its
4736 server for direct processing by the server (e.g., in-order processing
4737 of a roster get and initial presence as described in [XMPP-IM]).
4739 Beyond the requirement for in-order processing, each server
4740 implementation will contain its own logic for processing stanzas it
4741 receives. Such logic determines whether the server needs to ROUTE a
4742 given stanza to another domain, DELIVER it to a local entity
4743 (typically a connected client associated with a local account), or
4744 HANDLE it directly within the server itself. The following rules
4745 apply.
4747 Note: Particular XMPP applications MAY specify delivery rules that
4748 modify or supplement the following rules; for example, a set of
4749 delivery rules for instant messaging and presence applications is
4750 defined in [XMPP-IM].
4752 11.1. No 'to' Address
4754 11.1.1. Overview
4756 If the stanza possesses no 'to' attribute, the server SHOULD handle
4757 it directly on behalf of the entity that sent it. Because all
4758 stanzas received from other servers MUST possess a 'to' attribute,
4759 this rule applies only to stanzas received from a local entity (such
4760 as a client) that is connected to the server.
4762 11.1.2. Message
4764 If the server receives a message stanza with no 'to' attribute, it
4765 SHOULD handle it directly, which may include returning an error to
4766 the sending entity.
4768 11.1.3. Presence
4770 If the server receives a presence stanza with no 'to' attribute, it
4771 SHOULD broadcast it to the entities that are subscribed to the
4772 sending entity's presence, if applicable (the semantics of presence
4773 broadcast for presence applications are defined in [XMPP-IM]).
4775 11.1.4. IQ
4777 If the server receives an IQ stanza of type "get" or "set" with no
4778 'to' attribute, it MUST do the following:
4780 1. If it understands the namespace that qualifies the content of the
4781 stanza, it MUST either handle the stanza directly on behalf of
4782 sending entity (where the meaning of "handle" is determined by
4783 the semantics of the qualifying namespace) or return an
4784 appropriate error to the sending entity.
4785 2. If it does not understand the namespace that qualifies the
4786 content of the stanza, it MUST return an error to the sending
4787 entity, which SHOULD be ,
4801 then the server MUST either handle the stanza as appropriate for the
4802 stanza kind or return an error stanza to the sender.
4804 11.2.2. Resource at Domain
4806 If the JID contained in the 'to' attribute is of the form , then the server MUST either handle the stanza as
4808 appropriate for the stanza kind or return an error stanza to the
4809 sender.
4811 11.2.3. Node at Local Domain
4813 If the JID contained in the 'to' attribute is of the form
4814 (bare JID) or (full JID), then
4815 the server SHOULD deliver the stanza to the intended recipient. The
4816 following rules apply:
4818 1. If the JID contains an XMPP resource identifier (i.e., is of the
4819 form ) and there exists a connected
4820 resource that exactly matches the full JID, the recipient's
4821 server SHOULD deliver the stanza to that connection.
4822 2. If the JID contains an XMPP resource identifier and there exists
4823 no connected resource that exactly matches the full JID, the
4824 recipient's server SHOULD return a and there exists at least
4827 one connected resource for the node, the recipient's server
4828 SHOULD deliver the stanza to at least one of the connected
4829 resources if the stanza is a message or presence stanza and
4830 SHOULD handle it directly on behalf of the node if the stanza is
4831 an IQ stanza.
4833 Note: More detailed rules in the context of instant messaging and
4834 presence applications are provided in [XMPP-IM].
4836 11.3. Foreign Domain
4838 If the hostname of the domain identifier portion of the JID contained
4839 in the 'to' attribute does not match one of the configured hostnames
4840 of the server itself, the server SHOULD attempt to route the stanza
4841 to the foreign domain (subject to local service provisioning and
4842 security policies regarding inter-domain communication, since such
4843 communication is optional for any given deployment). There are two
4844 possible cases.
4846 11.3.1. Existing Stream
4848 If a server-to-server stream already exists between the two domains,
4849 the sender's server shall attempt to route the stanza to the
4850 authoritative server for the foreign domain over the existing stream.
4852 11.3.2. No Existing Stream
4854 If there exists no server-to-server stream between the two domains,
4855 the sender's server shall proceed as follows:
4857 1. Resolve the hostname of the foreign domain (as defined under
4858 Section 15.4).
4859 2. Negotiate a server-to-server stream between the two domains (as
4860 defined under Section 6 and Section 7).
4861 3. Route the stanza to the authoritative server for the foreign
4862 domain over the newly-established stream.
4864 11.3.3. Error Handling
4866 If routing to the intended recipient's server is unsuccessful, the
4867 sender's server MUST return an error to the sender, which SHOULD be
4868
5000
5003 An XML stanza MAY contain XML data qualified by more than one
5004 extended namespace, either at the direct child level of the stanza
5005 (for presence and message stanzas) or in any mix of levels (for all
5006 stanzas).
5008
5009
5013 sha1-hash-of-image
5014
5015
5017
5018 Hello?
5019
5020
5021 Hello?
5022
5023
5024
5026
5029
5030
5031 some-long-opaque-string
5032
5033
5034
5036 An implementation SHOULD NOT generate namespace prefixes for elements
5037 qualified by content (as opposed to stream) namespaces other than the
5038 default namespace. However, if included, the namespace declarations
5039 for those prefixes MUST be included on the stanza root or a child
5040 thereof, not at the level of the stream element (this helps to ensure
5041 that any such namespace declaration is routed and delivered with the
5042 stanza, instead of assumed from the stream).
5044 12.3. Validation
5046 A server is not responsible for ensuring that XML data delivered to a
5047 client or routed to another server is valid, in accorfdance with the
5048 definition of "valid" provided in Section 2.8 of [XML]. An
5049 implementation MAY choose to provide only validated data, but such
5050 behavior is OPTIONAL. A client SHOULD NOT rely on the ability to
5051 send data that does not conform to the schemas, and SHOULD ignore any
5052 non-conformant elements or attributes on the incoming XML stream.
5054 Note: The terms "valid" and "well-formed" are distinct in XML. All
5055 XMPP data MUST be well-formed, in accordance with the definition of
5056 "well-formed" provided in Section 2.1 of [XML].
5058 12.4. Inclusion of Text Declaration
5060 Implementations SHOULD send a text declaration before sending a
5061 stream header. Applications MUST follow the rules provided in [XML]
5062 regarding the circumstances under which a text declaration is
5063 included.
5065 12.5. Character Encoding
5067 Implementations MUST support the UTF-8 transformation of Universal
5068 Character Set [UCS2] characters, as required by [CHARSET] and defined
5069 in [UTF-8]. Implementations MUST NOT attempt to use any other
5070 encoding. If one party to an XML stream detects that the other party
5071 has attempted to send XML data with an encoding other than UTF-8, it
5072 MUST return a stream error, which SHOULD be ) or full JID
5548 ().
5550 15.14. Directory Harvesting
5552 To help prevent directory harvesting attacks, a server MUST NOT
5553 return different stanza errors if a potential attacker sends XML
5554 stanzas to an existing entity or a nonexistent entity. The stanza
5555 error returned in both cases SHOULD be
5576 16.2. XML Namespace Name for SASL Data
5578 A URN sub-namespace for SASL negotiation data in the Extensible
5579 Messaging and Presence Protocol (XMPP) is defined as follows. (This
5580 namespace name adheres to the format defined in [XML-REG].)
5582 URI: urn:ietf:params:xml:ns:xmpp-sasl
5583 Specification: XXXX
5584 Description: This is the XML namespace name for SASL negotiation
5585 data in the Extensible Messaging and Presence Protocol (XMPP) as
5586 defined by XXXX.
5587 Registrant Contact: IETF, XMPP Working Group,
5589 16.3. XML Namespace Name for Stream Errors
5591 A URN sub-namespace for stream error data in the Extensible Messaging
5592 and Presence Protocol (XMPP) is defined as follows. (This namespace
5593 name adheres to the format defined in [XML-REG].)
5595 URI: urn:ietf:params:xml:ns:xmpp-streams
5596 Specification: XXXX
5597 Description: This is the XML namespace name for stream error data in
5598 the Extensible Messaging and Presence Protocol (XMPP) as defined
5599 by XXXX.
5600 Registrant Contact: IETF, XMPP Working Group,
5602 16.4. XML Namespace Name for Resource Binding
5604 A URN sub-namespace for resource binding in the Extensible Messaging
5605 and Presence Protocol (XMPP) is defined as follows. (This namespace
5606 name adheres to the format defined in [XML-REG].)
5607 URI: urn:ietf:params:xml:ns:xmpp-bind
5608 Specification: XXXX
5609 Description: This is the XML namespace name for resource binding in
5610 the Extensible Messaging and Presence Protocol (XMPP) as defined
5611 by XXXX.
5612 Registrant Contact: IETF, XMPP Working Group,
5614 16.5. XML Namespace Name for Stanza Errors
5616 A URN sub-namespace for stanza error data in the Extensible Messaging
5617 and Presence Protocol (XMPP) is defined as follows. (This namespace
5618 name adheres to the format defined in [XML-REG].)
5620 URI: urn:ietf:params:xml:ns:xmpp-stanzas
5621 Specification: XXXX
5622 Description: This is the XML namespace name for stanza error data in
5623 the Extensible Messaging and Presence Protocol (XMPP) as defined
5624 by XXXX.
5625 Registrant Contact: IETF, XMPP Working Group,
5627 16.6. Nodeprep Profile of Stringprep
5629 The Nodeprep profile of stringprep is defined under Nodeprep
5630 (Appendix A). The IANA has registered Nodeprep in the stringprep
5631 profile registry.
5633 Name of this profile:
5635 Nodeprep
5637 RFC in which the profile is defined:
5639 XXXX
5641 Indicator whether or not this is the newest version of the profile:
5643 This is the first version of Nodeprep
5645 16.7. Resourceprep Profile of Stringprep
5647 The Resourceprep profile of stringprep is defined under Resourceprep
5648 (Appendix B). The IANA has registered Resourceprep in the stringprep
5649 profile registry.
5651 Name of this profile:
5653 Resourceprep
5655 RFC in which the profile is defined:
5657 XXXX
5659 Indicator whether or not this is the newest version of the profile:
5661 This is the first version of Resourceprep
5663 16.8. GSSAPI Service Name
5665 The IANA has registered "xmpp" as a GSSAPI [GSS-API] service name, as
5666 defined under Section 7.4.
5668 16.9. Port Numbers
5670 The IANA has registered "xmpp-client" and "xmpp-server" as keywords
5671 for [TCP] ports 5222 and 5269 respectively.
5673 These ports SHOULD be used for client-to-server and server-to-server
5674 communications respectively, but other ports MAY be used.
5676 17. References
5678 17.1. Normative References
5680 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
5681 Specifications: ABNF", RFC 4234, October 2005.
5683 [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data
5684 Encodings", RFC 4648, October 2006.
5686 [CHARSET] Alvestrand, H., "IETF Policy on Character Sets and
5687 Languages", BCP 18, RFC 2277, January 1998.
5689 [DIGEST-MD5]
5690 Leach, P. and C. Newman, "Using Digest Authentication as a
5691 SASL Mechanism", RFC 2831, May 2000.
5693 [DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
5694 specifying the location of services (DNS SRV)", RFC 2782,
5695 February 2000.
5697 [DNS] Mockapetris, P., "Domain names - implementation and
5698 specification", STD 13, RFC 1035, November 1987.
5700 [IDNA] Faltstrom, P., Hoffman, P., and A. Costello,
5701 "Internationalizing Domain Names in Applications (IDNA)",
5702 RFC 3490, March 2003.
5704 [IPv6] Hinden, R. and S. Deering, "IP Version 6 Addressing
5705 Architecture", RFC 4291, February 2006.
5707 [LANGTAGS]
5708 Phillips, A. and M. Davis, "Tags for Identifying
5709 Languages", BCP 47, RFC 4646, September 2006.
5711 [NAMEPREP]
5712 Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
5713 Profile for Internationalized Domain Names (IDN)",
5714 RFC 3491, March 2003.
5716 [RANDOM] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
5717 Requirements for Security", BCP 106, RFC 4086, June 2005.
5719 [SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and
5720 Security Layer (SASL)", RFC 4422, June 2006.
5722 [STRINGPREP]
5723 Hoffman, P. and M. Blanchet, "Preparation of
5724 Internationalized Strings ("stringprep")", RFC 3454,
5725 December 2002.
5727 [TCP] Postel, J., "Transmission Control Protocol", STD 7,
5728 RFC 793, September 1981.
5730 [TERMS] Bradner, S., "Key words for use in RFCs to Indicate
5731 Requirement Levels", BCP 14, RFC 2119, March 1997.
5733 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security
5734 (TLS) Protocol Version 1.1", RFC 4346, April 2006.
5736 [UCS2] International Organization for Standardization,
5737 "Information Technology - Universal Multiple-octet coded
5738 Character Set (UCS) - Amendment 2: UCS Transformation
5739 Format 8 (UTF-8)", ISO Standard 10646-1 Addendum 2,
5740 October 1996.
5742 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
5743 10646", STD 63, RFC 3629, November 2003.
5745 [UUID] Leach, P., Mealling, M., and R. Salz, "A Universally
5746 Unique IDentifier (UUID) URN Namespace", RFC 4122,
5747 July 2005.
5749 [X509] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
5750 X.509 Public Key Infrastructure Certificate and
5751 Certificate Revocation List (CRL) Profile", RFC 3280,
5752 April 2002.
5754 [XML] Paoli, J., Maler, E., Sperberg-McQueen, C., Yergeau, F.,
5755 and T. Bray, "Extensible Markup Language (XML) 1.0 (Fourth
5756 Edition)", World Wide Web Consortium Recommendation REC-
5757 xml-20060816, August 2006,
5758 .
5760 [XML-NAMES]
5761 Bray, T., Hollander, D., and A. Layman, "Namespaces in
5762 XML", W3C REC-xml-names, January 1999,
5763 .
5765 17.2. Informative References
5767 [ACAP] Newman, C. and J. Myers, "ACAP -- Application
5768 Configuration Access Protocol", RFC 2244, November 1997.
5770 [ASN.1] CCITT, "Recommendation X.208: Specification of Abstract
5771 Syntax Notation One (ASN.1)", 1988.
5773 [DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S.
5774 Rose, "DNS Security Introduction and Requirements",
5775 RFC 4033, March 2005.
5777 [DNS-TXT] Rosenbaum, R., "Using the Domain Name System To Store
5778 Arbitrary String Attributes", RFC 1464, May 1993.
5780 [DOS] Handley, M., Rescorla, E., and IAB, "Internet Denial-of-
5781 Service Considerations", RFC 4732, December 2006.
5783 [GSS-API] Linn, J., "Generic Security Service Application Program
5784 Interface Version 2, Update 1", RFC 2743, January 2000.
5786 [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
5787 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
5788 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
5790 [HTTP-TLS]
5791 Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
5793 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
5794 4rev1", RFC 3501, March 2003.
5796 [IMP-REQS]
5797 Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging
5798 / Presence Protocol Requirements", RFC 2779,
5799 February 2000.
5801 [IRI] Duerst, M. and M. Suignard, "Internationalized Resource
5802 Identifiers (IRIs)", RFC 3987, January 2005.
5804 [LINKLOCAL]
5805 Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
5806 Configuration of IPv4 Link-Local Addresses", RFC 3927,
5807 May 2005.
5809 [MAILBOXES]
5810 Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND
5811 FUNCTIONS", RFC 2142, May 1997.
5813 [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
5814 STD 53, RFC 1939, May 1996.
5816 [PUNYCODE]
5817 Costello, A., "Punycode: A Bootstring encoding of Unicode
5818 for Internationalized Domain Names in Applications
5819 (IDNA)", RFC 3492, March 2003.
5821 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence
5822 Protocol (XMPP): Core", RFC 3920, October 2004.
5824 [RFC3921] Saint-Andre, P., Ed., "Extensible Messaging and Presence
5825 Protocol (XMPP): Instant Messaging and Presence",
5826 RFC 3921, October 2004.
5828 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
5829 April 2001.
5831 [STD13] Mockapetris, P., "Domain names - implementation and
5832 specification", STD 13, RFC 1035, November 1987.
5834 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
5835 Resource Identifier (URI): Generic Syntax", STD 66,
5836 RFC 3986, January 2005.
5838 [URN-OID] Mealling, M., "A URN Namespace of Object Identifiers",
5839 RFC 3061, February 2001.
5841 [USINGTLS]
5842 Newman, C., "Using TLS with IMAP, POP3 and ACAP",
5843 RFC 2595, June 1999.
5845 [XEP-0001]
5846 Saint-Andre, P., "XMPP Extension Protocols", XSF XEP 0001,
5847 December 2006.
5849 [XEP-0045]
5850 Saint-Andre, P., "Multi-User Chat", XSF XEP 0045,
5851 April 2007.
5853 [XEP-0060]
5854 Millard, P., Saint-Andre, P., and R. Meijer, "Publish-
5855 Subscribe", XSF XEP 0060, September 2007.
5857 [XEP-0071]
5858 Saint-Andre, P., "XHTML-IM", XSF XEP 0071, August 2007.
5860 [XEP-0077]
5861 Saint-Andre, P., "In-Band Registration", XSF XEP 0077,
5862 January 2006.
5864 [XEP-0124]
5865 Paterson, I., Smith, D., and P. Saint-Andre,
5866 "Bidirectional-streams Over Synchronous HTTP (BOSH)", XSF
5867 XEP 0124, February 2007.
5869 [XEP-0156]
5870 Hildebrand, J. and P. Saint-Andre, "Discovering
5871 Alternative XMPP Connection Methods", XSF XEP 0156,
5872 June 2007.
5874 [XEP-0157]
5875 Saint-Andre, P. and J. Konieczny, "Contact Addresses for
5876 XMPP Services", XSF XEP 0157, January 2007.
5878 [XEP-0165]
5879 Saint-Andre, P., "Best Practices to Prevent JID
5880 Mimicking", XSF XEP 0165, July 2007.
5882 [XEP-0174]
5883 Saint-Andre, P., "Link-Local Messaging", XSF XEP 0174,
5884 June 2007.
5886 [XEP-0175]
5887 Saint-Andre, P., "Best Practices for Use of SASL
5888 ANONYMOUS", XSF XEP 0175, September 2006.
5890 [XEP-0178]
5891 Saint-Andre, P. and P. Millard, "Best Practices for Use of
5892 SASL EXTERNAL with Certificates", XSF XEP 0178,
5893 February 2007.
5895 [XEP-0205]
5896 Saint-Andre, P., "Best Practices to Discourage Denial of
5897 Service Attacks", XSF XEP 0205, July 2007.
5899 [XEP-0206]
5900 Paterson, I., "XMPP Over BOSH", XSF XEP 0206, June 2007.
5902 [XEP-0220]
5903 Saint-Andre, P. and J. Miller, "Server Dialback", XSF
5904 XEP 0220, July 2007.
5906 [XML-REG] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
5907 January 2004.
5909 [XML-SCHEMA]
5910 Thompson, H., Maloney, M., Mendelsohn, N., and D. Beech,
5911 "XML Schema Part 1: Structures Second Edition", World Wide
5912 Web Consortium Recommendation REC-xmlschema-1-20041028,
5913 October 2004,
5914 .
5916 [XMPP-IM] Saint-Andre, P., "Extensible Messaging and Presence
5917 Protocol (XMPP): Instant Messaging and Presence",
5918 draft-saintandre-rfc3921bis-03 (work in progress),
5919 July 2007.
5921 [XMPP-URI]
5922 Saint-Andre, P., "Internationalized Resource Identifiers
5923 (IRIs) and Uniform Resource Identifiers (URIs) for the
5924 Extensible Messaging and Presence Protocol (XMPP)",
5925 draft-saintandre-rfc4622bis-01 (work in progress),
5926 June 2007.
5928 Appendix A. Nodeprep
5930 A.1. Introduction
5932 This appendix defines the "Nodeprep" profile of stringprep. As such,
5933 it specifies processing rules that will enable users to enter
5934 internationalized node identifiers in the Extensible Messaging and
5935 Presence Protocol (XMPP) and have the highest chance of getting the
5936 content of the strings correct. (An XMPP node identifier is the
5937 optional portion of an XMPP address that precedes an XMPP domain
5938 identifier and the '@' separator; it is often but not exclusively
5939 associated with an instant messaging username.) These processing
5940 rules are intended only for XMPP node identifiers and are not
5941 intended for arbitrary text or any other aspect of an XMPP address.
5943 This profile defines the following, as required by [STRINGPREP]:
5945 o The intended applicability of the profile: internationalized node
5946 identifiers within XMPP
5947 o The character repertoire that is the input and output to
5948 stringprep: Unicode 3.2, specified in Section 2 of this Appendix
5949 o The mappings used: specified in Section 3
5950 o The Unicode normalization used: specified in Section 4
5951 o The characters that are prohibited as output: specified in Section
5952 5
5953 o Bidirectional character handling: specified in Section 6
5955 A.2. Character Repertoire
5957 This profile uses Unicode 3.2 with the list of unassigned code points
5958 being Table A.1, both defined in Appendix A of [STRINGPREP].
5960 A.3. Mapping
5962 This profile specifies mapping using the following tables from
5963 [STRINGPREP]:
5965 Table B.1
5966 Table B.2
5968 A.4. Normalization
5970 This profile specifies the use of Unicode normalization form KC, as
5971 described in [STRINGPREP].
5973 A.5. Prohibited Output
5975 This profile specifies the prohibition of using the following tables
5976 from [STRINGPREP].
5978 Table C.1.1
5979 Table C.1.2
5980 Table C.2.1
5981 Table C.2.2
5982 Table C.3
5983 Table C.4
5984 Table C.5
5985 Table C.6
5986 Table C.7
5987 Table C.8
5988 Table C.9
5990 In addition, the following Unicode characters are also prohibited:
5992 #x22 (")
5993 #x26 (&)
5994 #x27 (')
5995 #x2F (/)
5996 #x3A (:)
5997 #x3C (<)
5998 #x3E (>)
5999 #x40 (@)
6001 A.6. Bidirectional Characters
6003 This profile specifies checking bidirectional strings, as described
6004 in Section 6 of [STRINGPREP].
6006 Appendix B. Resourceprep
6008 B.1. Introduction
6010 This appendix defines the "Resourceprep" profile of stringprep. As
6011 such, it specifies processing rules that will enable users to enter
6012 internationalized resource identifiers in the Extensible Messaging
6013 and Presence Protocol (XMPP) and have the highest chance of getting
6014 the content of the strings correct. (An XMPP resource identifier is
6015 the optional portion of an XMPP address that follows an XMPP domain
6016 identifier and the '/' separator.) These processing rules are
6017 intended only for XMPP resource identifiers and are not intended for
6018 arbitrary text or any other aspect of an XMPP address.
6020 This profile defines the following, as required by [STRINGPREP]:
6022 o The intended applicability of the profile: internationalized
6023 resource identifiers within XMPP
6024 o The character repertoire that is the input and output to
6025 stringprep: Unicode 3.2, specified in Section 2 of this Appendix
6026 o The mappings used: specified in Section 3
6027 o The Unicode normalization used: specified in Section 4
6028 o The characters that are prohibited as output: specified in Section
6029 5
6031 o Bidirectional character handling: specified in Section 6
6033 B.2. Character Repertoire
6035 This profile uses Unicode 3.2 with the list of unassigned code points
6036 being Table A.1, both defined in Appendix A of [STRINGPREP].
6038 B.3. Mapping
6040 This profile specifies mapping using the following tables from
6041 [STRINGPREP]:
6043 Table B.1
6045 B.4. Normalization
6047 This profile specifies the use of Unicode normalization form KC, as
6048 described in [STRINGPREP].
6050 B.5. Prohibited Output
6052 This profile specifies the prohibition of using the following tables
6053 from [STRINGPREP].
6055 Table C.1.2
6056 Table C.2.1
6057 Table C.2.2
6058 Table C.3
6059 Table C.4
6060 Table C.5
6061 Table C.6
6062 Table C.7
6063 Table C.8
6064 Table C.9
6066 B.6. Bidirectional Characters
6068 This profile specifies checking bidirectional strings, as described
6069 in Section 6 of [STRINGPREP].
6071 Appendix C. XML Schemas
6073 Because validation of XML streams and stanzas is optional, the
6074 following XML schemas are provided for descriptive purposes only.
6075 These schemas are not normative.
6077 The following schemas formally define various XML namespaces used in
6078 the core XMPP protocols, in conformance with [XML-SCHEMA]. For
6079 schemas defining the 'jabber:client' and 'jabber:server' namespaces,
6080 refer to [XMPP-IM].
6082 C.1. Streams namespace
6084
6086
6092
6096
6097
6099
6107
6108
6112
6113
6119
6120
6122
6128
6130
6131
6132
6134
6136
6137
6138
6139
6147
6148
6150
6152 C.2. Stream error namespace
6154
6156
6162
6188
6189
6214
6216
6217
6218
6219
6220
6223
6224
6225
6227
6228
6229
6231
6233
6235 C.3. STARTTLS namespace
6237
6239
6245
6246
6247
6248
6252
6253
6255
6259
6260
6262
6264
6266 C.4. SASL namespace
6268
6270
6276
6277
6278
6279
6291
6292
6294
6295
6296
6297
6298
6302
6303
6304
6306
6312
6313
6314
6323
6324
6326
6327
6328
6330
6332
6334 C.5. Resource binding namespace
6335
6337
6343
6344
6345
6346
6347
6350
6355
6356
6358
6359
6360
6361
6363
6364
6366
6367
6368
6371
6373
6374
6375
6378
6380
6382 C.6. Stanza error namespace
6383
6385
6391
6416
6417
6442
6444
6445
6446
6447
6448
6450
6451
6452
6454
6455
6456
6458
6460
6462 Appendix D. Contact Addresses
6464 Consistent with [MAILBOXES], an organization that offers an XMPP
6465 service should provide an Internet mailbox of "XMPP" for inquiries
6466 related to that service, where the host portion of the resulting
6467 mailto URI should be the organization's domain, not necessarily the
6468 domain of the XMPP service itself (e.g., the XMPP service might be
6469 offered at xmpp.example.net but the Internet mailbox should be
6470 ).
6472 In addition, the XMPP service should provide a way to discover the
6473 XMPP contact address(es) of the service administrator(s), as
6474 specified in [XEP-0157].
6476 Appendix E. Account Provisioning
6478 Account provisioning is out of scope for this specification.
6479 Possible methods for account provisioning include account creation by
6480 a server administrator and in-band account registration using the
6481 'jabber:iq:register' namespace as documented in [XEP-0077].
6483 Appendix F. Differences From RFC 3920
6485 Based on consensus derived from implementation and deployment
6486 experience as well as formal interoperability testing, the following
6487 substantive modifications were made from RFC 3920.
6489 o Corrected the ABNF syntax for JIDs to prevent zero-length node
6490 identifiers, domain identifiers, and resource identifiers.
6491 o Corrected the nameprep processing rules to require use of the
6492 UseSTD3ASCIIRules flag.
6493 o Encouraged use of the 'from' and 'to' attributes on stream
6494 headers.
6495 o More fully specified stream closing handshake.
6496 o Specified recommended stream reconnection algorithm.
6497 o Specified return of