' 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: '3' on line 481
-- Looks like a reference, but probably isn't: '1' on line 1045
** 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'
-- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE'
** Obsolete normative reference: RFC 3280 (ref. 'X509') (Obsoleted by RFC
5280)
-- Possible downref: Non-RFC (?) normative reference: ref. 'XML'
-- Possible downref: Non-RFC (?) normative reference: ref. 'XML-NAMES'
-- Obsolete informational reference (is this intentional?): RFC 2831 (ref.
'DIGEST-MD5') (Obsoleted by RFC 6331)
-- Obsolete informational reference (is this intentional?): RFC 2616 (ref.
'HTTP') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234,
RFC 7235)
-- Obsolete informational reference (is this intentional?): RFC 3501 (ref.
'IMAP') (Obsoleted by RFC 9051)
-- Obsolete informational reference (is this intentional?): RFC 3920
(Obsoleted by RFC 6120)
-- Obsolete informational reference (is this intentional?): RFC 3921
(Obsoleted by RFC 6121)
-- Obsolete informational reference (is this intentional?): RFC 2821 (ref.
'SMTP') (Obsoleted by RFC 5321)
== Outdated reference: A later version (-08) exists of
draft-saintandre-rfc3921bis-06
Summary: 8 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 16, 2008
5 Intended status: Standards Track
6 Expires: April 19, 2009
8 Extensible Messaging and Presence Protocol (XMPP): Core
9 draft-saintandre-rfc3920bis-08
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 19, 2009.
36 Abstract
38 This document defines the core features of the Extensible Messaging
39 and Presence Protocol (XMPP), a technology for streaming Extensible
40 Markup Language (XML) elements for the purpose of exchanging
41 structured information in close to real time between any two or more
42 network-aware entities. XMPP provides a generalized, extensible
43 framework for incrementally exchanging XML data, upon which a variety
44 of applications can be built. The framework includes methods for
45 stream setup and teardown, channel encryption, authentication of a
46 client to a server and of one server to another server, and
47 primitives for push-style messages, publication of network
48 availability information ("presence"), and request-response
49 interactions. This document also specifies the format for XMPP
50 addresses, which are fully internationalizable.
52 This document obsoletes RFC 3920.
54 Table of Contents
56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 9
57 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 9
58 1.2. Functional Summary . . . . . . . . . . . . . . . . . . . 10
59 1.3. Conventions . . . . . . . . . . . . . . . . . . . . . . 11
60 1.4. Acknowledgements . . . . . . . . . . . . . . . . . . . . 12
61 1.5. Discussion Venue . . . . . . . . . . . . . . . . . . . . 12
62 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 12
63 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 12
64 2.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 13
65 2.3. Client . . . . . . . . . . . . . . . . . . . . . . . . . 13
66 2.4. Network . . . . . . . . . . . . . . . . . . . . . . . . 14
67 3. Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 14
68 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 14
69 3.2. Domain Identifier . . . . . . . . . . . . . . . . . . . 15
70 3.3. Node Identifier . . . . . . . . . . . . . . . . . . . . 16
71 3.4. Resource Identifier . . . . . . . . . . . . . . . . . . 17
72 3.5. Determination of Addresses . . . . . . . . . . . . . . . 18
73 4. TCP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 18
74 4.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . 18
75 4.2. Hostname Resolution . . . . . . . . . . . . . . . . . . 19
76 4.3. Client-to-Server Communication . . . . . . . . . . . . . 20
77 4.4. Server-to-Server Communication . . . . . . . . . . . . . 20
78 4.5. Reconnection . . . . . . . . . . . . . . . . . . . . . . 20
79 4.6. Other Bindings . . . . . . . . . . . . . . . . . . . . . 21
80 5. XML Streams . . . . . . . . . . . . . . . . . . . . . . . . . 21
81 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 21
82 5.2. Stream Security . . . . . . . . . . . . . . . . . . . . 23
83 5.3. Stream Attributes . . . . . . . . . . . . . . . . . . . 24
84 5.3.1. from . . . . . . . . . . . . . . . . . . . . . . . . 24
85 5.3.2. to . . . . . . . . . . . . . . . . . . . . . . . . . 26
86 5.3.3. id . . . . . . . . . . . . . . . . . . . . . . . . . 27
87 5.3.4. xml:lang . . . . . . . . . . . . . . . . . . . . . . 27
88 5.3.5. version . . . . . . . . . . . . . . . . . . . . . . 29
89 5.3.6. Summary of Stream Attributes . . . . . . . . . . . . 30
90 5.4. Namespace Declarations . . . . . . . . . . . . . . . . . 30
91 5.5. Stream Features . . . . . . . . . . . . . . . . . . . . 31
92 5.6. Restarts During Stream Negotiation . . . . . . . . . . . 33
93 5.7. Closing a Stream . . . . . . . . . . . . . . . . . . . . 33
94 5.7.1. With Stream Error . . . . . . . . . . . . . . . . . 33
95 5.7.2. Without Stream Error . . . . . . . . . . . . . . . . 34
96 5.7.3. Handling of Idle Streams . . . . . . . . . . . . . . 34
97 5.8. Stream Errors . . . . . . . . . . . . . . . . . . . . . 35
98 5.8.1. Rules . . . . . . . . . . . . . . . . . . . . . . . 35
99 5.8.1.1. Stream Errors Are Unrecoverable . . . . . . . . . 35
100 5.8.1.2. Stream Errors Can Occur During Setup . . . . . . 35
101 5.8.1.3. Stream Errors When the Host is Unspecified or
102 Unknown . . . . . . . . . . . . . . . . . . . . . 36
103 5.8.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . 37
104 5.8.3. Defined Stream Error Conditions . . . . . . . . . . 38
105 5.8.3.1. bad-format . . . . . . . . . . . . . . . . . . . 38
106 5.8.3.2. bad-namespace-prefix . . . . . . . . . . . . . . 38
107 5.8.3.3. conflict . . . . . . . . . . . . . . . . . . . . 39
108 5.8.3.4. connection-timeout . . . . . . . . . . . . . . . 40
109 5.8.3.5. host-gone . . . . . . . . . . . . . . . . . . . . 40
110 5.8.3.6. host-unknown . . . . . . . . . . . . . . . . . . 41
111 5.8.3.7. improper-addressing . . . . . . . . . . . . . . . 42
112 5.8.3.8. internal-server-error . . . . . . . . . . . . . . 42
113 5.8.3.9. invalid-from . . . . . . . . . . . . . . . . . . 43
114 5.8.3.10. invalid-id . . . . . . . . . . . . . . . . . . . 43
115 5.8.3.11. invalid-namespace . . . . . . . . . . . . . . . . 44
116 5.8.3.12. invalid-xml . . . . . . . . . . . . . . . . . . . 44
117 5.8.3.13. not-authorized . . . . . . . . . . . . . . . . . 45
118 5.8.3.14. policy-violation . . . . . . . . . . . . . . . . 46
119 5.8.3.15. remote-connection-failed . . . . . . . . . . . . 47
120 5.8.3.16. resource-constraint . . . . . . . . . . . . . . . 47
121 5.8.3.17. restricted-xml . . . . . . . . . . . . . . . . . 48
122 5.8.3.18. see-other-host . . . . . . . . . . . . . . . . . 48
123 5.8.3.19. system-shutdown . . . . . . . . . . . . . . . . . 49
124 5.8.3.20. undefined-condition . . . . . . . . . . . . . . . 50
125 5.8.3.21. unsupported-encoding . . . . . . . . . . . . . . 50
126 5.8.3.22. unsupported-stanza-type . . . . . . . . . . . . . 51
127 5.8.3.23. unsupported-version . . . . . . . . . . . . . . . 51
128 5.8.3.24. xml-not-well-formed . . . . . . . . . . . . . . . 52
129 5.8.4. Application-Specific Conditions . . . . . . . . . . 53
130 5.9. Simplified Stream Examples . . . . . . . . . . . . . . . 53
131 6. STARTTLS Negotiation . . . . . . . . . . . . . . . . . . . . 55
132 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 56
133 6.2. Rules . . . . . . . . . . . . . . . . . . . . . . . . . 56
134 6.2.1. Data Formatting . . . . . . . . . . . . . . . . . . 56
135 6.2.2. Order of Negotiation . . . . . . . . . . . . . . . . 56
136 6.3. Process . . . . . . . . . . . . . . . . . . . . . . . . 57
137 6.3.1. Exchange of Stream Headers and Stream Features . . . 57
138 6.3.2. Initiation of STARTTLS Negotiation . . . . . . . . . 58
139 6.3.2.1. STARTTLS Command . . . . . . . . . . . . . . . . 58
140 6.3.2.2. Failure Case . . . . . . . . . . . . . . . . . . 58
141 6.3.2.3. Proceed Case . . . . . . . . . . . . . . . . . . 59
142 6.3.3. TLS Negotiation . . . . . . . . . . . . . . . . . . 59
143 6.3.3.1. Rules . . . . . . . . . . . . . . . . . . . . . . 59
144 6.3.3.2. TLS Failure . . . . . . . . . . . . . . . . . . . 60
145 6.3.3.3. TLS Success . . . . . . . . . . . . . . . . . . . 60
146 7. SASL Negotiation . . . . . . . . . . . . . . . . . . . . . . 61
147 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 61
148 7.2. Rules . . . . . . . . . . . . . . . . . . . . . . . . . 61
149 7.2.1. Mechanism Preferences . . . . . . . . . . . . . . . 61
150 7.2.2. Mechanism Offers . . . . . . . . . . . . . . . . . . 62
151 7.2.3. Data Formatting . . . . . . . . . . . . . . . . . . 62
152 7.2.4. Security Layers . . . . . . . . . . . . . . . . . . 63
153 7.2.5. Simple Usernames . . . . . . . . . . . . . . . . . . 63
154 7.2.6. Authorization Identities . . . . . . . . . . . . . . 63
155 7.2.7. Round Trips . . . . . . . . . . . . . . . . . . . . 64
156 7.3. Process . . . . . . . . . . . . . . . . . . . . . . . . 64
157 7.3.1. Exchange of Stream Headers and Stream Features . . . 64
158 7.3.2. Initiation . . . . . . . . . . . . . . . . . . . . . 66
159 7.3.3. Challenge-Response Sequence . . . . . . . . . . . . 66
160 7.3.4. Abort . . . . . . . . . . . . . . . . . . . . . . . 67
161 7.3.5. Failure . . . . . . . . . . . . . . . . . . . . . . 67
162 7.3.6. Success . . . . . . . . . . . . . . . . . . . . . . 68
163 7.4. SASL Errors . . . . . . . . . . . . . . . . . . . . . . 69
164 7.4.1. aborted . . . . . . . . . . . . . . . . . . . . . . 69
165 7.4.2. account-disabled . . . . . . . . . . . . . . . . . . 70
166 7.4.3. credentials-expired . . . . . . . . . . . . . . . . 70
167 7.4.4. encryption-required . . . . . . . . . . . . . . . . 70
168 7.4.5. incorrect-encoding . . . . . . . . . . . . . . . . . 71
169 7.4.6. invalid-authzid . . . . . . . . . . . . . . . . . . 71
170 7.4.7. invalid-mechanism . . . . . . . . . . . . . . . . . 71
171 7.4.8. malformed-request . . . . . . . . . . . . . . . . . 71
172 7.4.9. mechanism-too-weak . . . . . . . . . . . . . . . . . 72
173 7.4.10. not-authorized . . . . . . . . . . . . . . . . . . . 72
174 7.4.11. temporary-auth-failure . . . . . . . . . . . . . . . 73
175 7.4.12. transition-needed . . . . . . . . . . . . . . . . . 73
176 7.5. SASL Definition . . . . . . . . . . . . . . . . . . . . 73
177 8. Resource Binding . . . . . . . . . . . . . . . . . . . . . . 74
178 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 74
179 8.2. Advertising Support . . . . . . . . . . . . . . . . . . 75
180 8.3. Generation of Resource Identifiers . . . . . . . . . . . 75
181 8.4. Server-Generated Resource Identifier . . . . . . . . . . 76
182 8.4.1. Success Case . . . . . . . . . . . . . . . . . . . . 76
183 8.4.2. Error Cases . . . . . . . . . . . . . . . . . . . . 76
184 8.4.2.1. Resource Constraint . . . . . . . . . . . . . . . 76
185 8.4.2.2. Not Allowed . . . . . . . . . . . . . . . . . . . 77
186 8.5. Client-Submitted Resource Identifier . . . . . . . . . . 77
187 8.5.1. Success Case . . . . . . . . . . . . . . . . . . . . 77
188 8.5.2. Error Cases . . . . . . . . . . . . . . . . . . . . 78
189 8.5.2.1. Bad Request . . . . . . . . . . . . . . . . . . . 78
190 8.5.2.2. Conflict . . . . . . . . . . . . . . . . . . . . 78
191 8.5.3. Retries . . . . . . . . . . . . . . . . . . . . . . 79
193 8.6. Binding Multiple Resources . . . . . . . . . . . . . . . 79
194 8.6.1. Support . . . . . . . . . . . . . . . . . . . . . . 80
195 8.6.2. Binding an Additional Resource . . . . . . . . . . . 80
196 8.6.3. Unbinding a Resource . . . . . . . . . . . . . . . . 80
197 8.6.3.1. Success Case . . . . . . . . . . . . . . . . . . 80
198 8.6.3.2. Error Cases . . . . . . . . . . . . . . . . . . . 81
199 8.6.4. From Addresses . . . . . . . . . . . . . . . . . . . 81
200 9. XML Stanzas . . . . . . . . . . . . . . . . . . . . . . . . . 82
201 9.1. Common Attributes . . . . . . . . . . . . . . . . . . . 82
202 9.1.1. to . . . . . . . . . . . . . . . . . . . . . . . . . 83
203 9.1.1.1. Client-to-Server Streams . . . . . . . . . . . . 83
204 9.1.1.2. Server-to-Server Streams . . . . . . . . . . . . 83
205 9.1.2. from . . . . . . . . . . . . . . . . . . . . . . . . 83
206 9.1.2.1. Client-to-Server Streams . . . . . . . . . . . . 84
207 9.1.2.2. Server-to-Server Streams . . . . . . . . . . . . 84
208 9.1.3. id . . . . . . . . . . . . . . . . . . . . . . . . . 85
209 9.1.4. type . . . . . . . . . . . . . . . . . . . . . . . . 85
210 9.1.5. xml:lang . . . . . . . . . . . . . . . . . . . . . . 85
211 9.2. Basic Semantics . . . . . . . . . . . . . . . . . . . . 86
212 9.2.1. Message Semantics . . . . . . . . . . . . . . . . . 86
213 9.2.2. Presence Semantics . . . . . . . . . . . . . . . . . 87
214 9.2.3. IQ Semantics . . . . . . . . . . . . . . . . . . . . 87
215 9.3. Stanza Errors . . . . . . . . . . . . . . . . . . . . . 89
216 9.3.1. Rules . . . . . . . . . . . . . . . . . . . . . . . 89
217 9.3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . 89
218 9.3.3. Defined Conditions . . . . . . . . . . . . . . . . . 91
219 9.3.3.1. bad-request . . . . . . . . . . . . . . . . . . . 91
220 9.3.3.2. conflict . . . . . . . . . . . . . . . . . . . . 91
221 9.3.3.3. feature-not-implemented . . . . . . . . . . . . . 92
222 9.3.3.4. forbidden . . . . . . . . . . . . . . . . . . . . 92
223 9.3.3.5. gone . . . . . . . . . . . . . . . . . . . . . . 93
224 9.3.3.6. internal-server-error . . . . . . . . . . . . . . 93
225 9.3.3.7. item-not-found . . . . . . . . . . . . . . . . . 94
226 9.3.3.8. jid-malformed . . . . . . . . . . . . . . . . . . 94
227 9.3.3.9. not-acceptable . . . . . . . . . . . . . . . . . 95
228 9.3.3.10. not-allowed . . . . . . . . . . . . . . . . . . . 95
229 9.3.3.11. not-authorized . . . . . . . . . . . . . . . . . 96
230 9.3.3.12. not-modified . . . . . . . . . . . . . . . . . . 96
231 9.3.3.13. payment-required . . . . . . . . . . . . . . . . 97
232 9.3.3.14. recipient-unavailable . . . . . . . . . . . . . . 98
233 9.3.3.15. redirect . . . . . . . . . . . . . . . . . . . . 99
234 9.3.3.16. registration-required . . . . . . . . . . . . . . 99
235 9.3.3.17. remote-server-not-found . . . . . . . . . . . . . 100
236 9.3.3.18. remote-server-timeout . . . . . . . . . . . . . . 100
237 9.3.3.19. resource-constraint . . . . . . . . . . . . . . . 100
238 9.3.3.20. service-unavailable . . . . . . . . . . . . . . . 101
239 9.3.3.21. subscription-required . . . . . . . . . . . . . . 101
240 9.3.3.22. undefined-condition . . . . . . . . . . . . . . . 102
241 9.3.3.23. unexpected-request . . . . . . . . . . . . . . . 103
242 9.3.3.24. unknown-sender . . . . . . . . . . . . . . . . . 104
243 9.3.4. Application-Specific Conditions . . . . . . . . . . 104
244 9.4. Extended Content . . . . . . . . . . . . . . . . . . . . 105
245 9.5. Stanza Size . . . . . . . . . . . . . . . . . . . . . . 106
246 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 106
247 10.1. Client-to-Server . . . . . . . . . . . . . . . . . . . . 106
248 10.1.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . 107
249 10.1.2. SASL . . . . . . . . . . . . . . . . . . . . . . . . 108
250 10.1.3. Resource Binding . . . . . . . . . . . . . . . . . . 109
251 10.1.4. Stanza Exchange . . . . . . . . . . . . . . . . . . 110
252 10.1.5. Close . . . . . . . . . . . . . . . . . . . . . . . 111
253 10.2. Server-to-Server Examples . . . . . . . . . . . . . . . 111
254 10.2.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . 111
255 10.2.2. SASL . . . . . . . . . . . . . . . . . . . . . . . . 113
256 10.2.3. Stanza Exchange . . . . . . . . . . . . . . . . . . 114
257 10.2.4. Close . . . . . . . . . . . . . . . . . . . . . . . 115
258 11. Server Rules for Processing XML Stanzas . . . . . . . . . . . 115
259 11.1. No 'to' Address . . . . . . . . . . . . . . . . . . . . 115
260 11.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 115
261 11.1.2. Message . . . . . . . . . . . . . . . . . . . . . . 116
262 11.1.3. Presence . . . . . . . . . . . . . . . . . . . . . . 116
263 11.1.4. IQ . . . . . . . . . . . . . . . . . . . . . . . . . 116
264 11.2. Local Domain . . . . . . . . . . . . . . . . . . . . . . 116
265 11.2.1. Mere Domain . . . . . . . . . . . . . . . . . . . . 117
266 11.2.2. Domain with Resource . . . . . . . . . . . . . . . . 117
267 11.2.3. Node at Domain . . . . . . . . . . . . . . . . . . . 117
268 11.2.3.1. No Such User . . . . . . . . . . . . . . . . . . 117
269 11.2.3.2. Bare JID . . . . . . . . . . . . . . . . . . . . 117
270 11.2.3.3. Full JID . . . . . . . . . . . . . . . . . . . . 118
271 11.3. Foreign Domain . . . . . . . . . . . . . . . . . . . . . 118
272 11.3.1. Existing Stream . . . . . . . . . . . . . . . . . . 118
273 11.3.2. No Existing Stream . . . . . . . . . . . . . . . . . 118
274 11.3.3. Error Handling . . . . . . . . . . . . . . . . . . . 119
275 12. XML Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 119
276 12.1. Restrictions . . . . . . . . . . . . . . . . . . . . . . 119
277 12.2. XML Namespace Names and Prefixes . . . . . . . . . . . . 120
278 12.2.1. Streams Namespace . . . . . . . . . . . . . . . . . 120
279 12.2.2. Default Namespace . . . . . . . . . . . . . . . . . 120
280 12.2.3. Extended Namespaces . . . . . . . . . . . . . . . . 121
281 12.3. Well-Formedness . . . . . . . . . . . . . . . . . . . . 122
282 12.4. Validation . . . . . . . . . . . . . . . . . . . . . . . 123
283 12.5. Inclusion of Text Declaration . . . . . . . . . . . . . 123
284 12.6. Character Encoding . . . . . . . . . . . . . . . . . . . 123
285 12.7. Whitespace . . . . . . . . . . . . . . . . . . . . . . . 124
286 12.8. XML Versions . . . . . . . . . . . . . . . . . . . . . . 124
287 13. Compliance Requirements . . . . . . . . . . . . . . . . . . . 124
288 13.1. Servers . . . . . . . . . . . . . . . . . . . . . . . . 124
289 13.2. Clients . . . . . . . . . . . . . . . . . . . . . . . . 125
290 14. Internationalization Considerations . . . . . . . . . . . . . 125
291 15. Security Considerations . . . . . . . . . . . . . . . . . . . 126
292 15.1. High Security . . . . . . . . . . . . . . . . . . . . . 126
293 15.2. Certificates . . . . . . . . . . . . . . . . . . . . . . 126
294 15.2.1. Certificate Generation . . . . . . . . . . . . . . . 126
295 15.2.1.1. Server Certificates . . . . . . . . . . . . . . . 126
296 15.2.1.2. Client Certificates . . . . . . . . . . . . . . . 128
297 15.2.1.3. ASN.1 Object Identifier . . . . . . . . . . . . . 129
298 15.2.2. Certificate Validation . . . . . . . . . . . . . . . 129
299 15.2.2.1. Server-to-Server Streams . . . . . . . . . . . . 130
300 15.2.2.2. Client-to-Server Streams . . . . . . . . . . . . 131
301 15.2.2.3. Use of Certificates in XMPP Extensions . . . . . 132
302 15.3. Client-to-Server Communication . . . . . . . . . . . . . 132
303 15.4. Server-to-Server Communication . . . . . . . . . . . . . 133
304 15.5. Order of Layers . . . . . . . . . . . . . . . . . . . . 133
305 15.6. Lack of SASL Channel Binding to TLS . . . . . . . . . . 134
306 15.7. Mandatory-to-Implement Technologies . . . . . . . . . . 134
307 15.8. Firewalls . . . . . . . . . . . . . . . . . . . . . . . 135
308 15.9. Use of base64 in SASL . . . . . . . . . . . . . . . . . 135
309 15.10. Stringprep Profiles . . . . . . . . . . . . . . . . . . 135
310 15.11. Address Spoofing . . . . . . . . . . . . . . . . . . . . 136
311 15.11.1. Address Forging . . . . . . . . . . . . . . . . . . 136
312 15.11.2. Address Mimicking . . . . . . . . . . . . . . . . . 137
313 15.12. Denial of Service . . . . . . . . . . . . . . . . . . . 138
314 15.13. Presence Leaks . . . . . . . . . . . . . . . . . . . . . 139
315 15.14. Directory Harvesting . . . . . . . . . . . . . . . . . . 140
316 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 140
317 16.1. XML Namespace Name for TLS Data . . . . . . . . . . . . 140
318 16.2. XML Namespace Name for SASL Data . . . . . . . . . . . . 140
319 16.3. XML Namespace Name for Stream Errors . . . . . . . . . . 140
320 16.4. XML Namespace Name for Resource Binding . . . . . . . . 141
321 16.5. XML Namespace Name for Stanza Errors . . . . . . . . . . 141
322 16.6. Nodeprep Profile of Stringprep . . . . . . . . . . . . . 141
323 16.7. Resourceprep Profile of Stringprep . . . . . . . . . . . 142
324 16.8. GSSAPI Service Name . . . . . . . . . . . . . . . . . . 142
325 16.9. Port Numbers . . . . . . . . . . . . . . . . . . . . . . 142
326 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 142
327 17.1. Normative References . . . . . . . . . . . . . . . . . . 142
328 17.2. Informative References . . . . . . . . . . . . . . . . . 145
329 Appendix A. Nodeprep . . . . . . . . . . . . . . . . . . . . . . 148
330 A.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 148
331 A.2. Character Repertoire . . . . . . . . . . . . . . . . . . 149
332 A.3. Mapping . . . . . . . . . . . . . . . . . . . . . . . . 149
333 A.4. Normalization . . . . . . . . . . . . . . . . . . . . . 149
334 A.5. Prohibited Output . . . . . . . . . . . . . . . . . . . 149
335 A.6. Bidirectional Characters . . . . . . . . . . . . . . . . 150
336 A.7. Notes . . . . . . . . . . . . . . . . . . . . . . . . . 150
338 Appendix B. Resourceprep . . . . . . . . . . . . . . . . . . . . 150
339 B.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 151
340 B.2. Character Repertoire . . . . . . . . . . . . . . . . . . 151
341 B.3. Mapping . . . . . . . . . . . . . . . . . . . . . . . . 151
342 B.4. Normalization . . . . . . . . . . . . . . . . . . . . . 151
343 B.5. Prohibited Output . . . . . . . . . . . . . . . . . . . 151
344 B.6. Bidirectional Characters . . . . . . . . . . . . . . . . 152
345 Appendix C. XML Schemas . . . . . . . . . . . . . . . . . . . . 152
346 C.1. Streams Namespace . . . . . . . . . . . . . . . . . . . 152
347 C.2. Stream Error Namespace . . . . . . . . . . . . . . . . . 154
348 C.3. STARTTLS Namespace . . . . . . . . . . . . . . . . . . . 156
349 C.4. SASL Namespace . . . . . . . . . . . . . . . . . . . . . 156
350 C.5. Resource Binding Namespace . . . . . . . . . . . . . . . 158
351 C.6. Stanza Error Namespace . . . . . . . . . . . . . . . . . 159
352 Appendix D. Contact Addresses . . . . . . . . . . . . . . . . . 161
353 Appendix E. Account Provisioning . . . . . . . . . . . . . . . . 161
354 Appendix F. Differences From RFC 3920 . . . . . . . . . . . . . 161
355 Appendix G. Copying Conditions . . . . . . . . . . . . . . . . . 162
356 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
357 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 164
358 Intellectual Property and Copyright Statements . . . . . . . . . 165
360 1. Introduction
362 1.1. Overview
364 The Extensible Messaging and Presence Protocol (XMPP) is an
365 application profile of the Extensible Markup Language [XML] for
366 streaming XML data in close to real time between any two (or more)
367 network-aware entities. XMPP is typically used to exchange messages,
368 share presence information, and engage in structured request-response
369 interactions. The basic syntax and semantics of XMPP were developed
370 originally within the Jabber open-source community, mainly in 1999.
371 In late 2002, the XMPP Working Group was chartered with developing an
372 adaptation of the core Jabber protocol that would be suitable as an
373 IETF instant messaging (IM) and presence technology. As a result of
374 work by the XMPP WG, [RFC3920] and [RFC3921] were published in
375 October 2004, representing the most complete definition of XMPP at
376 that time.
378 As a result of extensive implementation and deployment experience
379 with XMPP since 2004, as well as more formal interoperability testing
380 carried out under the auspices of the XMPP Standards Foundation
381 (XSF), this document reflects consensus from the XMPP developer
382 community regarding XMPP's core XML streaming technology. In
383 particular, this document incorporates the following backward-
384 compatible changes from RFC 3920:
386 o Incorporated corrections and errata
387 o Added examples throughout
388 o Clarified and more completely specified matters that were
389 underspecified
390 o Modified text to reflect updated technologies for which XMPP is a
391 using protocol, e.g., Transport Layer Security (TLS) and the
392 Simple Authentication and Security Layer (SASL)
393 o Defined several additional stream, stanza, and SASL error
394 conditions
395 o Removed the deprecated DIGEST-MD5 SASL mechanism [DIGEST-MD5] as a
396 mandatory-to-implement technology
397 o Added the TLS plus the SASL PLAIN mechanism [PLAIN] as a
398 mandatory-to-implement technology
399 o Defined of optional support for multiple resources over the same
400 connection
401 o Transferred historical documentation for the server dialback
402 protocol from this specification to a separate specification
404 Therefore, this document defines the core features of XMPP 1.0, thus
405 obsoleting RFC 3920.
407 Note: [XMPP-IM] defines the XMPP features needed to provide the
408 basic instant messaging and presence functionality that is
409 described in [IMP-REQS].
411 1.2. Functional Summary
413 This non-normative section provides a developer-friendly, functional
414 summary of XMPP; refer to the sections that follow for a normative
415 definition of XMPP.
417 The purpose of XMPP is to enable the exchange of relatively small
418 pieces of structured data (called "XML stanzas") over a network
419 between any two (or more) entities. XMPP is implemented using a
420 client-server architecture, wherein a client needs to connect to a
421 server in order to gain access to the network and thus be allowed to
422 exchange XML stanzas with other entities (which can be associated
423 with other servers). The process whereby a client connects to a
424 server, exchanges XML stanzas, and ends the connection is:
426 1. Determine the hostname and port at which to connect
427 2. Open a TCP connection
428 3. Open an XML stream
429 4. Complete TLS negotiation for channel encryption (recommended)
430 5. Complete SASL negotiation for authentication
431 6. Bind a resource to the stream
432 7. Exchange an unbounded number of XML stanzas with other entities
433 on the network
434 8. Close the XML stream
435 9. Close the TCP connection
437 Within XMPP, one server can optionally connect to another server to
438 enable inter-domain or inter-server communication. For this to
439 happen, the two servers need to negotiate a connection between
440 themselves and then exchange XML stanzas; the process for doing so
441 is:
443 1. Determine the hostname and port at which to connect
444 2. Open a TCP connection
445 3. Open an XML stream
446 4. Complete TLS negotiation for channel encryption (recommended)
447 5. Complete SASL negotiation for authentication *
448 6. Exchange an unbounded number of XML stanzas both directly for the
449 servers and indirectly on behalf of entities associated with each
450 server (e.g., connected clients)
451 7. Close the XML stream
452 8. Close the TCP connection
453 * Note: Depending on local service policies, it is possible that a
454 deployed server will use the older server dialback protocol to
455 provide weak identity verification in cases where SASL negotiation
456 would not result in strong authentication (e.g., because TLS
457 negotiation was not mandated by the peer server, or because the
458 certificate presented by the peer server during TLS negotiation is
459 self-signed and thus provides only weak identity); for details,
460 see [XEP-0220].
462 In the sections following discussion of XMPP architecture and XMPP
463 addresses, this document specifies how clients connect to servers and
464 specifies the basic semantics of XML stanzas. However, this document
465 does not define the "payloads" of the XML stanzas that might be
466 exchanged once a connection is successfully established; instead,
467 those payloads are defined by various XMPP extensions. For example,
468 [XMPP-IM] defines extensions for basic instant messaging and presence
469 functionality. In addition, various specifications produced in the
470 XSF's XEP series [XEP-0001] define extensions for a wide range of
471 more advanced functionality.
473 1.3. Conventions
475 The following capitalized keywords are to be interpreted as described
476 in [TERMS]: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT";
477 "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY",
478 "OPTIONAL".
480 The term "whitespace" is used to refer to any character that matches
481 production [3] content of [XML], i.e., any instance of SP, HT, CR,
482 and LF.
484 Following the "XML Notation" used in [IRI] to represent characters
485 that cannot be rendered in ASCII-only documents, some examples in
486 this document use the form "&#x...." as a notational device to
487 represent Unicode characters (e.g., the string "ř" stands for
488 the Unicode character LATIN SMALL LETTER R WITH CARON).
490 In examples, lines have been wrapped for improved readability,
491 "[...]" means elision, and the following prepended strings are used
492 (these prepended strings are not to be sent over the wire):
494 o C: = a client
495 o E: = any XMPP entity
496 o I: = an initiating entity
497 o P: = a peer server
498 o R: = a receiving entity
499 o S: = a server
500 o S1: = server1
501 o S2: = server2
503 1.4. Acknowledgements
505 The editor of this document finds it impossible to appropriately
506 acknowledge the many individuals who have provided comments regarding
507 the protocols defined herein. However, thanks are due to those who
508 have who have provided implementation feedback, bug reports, requests
509 for clarification, and suggestions for improvement since the
510 publication of the RFC this document supersedes. The editor has
511 endeavored to address all such feedback, but is solely responsible
512 for any remaining errors and ambiguities.
514 1.5. Discussion Venue
516 The document editor and the broader XMPP developer community welcome
517 discussion and comments related to the topics presented in this
518 document. The preferred forum is the mailing
519 list, for which archives and subscription information are available
520 at .
522 2. Architecture
524 2.1. Overview
526 XMPP assumes a client-server architecture, wherein a client utilizing
527 XMPP accesses a server (normally over a [TCP] connection) and servers
528 can also communicate with each other over TCP connections.
530 A simplified architectural diagram for a typical deployment is shown
531 here, where the entities have the following significance:
533 o romeo@example.net -- an XMPP user.
534 o example.net -- an XMPP server.
535 o im.example.com -- an XMPP server.
536 o juliet@im.example.com -- an XMPP user.
538 example.net ---------------- im.example.com
539 | |
540 | |
541 romeo@example.net juliet@im.example.com
542 Note: Architectures that employ XML streams (Section 5) and XML
543 stanzas (Section 9) but that establish peer-to-peer connections
544 directly between clients using technologies based on [LINKLOCAL]
545 have been deployed, but such architectures are not XMPP and are
546 best described as "XMPP-like"; for details, see [XEP-0174]. In
547 addition, XML streams can be established end-to-end over any
548 reliable transport, including extensions to XMPP itself; for
549 details, see [XEP-0246].
551 2.2. Server
553 A SERVER is an entity whose primary responsibilities are to:
555 o Manage XML streams (Section 5) with local clients and deliver XML
556 stanzas (Section 9) to those clients over the negotiated XML
557 streams.
558 o Subject to local service policies on server-to-server
559 communication, manage XML streams (Section 5) with foreign servers
560 and route XML stanzas (Section 9) to those servers over the
561 negotiated XML streams.
563 Depending on the application, the secondary responsibilities of an
564 XMPP server can include:
566 o Storing XML data that is used by clients (e.g., contact lists for
567 users of XMPP-based instant messaging and presence applications as
568 defined in [XMPP-IM]); in this case, the relevant XML stanza is
569 handled directly by the server itself on behalf of the client and
570 is not routed to a foreign server or delivered to a local entity.
571 o Hosting local services that also use XMPP as the basis for
572 communication but that provide additional functionality beyond
573 that defined in this document or in [XMPP-IM]; examples include
574 multi-user conferencing services as specified in [XEP-0045] and
575 publish-subscribe services as specified in [XEP-0060].
577 2.3. Client
579 A CLIENT is an entity that establishes an XML stream with a server by
580 authenticating using the credentials of a local account and that then
581 completes resource binding (Section 8) in order to enable delivery of
582 XML stanzas via the server to the client. A client then uses XMPP to
583 communicate with its server, other clients, and any other accessible
584 entities on a network. Multiple clients can connect simultaneously
585 to a server on behalf of a local account, where each client is
586 differentiated by the resource identifier portion of an XMPP address
587 (e.g., vs. ), as defined under
588 Section 3 and Section 8. The RECOMMENDED port for TCP connections
589 between a client and a server is 5222, as registered with the IANA
590 (see Section 16.9).
592 2.4. Network
594 Because each server is identified by a network address and because
595 server-to-server communication is a straightforward extension of the
596 client-to-server protocol, in practice the system consists of a
597 network of servers that inter-communicate. Thus, for example,
598 is able to exchange messages, presence, and
599 other information with . This pattern is familiar
600 from messaging protocols (such as [SMTP]) that make use of network
601 addressing standards. Communication between any two servers is
602 OPTIONAL. The RECOMMENDED port for TCP connections between servers
603 is 5269, as registered with the IANA (see Section 16.9).
605 3. Addresses
607 3.1. Overview
609 An ENTITY is anything that is network-addressable and that can
610 communicate using XMPP. For historical reasons, the native address
611 of an XMPP entity is called a JABBER IDENTIFIER or JID. A valid JID
612 contains a set of ordered elements formed of an XMPP node identifier,
613 domain identifier, and resource identifier.
615 The syntax for a JID is defined as follows using the Augmented
616 Backus-Naur Form as specified in [ABNF].
618 jid = [ node "@" ] domain [ "/" resource ]
619 node = 1*(nodepoint)
620 ; a "nodepoint" is a UTF-8 encoded Unicode code
621 ; point that satisfies the Nodeprep profile of
622 ; stringprep
623 domain = fqdn / address-literal
624 fqdn = *(ldhlabel ".") toplabel
625 ldhlabel = letdig [*61(ldh) letdig]
626 toplabel = ALPHA *61(ldh) letdig
627 letdig = ALPHA / DIGIT
628 ldh = ALPHA / DIGIT / "-"
629 address-literal = IPv4address / IPv6address
630 ; the "IPv4address" and "IPv6address" rules are
631 ; defined in RFC 3986
632 resource = 1*(resourcepoint)
633 ; a "resourcepoint" is a UTF-8 encoded Unicode
634 ; code point that satisfies the Resourceprep
635 ; profile of stringprep
637 All JIDs are based on the foregoing structure. One common use of
638 this structure is to identify a messaging and presence account, the
639 server that hosts the account, and a connected resource (e.g., a
640 specific device) in the form of . However,
641 node types other than clients are possible; for example, a specific
642 chat room offered by a multi-user conference service (see [XEP-0045])
643 could be addressed as (where "room" is the name of the
644 chat room and "service" is the hostname of the multi-user conference
645 service) and a specific occupant of such a room could be addressed as
646 (where "nick" is the occupant's room nickname).
647 Many other JID types are possible (e.g., could be a
648 server-side script or service).
650 Each allowable portion of a JID (node identifier, domain identifier,
651 and resource identifier) MUST NOT be more than 1023 bytes in length,
652 resulting in a maximum total size (including the '@' and '/'
653 separators) of 3071 bytes.
655 Note: While the format of a JID is consistent with [URI], an
656 entity's address on an XMPP network MUST be represented as a JID
657 (without a URI scheme) and not a [URI] or [IRI] as specified in
658 [XMPP-URI]; the latter specification is provided only for
659 identification and interaction outside the context of the XMPP
660 wire protocol itself.
662 3.2. Domain Identifier
664 The DOMAIN IDENTIFIER portion of a JID is that portion after the '@'
665 character (if any) and before the '/' character (if any); it is the
666 primary identifier and is the only REQUIRED element of a JID (a mere
667 domain identifier is a valid JID). Typically a domain identifier
668 identifies the "home" server to which clients connect for XML routing
669 and data management functionality. However, it is not necessary for
670 an XMPP domain identifier to identify an entity that provides core
671 XMPP server functionality (e.g., a domain identifier can identity an
672 entity such as a multi-user conference service, a publish-subscribe
673 service, or a user directory).
675 Note: A single server can service multiple domain identifiers,
676 i.e., multiple local domains; this is typically referred to as
677 virtual hosting.
679 The domain identifier for every server or service that will
680 communicate over a network SHOULD be a fully qualified domain name
681 (see [DNS]); while the domain identifier MAY be either an Internet
682 Protocol (IPv4 or IPv6) address or a text label that is resolvable on
683 a local network (commonly called an "unqualified hostname"), it is
684 possible that domain identifiers that are IP addresses will not be
685 acceptable to other services for the sake of interdomain
686 communication. Furthermore, domain identifiers that are unqualified
687 hostnames MUST NOT be used on public networks but MAY be used on
688 private networks.
690 Note: If the domain identifier includes a final character
691 considered to be a label separator (dot) by [IDNA] or [DNS], this
692 character MUST be stripped from the domain identifier before the
693 JID of which it is a part is used for the purpose of routing an
694 XML stanza, comparing against another JID, or constructing an
695 [XMPP-URI]; in particular, the character MUST be stripped before
696 any other canonicalization steps are taken, such as application of
697 the [NAMEPREP] profile of [STRINGPREP] or completion of the
698 ToASCII operation as described in [IDNA].
700 A domain identifier MUST be an "internationalized domain name" as
701 defined in [IDNA], that is, "a domain name in which every label is an
702 internationalized label". When preparing a text label (consisting of
703 a sequence of Unicode code points) for representation as an
704 internationalized label in the process of constructing an XMPP domain
705 identifier or comparing two XMPP domain identifiers, an application
706 MUST ensure that for each text label it is possible to apply without
707 failing the ToASCII operation specified in [IDNA] with the
708 UseSTD3ASCIIRules flag set (thus forbidding ASCII code points other
709 than letters, digits, and hyphens). If the ToASCII operation can be
710 applied without failing, then the label is an internationalized
711 label. An internationalized domain name (and therefore an XMPP
712 domain identifier) is constructed from its constituent
713 internationalized labels by following the rules specified in [IDNA].
715 Note: The ToASCII operation includes application of the [NAMEPREP]
716 profile of [STRINGPREP] and encoding using the algorithm specified
717 in [PUNYCODE]; for details, see [IDNA]. Although the output of
718 the ToASCII operation is not used in XMPP, it MUST be possible to
719 apply that operation without failing.
721 3.3. Node Identifier
723 The NODE IDENTIFIER portion of a JID is an optional secondary
724 identifier placed before the domain identifier and separated from the
725 latter by the '@' character. Typically a node identifier uniquely
726 identifies the entity requesting and using network access provided by
727 a server (i.e., a local account), although it can also represent
728 other kinds of entities (e.g., a chat room associated with a multi-
729 user conference service). The entity represented by an XMPP node
730 identifier is addressed within the context of a specific domain.
732 A node identifier MUST be formatted such that the Nodeprep profile of
734 [STRINGPREP] can be applied without failing (see Appendix A). Before
735 comparing two node identifiers, an application MUST first ensure that
736 the Nodeprep profile has been applied to each identifier (the profile
737 need not be applied each time a comparison is made, as long as it has
738 been applied before comparison).
740 3.4. Resource Identifier
742 The RESOURCE IDENTIFIER portion of a JID is an optional tertiary
743 identifier placed after the domain identifier and separated from the
744 latter by the '/' character. A resource identifier can modify either
745 a address or a mere address. Typically a
746 resource identifier uniquely identifies a specific connection (e.g.,
747 a device or location) or object (e.g., a participant in a multi-user
748 conference room) belonging to the entity associated with an XMPP node
749 identifier at a local domain.
751 When an XMPP address does not include a resource identifier (i.e.,
752 when it is of the form or ), it is referred to
753 as a BARE JID. When an XMPP address includes a resource identifier
754 (i.e., when it is of the form or
755 ), is referred to as a FULL JID.
757 A resource identifier MUST be formatted such that the Resourceprep
758 profile of [STRINGPREP] can be applied without failing (see
759 Appendix B). Before comparing two resource identifiers, an
760 application MUST first ensure that the Resourceprep profile has been
761 applied to each identifier (the profile need not be applied each time
762 a comparison is made, as long as it has been applied before
763 comparison).
765 Note: For historical reasons, the term "resource identifier" is
766 used in XMPP to refer to the optional portion of an XMPP address
767 that follows the domain identifier and the "/" separator
768 character; this use of the term "resource identifier" is not to be
769 confused with the meanings of "resource" and "identifier" provided
770 in Section 1.1 of [URI].
772 XMPP entities SHOULD consider resource identifiers to be opaque
773 strings and SHOULD NOT impute meaning to any given resource
774 identifier. In paticular, the use of the '/' character as a
775 separator between the domain identifier and the resource identifier
776 does not imply that resource identifiers are hierarchical in the say
777 that, say, HTTP addresses are hierarchical; thus for example an XMPP
778 address of the form does not identify a
779 resource "bar" that exists below a resource "foo" in a hierarchy of
780 resources associated with the entity "node@domain".
782 3.5. Determination of Addresses
784 After the parties to an XML stream have completed the appropriate
785 aspects of stream negotiation (typically SASL negotiation (Section 7)
786 and, if appropriate, resource binding (Section 8)) the receiving
787 entity for a stream MUST determine the initiating entity's JID.
789 For server-to-server communication, the initiating server's JID MUST
790 be the authorization identity (as defined by [SASL]), either (1) as
791 directly communicated by the initiating server during SASL
792 negotiation (Section 7) or (2) as derived by the receiving server
793 from the authentication identity if no authorization identity was
794 specified during SASL negotiation (Section 7). (For information
795 about the determination of addresses in the absence of SASL
796 negotiation when the older server dialback protocol is used, see
797 [XEP-0220].)
799 For client-to-server communication, the client's bare JID
800 () MUST be the authorization identity (as defined by
801 [SASL]), either (1) as directly communicated by the client during
802 SASL negotiation (Section 7) or (2) as derived by the server from the
803 authentication identity if no authorization identity was specified
804 during SASL negotiation (Section 7). The resource identifier portion
805 of the full JID () MUST be the resource
806 identifier negotiated by the client and server during resource
807 binding (Section 8).
809 The receiving entity MUST ensure that the resulting JID (including
810 node identifier, domain identifier, resource identifier, and
811 separator characters) conforms to the rules and formats defined
812 earlier in this section; to meet this restriction, the receiving
813 entity MAY replace the JID sent by the initiating entity with the
814 canonicalized JID as determined by the receiving entity.
816 4. TCP Binding
818 4.1. Scope
820 As XMPP is defined in this specification, an initiating entity
821 (client or server) MUST open a Transmission Control Protocol [TCP]
822 connection at the receiving entity (server) before it negotiates XML
823 streams with the receiving entity. The rules specified in the
824 following sections apply to the TCP binding.
826 4.2. Hostname Resolution
828 Before opening the TCP connection, the initiating entity first MUST
829 resolve the Domain Name System (DNS) hostname associated with the
830 receiving entity and determine the appropriate TCP port for
831 communication with the receiving entity. The process is:
833 1. Attempt to resolve the hostname using (a) a [DNS-SRV] Service of
834 "xmpp-client" (for client-to-server connections) or "xmpp-server"
835 (for server-to-server connections) and (b) a Proto of "tcp",
836 resulting in resource records such as "_xmpp-
837 client._tcp.example.net." or "_xmpp-server._tcp.im.example.com.".
838 The result of the SRV lookup will be one or more combinations of
839 a port and hostname, which hostnames the initiating entity MUST
840 resolve according to returned SRV record weight (if the result of
841 the SRV lookup is a single RR with a Target of ".", i.e. the root
842 domain, the initiating entity MUST abort SRV processing but
843 SHOULD attempt a fallback resolution as described below). The
844 initiating entity uses the IP address(es) from the first
845 successfully resolved hostname (with the corresponding port
846 number returned by the SRV lookup) in order to connect to the
847 receiving entity. If the initiating entity fails to connect
848 using one of the IP addresses, the initiating entity uses the
849 next resolved IP address to connect. If the initiating entity
850 fails to connect using all resolved IP addresses, then the
851 initiating entity repeats the process of resolution and
852 connection for the next hostname returned by the SRV lookup.
853 2. If the SRV lookup aborts or fails, the fallback SHOULD be a
854 normal IPv4 or IPv6 address record resolution to determine the IP
855 address, where the port used is the "xmpp-client" port of 5222
856 for client-to-server connections or the "xmpp-server" port 5269
857 for server-to-server connections.
858 3. For client-to-server connections, the fallback MAY be a [DNS-TXT]
859 lookup for alternative connection methods, for example as
860 described in [XEP-0156].
862 Note: If the initiating entity has been explicitly configured to
863 associate a particular hostname (and potentially port) with the
864 original hostname of the receiving entity (say, to "hardcode" an
865 association between an original hostname of example.net and a
866 configured hostname and of webcm.example.com:80), the initiating
867 entity SHALL use the configured name instead of performing the
868 foregoing resolution process on the original name.
870 Note: Many XMPP servers are implemented in such a way that they
871 can host additional services (beyond those defined in this
872 specification and [XMPP-IM]) at hostnames that are subdomains of
873 the hostname of the main XMPP service (e.g.,
874 conference.example.net for a [XEP-0045] service associated with
875 the example.net XMPP service) or subdomains of the first-level
876 domain of the underlying host (e.g., muc.example.com for a
877 [XEP-0045] service associated with the im.example.com XMPP
878 service). If an entity from a remote domain wishes to use such
879 additional services, it would generate an appropriate XML stanza
880 and the remote domain itself would attempt to resolve the
881 service's hostname via an SRV lookup on resource records such as
882 "_xmpp-server._tcp.conference.example.net." or "_xmpp-
883 server._tcp.muc.example.com.". Therefore if a service wishes to
884 enable entities from remote domains to access these additional
885 services, it needs to advertise the appropriate "_xmpp-server" SRV
886 records in addition to the "_xmpp-server" record for its main XMPP
887 service.
889 4.3. Client-to-Server Communication
891 Because a client is subordinate to a server and therefore a client
892 authenticates to the server but the server does not necessarily
893 authenticate to the client, it is necessary to have only one TCP
894 connection between client and server. Thus the server MUST allow the
895 client to share a single TCP connection for XML stanzas sent from
896 client to server and from server to client (i.e., the inital stream
897 and response stream as specified under Section 5).
899 4.4. Server-to-Server Communication
901 Because two servers are peers and therefore each peer MUST
902 authenticate with the other, the servers MUST use two TCP
903 connections: one for XML stanzas sent from the first server to the
904 second server and another (initiated by the second server) for XML
905 stanzas from the second server to the first server.
907 This rule applies only to XML stanzas (Section 9). Therefore during
908 STARTTLS negotiation (Section 6) and SASL negotiation (Section 7) the
909 servers would use one TCP connection, but after stream setup that TCP
910 connection would be used only for the initiating server to send XML
911 stanzas to the receiving server. In order for the receiving server
912 to send XML stanzas to the initiating server, the receiving server
913 would need to reverse the roles and negotiate an XML stream from the
914 receiving server to the initiating server.
916 4.5. Reconnection
918 It can happen that an XMPP server goes offline while servicing TCP
919 connections from local clients and from other servers. Because the
920 number of such connections can be quite large, the reconnection
921 algorithm employed by entities that seek to reconnect can have a
922 significant impact on software and network performance. The
923 following guidelines are RECOMMENDED:
925 o The time to live (TTL) specified in Domain Name System records
926 MUST be honored, even if DNS results are cached; if the TTL has
927 not expired, an entity that seeks to reconnect MUST NOT re-resolve
928 the server hostname before reconnecting.
929 o The time that expires before an entity first seeks to reconnect
930 MUST be randomized (e.g., so that all clients do not attempt to
931 reconnect exactly 30 seconds after being disconnected).
932 o If the first reconnection attempt does not succeed, an entity MUST
933 back off increasingly on the time between subsequent reconnection
934 attempts.
936 Note: Because it is possible that a disconnected entity cannot
937 determine the cause of disconnection (e.g., because there was no
938 explicit stream error) or does not require a new stream for
939 immediate communication (e.g., because the stream was idle and
940 therefore timed out), it SHOULD NOT assume that is needs to
941 reconnect immediately.
943 4.6. Other Bindings
945 There is no necessary coupling of an XML stream to a TCP connection.
946 For example, two entities could connect to each other via another
947 transport, such as [HTTP] as specified in [XEP-0124] and [XEP-0206].
948 Although this specification neither encourages nor discourages other
949 bindings, it defines only a binding of XMPP to TCP.
951 5. XML Streams
953 5.1. Overview
955 Two fundamental concepts make possible the rapid, asynchronous
956 exchange of relatively small payloads of structured information
957 between presence-aware entities: XML streams and XML stanzas. These
958 terms are defined as follows.
960 Definition of XML Stream: An XML STREAM is a container for the
961 exchange of XML elements between any two entities over a network.
962 The start of an XML stream is denoted unambiguously by an opening
963 STREAM HEADER (i.e., an XML tag with appropriate
964 attributes and namespace declarations), while the end of the XML
965 stream is denoted unambiguously by a closing XML tag.
966 During the life of the stream, the entity that initiated it can
967 send an unbounded number of XML elements over the stream, either
968 elements used to negotiate the stream (e.g., to complete TLS
969 negotiation (Section 6) or SASL negotiation (Section 7)) or XML
970 stanzas. The INITIAL STREAM is negotiated from the initiating
971 entity (typically a client or server) to the receiving entity
972 (typically a server), and can be seen as corresponding to the
973 initiating entity's "connection" or "session" with the receiving
974 entity. The initial stream enables unidirectional communication
975 from the initiating entity to the receiving entity; in order to
976 enable information exchange from the receiving entity to the
977 initiating entity, the receiving entity MUST negotiate a stream in
978 the opposite direction (the RESPONSE STREAM).
979 Definition of XML Stanza: An XML STANZA is a discrete semantic unit
980 of structured information that is sent from one entity to another
981 over an XML stream, and is the basic unit of meaning in XMPP. An
982 XML stanza exists at the direct child level of the root ), and the end of any XML stanza is denoted
986 unambiguously by the corresponding close tag at depth=1 (e.g.,
987 ). The only XML stanzas defined herein are the
988 |
1018 |--------------------|
1019 | |
1020 | |
1022 |--------------------|
1023 | |
1024 | |
1025 | |
1026 |--------------------|
1027 | |
1028 | |
1030 |--------------------|
1031 | |
1032 | |
1034 |--------------------|
1035 | [ ... ] |
1036 |--------------------|
1037 | |
1038 +--------------------+
1040 Note: Those who are accustomed to thinking of XML in a document-
1041 centric manner might view a client's connection to a server as
1042 consisting of two open-ended XML documents: one from the client to
1043 the server and one from the server to the client. On this
1044 analogy, the two XML streams can be considered equivalent to two
1045 "documents" (matching production [1] content of [XML]) that are
1046 built up through the accumulation of XML stanzas, the root
1047 ), then it
1102 MUST include the 'from' attribute and MUST set its value to that
1103 identity. If the client does not know the XMPP identity of the
1104 principal controlling the client, then it MUST NOT include the 'from'
1105 attribute.
1107 I:
1108
1116 For initial stream headers in server-to-server communication, a
1117 server MUST include the 'from' attribute and MUST set its value to a
1118 hostname serviced by the initiating entity.
1120 I:
1121
1129 For response stream headers in both client-to-server and server-to-
1130 server communication, the receiving entity MUST include the 'from'
1131 attribute and MUST set its value to a hostname serviced by the
1132 receiving entity (which MAY be a hostname other than that specified
1133 in the 'to' attribute of the initial stream header).
1135 R:
1136
1145 Whether or not the 'from' attribute is included, each entity MUST
1146 verify the identity of the other entity before exchanging XML stanzas
1147 with it (see Section 15.3 and Section 15.4).
1149 Note: It is possible that implementations based on an earlier
1150 revision of this specification will not include the 'from' address
1151 on stream headers; an entity SHOULD be liberal in accepting such
1152 stream headers.
1154 5.3.2. to
1156 For initial stream headers in both client-to-server and server-to-
1157 server communication, the initiating entity MUST include the 'to'
1158 attribute and MUST set its value to a hostname that the initiating
1159 entity knows or expects the receiving entity to service.
1161 I:
1162
1170 For response stream headers in client-to-server communication, if the
1171 client included a 'from' attribute in the initial stream header then
1172 the server MUST include a 'to' attribute in the response stream
1173 header and MUST set its value to the bare JID specified in the 'from'
1174 attribute of the initial stream header. If the client did not
1175 include a 'from' attribute in the initial stream header then the
1176 server MUST NOT include a 'to' attribute in the response stream
1177 header.
1179 R:
1180
1189 For response stream headers in server-to-server communication, the
1190 receiving entity MUST include a 'to' attribute in the response stream
1191 header and MUST set its value to the hostname specified in the 'from'
1192 attribute of the initial stream header.
1194 R:
1195
1204 Whether or not the 'to' attribute is included, each entity MUST
1205 verify the identity of the other entity before exchanging XML stanzas
1206 with it (see Section 15.3 and Section 15.4).
1208 Note: It is possible that implementations based on an earlier
1209 revision of this specification will not include the 'from' address
1210 on stream headers; an entity SHOULD be liberal in accepting such
1211 stream headers.
1213 5.3.3. id
1215 The 'id' attribute communicates a unique identifier for the stream.
1216 This identifier is called a STREAM ID. The stream ID MUST be
1217 generated by the receiving entity when it sends a response stream
1218 header, MUST BE unique within the receiving application (normally a
1219 server), and MUST be both unpredictable and nonrepeating because it
1220 can be security-critical (see [RANDOM] for recommendations regarding
1221 randomness for security purposes).
1223 For initial stream headers, the initiating entity MUST NOT include
1224 the 'id' attribute; however, if the 'id' attribute is included, the
1225 receiving entity MUST silently ignore it.
1227 For response stream headers, the receiving entity MUST include the
1228 'id' attribute.
1230 R:
1231
1240 5.3.4. xml:lang
1242 The 'xml:lang' attribute communicates an entity's preferred or
1243 default language for any human-readable XML character data to be sent
1244 over the stream. The syntax of this attribute is defined in Section
1245 2.12 of [XML]; in particular, the value of the 'xml:lang' attribute
1246 MUST conform to the NMTOKEN datatype (as defined in Section 2.3 of
1247 [XML]) and MUST conform to the language identifier format defined in
1248 [LANGTAGS].
1250 For initial stream headers, the initiating entity SHOULD include the
1251 'xml:lang' attribute.
1253 I:
1254
1262 For response stream headers, the receiving entity MUST include the
1263 'xml:lang' attribute. If the initiating entity included an 'xml:
1264 lang' attribute in its initial stream header and the receiving entity
1265 supports that language in the human-readable XML character data that
1266 it generates and sends to the initiating entity (e.g., in the
1290 If the initiating entity included the 'xml:lang' attribute in its
1291 initial stream header, the receiving entity SHOULD remember that
1292 value as the default xml:lang for all stanzas sent by the initiating
1293 entity. As described under Section 9.1.5, the initiating entity MAY
1294 include the 'xml:lang' attribute in any XML stanzas it sends over the
1295 stream. If the initiating entity does not include the 'xml:lang'
1296 attribute in any such stanza, the receiving entity SHOULD add the
1297 'xml:lang' attribute to the stanza, whose value MUST be the
1298 identifier for the language preferred by the initiating entity (even
1299 if the receiving entity does not support that language for human-
1300 readable XML character data it generates and sends to the initiating
1301 entity, such as in stream or stanza errors). If the initiating
1302 entity includes the 'xml:lang' attribute in any such stanza, the
1303 receiving entity MUST NOT modify or delete it.
1305 5.3.5. version
1307 The inclusion of the version attribute set to a value of at least
1308 "1.0" signals support for the stream-related protocols defined in
1309 this specification, including (TLS negotiation (Section 6), SASL
1310 negotiation (Section 7), Section 5.5, and stream errors
1311 (Section 5.8).
1313 The version of XMPP specified herein is "1.0"; in particular, XMPP
1314 1.0 encapsulates the stream-related protocols as well as the basic
1315 semantics of the three defined XML stanza types (.". The
1319 major and minor numbers MUST be treated as separate integers and each
1320 number MAY be incremented higher than a single digit. Thus, "XMPP
1321 2.4" would be a lower version than "XMPP 2.13", which in turn would
1322 be lower than "XMPP 12.3". Leading zeros (e.g., "XMPP 6.01") MUST be
1323 ignored by recipients and MUST NOT be sent.
1325 The major version number will be incremented only if the stream and
1326 stanza formats or required actions have changed so dramatically that
1327 an older version entity would not be able to interoperate with a
1328 newer version entity if it simply ignored the elements and attributes
1329 it did not understand and took the actions specified in the older
1330 specification.
1332 The minor version number will be incremented only if significant new
1333 capabilities have been added to the core protocol (e.g., a newly
1334 defined value of the 'type' attribute for message, presence, or IQ
1335 stanzas). The minor version number MUST be ignored by an entity with
1336 a smaller minor version number, but MAY be used for informational
1337 purposes by the entity with the larger minor version number (e.g.,
1338 the entity with the larger minor version number would simply note
1339 that its correspondent would not be able to understand that value of
1340 the 'type' attribute and therefore would not send it).
1342 The following rules apply to the generation and handling of the
1343 'version' attribute within stream headers:
1345 1. The initiating entity MUST set the value of the 'version'
1346 attribute in the initial stream header to the highest version
1347 number it supports (e.g., if the highest version number it
1348 supports is that defined in this specification, it MUST set the
1349 value to "1.0").
1350 2. The receiving entity MUST set the value of the 'version'
1351 attribute in the response stream header to either the value
1352 supplied by the initiating entity or the highest version number
1353 supported by the receiving entity, whichever is lower. The
1354 receiving entity MUST perform a numeric comparison on the major
1355 and minor version numbers, not a string match on
1356 ".".
1357 3. If the version number included in the response stream header is
1358 at least one major version lower than the version number included
1359 in the initial stream header and newer version entities cannot
1360 interoperate with older version entities as described, the
1361 initiating entity SHOULD generate an
1409 R:
1410
1411
1413
1415 Stream features are used mainly to advertise TLS negotiation
1416 (Section 6), SASL negotiation (Section 7), and resource binding
1417 (Section 8); however, stream features also can be used to advertise
1418 features associated with various XMPP extensions.
1420 If it is mandatory for a feature to be successfully negotiated before
1421 the initiating entity will be allowed to proceed with the sending of
1422 XML stanzas or with further steps of the stream negotiation, the
1423 advertisement of that feature SHOULD include an empty
1428
1429
1431
1433 If successful negotiation of a feature is discretionary, the
1434 advertisement of that feature MUST include an empty
1438
1439
1441
1443 If an entity does not understand or support a feature that has been
1444 advertised, it MUST still inspect the feature advertisement to
1445 determine if negotiation of the feature is mandatory. If negotiation
1446 of an unsupported feature is mandatory (as determined by inclusion of
1447 the
1491 R:
1522 After an entity sends a closing stream tag, it MUST NOT send further
1523 data over that stream.
1525 5.7.1. With Stream Error
1527 If a stream error has occurred, the entity that detects the error
1528 MUST close the stream as described under Section 5.8.1.
1530 5.7.2. Without Stream Error
1532 At any time after XML streams have been negotiated between two
1533 entities, either entity MAY close its stream to the other party in
1534 the absence of a stream error by sending a closing stream tag.
1536 P:
1538 The entity that sends the closing stream tag SHOULD wait for the
1539 other party to also close its stream.
1541 S:
1543 However, the entity that sends the first closing stream tag MAY
1544 consider both streams to be void if the other party does not send its
1545 closing stream tag within a reasonable amount of time (where the
1546 definition of "reasonable" is a matter of implementation or
1547 deployment).
1549 After the entity that sent the first closing stream tag receives a
1550 reciprocal closing stream tag from the other party (or if it
1551 considers the stream to be void after a reasonable amount of time),
1552 it MUST terminate the underlying TCP connection or connections.
1554 5.7.3. Handling of Idle Streams
1556 An XML stream can become idle, i.e., neither entity has sent XMPP
1557 traffic over the stream for some period of time. A server MAY close
1558 an idle stream with a local client or remote server, preferably
1559 through use of the
1605
1608
1610 The entity that generates the stream error then SHOULD immediately
1611 terminate the underlying TCP connection, although it MAY wait until
1612 after it receives a closing tag from the entity to which it
1613 sent the stream error.
1615 C:
1617 5.8.1.2. Stream Errors Can Occur During Setup
1619 If the error is triggered by the initial stream header, the receiving
1620 entity MUST still send the opening tag, include the tag (preferably all at the same time).
1624 C:
1625
1633 S:
1634
1643
1648 5.8.1.3. Stream Errors When the Host is Unspecified or Unknown
1650 If the initiating entity provides no 'to' attribute or provides an
1651 unknown host in the 'to' attribute and the error occurs during stream
1652 setup, the receiving entity MUST provide an authoritative hostname in
1653 the 'from' attribute of the stream header sent before termination.
1655 C:
1656
1664 S:
1665
1673
1674
1677
1679 5.8.2. Syntax
1681 The syntax for stream errors is as follows, where "defined-condition"
1682 is a placeholder for one of the conditions defined under
1683 Section 5.8.3.
1685
1686
1689 [ ... descriptive text ... ]
1690 ]
1691 [application-specific condition element]
1692
1694 The
1730 No closing body tag!
1731
1733 S:
1734
1737
1739 This error MAY be used instead of the more specific XML-related
1740 errors, such as
1761 S:
1762
1770
1771
1774
1776 5.8.3.3. conflict
1778 The server is either (1) closing the existing stream for this entity
1779 because a new stream has been initiated that conflicts with the
1780 existing stream, or (2) is refusing a new stream for this entity
1781 because allowing the new stream would conflict with an existing
1782 stream (e.g., because the server allows only a certain number of
1783 connections from the same IP address).
1785 C:
1786
1793 S:
1794
1802
1803
1806
1808 5.8.3.4. connection-timeout
1810 The entity has not generated any traffic over the stream for some
1811 period of time (configurable according to a local service policy) and
1812 therefore the connection is being dropped.
1814 P:
1815
1818
1820 5.8.3.5. host-gone
1822 The value of the 'to' attribute provided in the initial stream header
1823 corresponds to a hostname that is no longer serviced by the receiving
1824 entity.
1826 (In the following example, the peer specifies a 'to' address of
1827 "foo.im.example.com" when connecting to the "im.example.com" server,
1828 but the server no longer hosts a service at that address.)
1829 P:
1830
1837 S:
1838
1846
1847
1850
1852 5.8.3.6. host-unknown
1854 The value of the 'to' attribute provided in the initial stream header
1855 does not correspond to a hostname that is serviced by the receiving
1856 entity.
1858 (In the following example, the peer specifies a 'to' address of
1859 "example.org" when connecting to the "im.example.com" server, but the
1860 server knows nothing of that address.)
1861 P:
1862
1869 S:
1870
1878
1879
1882
1884 5.8.3.7. improper-addressing
1886 A stanza sent between two servers lacks a 'to' or 'from' attribute,
1887 the 'from' or 'to' attribute has no value, or the value is not a
1888 valid XMPP address.
1890 (In the following example, the peer sends a stanza without a 'to'
1891 address.)
1893 P:
1894 Wherefore art thou?
1895
1897 S:
1898
1901
1903 5.8.3.8. internal-server-error
1905 The server has experienced a misconfiguration or an otherwise-
1906 undefined internal error that prevents it from servicing the stream.
1908 S:
1909
1912
1914 5.8.3.9. invalid-from
1916 The JID or hostname provided in a 'from' address is not a valid JID
1917 or does not match an authorized JID or validated domain as negotiated
1918 between servers via SASL or server dialback, or as negotiated between
1919 a client and a server via authentication and resource binding.
1921 (In the following example, a peer that has authenticated only as
1922 "example.net" attempts to send a stanza from an address at
1923 "example.org".)
1925 P:
1926 Neither, fair saint, if either thee dislike.
1927
1929 S:
1930
1933
1935 5.8.3.10. invalid-id
1937 The stream ID or server dialback ID is invalid or does not match an
1938 ID previously provided.
1940 (In the following example, the server dialback ID is invalid; see
1941 [XEP-0220].)
1943 P:
1950
1953
1955 5.8.3.11. invalid-namespace
1957 The streams namespace name is something other than
1958 "http://etherx.jabber.org/streams" (see Section 12.2) or the default
1959 namespace is not supported (e.g., something other than "jabber:
1960 client" or "jabber:server").
1962 (In the following example, the client specifies a streams namespace
1963 of 'http://wrong.namespace.example.org/'.)
1965 C:
1966
1973 S:
1974
1982
1983
1986
1988 5.8.3.12. invalid-xml
1990 The entity has sent invalid XML over the stream to a server that
1991 performs validation (see Section 12.4).
1993 (In the following example, the peer attempts to send an IQ stanza of
1994 type "subscribe" but the XML schema defines no such value for the
1995 'type' attribute.)
1996 P:
2000
2003 S:
2004
2007
2009 5.8.3.13. not-authorized
2011 The entity has attempted to send XML stanzas before the stream has
2012 been authenticated, or otherwise is not authorized to perform an
2013 action related to stream negotiation; the receiving entity MUST NOT
2014 process the offending stanza before sending the stream error.
2016 (In the following example, the client attempts to send XML stanzas
2017 before authenticating with the server.)
2018 C:
2019
2026 S:
2027
2037 Wherefore art thou?
2038
2040 S:
2041
2044
2046 5.8.3.14. policy-violation
2048 The entity has violated some local service policy (e.g., the stanza
2049 exceeds a configured size limit); the server MAY choose to specify
2050 the policy in the
2057 [ ... the-emacs-manual ... ]
2058
2060 S:
2061
2065 S:
2067 5.8.3.15. remote-connection-failed
2069 The server is unable to properly connect to a remote entity that is
2070 required for authentication or authorization, such as a remote
2071 authentication database or (in server dialback) the authoritative
2072 server.
2074 C:
2075
2082 S:
2083
2091
2092
2095
2097 5.8.3.16. resource-constraint
2099 The server lacks the system resources necessary to service the
2100 stream.
2102 C:
2103
2110 S:
2111
2119
2120
2123
2125 5.8.3.17. restricted-xml
2127 The entity has attempted to send restricted XML features such as a
2128 comment, processing instruction, DTD subset, or XML entity reference
2129 (see Section 12.1).
2131 (In the following example, the client sends an XMPP message
2132 containing an XML comment.)
2134 C:
2135
2136 This message has no subject.
2137
2139 S:
2140
2143
2145 5.8.3.18. see-other-host
2147 The server will not provide service to the initiating entity but is
2148 redirecting traffic to another host; the XML character data of the
2149
2166 S:
2167
2175
2176
2178 im.example.com:9090
2179
2180
2181
2183 5.8.3.19. system-shutdown
2185 The server is being shut down and all active streams are being
2186 closed.
2188 S:
2189
2192
2194 5.8.3.20. undefined-condition
2196 The error condition is not one of those defined by the other
2197 conditions in this list; this error condition SHOULD be used only in
2198 conjunction with an application-specific condition.
2200 S:
2201
2205
2207 5.8.3.21. unsupported-encoding
2209 The initiating entity has encoded the stream in an encoding that is
2210 not supported by the server (see Section 12.6) or has otherwise
2211 improperly encoded the stream (e.g., by violating the rules of the
2212 UTF-8 encoding).
2214 (In the following example, the client attempts to encode data using
2215 UTF-16 instead of UTF-8.)
2217 C:
2218
2225 S:
2226
2235
2240 5.8.3.22. unsupported-stanza-type
2242 The initiating entity has sent a first-level child of the stream that
2243 is not supported by the server or consistent with the default
2244 namespace.
2246 (In the following example, the client attempts to send an XML stanza
2247 of
2250
2251 -
2252
2253 Soliloquy
2254
2255 To be, or not to be: that is the question:
2256 Whether 'tis nobler in the mind to suffer
2257 The slings and arrows of outrageous fortune,
2258 Or to take arms against a sea of troubles,
2259 And by opposing end them?
2260
2261
2263 tag:denmark.example,2003:entry-32397
2264 2003-12-13T18:30:02Z
2265 2003-12-13T18:30:02Z
2266
2267
2268
2269
2271 S:
2272
2275
2277 5.8.3.23. unsupported-version
2279 The value of the 'version' attribute provided by the initiating
2280 entity in the stream header specifies a version of XMPP that is not
2281 supported by the server; the server MAY specify the version(s) it
2282 supports in the
2294 S:
2295
2304
2307 1.0, 1.1
2308
2309
2310
2312 5.8.3.24. xml-not-well-formed
2314 The initiating entity has sent XML that violates the well-formedness
2315 rules of [XML] or [XML-NAMES].
2317 (In the following example, the client sends an XMPP message that is
2318 not well-formed XML.)
2320 C:
2321 No closing body tag!
2322
2324 S:
2325
2328
2330 5.8.4. Application-Specific Conditions
2332 As noted, an application MAY provide application-specific stream
2333 error information by including a properly-namespaced child in the
2334 error element. The application-specific element SHOULD supplement or
2335 further qualify a defined element. Thus the
2339
2340 My keyboard layout is:
2342 QWERTYUIOP{}|
2343 ASDFGHJKL:"
2344 ZXCVBNM<>?
2345
2346
2348 S:
2349
2352 Some special application diagnostic information!
2353
2354
2356
2358 5.9. Simplified Stream Examples
2360 This section contains two simplified examples of a stream-based
2361 connection between a client and a server; these examples are included
2362 for the purpose of illustrating the concepts introduced thus far.
2364 A basic connection:
2366 C:
2367
2376
2385 [ ... channel encryption ... ]
2387 [ ... authentication ... ]
2389 [ ... resource binding ... ]
2391 C:
2394 Art thou not Romeo, and a Montague?
2395
2397 S:
2400 Neither, fair saint, if either thee dislike.
2401
2403 C:
2405 S:
2406 A connection gone bad:
2408 C:
2409
2417 S:
2418
2427 [ ... channel encryption ... ]
2429 [ ... authentication ... ]
2431 [ ... resource binding ... ]
2433 C:
2436 No closing body tag!
2437
2439 S:
2440
2443
2445 More detailed examples are provided under Section 10.
2447 6. STARTTLS Negotiation
2448 6.1. Overview
2450 XMPP includes a method for securing the stream from tampering and
2451 eavesdropping. This channel encryption method makes use of the
2452 Transport Layer Security [TLS] protocol, specifically a "STARTTLS"
2453 extension that is modelled after similar extensions for the [IMAP],
2454 [POP3], and [ACAP] protocols as described in [USINGTLS]. The XML
2455 namespace name for the STARTTLS extension is
2456 'urn:ietf:params:xml:ns:xmpp-tls'.
2458 Support for STARTTLS is REQUIRED in XMPP client and server
2459 implementations. An administrator of a given deployment MAY require
2460 the use of TLS for client-to-server communication, server-to-server
2461 communication, or both. A deployed client SHOULD use TLS to secure
2462 its stream with a server prior to attempting the completion of SASL
2463 negotiation (Section 7), and deployed servers SHOULD use TLS between
2464 two domains for the purpose of securing server-to-server
2465 communication.
2467 6.2. Rules
2469 6.2.1. Data Formatting
2471 During STARTTLS negotiation, the entities MUST NOT send any
2472 whitespace within the root stream element as separators between XML
2473 elements (i.e., from the last character of the
2513 The receiving entity MUST send a response stream header to the
2514 initiating entity over the TCP connection opened by the initiating
2515 entity; if the receiving entity is capable of STARTTLS negotiation,
2516 it MUST include the 'version' attribute set to a value of at least
2517 "1.0" in the response stream header.
2519 R:
2539
2540
2542
2544 If the receiving entity considers STARTTLS negotiation to be
2545 mandatory, the
2549
2550
2552
2554 6.3.2. Initiation of STARTTLS Negotiation
2556 6.3.2.1. STARTTLS Command
2558 In order to begin the STARTTLS negotiation, the initiating entity
2559 issues the STARTTLS command (i.e., a
2581 Causes for the failure case include but are not limited to:
2583 1. The initiating entity has sent a malformed STARTTLS command.
2585 2. The receiving entity does not offer STARTTLS negotiation either
2586 temporarily or permanently.
2587 3. The receiving entity cannot complete STARTTLS negotiation because
2588 of an internal error.
2590 Note: STARTTLS failure is not triggered by TLS errors such as bad
2591 certificate or unknown certificate authority; those errors are
2592 generated and handled during the TLS negotiation itself as
2593 described in [TLS].
2595 If the failure case occurs, the initiating entity MAY attempt to
2596 reconnect as explained under Section 4.5.
2598 6.3.2.3. Proceed Case
2600 If the proceed case occurs, the receiving entity MUST return a
2601
2671 Note: The initiating entity MUST NOT send a closing tag
2672 before sending the new initial stream header, since the receiving
2673 entity and initiating entity MUST consider the original stream to
2674 be replaced upon success of the TLS negotiation.
2675 4. The receiving entity MUST respond with a new response stream
2676 header over the encrypted connection.
2678 R:
2693
2694 EXTERNAL
2695 PLAIN
2696
2698
2700 7. SASL Negotiation
2702 7.1. Overview
2704 XMPP includes a method for authenticating a stream by means of an
2705 XMPP-specific profile of the Simple Authentication and Security Layer
2706 protocol (see [SASL]). SASL provides a generalized method for adding
2707 authentication support to connection-based protocols, and XMPP uses
2708 an XML namespace profile of SASL that conforms to the profiling
2709 requirements of [SASL].
2711 Support for SASL negotiation is REQUIRED in XMPP client and server
2712 implementations.
2714 7.2. Rules
2716 7.2.1. Mechanism Preferences
2718 Any entity that will act as a SASL client or a SASL server MUST
2719 maintain an ordered list of its preferred SASL mechanisms according
2720 to the client or server, where the list is ordered by the perceived
2721 strength of the mechanisms. A server MUST offer and a client MUST
2722 try SASL mechanisms in the order of their perceived strength. For
2723 example, if the server offers the ordered list "PLAIN DIGEST-MD5
2724 GSSAPI" or "DIGEST-MD5 GSSAPI PLAIN" but the client's ordered list is
2725 "GSSAPI DIGEST-MD5", the client shall try GSSAPI first and then
2726 DIGEST-MD5 but shall never try PLAIN (since PLAIN is not on its
2727 list).
2729 7.2.2. Mechanism Offers
2731 If the receiving entity considers TLS negotiation (Section 6) to be
2732 mandatory before use of a particular SASL authentication mechanism
2733 will be acceptable, the receiving entity MUST NOT advertise that
2734 mechanism in its list of available SASL authentication mechanisms
2735 prior to successful TLS negotiation.
2737 If during prior TLS negotiation the initiating entity presented a
2738 certificate that is acceptable to the receiving entity for purposes
2739 of strong identity verification in accordance with local service
2740 policies, the receiving entity MUST offer the SASL EXTERNAL mechanism
2741 to the initiating entity during SASL negotiation (refer to [SASL])
2742 and SHOULD prefer that mechanism. However, the EXTERNAL mechanism
2743 MAY be offered under other circumstances as well.
2745 See Section 15.7 regarding mechanisms that MUST be supported;
2746 naturally, other SASL mechanisms MAY be supported as well. Best
2747 practices for the use of several SASL mechanisms in the context of
2748 XMPP are described in [XEP-0175] and [XEP-0178].
2750 7.2.3. Data Formatting
2752 The following data formattting rules apply to the SASL negotiation:
2754 1. During SASL negotiation, the entities MUST NOT send any
2755 whitespace within the root stream element as separators between
2756 XML elements (i.e., from the last character of the but
2796 only the node portion of the JID). The simple username MUST
2797 adhere to the Nodeprep (Appendix A) profile of [STRINGPREP].
2798 Server-to-server communication: The initiating entity's sending
2799 domain, i.e., IP address or fully qualified domain name as
2800 contained in an XMPP domain identifier. The simple username MUST
2801 adhere to the [NAMEPREP] profile of [STRINGPREP].
2803 7.2.6. Authorization Identities
2805 If the initiating entity wishes to act on behalf of another entity
2806 and the selected SASL mechanism supports transmission of an
2807 authorization identity, the initiating entity MUST provide an
2808 authorization identity during SASL negotiation. If the initiating
2809 entity does not wish to act on behalf of another entity, it MUST NOT
2810 provide an authorization identity. As specified in [SASL], the
2811 initiating entity MUST NOT provide an authorization identity unless
2812 the authorization identity is different from the default
2813 authorization identity derived from the authentication identity. If
2814 provided, the value of the authorization identity MUST be a bare JID
2815 of the form (i.e., an XMPP domain identifier only) for
2816 servers and a bare JID of the form (i.e., node
2817 identifier and domain identifier) for clients.
2819 Note: The authorization identity communited during SASL
2820 negotiation is used to determine the canonical address for the
2821 initiating client or server according to the receiving server, as
2822 described under Section 3.5.
2824 7.2.7. Round Trips
2826 [SASL] specifies that a using protocol such as XMPP can define two
2827 methods by which the protocol can save round trips where allowed for
2828 the SASL mechanism:
2830 1. When the SASL client (the XMPP "initiating entity") requests an
2831 authentication exchange, it can include "initial response" data
2832 with its request if appropriate for the SASL mechanism in use.
2833 In XMPP this is done by including the initial response as the XML
2834 character data of the
2869 The receiving entity MUST send a response stream header to the
2870 initiating entity; if the receiving entity is capable of SASL
2871 negotiation, it MUST include the 'version' attribute set to a value
2872 of at least "1.0" in the response stream header.
2874 R:
2898
2899 EXTERNAL
2900 PLAIN
2901
2903
2905 If the receiving entity considers SASL negotiation to be
2906 discretionary, the
2910
2911 EXTERNAL
2912 PLAIN
2913
2916
2918 If the receiving entity considers SASL negotiation to be mandatory,
2919 the
2923
2924 EXTERNAL
2925 PLAIN
2926
2928
2930 7.3.2. Initiation
2932 In order to begin the SASL negotiation, the initiating entity sends
2933 an UjBtMzBSMGNrcw==
2945 7.3.3. Challenge-Response Sequence
2947 If necessary, the receiving entity challenges the initiating entity
2948 by sending a
2999
3002 Where appropriate for the chosen SASL mechanism, the receiving entity
3003 SHOULD allow a configurable but reasonable number of retries (at
3004 least 2 and no more than 5); this enables the initiating entity
3005 (e.g., an end-user client) to tolerate incorrectly-provided
3006 credentials (e.g., a mistyped password) without being forced to
3007 reconnect.
3009 If the initiating entity attempts a reasonable number of retries with
3010 the same SASL mechanism and all attempts fail, it MAY fall back to
3011 the next mechanism in its ordered list by sending a new tag
3050 before sending the new initial stream header, since the receiving
3051 entity and initiating entity MUST consider the original stream to
3052 be replaced upon sending or receiving the
3067 The receiving entity MUST also send stream features, containing any
3068 further available features or containing no features (via an empty
3069
3072
3073
3075
3077 7.4. SASL Errors
3079 The syntax of SASL errors is as follows:
3081
3082
3084 OPTIONAL descriptive text
3085 ]
3086
3088 Where "defined-condition" is one of the SASL-related error conditions
3089 defined in the following sections.
3091 Inclusion of a defined condition is REQUIRED.
3093 Inclusion of the
3106
3109 7.4.2. account-disabled
3111 The account of the initiating entity has been temporarily disabled;
3112 sent in reply to an UjBtMzBSMGNrcw==
3118 R:
3119 Call 212-555-1212 for assistance.
3121
3123 7.4.3. credentials-expired
3125 The authentication failed because the initiating entity provided
3126 credentials that have expired; sent in reply to a
3130 [ ... ]
3131
3133 R:
3134
3137 7.4.4. encryption-required
3139 The mechanism requested by the initiating entity cannot be used
3140 unless the underlying stream is encrypted; sent in reply to an
3141 UjBtMzBSMGNrcw==
3146 R:
3147
3150 7.4.5. incorrect-encoding
3152 The data provided by the initiating entity could not be processed
3153 because the [BASE64] encoding is incorrect (e.g., because the
3154 encoding does not adhere to the definition in Section 4 of [BASE64]);
3155 sent in reply to a [ ... ]
3161 R:
3162
3165 7.4.6. invalid-authzid
3167 The authzid provided by the initiating entity is invalid, either
3168 because it is incorrectly formatted or because the initiating entity
3169 does not have permissions to authorize that ID; sent in reply to a
3170
3173 [ ... ]
3174
3176 R:
3177
3180 7.4.7. invalid-mechanism
3182 The initiating entity did not provide a mechanism or requested a
3183 mechanism that is not supported by the receiving entity; sent in
3184 reply to an
3190
3193 7.4.8. malformed-request
3195 The request is malformed (e.g., the [ ... some-long-token ... ]
3208 R:
3209
3212 7.4.9. mechanism-too-weak
3214 The mechanism requested by the initiating entity is weaker than
3215 server policy permits for that initiating entity; sent in reply to an
3216 UjBtMzBSMGNrcw==
3221 R:
3222
3225 7.4.10. not-authorized
3227 The authentication failed because the initiating entity did not
3228 provide proper credentials; sent in reply to a
3232 [ ... ]
3233
3235 R:
3236
3239 Note: This error condition includes but is not limited to the case
3240 of incorrect credentials or an unknown username. In order to
3241 discourage directory harvest attacks, no differentiation is made
3242 between incorrect credentials and an unknown username.
3244 7.4.11. temporary-auth-failure
3246 The authentication failed because of a temporary error condition
3247 within the receiving entity, and it is advisable for the initiating
3248 entity to try again later; sent in reply to an
3252 [ ... ]
3253
3255 R:
3256
3259 7.4.12. transition-needed
3261 The authentication failed because the mechanism cannot be used until
3262 the initiating entity provides (for one time only) a plaintext
3263 password so that the receiving entity can build a hashed password for
3264 use in future authentication attempts; sent in reply to an [ ... ]
3270 R:
3271
3274 Note: An XMPP client MUST treat a of a client
3310 or the sending of a server; an empty string is equivalent
3311 to an absent authorization identity.
3313 8. Resource Binding
3315 8.1. Overview
3317 After a client authenticates with a server, it MUST bind a specific
3318 resource to the stream so that the server can properly address the
3319 client (see Section 3). That is, there MUST be an XMPP resource
3320 identifier associated with the bare JID () of the
3321 client, so that the address for use over that stream is a full JID of
3322 the form . This ensures that the server can
3323 deliver XML stanzas to and receive XML stanzas from the client (see
3324 Section 11).
3326 After a client has bound a resource to the stream, it is referred to
3327 as a CONNECTED RESOURCE. A server SHOULD allow an entity to maintain
3328 multiple connected resources simultaneously, where each connected
3329 resource is differentiated by a distinct resource identifier;
3330 however, a server MUST enable the administrator of an XMPP service to
3331 limit the number of connected resources in order to prevent certain
3332 denial of service attacks as described under Section 15.12.
3334 If, before completing the resource binding step, the client attempts
3335 to send an outbound XML stanza (i.e., a stanza not directed to the
3336 server itself or to the client's own account), the server MUST NOT
3337 process the stanza and MUST either ignore the stanza or return a
3338
3365 S:
3366
3367
3369
3371 Upon being so informed that resource binding is required, the client
3372 MUST bind a resource to the stream as described in the following
3373 sections.
3375 8.3. Generation of Resource Identifiers
3377 A resource identifier MUST at a minimum be unique among the connected
3378 resources for that . Enforcement of this policy is the
3379 responsibility of the server.
3381 A resource identifier can be security-critical. For example, if a
3382 malicious entity can guess a client's resource identifier then it
3383 might be able to determine if the client (and therefore the
3384 controlling principal) is online or offline, thus resulting in a
3385 presence leak as described under Section 15.13. To prevent that
3386 possibility, a client can either (1) generate a random resource
3387 identifier on its own or (2) ask the server to generate a resource
3388 identifier on its behalf, which MUST be random (see [RANDOM]). When
3389 generating a random resource identifier, it is RECOMMENDED that the
3390 resource identifier be a Universally Unique Identifier (UUID), for
3391 which the format specified in [UUID] is RECOMMENDED.
3393 8.4. Server-Generated Resource Identifier
3395 A server that supports resource binding MUST be able to generate an
3396 XMPP resource identifier on behalf of a client.
3398 8.4.1. Success Case
3400 A client requests a server-generated resource identifier by sending
3401 an IQ stanza of type "set" (see Section 9.2.3) containing an empty
3402
3406
3409 Once the server has generated an XMPP resource identifier for the
3410 client, it MUST return an IQ stanza of type "result" to the client,
3411 which MUST include a
3415
3416
3417 juliet@im.example.com/4db06f06-1ea4-11dc-aca3-000bcd821bfb
3418
3419
3420
3422 8.4.2. Error Cases
3424 When a client asks the server to generate a resource identifer during
3425 resource binding, the following stanza error conditions are possible:
3427 o The account has reached a limit on the number of simultaneous
3428 connected resources allowed.
3429 o The client is otherwise not allowed to bind a resource to the
3430 stream.
3432 8.4.2.1. Resource Constraint
3434 If the account has reached a limit on the number of simultaneous
3435 connected resources allowed, the server MUST return a
3439
3440
3443
3445 8.4.2.2. Not Allowed
3447 If the client is otherwise not allowed to bind a resource to the
3448 stream, the server MUST return a
3451
3452
3455
3457 8.5. Client-Submitted Resource Identifier
3459 Instead of asking the server to generate a resource identifier on its
3460 behalf, a client MAY attempt to submit a resource identifier that it
3461 has generated or that the controlling user has provided.
3463 8.5.1. Success Case
3465 A client asks its server to accept a client-submitted resource
3466 identifier by sending an IQ stanza of type "set" containing a
3471
3472 balcony
3473
3474
3476 The server SHOULD accept the client-submitted resource identifier.
3477 It does so by returning an IQ stanza of type "result" to the client,
3478 including a
3483
3484 juliet@im.example.com/balcony
3485
3486
3488 8.5.2. Error Cases
3490 When a client attempts to submit its own XMPP resource identifier
3491 during resource binding, the following stanza error conditions are
3492 possible in addition to those described under Section 8.4.2:
3494 o The provided resource identifier cannot be processed by the
3495 server, e.g. because it is not in accordance with the Resourceprep
3496 (Appendix B) profile of [STRINGPREP]).
3497 o The provided resource identifier is already in use.
3499 8.5.2.1. Bad Request
3501 If the provided resource identifier cannot be processed by the
3502 server, the server MAY return a
3508
3509
3511
3513 8.5.2.2. Conflict
3515 If there is already a connected resource of the same name, the server
3516 MUST do one of the following:
3518 1. Not accept the resource identifier provided by the client but
3519 instead override it with an XMPP resource identifier that the
3520 server generates.
3521 2. Terminate the current resource and allow the newly-requested
3522 resource.
3523 3. Disallow the newly-requested resource and maintain the current
3524 resource.
3526 Which of these the server does is up to the implementation, although
3527 it is RECOMMENDED to implement case #1.
3529 S:
3530
3531
3532 juliet@im.example.com/balcony 4db06f06-1ea4-11dc-aca3-000bcd821bfb
3533
3534
3535
3537 In case #2, the server MUST send a
3550
3551
3553
3555 8.5.3. Retries
3557 If an error occurs when a client submits a resource identifier, the
3558 server SHOULD allow a configurable but reasonable number of retries
3559 (at least 2 and no more than 5); this enables the client to tolerate
3560 incorrectly-provided resource identifiers (e.g., bad data formats or
3561 duplicate text strings) without being forced to reconnect.
3563 After the client has reached the retry limit, the server MUST return
3564 a
3584
3585
3587
3588
3590
3592 If a server supports binding of mulitple resources, it MUST also send
3593 the unbind feature advertisement after resource binding has been
3594 completed.
3596 8.6.2. Binding an Additional Resource
3598 A connected client binds an additional resource by following the
3599 protocol for binding of the original resource, i.e., by sending an IQ
3600 stanza of type "set" containing a
3617
3618 someresource
3619
3620
3622 If no error occurs, the server MUST unbind the resource and no longer
3623 accept stanzas whose 'from' address specifies the full JID associated
3624 with that resource.
3626 S:
3635 8.6.3.2. Error Cases
3637 8.6.3.2.1. Unbind Not Supported
3639 If the server understands the 'urn:ietf:params:xml:ns:xmpp-bind'
3640 namespace but does not understand the
3644
3645
3648
3650 8.6.3.2.2. No Such Resource
3652 If there is no such resource for that stream, the server MUST return
3653 an error of
3656
3657
3659
3661 8.6.4. From Addresses
3663 When a client binds multiple resources to the same stream, proper
3664 management of 'from' addresses is imperative. In particular, a
3665 client MUST specify a 'from' address on every stanza it sends over a
3666 stream to which it has bound multiple resources, where the 'from'
3667 address is the full JID () associated with
3668 the relevant resource. If a client does not specify a 'from' address
3669 on a stanza it sends over a stream to which it has bound multiple
3670 resources, the server MUST return the stanza to the client with an
3671
3674 Wherefore art thou?
3675
3677 S:
3679 Wherefore art thou?
3680
3681
3683
3685 Naturally, the rules regarding validation of asserted 'from'
3686 addresses still apply (see Section 11).
3688 9. XML Stanzas
3690 After a client has connected to a server or two servers have
3691 connected to each other, either party can send XML stanzas over the
3692 negotiated stream. Three kinds of XML stanza are defined for the
3693 'jabber:client' and 'jabber:server' namespaces:
3720 Art thou not Romeo, and a Montague?
3721
3723 For information about server processing of inbound and outbound XML
3724 stanzas based on the nature of the 'to' address, refer to Section 11.
3726 9.1.1.1. Client-to-Server Streams
3728 The following rules apply to inclusion of the 'to' attribute in the
3729 context of XML streams qualified by the 'jabber:client' namespace
3730 (i.e., client-to-server streams).
3732 1. A stanza with a specific intended recipient MUST possess a 'to'
3733 attribute whose value is an XMPP address.
3734 2. A stanza sent from a client to a server for direct processing by
3735 the server on behalf of the client (e.g., presence sent to the
3736 server for broadcasting to other entities) MUST NOT possess a
3737 'to' attribute.
3739 9.1.1.2. Server-to-Server Streams
3741 The following rules apply to inclusion of the 'to' attribute in the
3742 context of XML streams qualified by the 'jabber:server' namespace
3743 (i.e., server-to-server streams).
3745 1. A stanza MUST possess a 'to' attribute whose value is an XMPP
3746 address; if a server receives a stanza that does not meet this
3747 restriction, it MUST generate an
3760 Art thou not Romeo, and a Montague?
3761
3763 9.1.2.1. Client-to-Server Streams
3765 The following rules apply to the 'from' attribute in the context of
3766 XML streams qualified by the 'jabber:client' namespace (i.e., client-
3767 to-server streams).
3769 1. When the server receives an XML stanza from a client and the
3770 stanza does not include a 'from' attribute, the server MUST add a
3771 'from' attribute to the stanza, where the value of the 'from'
3772 attribute is the full JID () determined by
3773 the server for the connected resource that generated the stanza
3774 (see Section 3.5), or the bare JID () in the case of
3775 subscription-related presence stanzas (see [XMPP-IM]); the only
3776 exception to this rule occurs when multiple resources are bound
3777 to the same stream as described under Section 8.6.
3778 2. When the server receives an XML stanza from a client and the
3779 stanza includes a 'from' attribute, the server MUST either (a)
3780 validate that the value of the 'from' attribute provided by the
3781 client is that of a connected resource for the associated entity
3782 or (b) override the provided 'from' attribute by adding a 'from'
3783 attribute as specified under Rule #1.
3784 3. When the server generates a stanza from the server for delivery
3785 to the client on behalf of the account of the connected client
3786 (e.g., in the context of data storage services provided by the
3787 server on behalf of the client), the stanza MUST either (a) not
3788 include a 'from' attribute or (b) include a 'from' attribute
3789 whose value is the account's bare JID ().
3790 4. When the server generates a stanza from the server itself for
3791 delivery to the client, the stanza MUST include a 'from'
3792 attribute whose value is the bare JID (i.e., ) of the
3793 server.
3794 5. A server MUST NOT send to the client a stanza without a 'from'
3795 attribute if the stanza was not generated by the server (e.g., if
3796 it was generated by another client or another server); therefore,
3797 when a client receives a stanza that does not include a 'from'
3798 attribute, it MUST assume that the stanza is from the server to
3799 which the client is connected.
3801 9.1.2.2. Server-to-Server Streams
3803 The following rules apply to the 'from' attribute in the context of
3804 XML streams qualified by the 'jabber:server' namespace (i.e., server-
3805 to-server streams).
3807 1. A stanza MUST possess a 'from' attribute whose value is an XMPP
3808 address; if a server receives a stanza that does not meet this
3809 restriction, it MUST generate an
3854 dnd
3855 Wooing Juliet
3856
3858 The value of the 'xml:lang' attribute MAY be overridden by the 'xml:
3859 lang' attribute of a specific child element.
3861
3862 dnd
3863 Wooing Juliet
3864 Dvořím se Julii
3865
3873 dnd
3874 Wooing Juliet
3875
3877 S:
3880 dnd
3881 Wooing Juliet
3882
3884 If an inbound stanza received received by a client or server does not
3885 possess an 'xml:lang' attribute, an implementation MUST assume that
3886 the default language is that specified for the stream as defined
3887 under Section 5.3.4.
3889 The value of the 'xml:lang' attribute MUST conform to the NMTOKEN
3890 datatype (as defined in Section 2.3 of [XML]) and MUST conform to the
3891 format defined in [LANGTAGS].
3893 A server MUST NOT modify or delete 'xml:lang' attributes on stanzas
3894 it receives from other entities.
3896 9.2. Basic Semantics
3898 9.2.1. Message Semantics
3900 The |
3942 | [ ... payload ... ] |
3943 | |
3944 | -------------------------> |
3945 | |
3946 | |
3947 | [ ... payload ... ] |
3948 | |
3949 | <------------------------- |
3950 | |
3951 | |
3952 | [ ... payload ... ] |
3953 | |
3954 | -------------------------> |
3955 | |
3956 | |
3957 | [ ... condition ... ] |
3958 | |
3959 | <------------------------- |
3960 | |
3962 To enforce these semantics, the following rules apply:
3964 1. The 'id' attribute is REQUIRED for IQ stanzas.
3965 2. The 'type' attribute is REQUIRED for IQ stanzas. The value MUST
3966 be one of the following (if the value is other than one of the
3967 following strings, the recipient or an intermediate router MUST
3968 return a stanza error of
4032 [OPTIONAL to include sender XML here]
4033
4034
4037 OPTIONAL descriptive text
4038 ]
4039 [OPTIONAL application-specific condition element]
4040
4041
4043 The "stanza-kind" MUST be one of message, presence, or iq.
4045 The "error-type MUST be one of the following:
4047 o auth -- retry after providing credentials
4048 o cancel -- do not retry (the error cannot be remedied)
4049 o continue -- proceed (the condition was only a warning)
4050 o modify -- retry after changing the data sent
4051 o wait -- retry after waiting (the error is temporary)
4053 The
4094
4097 S:
4101
4102
4104
4106 9.3.3.2. conflict
4108 Access cannot be granted because an existing resource exists with the
4109 same name or address; the associated error type SHOULD be "cancel".
4111 C:
4112
4113 balcony
4114
4115
4117 S:
4118
4119
4121
4123 9.3.3.3. feature-not-implemented
4125 The feature represented in the XML stanza is not implemented by the
4126 intended recipient or an intermediate server and therefore the stanza
4127 cannot be processed (e.g., the entity understands the namespace but
4128 does not recognize the element name); the associated error type
4129 SHOULD be "cancel" or "modify".
4131 C:
4135
4136
4138
4140 E:
4144
4145
4151
4153 9.3.3.4. forbidden
4155 The requesting entity does not possess the required permissions to
4156 perform the action; the associated error type SHOULD be "auth".
4158 C:
4161
4164 E:
4168
4169
4172
4174 9.3.3.5. gone
4176 The recipient or server can no longer be contacted at this address,
4177 typically on a permanent basis, and no updated address is available
4178 for forwarding or redirection; the associated error type SHOULD be
4179 "cancel" or "modify" and the error stanza SHOULD include a new
4180 address as the XML character data of the
4187
4190 E:
4194
4195
4196 xmpp:conference.example.com
4197
4198
4199
4201 9.3.3.6. internal-server-error
4203 The server could not process the stanza because of a misconfiguration
4204 or an otherwise-undefined internal server error; the associated error
4205 type SHOULD be "wait" or "cancel".
4207 C:
4210
4213 E:
4217
4218
4221
4223 9.3.3.7. item-not-found
4225 The addressed JID or item requested cannot be found; the associated
4226 error type SHOULD be "cancel" or "modify".
4228 C:
4229
4230 someresource
4231
4232
4234 S:
4235
4236
4238
4240 Note: An application MUST NOT return this error if doing so would
4241 provide information about the intended recipient's network
4242 availability to an entity that is not authorized to know such
4243 information; instead it MUST return a
4256
4259 E:
4263
4264
4267
4269 9.3.3.9. not-acceptable
4271 The recipient or server understands the request but is refusing to
4272 process it because it does not meet criteria defined by the recipient
4273 or server (e.g., a local policy regarding stanza size limits or
4274 acceptable words in messages); the associated error type SHOULD be
4275 "modify".
4277 C:
4278 [ ... the-emacs-manual ... ]
4279
4281 S:
4282
4283
4286
4288 9.3.3.10. not-allowed
4290 The recipient or server does not allow any entity to perform the
4291 action (e.g., sending to entities at a blacklisted domain); the
4292 associated error type SHOULD be "cancel".
4294 C:
4297
4300 E:
4303
4304
4306
4308 9.3.3.11. not-authorized
4310 The sender needs to provide proper credentials before being allowed
4311 to perform the action, or has provided improper credentials; the
4312 associated error type SHOULD be "auth".
4314 C:
4317
4320 E:
4323
4324
4326
4328 9.3.3.12. not-modified
4330 The item requested has not changed since it was last requested; the
4331 associated error type SHOULD be "continue".
4333 C:
4336
4337
4338
4339 some-long-opaque-string
4340
4341
4342
4343
4345 S:
4348
4349
4350
4351 some-long-opaque-string
4352
4353
4354
4355
4356
4358
4360 9.3.3.13. payment-required
4362 The requesting entity is not authorized to access the requested
4363 service because payment is required; the associated error type SHOULD
4364 be "auth".
4366 C:
4370
4371
4373
4375 E:
4379
4380
4383
4385 9.3.3.14. recipient-unavailable
4387 The intended recipient is temporarily unavailable; the associated
4388 error type SHOULD be "wait".
4390 C:
4393
4396 E:
4399
4400
4403
4405 Note: An application MUST NOT return this error if doing so would
4406 provide information about the intended recipient's network
4407 availability to an entity that is not authorized to know such
4408 information; instead it MUST return a
4424
4427 E:
4431
4432
4433 xmpp:characters@conference.example.org
4434
4435
4436
4438 9.3.3.16. registration-required
4440 The requesting entity is not authorized to access the requested
4441 service because prior registration is required; the associated error
4442 type SHOULD be "auth".
4444 C:
4447
4450 E:
4453
4454
4457
4459 9.3.3.17. remote-server-not-found
4461 A remote server or service specified as part or all of the JID of the
4462 intended recipient does not exist; the associated error type SHOULD
4463 be "cancel".
4465 C:
4468
4471 E:
4474
4475
4478
4480 9.3.3.18. remote-server-timeout
4482 A remote server or service specified as part or all of the JID of the
4483 intended recipient (or required to fulfill a request) could not be
4484 contacted within a reasonable amount of time; the associated error
4485 type SHOULD be "wait".
4487 C:
4490
4493 E:
4496
4497
4500
4502 9.3.3.19. resource-constraint
4504 The server or recipient lacks the system resources necessary to
4505 service the request; the associated error type SHOULD be "wait".
4507 C:
4511
4512
4514
4516 E:
4520
4521
4524
4526 9.3.3.20. service-unavailable
4528 The server or recipient does not currently provide the requested
4529 service; the associated error type SHOULD be "cancel".
4531 C:
4533 Hello?
4534
4536 S:
4538
4539
4542
4544 An application MUST return a help
4560
4562 E:
4566
4567
4570
4572 9.3.3.22. undefined-condition
4574 The error condition is not one of those defined by the other
4575 conditions in this list; any error type can be associated with this
4576 condition, and it SHOULD be used only in conjunction with an
4577 application-specific condition.
4579 C:
4583 My lord, dispatch; read o'er these articles.
4584
4585
4590 S:
4594
4598
4602
4603
4606
4610
4611
4613 9.3.3.23. unexpected-request
4615 The recipient or server understood the request but was not expecting
4616 it at this time (e.g., the request was out of order); the associated
4617 error type SHOULD be "wait" or "modify".
4619 C:
4623
4624
4628
4630 E:
4634
4635
4640
4642 9.3.3.24. unknown-sender
4644 The stanza 'from' address specified by a connected client is not
4645 valid for the stream (e.g., the stanza does not include a 'from'
4646 address when multiple resources are bound to the stream as described
4647 under Section 8.6.4); the associated error type SHOULD be "modify".
4649 C:
4650 Wherefore art thou?
4651
4653 S:
4655 Wherefore art thou?
4656
4657
4659
4661 9.3.4. Application-Specific Conditions
4663 As noted, an application MAY provide application-specific stanza
4664 error information by including a properly-namespaced child in the
4665 error element. The application-specific element SHOULD supplement or
4666 further qualify a defined element. Thus, the
4670
4671
4674
4676
4677
4678
4682 [ ... application-specific information ... ]
4683
4684
4686
4688 An entity that receives an application-specific error condition it
4689 does not understand MUST ignore the condition.
4691 9.4. Extended Content
4693 While the message, presence, and IQ stanzas provide basic semantics
4694 for messaging, availability, and request-response interactions, XMPP
4695 uses XML namespaces (see [XML-NAMES] to extend the basic stanza
4696 syntax for the purpose of providing additional functionality. Thus a
4697 message or presence stanza MAY contain one or more optional child
4698 elements specifying content that extends the meaning of the message
4699 (e.g., an XHTML-formatted version of the message body as described in
4700 [XEP-0071]), and an IQ stanza of type "get" or "set" MUST contain one
4701 such child element. This child element MAY have any name and MUST
4702 possess a namespace declaration (other than "jabber:client", "jabber:
4703 server", or "http://etherx.jabber.org/streams") that defines all data
4704 contained within the child element. Such a child element is said to
4705 be EXTENDED CONTENT and its namespace name is said to be an EXTENDED
4706 NAMESPACE.
4708 Support for any given extended namespace is OPTIONAL on the part of
4709 any implementation. If an entity does not understand such a
4710 namespace, the entity's expected behavior depends on whether the
4711 entity is (1) the recipient or (2) an entity that is routing the
4712 stanza to the recipient.
4714 Recipient: If a recipient receives a stanza that contains a child
4715 element it does not understand, it MUST silently ignore that
4716 particular XML data, i.e., it MUST not process it or present it to
4717 a user or associated application (if any). In particular:
4718 * If an entity receives a message or presence stanza that
4719 contains XML data qualified by a namespace it does not
4720 understand, the portion of the stanza that qualified by the
4721 unknown namespace MUST be ignored.
4722 * If an entity receives a message stanza whose only child element
4723 is qualified by a namespace it does not understand, it MUST
4724 ignore the entire stanza.
4725 * If an entity receives an IQ stanza of type "get" or "set"
4726 containing a child element qualified by a namespace it does not
4727 understand, the entity MUST return an IQ stanza of type "error"
4728 with an error condition of
4774 Step 2: Server responds by sending a response stream header to
4775 client:
4777 S:
4790
4791
4793
4795 Step 4: Client sends STARTTLS command to server:
4797 C:
4809 Step 6: Client and server attempt to complete TLS negotiation over
4810 the existing TCP connection (see [TLS] for details).
4812 Step 7: If TLS negotiation is successful, client initiates a new
4813 stream to server:
4815 C:
4823 Step 7 (alt): If TLS negotiation is unsuccessful, server closes TCP
4824 connection.
4826 10.1.2. SASL
4828 Step 8: Server responds by sending a stream header to client along
4829 with any available stream features:
4831 S:
4841
4842 DIGEST-MD5
4843 PLAIN
4844
4846
4848 Step 9: Client selects an authentication mechanism, in this case
4849 [PLAIN]:
4851 C: UjBtMzBSMGNrcw==
4854 Step 10: Server informs client of success:
4856 S:
4861
4864 Step 11: Client initiates a new stream to server:
4866 C:
4888 S:
4889
4890
4892
4894 Upon being so informed that resource binding is mandatory, the client
4895 needs to bind a resource to the stream; here we assume that the
4896 client submits a human-readable text string.
4898 Step 13: Client binds a resource:
4900 C:
4901
4902 balcony
4903
4904
4906 Step 14: Server accepts submitted resource identifier and informs
4907 client of successful resource binding:
4909 S:
4910
4911
4912 juliet@im.example.com/balcony
4913
4914
4915
4917 10.1.4. Stanza Exchange
4919 Now the client is allowed to send XML stanzas over the negotiated
4920 stream.
4922 C:
4925 Art thou not Romeo, and a Montague?
4926
4928 If necessary, sender's server negotiates XML streams with intended
4929 recipient's server (see Section 10.2).
4931 The intended recipient replies and the message is delivered to the
4932 client.
4934 E:
4937 Neither, fair saint, if either thee dislike.
4938
4940 The client can subsequently send and receive an unbounded number of
4941 subsequent XML stanzas over the stream.
4943 10.1.5. Close
4945 Desiring to send no further messages, the client closes the stream.
4947 C:
4949 Consistent with the recommended stream closing handshake, the server
4950 closes the stream as well:
4952 S:
4954 Client now terminates the underlying TCP connection.
4956 10.2. Server-to-Server Examples
4958 The following examples show the data flow for a server negotiating an
4959 XML stream with another server, exchanging XML stanzas, and closing
4960 the negotiated stream. The initiating server ("Server1") is
4961 im.example.com; the receiving server ("Server2") is example.net and
4962 it requires use of TLS; im.example.com presents a certificate and
4963 authenticates via the SASL EXTERNAL mechanism. It is assumed that
4964 before sending the initial stream header, Server1 has already
4965 resolved an SRV record of _xmpp-server._tcp.example.net and has
4966 opened a TCP connection to the advertised port at the resolved IP
4967 address.
4969 Note: The alternate steps shown are provided only to illustrate
4970 the protocol for failure cases; they are not exhaustive and would
4971 not necessarily be triggered by the data sent in the examples.
4973 10.2.1. TLS
4975 Step 1: Server1 initiates stream to Server2:
4977 S1:
4984 Step 2: Server2 responds by sending a response stream header to
4985 Server1:
4987 S2:
4995 Step 3: Server2 sends stream features to Server1:
4997 S2:
4998
4999
5001
5003 Step 4: Server1 sends the STARTTLS command to Server2:
5005 S1:
5018 Step 6: Server1 and Server2 attempt to complete TLS negotiation via
5019 TCP (see [TLS] for details).
5021 Step 7: If TLS negotiation is successful, Server1 initiates a new
5022 stream to Server2:
5024 S1:
5031 Step 7 (alt): If TLS negotiation is unsuccessful, Server2 closes TCP
5032 connection.
5034 10.2.2. SASL
5036 Step 8: Server2 sends a response stream header to Server1 along with
5037 available stream features (including a preference for the SASL
5038 EXTERNAL mechanism):
5040 S2:
5048 S2:
5049
5050 EXTERNAL
5051
5053
5055 Step 9: Server1 selects the EXTERNAL mechanism, in this case with an
5056 authorization identity encoded according to [BASE64]:
5058 S1:
5072
5075 S2:
5076 Step 11: Server1 initiates a new stream to Server2:
5078 S1:
5085 Step 12: Server2 responds by sending a stream header to Server1 along
5086 with any additional features (or, in this case, an empty features
5087 element):
5089 S2:
5097 S2:
5111 Art thou not Romeo, and a Montague?
5112
5114 The intended recipient replies and the message is delivered from
5115 Server2 to Server1.
5117 Server2 sends XML stanza to Server1:
5119 S2:
5122 Neither, fair saint, if either thee dislike.
5123
5125 10.2.4. Close
5127 Desiring to send no further messages, Server1 closes the stream. (In
5128 practice, the stream would most likely remain open for some time,
5129 since Server1 and Server2 do not immediately know if the stream will
5130 be needed for further communication.)
5132 S1:
5134 Consistent with the recommended stream closing handshake, Server2
5135 closes the stream as well:
5137 S2:
5139 Server1 now terminates the underlying TCP connection.
5141 11. Server Rules for Processing XML Stanzas
5143 An XMPP server MUST ensure in-order processing of XML stanzas between
5144 any two entities. This includes stanzas sent by a client to its
5145 server for direct processing by the server (e.g., in-order processing
5146 of a roster get and initial presence as described in [XMPP-IM]).
5148 Beyond the requirement for in-order processing, each server
5149 implementation will contain its own logic for processing stanzas it
5150 receives. Such logic determines whether the server needs to ROUTE a
5151 given stanza to another domain, DELIVER it to a local entity
5152 (typically a connected client associated with a local account), or
5153 HANDLE it directly within the server itself. The following rules
5154 apply.
5156 Note: Particular XMPP applications MAY specify delivery rules that
5157 modify or supplement the following rules; for example, a set of
5158 delivery rules for instant messaging and presence applications is
5159 defined in [XMPP-IM].
5161 11.1. No 'to' Address
5163 11.1.1. Overview
5165 If the stanza possesses no 'to' attribute, the server MUST handle it
5166 directly on behalf of the entity that sent it, where the meaning of
5167 "handle it directly" depends on whether the stanza is message,
5168 presence, or IQ. Because all stanzas received from other servers
5169 MUST possess a 'to' attribute, this rule applies only to stanzas
5170 received from a local entity (such as a client) that is connected to
5171 the server.
5173 11.1.2. Message
5175 If the server receives a message stanza with no 'to' attribute, it
5176 MUST treat the message as if the 'to' address were the bare JID
5177 of the sending entity.
5179 11.1.3. Presence
5181 If the server receives a presence stanza with no 'to' attribute, it
5182 MUST broadcast it to the entities that are subscribed to the sending
5183 entity's presence, if applicable ([XMPP-IM] defines the semantics of
5184 such broadcasting for presence applications).
5186 11.1.4. IQ
5188 If the server receives an IQ stanza with no 'to' attribute, it MUST
5189 process the stanza on behalf of the account from which received the
5190 stanza, as follows:
5192 1. If the IQ stanza is of type "get" or "set" and the server
5193 understands the namespace that qualifies the payload, the server
5194 MUST handle the stanza on behalf of the sending entity or return
5195 an appropriate error to the sending entity. While the meaning of
5196 "handle" is determined by the semantics of the qualifying
5197 namespace, in general the server shall respond to the IQ stanza
5198 of type "get" or "set" by returning an appropriate IQ stanza of
5199 type "result" or "error", responding as if the server were the
5200 bare JID of the sending entity. As an example, if the sending
5201 entity sends an IQ stanza of type "get" where the payload is
5202 qualified by the 'jabber:iq:roster' namespace (as described in
5203 [XMPP-IM]), then the server shall return the roster associated
5204 with the sending entity's bare JID to the particular resource of
5205 the sending entity that requested the roster.
5206 2. If the IQ stanza is of type "get" or "set" and the server does
5207 not understand the namespace that qualifies the payload, the
5208 server MUST return an error to the sending entity, which MUST be
5209 ,
5227 then the server MUST either handle the stanza as appropriate for the
5228 stanza kind or return an error stanza to the sender.
5230 11.2.2. Domain with Resource
5232 If the JID contained in the 'to' attribute is of the form , then the server MUST either handle the stanza as
5234 appropriate for the stanza kind or return an error stanza to the
5235 sender.
5237 11.2.3. Node at Domain
5239 Note: For addresses of this type, more detailed rules in the
5240 context of instant messaging and presence applications are
5241 provided in [XMPP-IM].
5243 11.2.3.1. No Such User
5245 If there is no local account associated with the , how
5246 the stanza shall be processed depends on the stanza type.
5248 o For a message stanza, the server MUST return a , how the stanza shall be processed depends on the
5259 stanza type.
5261 o For a message stanza, if there exists at least one connected
5262 resource for the node the server SHOULD deliver it to at least one
5263 of the connected resources. If there exists no connected
5264 resource, the server MUST either return an error or store the
5265 message offline for delivery when the account next has a connected
5266 resource.
5268 o For a presence stanza, if there exists at least one connected
5269 resource for the node the server SHOULD deliver it to at least one
5270 of the connected resources. If there exists no connected
5271 resource, the server MUST silently discard the stanza.
5272 o For an IQ stanza, the server MUST handle it directly on behalf of
5273 the intended recipient.
5275 11.2.3.3. Full JID
5277 If the JID contained in the 'to' attribute is of the form
5278 and there is no connected resource that
5279 exactly matches the full JID, the stanza shall be processed as if the
5280 JID were of the form .
5282 If the JID contained in the 'to' attribute is of the form
5283 and there is a connected resource that exactly
5284 matches the full JID, the server SHOULD deliver the stanza to that
5285 connected resource.
5287 11.3. Foreign Domain
5289 If the hostname of the domain identifier portion of the JID contained
5290 in the 'to' attribute does not match one of the configured hostnames
5291 of the server itself, the server SHOULD attempt to route the stanza
5292 to the foreign domain (subject to local service provisioning and
5293 security policies regarding inter-domain communication, since such
5294 communication is optional for any given deployment). There are two
5295 possible cases.
5297 11.3.1. Existing Stream
5299 If a server-to-server stream already exists between the two domains,
5300 the sender's server shall attempt to route the stanza to the
5301 authoritative server for the foreign domain over the existing stream.
5303 11.3.2. No Existing Stream
5305 If there exists no server-to-server stream between the two domains,
5306 the sender's server shall proceed as follows:
5308 1. Resolve the hostname of the foreign domain (as defined under
5309 Section 15.4).
5310 2. Negotiate a server-to-server stream between the two domains (as
5311 defined under Section 6 and Section 7).
5312 3. Route the stanza to the authoritative server for the foreign
5313 domain over the newly-established stream.
5315 11.3.3. Error Handling
5317 If routing of a stanza to the intended recipient's server is
5318 unsuccessful, the sender's server MUST return an error to the sender.
5319 If resolution of the foreign domain is unsuccessful, the stanza error
5320 MUST be
5452
5454 An XML stanza MAY contain XML data qualified by more than one
5455 extended namespace, either at the direct child level of the stanza
5456 (for presence and message stanzas) or in any mix of levels (for all
5457 stanzas).
5459
5460
5464 sha1-hash-of-image
5465
5466
5468
5469 Hello?
5470
5471
5472 Hello?
5473
5474
5475
5477
5480
5481
5482 some-long-opaque-string
5483
5484
5485
5487 An implementation SHOULD NOT generate namespace prefixes for elements
5488 qualified by content (as opposed to stream) namespaces other than the
5489 default namespace. However, if included, the namespace declarations
5490 for those prefixes MUST be included on the stanza root or a child
5491 thereof, not at the level of the stream element (this helps to ensure
5492 that any such namespace declaration is routed and delivered with the
5493 stanza, instead of assumed from the stream).
5495 12.3. Well-Formedness
5497 There are two varieties of well-formedness:
5499 o "XML-well-formedness" in accordance with the definition of "well-
5500 formed" in Section 2.1 of [XML].
5501 o "Namespace-well-formedness" in accordance with the definition of
5502 "namespace-well-formed" in Section 7 of [XML-NAMES].
5504 The following rules apply.
5506 An XMPP entity MUST NOT generate data that is not XML-well-formed.
5507 An XMPP entity MUST NOT accept data that is not XML-well-formed;
5508 instead it MUST return an )
6307 or full JID ().
6309 15.14. Directory Harvesting
6311 To help prevent directory harvesting attacks, a server MUST NOT
6312 return different stanza errors if a potential attacker sends XML
6313 stanzas to an existing entity or a nonexistent entity.
6315 16. IANA Considerations
6317 The following sections update the registrations provided in
6318 [RFC3920].
6320 16.1. XML Namespace Name for TLS Data
6322 A URN sub-namespace for STARTTLS negotiation data in the Extensible
6323 Messaging and Presence Protocol (XMPP) is defined as follows. (This
6324 namespace name adheres to the format defined in [XML-REG].)
6326 URI: urn:ietf:params:xml:ns:xmpp-tls
6327 Specification: XXXX
6328 Description: This is the XML namespace name for STARTTLS negotiation
6329 data in the Extensible Messaging and Presence Protocol (XMPP) as
6330 defined by XXXX.
6331 Registrant Contact: IETF, XMPP Working Group,
6333 16.2. XML Namespace Name for SASL Data
6335 A URN sub-namespace for SASL negotiation data in the Extensible
6336 Messaging and Presence Protocol (XMPP) is defined as follows. (This
6337 namespace name adheres to the format defined in [XML-REG].)
6339 URI: urn:ietf:params:xml:ns:xmpp-sasl
6340 Specification: XXXX
6341 Description: This is the XML namespace name for SASL negotiation
6342 data in the Extensible Messaging and Presence Protocol (XMPP) as
6343 defined by XXXX.
6344 Registrant Contact: IETF, XMPP Working Group,
6346 16.3. XML Namespace Name for Stream Errors
6348 A URN sub-namespace for stream error data in the Extensible Messaging
6349 and Presence Protocol (XMPP) is defined as follows. (This namespace
6350 name adheres to the format defined in [XML-REG].)
6351 URI: urn:ietf:params:xml:ns:xmpp-streams
6352 Specification: XXXX
6353 Description: This is the XML namespace name for stream error data in
6354 the Extensible Messaging and Presence Protocol (XMPP) as defined
6355 by XXXX.
6356 Registrant Contact: IETF, XMPP Working Group,
6358 16.4. XML Namespace Name for Resource Binding
6360 A URN sub-namespace for resource binding in the Extensible Messaging
6361 and Presence Protocol (XMPP) is defined as follows. (This namespace
6362 name adheres to the format defined in [XML-REG].)
6364 URI: urn:ietf:params:xml:ns:xmpp-bind
6365 Specification: XXXX
6366 Description: This is the XML namespace name for resource binding in
6367 the Extensible Messaging and Presence Protocol (XMPP) as defined
6368 by XXXX.
6369 Registrant Contact: IETF, XMPP Working Group,
6371 16.5. XML Namespace Name for Stanza Errors
6373 A URN sub-namespace for stanza error data in the Extensible Messaging
6374 and Presence Protocol (XMPP) is defined as follows. (This namespace
6375 name adheres to the format defined in [XML-REG].)
6377 URI: urn:ietf:params:xml:ns:xmpp-stanzas
6378 Specification: XXXX
6379 Description: This is the XML namespace name for stanza error data in
6380 the Extensible Messaging and Presence Protocol (XMPP) as defined
6381 by XXXX.
6382 Registrant Contact: IETF, XMPP Working Group,
6384 16.6. Nodeprep Profile of Stringprep
6386 The Nodeprep profile of stringprep is defined under Nodeprep
6387 (Appendix A). The IANA has registered Nodeprep in the stringprep
6388 profile registry.
6390 Name of this profile:
6392 Nodeprep
6394 RFC in which the profile is defined:
6396 XXXX
6398 Indicator whether or not this is the newest version of the profile:
6400 This is the first version of Nodeprep
6402 16.7. Resourceprep Profile of Stringprep
6404 The Resourceprep profile of stringprep is defined under Resourceprep
6405 (Appendix B). The IANA has registered Resourceprep in the stringprep
6406 profile registry.
6408 Name of this profile:
6410 Resourceprep
6412 RFC in which the profile is defined:
6414 XXXX
6416 Indicator whether or not this is the newest version of the profile:
6418 This is the first version of Resourceprep
6420 16.8. GSSAPI Service Name
6422 The IANA has registered "xmpp" as a GSSAPI [GSS-API] service name, as
6423 defined under Section 7.5.
6425 16.9. Port Numbers
6427 The IANA has registered "xmpp-client" and "xmpp-server" as keywords
6428 for [TCP] ports 5222 and 5269 respectively.
6430 These ports SHOULD be used for client-to-server and server-to-server
6431 communications respectively, but other ports MAY be used.
6433 17. References
6435 17.1. Normative References
6437 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
6438 Specifications: ABNF", STD 68, RFC 5234, January 2008.
6440 [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data
6441 Encodings", RFC 4648, October 2006.
6443 [CHARSET] Alvestrand, H., "IETF Policy on Character Sets and
6444 Languages", BCP 18, RFC 2277, January 1998.
6446 [DNS] Mockapetris, P., "Domain names - implementation and
6447 specification", STD 13, RFC 1035, November 1987.
6449 [DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
6450 specifying the location of services (DNS SRV)", RFC 2782,
6451 February 2000.
6453 [IDNA] Faltstrom, P., Hoffman, P., and A. Costello,
6454 "Internationalizing Domain Names in Applications (IDNA)",
6455 RFC 3490, March 2003.
6457 [LANGTAGS]
6458 Phillips, A. and M. Davis, "Tags for Identifying
6459 Languages", BCP 47, RFC 4646, September 2006.
6461 [NAMEPREP]
6462 Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
6463 Profile for Internationalized Domain Names (IDN)",
6464 RFC 3491, March 2003.
6466 [PLAIN] Zeilenga, K., "The PLAIN Simple Authentication and
6467 Security Layer (SASL) Mechanism", RFC 4616, August 2006.
6469 [RANDOM] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
6470 Requirements for Security", BCP 106, RFC 4086, June 2005.
6472 [SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and
6473 Security Layer (SASL)", RFC 4422, June 2006.
6475 [STRINGPREP]
6476 Hoffman, P. and M. Blanchet, "Preparation of
6477 Internationalized Strings ("stringprep")", RFC 3454,
6478 December 2002.
6480 [TCP] Postel, J., "Transmission Control Protocol", STD 7,
6481 RFC 793, September 1981.
6483 [TERMS] Bradner, S., "Key words for use in RFCs to Indicate
6484 Requirement Levels", BCP 14, RFC 2119, March 1997.
6486 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security
6487 (TLS) Protocol Version 1.1", RFC 4346, April 2006.
6489 [UCS2] International Organization for Standardization,
6490 "Information Technology - Universal Multiple-octet coded
6491 Character Set (UCS) - Amendment 2: UCS Transformation
6492 Format 8 (UTF-8)", ISO Standard 10646-1 Addendum 2,
6493 October 1996.
6495 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version
6496 3.2.0", 2000.
6498 The Unicode Standard, Version 3.2.0 is defined by The
6499 Unicode Standard, Version 3.0 (Reading, MA, Addison-
6500 Wesley, 2000. ISBN 0-201-61633-5), as amended by the
6501 Unicode Standard Annex #27: Unicode 3.1
6502 (http://www.unicode.org/reports/tr27/) and by the Unicode
6503 Standard Annex #28: Unicode 3.2
6504 (http://www.unicode.org/reports/tr28/).
6506 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
6507 10646", STD 63, RFC 3629, November 2003.
6509 [UUID] Leach, P., Mealling, M., and R. Salz, "A Universally
6510 Unique IDentifier (UUID) URN Namespace", RFC 4122,
6511 July 2005.
6513 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
6514 Resource Identifier (URI): Generic Syntax", STD 66,
6515 RFC 3986, January 2005.
6517 [X509] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
6518 X.509 Public Key Infrastructure Certificate and
6519 Certificate Revocation List (CRL) Profile", RFC 3280,
6520 April 2002.
6522 [X509-SRV]
6523 Santesson, S., "Internet X.509 Public Key Infrastructure
6524 Subject Alternative Name for Expression of Service Name",
6525 RFC 4985, August 2007.
6527 [XML] Paoli, J., Maler, E., Sperberg-McQueen, C., Yergeau, F.,
6528 and T. Bray, "Extensible Markup Language (XML) 1.0 (Fourth
6529 Edition)", World Wide Web Consortium Recommendation REC-
6530 xml-20060816, August 2006,
6531 .
6533 [XML-NAMES]
6534 Layman, A., Hollander, D., Tobin, R., and T. Bray,
6535 "Namespaces in XML 1.1 (Second Edition)", World Wide Web
6536 Consortium Recommendation REC-xml-names11-20060816,
6537 August 2006, .
6539 17.2. Informative References
6541 [ACAP] Newman, C. and J. Myers, "ACAP -- Application
6542 Configuration Access Protocol", RFC 2244, November 1997.
6544 [ANONYMOUS]
6545 Zeilenga, K., "Anonymous Simple Authentication and
6546 Security Layer (SASL) Mechanism", RFC 4505, June 2006.
6548 [ASN.1] CCITT, "Recommendation X.208: Specification of Abstract
6549 Syntax Notation One (ASN.1)", 1988.
6551 [CHANNEL] Williams, N., "On the Use of Channel Bindings to Secure
6552 Channels", RFC 5056, November 2007.
6554 [DIGEST-MD5]
6555 Leach, P. and C. Newman, "Using Digest Authentication as a
6556 SASL Mechanism", RFC 2831, May 2000.
6558 [DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S.
6559 Rose, "DNS Security Introduction and Requirements",
6560 RFC 4033, March 2005.
6562 [DNS-TXT] Rosenbaum, R., "Using the Domain Name System To Store
6563 Arbitrary String Attributes", RFC 1464, May 1993.
6565 [DOS] Handley, M., Rescorla, E., and IAB, "Internet Denial-of-
6566 Service Considerations", RFC 4732, December 2006.
6568 [GSS-API] Linn, J., "Generic Security Service Application Program
6569 Interface Version 2, Update 1", RFC 2743, January 2000.
6571 [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
6572 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
6573 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
6575 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
6576 4rev1", RFC 3501, March 2003.
6578 [IMP-REQS]
6579 Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging
6580 / Presence Protocol Requirements", RFC 2779,
6581 February 2000.
6583 [IRI] Duerst, M. and M. Suignard, "Internationalized Resource
6584 Identifiers (IRIs)", RFC 3987, January 2005.
6586 [LINKLOCAL]
6587 Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
6588 Configuration of IPv4 Link-Local Addresses", RFC 3927,
6589 May 2005.
6591 [MAILBOXES]
6592 Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND
6593 FUNCTIONS", RFC 2142, May 1997.
6595 [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
6596 STD 53, RFC 1939, May 1996.
6598 [PUNYCODE]
6599 Costello, A., "Punycode: A Bootstring encoding of Unicode
6600 for Internationalized Domain Names in Applications
6601 (IDNA)", RFC 3492, March 2003.
6603 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence
6604 Protocol (XMPP): Core", RFC 3920, October 2004.
6606 [RFC3921] Saint-Andre, P., Ed., "Extensible Messaging and Presence
6607 Protocol (XMPP): Instant Messaging and Presence",
6608 RFC 3921, October 2004.
6610 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
6611 April 2001.
6613 [URN-OID] Mealling, M., "A URN Namespace of Object Identifiers",
6614 RFC 3061, February 2001.
6616 [USINGTLS]
6617 Newman, C., "Using TLS with IMAP, POP3 and ACAP",
6618 RFC 2595, June 1999.
6620 [XEP-0001]
6621 Saint-Andre, P., "XMPP Extension Protocols", XSF XEP 0001,
6622 January 2008.
6624 [XEP-0045]
6625 Saint-Andre, P., "Multi-User Chat", XSF XEP 0045,
6626 July 2007.
6628 [XEP-0060]
6629 Millard, P., Saint-Andre, P., and R. Meijer, "Publish-
6630 Subscribe", XSF XEP 0060, September 2007.
6632 [XEP-0071]
6633 Saint-Andre, P., "XHTML-IM", XSF XEP 0071, September 2007.
6635 [XEP-0077]
6636 Saint-Andre, P., "In-Band Registration", XSF XEP 0077,
6637 January 2006.
6639 [XEP-0124]
6640 Paterson, I., Smith, D., and P. Saint-Andre,
6641 "Bidirectional-streams Over Synchronous HTTP (BOSH)", XSF
6642 XEP 0124, February 2007.
6644 [XEP-0156]
6645 Hildebrand, J. and P. Saint-Andre, "Discovering
6646 Alternative XMPP Connection Methods", XSF XEP 0156,
6647 June 2007.
6649 [XEP-0165]
6650 Saint-Andre, P., "Best Practices to Prevent JID
6651 Mimicking", XSF XEP 0165, July 2007.
6653 [XEP-0174]
6654 Saint-Andre, P., "Link-Local Messaging", XSF XEP 0174,
6655 September 2007.
6657 [XEP-0175]
6658 Saint-Andre, P., "Best Practices for Use of SASL
6659 ANONYMOUS", XSF XEP 0175, September 2006.
6661 [XEP-0178]
6662 Saint-Andre, P. and P. Millard, "Best Practices for Use of
6663 SASL EXTERNAL with Certificates", XSF XEP 0178,
6664 February 2007.
6666 [XEP-0205]
6667 Saint-Andre, P., "Best Practices to Discourage Denial of
6668 Service Attacks", XSF XEP 0205, July 2007.
6670 [XEP-0206]
6671 Paterson, I., "XMPP Over BOSH", XSF XEP 0206, June 2007.
6673 [XEP-0220]
6674 Saint-Andre, P. and J. Miller, "Server Dialback", XSF
6675 XEP 0220, October 2008.
6677 [XEP-0246]
6678 Saint-Andre, P., "End-to-End XML Streams", XSF XEP 0246,
6679 June 2008.
6681 [XML-FRAG]
6682 Grosso, P. and D. Veillard, "XML Fragment Interchange",
6683 World Wide Web Consortium CR CR-xml-fragment-20010212,
6684 February 2001,
6685 .
6687 [XML-REG] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
6688 January 2004.
6690 [XML-SCHEMA]
6691 Thompson, H., Maloney, M., Mendelsohn, N., and D. Beech,
6692 "XML Schema Part 1: Structures Second Edition", World Wide
6693 Web Consortium Recommendation REC-xmlschema-1-20041028,
6694 October 2004,
6695 .
6697 [XMPP-IM] Saint-Andre, P., "Extensible Messaging and Presence
6698 Protocol (XMPP): Instant Messaging and Presence",
6699 draft-saintandre-rfc3921bis-06 (work in progress),
6700 July 2008.
6702 [XMPP-URI]
6703 Saint-Andre, P., "Internationalized Resource Identifiers
6704 (IRIs) and Uniform Resource Identifiers (URIs) for the
6705 Extensible Messaging and Presence Protocol (XMPP)",
6706 RFC 5122, February 2008.
6708 Appendix A. Nodeprep
6710 A.1. Introduction
6712 This appendix defines the "Nodeprep" profile of stringprep. As such,
6713 it specifies processing rules that will enable users to enter
6714 internationalized node identifiers in the Extensible Messaging and
6715 Presence Protocol (XMPP) and have the highest chance of getting the
6716 content of the strings correct. (An XMPP node identifier is the
6717 optional portion of an XMPP address that precedes an XMPP domain
6718 identifier and the '@' separator; it is often but not exclusively
6719 associated with an instant messaging username.) These processing
6720 rules are intended only for XMPP node identifiers and are not
6721 intended for arbitrary text or any other aspect of an XMPP address.
6723 This profile defines the following, as required by [STRINGPREP]:
6725 o The intended applicability of the profile: internationalized node
6726 identifiers within XMPP
6727 o The character repertoire that is the input and output to
6728 stringprep: Unicode 3.2, specified in Section 2 of this Appendix
6730 o The mappings used: specified in Section 3
6731 o The Unicode normalization used: specified in Section 4
6732 o The characters that are prohibited as output: specified in Section
6733 5
6734 o Bidirectional character handling: specified in Section 6
6736 A.2. Character Repertoire
6738 This profile uses Unicode 3.2 with the list of unassigned code points
6739 being Table A.1, both defined in Appendix A of [STRINGPREP].
6741 A.3. Mapping
6743 This profile specifies mapping using the following tables from
6744 [STRINGPREP]:
6746 Table B.1
6747 Table B.2
6749 A.4. Normalization
6751 This profile specifies the use of Unicode normalization form KC, as
6752 described in [STRINGPREP].
6754 A.5. Prohibited Output
6756 This profile specifies the prohibition of using the following tables
6757 from [STRINGPREP].
6759 Table C.1.1
6760 Table C.1.2
6761 Table C.2.1
6762 Table C.2.2
6763 Table C.3
6764 Table C.4
6765 Table C.5
6766 Table C.6
6767 Table C.7
6768 Table C.8
6769 Table C.9
6771 In addition, the following additional Unicode characters are also
6772 prohibited:
6774 U+0022 (QUOTATION MARK)
6775 U+0026 (AMPERSAND)
6776 U+0027 (APOSTROPHE)
6777 U+002F (SOLIDUS)
6778 U+003A (COLON)
6779 U+003C (LESS-THAN SIGN)
6780 U+003E (GREATER-THAN SIGN)
6781 U+0040 (COMMERCIAL AT)
6783 A.6. Bidirectional Characters
6785 This profile specifies checking bidirectional strings, as described
6786 in Section 6 of [STRINGPREP].
6788 A.7. Notes
6790 Because the additional characters prohibited by Nodeprep are
6791 prohibited after normalization, an implementation MUST NOT enable a
6792 human user to input any Unicode code point whose decomposition
6793 includes those characters; such code points include but are not
6794 necessarily limited to the following (refer to [UNICODE] for complete
6795 information).
6797 o U+2100 (ACCOUNT OF)
6798 o U+2101 (ADDRESSED TO THE SUBJECT)
6799 o U+2105 (CARE OF)
6800 o U+2106 (CADA UNA)
6801 o U+226E (NOT LESS-THAN)
6802 o U+226F (NOT GREATER-THAN)
6803 o U+2A74 (DOUBLE COLON EQUAL)
6804 o U+FE13 (SMALL COLON)
6805 o U+FE60 (SMALL AMPERSAND)
6806 o U+FE64 (SMALL LESS-THAN SIGN)
6807 o U+FE65 (SMALL GREATER-THAN SIGN)
6808 o U+FE6B (SMALL COMMERCIAL AT)
6809 o U+FF02 (FULLWIDTH QUOTATION MARK)
6810 o U+FF06 (FULLWIDTH AMPERSAND)
6811 o U+FF07 (FULLWIDTH APOSTROPHE)
6812 o U+FF0F (FULLWIDTH SOLIDUS)
6813 o U+FF1A (FULLWIDTH COLON)
6814 o U+FF1C (FULLWIDTH LESS-THAN SIGN)
6815 o U+FF1E (FULLWIDTH GREATER-THAN SIGN)
6816 o U+FF20 (FULLWIDTH COMMERCIAL AT)
6818 Appendix B. Resourceprep
6819 B.1. Introduction
6821 This appendix defines the "Resourceprep" profile of stringprep. As
6822 such, it specifies processing rules that will enable users to enter
6823 internationalized resource identifiers in the Extensible Messaging
6824 and Presence Protocol (XMPP) and have the highest chance of getting
6825 the content of the strings correct. (An XMPP resource identifier is
6826 the optional portion of an XMPP address that follows an XMPP domain
6827 identifier and the '/' separator.) These processing rules are
6828 intended only for XMPP resource identifiers and are not intended for
6829 arbitrary text or any other aspect of an XMPP address.
6831 This profile defines the following, as required by [STRINGPREP]:
6833 o The intended applicability of the profile: internationalized
6834 resource identifiers within XMPP
6835 o The character repertoire that is the input and output to
6836 stringprep: Unicode 3.2, specified in Section 2 of this Appendix
6837 o The mappings used: specified in Section 3
6838 o The Unicode normalization used: specified in Section 4
6839 o The characters that are prohibited as output: specified in Section
6840 5
6841 o Bidirectional character handling: specified in Section 6
6843 B.2. Character Repertoire
6845 This profile uses Unicode 3.2 with the list of unassigned code points
6846 being Table A.1, both defined in Appendix A of [STRINGPREP].
6848 B.3. Mapping
6850 This profile specifies mapping using the following tables from
6851 [STRINGPREP]:
6853 Table B.1
6855 B.4. Normalization
6857 This profile specifies the use of Unicode normalization form KC, as
6858 described in [STRINGPREP].
6860 B.5. Prohibited Output
6862 This profile specifies the prohibition of using the following tables
6863 from [STRINGPREP].
6865 Table C.1.2
6866 Table C.2.1
6867 Table C.2.2
6868 Table C.3
6869 Table C.4
6870 Table C.5
6871 Table C.6
6872 Table C.7
6873 Table C.8
6874 Table C.9
6876 B.6. Bidirectional Characters
6878 This profile specifies checking bidirectional strings, as described
6879 in Section 6 of [STRINGPREP].
6881 Appendix C. XML Schemas
6883 Because validation of XML streams and stanzas is optional, the
6884 following XML schemas are provided for descriptive purposes only.
6885 These schemas are not normative.
6887 The following schemas formally define various XML namespaces used in
6888 the core XMPP protocols, in conformance with [XML-SCHEMA]. For
6889 schemas defining the 'jabber:client' and 'jabber:server' namespaces,
6890 refer to [XMPP-IM].
6892 C.1. Streams Namespace
6894
6896
6902
6909
6910
6913
6921
6922
6926
6927
6933
6934
6936
6942
6944
6945
6946
6948
6950
6951
6952
6953
6962
6963
6965
6967 C.2. Stream Error Namespace
6969
6971
6977
7003
7004
7029
7031
7032
7033
7034
7035
7037
7038
7039
7041
7042
7043
7045
7047
7049 C.3. STARTTLS Namespace
7051
7053
7059
7060
7061
7062
7065
7066
7068
7073
7074
7076
7078
7080 C.4. SASL Namespace
7082
7084
7090
7091
7092
7093
7099
7102
7106
7107
7109
7112
7113
7114
7115
7119
7120
7121
7123
7130
7131
7132
7133
7146
7148
7149
7151
7152
7153
7154
7155
7157
7158
7159
7161
7162
7163
7165
7167
7169 C.5. Resource Binding Namespace
7171
7173
7179
7180
7181
7182
7183
7186
7187
7190
7191
7192
7193
7194
7195
7196
7197
7199
7200
7203
7204
7205
7207
7208
7209
7212
7214
7215
7216
7219
7221
7223 C.6. Stanza Error Namespace
7225
7227
7233
7259
7260
7285
7287
7288
7289
7290
7291
7293
7294
7295
7297
7298
7299
7301
7303
7305 Appendix D. Contact Addresses
7307 Consistent with [MAILBOXES], an organization that offers an XMPP
7308 service SHOULD provide an Internet mailbox of "XMPP" for inquiries
7309 related to that service, where the host portion of the resulting
7310 mailto URI MUST be the organization's domain, not the domain of the
7311 XMPP service itself (e.g., the XMPP service might be offered at
7312 im.example.com but the Internet mailbox would be ).
7314 Appendix E. Account Provisioning
7316 Account provisioning is out of scope for this specification.
7317 Possible methods for account provisioning include account creation by
7318 a server administrator and in-band account registration using the
7319 'jabber:iq:register' namespace as documented in [XEP-0077].
7321 Appendix F. Differences From RFC 3920
7323 Based on consensus derived from implementation and deployment
7324 experience as well as formal interoperability testing, the following
7325 substantive modifications were made from RFC 3920.
7327 o Corrected the ABNF syntax for JIDs to prevent zero-length node
7328 identifiers, domain identifiers, and resource identifiers.
7329 o Corrected the nameprep processing rules to require use of the
7330 UseSTD3ASCIIRules flag.
7331 o Recommended or mandated use of the 'from' and 'to' attributes on
7332 stream headers.
7334 o More fully specified stream closing handshake.
7335 o Specified recommended stream reconnection algorithm.
7336 o Specified return of