idnits 2.17.1
draft-saintandre-rfc3920bis-02.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3978, Section 5.1 on line 15.
-- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on
line 4773.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4784.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4791.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4797.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
-- The abstract seems to indicate that this document obsoletes RFC3920, but
the header doesn't have an 'Obsoletes:' line to match this.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust Copyright Line does not match the
current year
== Line 4306 has weird spacing: '...equence xmlns...'
== Line 4307 has weird spacing: '...s:group ref=...'
== The document seems to lack the recommended RFC 2119 boilerplate, even if
it appears to use RFC 2119 keywords.
(The document does seem to have the reference to RFC 2119 which the
ID-Checklist requires).
== Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please
use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
mean).
Found 'SHOULD not' in this paragraph:
Recipient: If a recipient receives a stanza that contains a child
element it does not understand, it SHOULD ignore that specific XML data,
i.e., it SHOULD not process it or present it to a user or associated
application (if any). In particular: * If an entity receives a message
or presence stanza that contains XML data qualified by a namespace it
does not understand, the portion of the stanza that is in the unknown
namespace SHOULD be ignored. * If an entity receives a message stanza
whose only child element is qualified by a namespace it does not
understand, it MUST ignore the entire stanza. * If an entity receives an
IQ stanza of type "get" or "set" containing a child element qualified by
a namespace it does not understand, the entity SHOULD return an IQ stanza
of type "error" with an error condition of .
Router: If a routing entity (usually a server) handles a stanza that
contains a child element it does not understand, it SHOULD ignore the
associated XML data by passing it on untouched to the recipient.
== Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please
use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
mean).
Found 'MUST not' in this paragraph:
Note: If any of the namespace names provided by the Authoritative
Server is incorrect, then the Receiving Server MUST generate an
stream error condition and terminate both the XML
stream and the underlying TCP connection between it and the Authoritative
Server. If the value of the 'to' address provided by the Authoritative
Server does not match a hostname serviced by the Receiving Server, then
the Receiving Server MUST generate a stream error
condition and terminate both the XML stream and the underlying TCP
connection. If a stream error occurs between the Receiving Server and
the Authoritative Server, then the Receiving Server MUST not only
terminate the XML stream and the underlying TCP connection between it and
the Authoritative Server but also terminate the XML stream and the
underlying TCP connection between it and the Originating Server,
generating a stream error for the latter
stream. 9. The Receiving Server sends the Authoritative Server a
request for verification of a key:
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (April 17, 2007) is 6191 days in the past. Is this
intentional?
-- Found something which looks like a code comment -- if you have code
sections in the document, please surround them with '' and
'' lines.
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
-- Looks like a reference, but probably isn't: '43' on line 580
-- Looks like a reference, but probably isn't: '3' on line 2918
** Obsolete normative reference: RFC 4234 (ref. 'ABNF') (Obsoleted by RFC
5234)
** Obsolete normative reference: RFC 2831 (ref. 'DIGEST-MD5') (Obsoleted by
RFC 6331)
-- Possible downref: Non-RFC (?) normative reference: ref. 'HMAC'
** Obsolete normative reference: RFC 2818 (ref. 'HTTP-TLS') (Obsoleted by
RFC 9110)
** 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)
-- Possible downref: Non-RFC (?) normative reference: ref. 'SHA'
** Obsolete normative reference: RFC 3454 (ref. 'STRINGPREP') (Obsoleted by
RFC 7564)
** Obsolete normative reference: RFC 793 (ref. 'TCP') (Obsoleted by RFC
9293)
** Obsolete normative reference: RFC 4346 (ref. 'TLS') (Obsoleted by RFC
5246)
-- Possible downref: Non-RFC (?) normative reference: ref. 'UCS2'
** Obsolete normative reference: RFC 3280 (ref. 'X509') (Obsoleted by RFC
5280)
-- Possible downref: Non-RFC (?) normative reference: ref. 'XML'
-- Possible downref: Non-RFC (?) normative reference: ref. 'XML-NAMES'
-- Obsolete informational reference (is this intentional?): RFC 2616 (ref.
'HTTP') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234,
RFC 7235)
-- Obsolete informational reference (is this intentional?): RFC 3501 (ref.
'IMAP') (Obsoleted by RFC 9051)
-- Obsolete informational reference (is this intentional?): RFC 2821 (ref.
'SMTP') (Obsoleted by RFC 5321)
-- Duplicate reference: RFC1035, mentioned in 'STD13', was also mentioned
in 'DNS'.
== Outdated reference: A later version (-08) exists of
draft-saintandre-rfc3921bis-02
== Outdated reference: A later version (-01) exists of
draft-saintandre-rfc4622bis-00
Summary: 11 errors (**), 0 flaws (~~), 8 warnings (==), 20 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 XMPP Working Group P. Saint-Andre, Ed.
3 Internet-Draft XSF
4 Intended status: Standards Track April 17, 2007
5 Expires: October 19, 2007
7 Extensible Messaging and Presence Protocol (XMPP): Core
8 draft-saintandre-rfc3920bis-02
10 Status of this Memo
12 By submitting this Internet-Draft, each author represents that any
13 applicable patent or other IPR claims of which he or she is aware
14 have been or will be disclosed, and any of which he or she becomes
15 aware will be disclosed, in accordance with Section 6 of BCP 79.
17 Internet-Drafts are working documents of the Internet Engineering
18 Task Force (IETF), its areas, and its working groups. Note that
19 other groups may also distribute working documents as Internet-
20 Drafts.
22 Internet-Drafts are draft documents valid for a maximum of six months
23 and may be updated, replaced, or obsoleted by other documents at any
24 time. It is inappropriate to use Internet-Drafts as reference
25 material or to cite them other than as "work in progress."
27 The list of current Internet-Drafts can be accessed at
28 http://www.ietf.org/ietf/1id-abstracts.txt.
30 The list of Internet-Draft Shadow Directories can be accessed at
31 http://www.ietf.org/shadow.html.
33 This Internet-Draft will expire on October 19, 2007.
35 Copyright Notice
37 Copyright (C) The IETF Trust (2007).
39 Abstract
41 This memo defines the core features of the Extensible Messaging and
42 Presence Protocol (XMPP), a technology for streaming Extensible
43 Markup Language (XML) elements in order to exchange structured
44 information in close to real time between any two network-aware
45 entities. XMPP provides a generalized, extensible framework for
46 incrementally exchanging XML data, upon which a variety of
47 applications can be built. The framework includes methods for stream
48 setup and teardown, channel encryption, authentication of a client to
49 a server and of one server to another server, and primitives for
50 push-style messages, publication of presence and availability
51 information, and request-response interactions between any two XMPP
52 entities. This document also specifies the format for XMPP
53 addresses, which are fully internationalizable.
55 This document obsoletes RFC 3920.
57 Table of Contents
59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
60 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
61 1.2. Functional Summary . . . . . . . . . . . . . . . . . . . 5
62 1.3. Conventions . . . . . . . . . . . . . . . . . . . . . . 6
63 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 6
64 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
65 2.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 7
66 2.3. Client . . . . . . . . . . . . . . . . . . . . . . . . . 7
67 2.4. Network . . . . . . . . . . . . . . . . . . . . . . . . 7
68 3. Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 8
69 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 8
70 3.2. Domain Identifier . . . . . . . . . . . . . . . . . . . 9
71 3.3. Node Identifier . . . . . . . . . . . . . . . . . . . . 10
72 3.4. Resource Identifier . . . . . . . . . . . . . . . . . . 10
73 3.5. Determination of Addresses . . . . . . . . . . . . . . . 11
74 4. TCP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 11
75 5. XML Streams . . . . . . . . . . . . . . . . . . . . . . . . . 12
76 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 12
77 5.2. Stream Security . . . . . . . . . . . . . . . . . . . . 14
78 5.3. Stream Attributes . . . . . . . . . . . . . . . . . . . 15
79 5.4. Namespace Declarations . . . . . . . . . . . . . . . . . 18
80 5.5. Stream Features . . . . . . . . . . . . . . . . . . . . 18
81 5.6. Closing Streams . . . . . . . . . . . . . . . . . . . . 18
82 5.7. Reconnection . . . . . . . . . . . . . . . . . . . . . . 19
83 5.8. Stream Errors . . . . . . . . . . . . . . . . . . . . . 19
84 5.9. Simplified Stream Examples . . . . . . . . . . . . . . . 23
85 6. TLS Negotiation . . . . . . . . . . . . . . . . . . . . . . . 25
86 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 25
87 6.2. Narrative . . . . . . . . . . . . . . . . . . . . . . . 28
88 7. SASL Negotiation . . . . . . . . . . . . . . . . . . . . . . 29
89 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 29
90 7.2. Narrative . . . . . . . . . . . . . . . . . . . . . . . 31
91 7.3. SASL Definition . . . . . . . . . . . . . . . . . . . . 33
92 7.4. SASL Errors . . . . . . . . . . . . . . . . . . . . . . 34
93 8. Resource Binding . . . . . . . . . . . . . . . . . . . . . . 34
94 8.1. Binding Multiple Resources . . . . . . . . . . . . . . . 38
95 9. XML Stanzas . . . . . . . . . . . . . . . . . . . . . . . . . 39
96 9.1. Common Attributes . . . . . . . . . . . . . . . . . . . 40
97 9.2. Basic Semantics . . . . . . . . . . . . . . . . . . . . 42
98 9.3. Stanza Errors . . . . . . . . . . . . . . . . . . . . . 44
99 9.4. Extended Namespaces . . . . . . . . . . . . . . . . . . 48
100 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 49
101 10.1. Client-to-Server . . . . . . . . . . . . . . . . . . . . 49
102 10.2. Server-to-Server Examples . . . . . . . . . . . . . . . 55
103 11. Server Rules for Handling XML Stanzas . . . . . . . . . . . . 58
104 11.1. No 'to' Address . . . . . . . . . . . . . . . . . . . . 59
105 11.2. Foreign Domain . . . . . . . . . . . . . . . . . . . . . 59
106 11.3. Local Domain . . . . . . . . . . . . . . . . . . . . . . 60
107 11.4. Mere Domain or Specific Resource . . . . . . . . . . . . 60
108 11.5. Node in Same Domain . . . . . . . . . . . . . . . . . . 60
109 12. XML Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 61
110 12.1. Restrictions . . . . . . . . . . . . . . . . . . . . . . 61
111 12.2. XML Namespace Names and Prefixes . . . . . . . . . . . . 61
112 12.3. Validation . . . . . . . . . . . . . . . . . . . . . . . 63
113 12.4. Inclusion of Text Declaration . . . . . . . . . . . . . 63
114 12.5. Character Encoding . . . . . . . . . . . . . . . . . . . 63
115 12.6. White Space . . . . . . . . . . . . . . . . . . . . . . 63
116 13. Compliance Requirements . . . . . . . . . . . . . . . . . . . 63
117 13.1. Servers . . . . . . . . . . . . . . . . . . . . . . . . 64
118 13.2. Clients . . . . . . . . . . . . . . . . . . . . . . . . 64
119 14. Internationalization Considerations . . . . . . . . . . . . . 65
120 15. Security Considerations . . . . . . . . . . . . . . . . . . . 65
121 15.1. High Security . . . . . . . . . . . . . . . . . . . . . 65
122 15.2. Certificate Validation . . . . . . . . . . . . . . . . . 65
123 15.3. Client-to-Server Communications . . . . . . . . . . . . 66
124 15.4. Server-to-Server Communications . . . . . . . . . . . . 67
125 15.5. Order of Layers . . . . . . . . . . . . . . . . . . . . 67
126 15.6. Lack of SASL Channel Binding to TLS . . . . . . . . . . 68
127 15.7. Mandatory-to-Implement Technologies . . . . . . . . . . 68
128 15.8. Firewalls . . . . . . . . . . . . . . . . . . . . . . . 68
129 15.9. Use of base64 in SASL . . . . . . . . . . . . . . . . . 69
130 15.10. Stringprep Profiles . . . . . . . . . . . . . . . . . . 69
131 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 70
132 16.1. XML Namespace Name for TLS Data . . . . . . . . . . . . 70
133 16.2. XML Namespace Name for SASL Data . . . . . . . . . . . . 70
134 16.3. XML Namespace Name for Stream Errors . . . . . . . . . . 70
135 16.4. XML Namespace Name for Resource Binding . . . . . . . . 71
136 16.5. XML Namespace Name for Stanza Errors . . . . . . . . . . 71
137 16.6. Nodeprep Profile of Stringprep . . . . . . . . . . . . . 71
138 16.7. Resourceprep Profile of Stringprep . . . . . . . . . . . 72
139 16.8. GSSAPI Service Name . . . . . . . . . . . . . . . . . . 72
140 16.9. Port Numbers . . . . . . . . . . . . . . . . . . . . . . 72
141 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 72
142 17.1. Normative References . . . . . . . . . . . . . . . . . . 72
143 17.2. Informative References . . . . . . . . . . . . . . . . . 75
145 Appendix A. Nodeprep . . . . . . . . . . . . . . . . . . . . . . 77
146 A.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 77
147 A.2. Character Repertoire . . . . . . . . . . . . . . . . . . 78
148 A.3. Mapping . . . . . . . . . . . . . . . . . . . . . . . . 78
149 A.4. Normalization . . . . . . . . . . . . . . . . . . . . . 78
150 A.5. Prohibited Output . . . . . . . . . . . . . . . . . . . 78
151 A.6. Bidirectional Characters . . . . . . . . . . . . . . . . 79
152 Appendix B. Resourceprep . . . . . . . . . . . . . . . . . . . . 79
153 B.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 79
154 B.2. Character Repertoire . . . . . . . . . . . . . . . . . . 79
155 B.3. Mapping . . . . . . . . . . . . . . . . . . . . . . . . 80
156 B.4. Normalization . . . . . . . . . . . . . . . . . . . . . 80
157 B.5. Prohibited Output . . . . . . . . . . . . . . . . . . . 80
158 B.6. Bidirectional Characters . . . . . . . . . . . . . . . . 80
159 Appendix C. Server Dialback . . . . . . . . . . . . . . . . . . 80
160 C.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 80
161 C.2. Order of Events . . . . . . . . . . . . . . . . . . . . 82
162 C.3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . 82
163 C.4. Reuse of Negotiated Connections . . . . . . . . . . . . 88
164 C.5. Dialback Key Generation . . . . . . . . . . . . . . . . 89
165 C.6. Advertisement . . . . . . . . . . . . . . . . . . . . . 90
166 Appendix D. XML Schemas . . . . . . . . . . . . . . . . . . . . 92
167 D.1. Streams namespace . . . . . . . . . . . . . . . . . . . 92
168 D.2. Stream error namespace . . . . . . . . . . . . . . . . . 93
169 D.3. TLS namespace . . . . . . . . . . . . . . . . . . . . . 95
170 D.4. SASL namespace . . . . . . . . . . . . . . . . . . . . . 95
171 D.5. Resource binding namespace . . . . . . . . . . . . . . . 97
172 D.6. Dialback namespace . . . . . . . . . . . . . . . . . . . 99
173 D.7. Server dialback stream feature namespace . . . . . . . . 101
174 D.8. Stanza error namespace . . . . . . . . . . . . . . . . . 101
175 Appendix E. Contact Addresses . . . . . . . . . . . . . . . . . 103
176 Appendix F. Differences From RFC 3920 . . . . . . . . . . . . . 103
177 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 104
178 Intellectual Property and Copyright Statements . . . . . . . . . 105
180 1. Introduction
182 1.1. Overview
184 The Extensible Messaging and Presence Protocol (XMPP) is an
185 Extensible Markup Language XML [XML] technology for near-real-time
186 messaging, presence, and request-response services. The basic syntax
187 and semantics were developed originally within the Jabber open-source
188 community, mainly in 1999. In 2002, the XMPP WG was chartered with
189 developing an adaptation of the core Jabber protocol that would be
190 suitable as an IETF instant messaging (IM) and presence technology.
191 As a result of work by the XMPP WG as well as implementation
192 experience and interoperability testing completed since the
193 publication of RFC 3920, this document defines the core features of
194 XMPP 1.0; the extensions required to provide the instant messaging
195 and presence functionality defined in [IMP-REQS] are specified in
196 [XMPP-IM].
198 This document obsoletes RFC 3920.
200 1.2. Functional Summary
202 The purpose of XMPP is to enable the exchange of relatively small
203 pieces of structured data (called "XML stanzas") over a network
204 between any two (or more) entities. XMPP is implemented using a
205 client-server architecture, wherein a client must connect to a server
206 in order to gain access to the network and thus be allowed to
207 exchange XML stanzas with other entities. The process whereby a
208 client connects to a server, exchanges XML stanzas, and ends the
209 connection is as follows:
211 1. Determine the hostname and port at which to connect
212 2. Open a TCP connection
213 3. Open an XML stream
214 4. Complete TLS negotiation for channel encryption (RECOMMENDED)
215 5. Complete SASL negotiation for authentication
216 6. Bind a resource to the stream
217 7. Exchange XML stanzas with other entities on the network
218 8. Close the stream when further communications are not needed or
219 desired
220 9. Close the TCP connection.
222 In the sections following discussion of XMPP architecture and XMPP
223 addresses, this document specifies how clients connect to servers and
224 specifies the basic semantics of XML stanzas, but does not define the
225 "payloads" of the XML stanzas that might be exchanged once a
226 connection is successfully established; instead, definition of such
227 semantics is provided by various XMPP extensions (e.g., [XMPP-IM] for
228 basic instant messaging and presence applications).
230 Within the client-server architecture used by XMPP, one server may
231 optionally connect to another server to enable inter-domain or inter-
232 server communication. For this to happen, the two servers must
233 negotiate a connection between themselves and then exchange XML
234 stanzas; the process for doing so is as follows:
236 1. Determine the hostname and port at which to connect
237 2. Open a TCP connection
238 3. Open an XML stream
239 4. Complete TLS negotiation for channel encryption (RECOMMENDED)
240 5. Complete SASL negotiation for authentication
241 6. Exchange XML stanzas both directly for the servers and indirectly
242 on behalf of entities associated with each server (e.g.,
243 connected clients)
244 7. Close the stream when further communications are not needed or
245 desired
246 8. Close the TCP connection.
248 Note: Depending on local policies, a service may wish to use server
249 dialback to provide weak verification in cases where SASL negotiation
250 would not result in strong authentication (e.g., because the
251 certificate presented by the peer service during TLS negotiation is
252 self-signed and thus provides only weak identity); for details, see
253 Appendix C.
255 1.3. Conventions
257 The following keywords are to be interpreted as described in [TERMS]:
258 "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD",
259 "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".
261 In examples, lines have been wrapped for improved readability.
263 2. Architecture
265 2.1. Overview
267 XMPP assumes a client-server architecture, wherein a client utilizing
268 XMPP accesses a server (normally over a [TCP] connection) and servers
269 can also communicate with each other over TCP connections.
270 Architectures that use the syntax of XML stanzas (Section 9) but that
271 establish peer-to-peer connections directly between clients using
272 technologies based on [LINKLOCAL] have been deployed, but such
273 architectures are not XMPP and are best described as "XMPP-like"; for
274 details, see [XEP-0174].
276 An architectural diagram for a typical deployment is shown here,
277 where the entities have the following significance:
279 o romeo@example.net -- an XMPP user.
280 o example.net -- an XMPP server.
281 o juliet@example.com -- an XMPP user.
282 o example.com -- an XMPP server.
284 example.net -------------------- example.com
285 | |
286 | |
287 romeo@example.net juliet@example.com
289 2.2. Server
291 A server acts as an intelligent abstraction layer for XMPP
292 communications. Its primary responsibilities are:
294 o to manage connections from other entities, in the form of XML
295 streams (Section 5) to and from authorized clients, servers, and
296 other entities
297 o to route appropriately-addressed XML stanzas (Section 9) among
298 such entities over XML streams
300 Most XMPP-compliant servers also assume responsibility for the
301 storage of data that is used by clients (e.g., contact lists for
302 users of XMPP-based instant messaging and presence applications); in
303 this case, the XML data is processed directly by the server itself on
304 behalf of the client and is not routed to another entity.
306 2.3. Client
308 Most clients connect directly to a server over a [TCP] connection and
309 use XMPP to take full advantage of the functionality provided by a
310 server and any associated services. Multiple resources (e.g.,
311 devices or locations) MAY connect simultaneously to a server on
312 behalf of each authorized client, with each resource differentiated
313 by the resource identifier of an XMPP address (e.g.,
314 vs. ) as defined under Addresses
315 (Section 3) and Resource Binding (Section 8). The RECOMMENDED port
316 for connections between a client and a server is 5222, as registered
317 with the IANA (see Port Numbers (Section 16.9)).
319 2.4. Network
321 Because each server is identified by a network address and because
322 server-to-server communications are a straightforward extension of
323 the client-to-server protocol, in practice, the system consists of a
324 network of servers that inter-communicate. Thus, for example,
325 is able to exchange messages, presence, and
326 other information with . This pattern is familiar
327 from messaging protocols (such as [SMTP]) that make use of network
328 addressing standards. Communications between any two servers are
329 OPTIONAL. If enabled, such communications SHOULD occur over XML
330 streams that are bound to [TCP] connections. The RECOMMENDED port
331 for connections between servers is 5269, as registered with the IANA
332 (see Port Numbers (Section 16.9)).
334 3. Addresses
336 3.1. Overview
338 An entity is anything that can be considered a network endpoint
339 (i.e., an ID on the network) and that can communicate using XMPP.
340 All such entities are uniquely addressable on the network. For
341 historical reasons, the address of an XMPP entity is called a Jabber
342 Identifier or JID. A valid JID contains a set of ordered elements
343 formed of a domain identifier, node identifier, and resource
344 identifier.
346 The syntax for a JID is defined as follows using the Augmented
347 Backus-Naur Form as defined in [ABNF].
349 jid = [ node "@" ] domain [ "/" resource ]
350 node = 1*(nodepoint)
351 ; a "nodepoint" is a UTF-8 encoded Unicode code
352 ; point that satisfies the Nodeprep profile of
353 ; stringprep
354 domain = fqdn / address-literal / idnlabel
355 fqdn = (idnlabel 1*("." idnlabel))
356 ; an "idnlabel" is an internationalized label
357 ; as described in RFC 3490
358 address-literal = IPv4address / IPv6address
359 ; the "IPv4address" and "IPv6address" rules are
360 ; defined in Appendix B of RFC 3513
361 resource = 1*(resourcepoint)
362 ; a "resourcepoint" is a UTF-8 encoded Unicode
363 ; code point that satisfies the Resourceprep
364 ; profile of stringprep
366 All JIDs are based on the foregoing structure. One common use of
367 this structure is to identify a messaging and presence account, the
368 server that hosts the account, and a connected resource (e.g., a
369 specific device) in the form of . However,
370 node types other than clients are possible; for example, a specific
371 chat room offered by a multi-user chat service (see [XEP-0045]) could
372 be addressed as (where "room" is the name of the chat
373 room and "service" is the hostname of the multi-user chat service)
374 and a specific occupant of such a room could be addressed as
375 (where "nick" is the occupant's room nickname).
376 Many other JID types are possible (e.g., could be a
377 server-side script or service).
379 Each allowable portion of a JID (node identifier, domain identifier,
380 and resource identifier) MUST NOT be more than 1023 bytes in length,
381 resulting in a maximum total size (including the '@' and '/'
382 separators) of 3071 bytes.
384 Note: While the format of a JID is consistent with [URI], an entity's
385 address on an XMPP network MUST be a JID (without a URI scheme) and
386 not a [URI] or [IRI] as specified in [XMPP-URI]; the latter
387 specification is provided only for use by non-XMPP applications.
389 3.2. Domain Identifier
391 The DOMAIN IDENTIFIER is the primary identifier and is the only
392 REQUIRED element of a JID (a mere domain identifier is a valid JID).
393 It usually represents the network or "home" server to which other
394 entities connect for XML routing and data management capabilities.
395 Note that a single server may host multiple domain identifiers (local
396 domains), and that it is not necessary for domain identifiers to
397 reference entities that provide traditional server functionality
398 (e.g., a multi-user chat service or a user directory).
400 The domain identifier for every server or service that will
401 communicate over a network SHOULD be a fully qualified domain name
402 (see [DNS]) but MAY be either an IPv4 or IPv6 address or a text label
403 (commonly called an "unqualified hostname") that is resolvable on a
404 local network. If the domain identifier includes a final character
405 considered to be a label separator (dot) by [IDNA] or [STD13], this
406 character MUST be stripped from the domain identifier before the JID
407 of which it is a part is used for the purpose of routing an XML
408 stanza, comparing against another JID, or constructing an [XMPP-URI];
409 in particular, the character should be stripped before any other
410 canonicalization steps are taken (such as application of the
411 [NAMEPREP] profile of [STRINGPREP] or completion of the ToASCII
412 operation as described in [IDNA]).
414 A domain identifier MUST be an "internationalized domain name" as
415 defined in [IDNA], that is, "a domain name in which every label is an
416 internationalized label". When preparing a text label (consisting of
417 a sequence of Unicode code points) for representation as an
418 internationalized label in the process of constructing an XMPP domain
419 identifier or comparing two XMPP domain identifiers, an application
420 MUST ensure that for each text label it is possible to apply without
421 failing the ToASCII operation specified in [IDNA] with the
422 UseSTD3ASCIIRules flag set (thus forbidding ASCII code points other
423 than letters, digits, and hyphens). If the ToASCII operation can be
424 applied without failing, then the label is an internationalized
425 label. An internationalized domain name (and therefore an XMPP
426 domain identifier) is constructed from its constituent
427 internationalized labels by following the rules specified in [IDNA].
428 Note: The ToASCII operation includes application of the [NAMEPREP]
429 profile of [STRINGPREP] and encoding using the algorithm specified in
430 [PUNYCODE]; for details, see [IDNA].
432 3.3. Node Identifier
434 The NODE IDENTIFIER is an optional secondary identifier placed before
435 the domain identifier and separated from the latter by the '@'
436 character. It usually represents the entity requesting and using
437 network access provided by a server (i.e., a client), although it can
438 also represent other kinds of entities (e.g., a chat room associated
439 with a multi-user chat service). The entity represented by a node
440 identifier is addressed within the context of a specific domain;
441 within instant messaging and presence applications of XMPP, this
442 address is called a "bare JID" and is of the form .
444 A node identifier MUST be formatted such that the Nodeprep profile of
445 [STRINGPREP] can be applied without failing (see Appendix A). Before
446 comparing two node identifiers, an application MUST first apply the
447 Nodeprep profile to each identifier.
449 3.4. Resource Identifier
451 The RESOURCE IDENTIFIER is an optional tertiary identifier placed
452 after the domain identifier and separated from the latter by the '/'
453 character. A resource identifier may modify either a
454 address or a mere address. It usually represents a specific
455 connection (e.g., a device or location) or object (e.g., a
456 participant in a multi-user chat room) belonging to the entity
457 associated with a node identifier. A resource identifier is opaque
458 to both servers and other clients, and is typically defined by a
459 client implementation when it provides the information necessary to
460 complete Resource Binding (Section 8) (although it may be generated
461 by a server on behalf of a client), after which the entity is
462 referred to as a "connected resource" and its address is referrred to
463 as a "full JID" (). An entity MAY maintain
464 multiple connected resources simultaneously, with each connected
465 resource differentiated by a distinct resource identifier.
467 A resource identifier MUST be formatted such that the Resourceprep
468 profile of [STRINGPREP] can be applied without failing (see
469 Appendix B). Before comparing two resource identifiers, an
470 application MUST first apply the Resourceprep profile to each
471 identifier.
473 3.5. Determination of Addresses
475 After SASL negotiation (Section 7) and, if appropriate, Resource
476 Binding (Section 8), the receiving entity for a stream MUST determine
477 the initiating entity's JID.
479 For server-to-server communications, the initiating entity's JID
480 SHOULD be the authorization identity, derived from the authentication
481 identity, as defined by [SASL], if no authorization identity was
482 specified during SASL negotiation (Section 7).
484 For client-to-server communications, the "bare JID" ()
485 SHOULD be the authorization identity, derived from the authentication
486 identity, as defined in [SASL], if no authorization identity was
487 specified during SASL negotiation (Section 7); the resource
488 identifier portion of the "full JID" () SHOULD
489 be the resource identifier negotiated by the client and server during
490 Resource Binding (Section 8).
492 The receiving entity MUST ensure that the resulting JID (including
493 node identifier, domain identifier, resource identifier, and
494 separator characters) conforms to the rules and formats defined
495 earlier in this section; to meet this restriction, the receiving
496 entity may need to replace the JID sent by the initiating entity with
497 the canonicalized JID as determined by the receiving entity.
499 4. TCP Binding
501 Although there is no necessary coupling of an XML stream to a [TCP]
502 connection (e.g., two entities could connect to each other via
503 another transport, e.g. [HTTP] as specified in [XEP-0124] and
504 [XEP-0206]), this specification defines a binding of XMPP to TCP
505 only.
507 Therefore, as XMPP is defined herein, an initiating entity (client or
508 server) MUST open a TCP connection at the receiving entity (server)
509 before it negotiates XML streams with the receiving entity. However,
510 prior to opening the TCP connection the initiating entity first MUST
511 resolve the Domain Name System (DNS) hostname associated with the
512 receiving entity and determine the appropriate TCP port for
513 communications with the receiving entity. The process is as follows:
515 1. Attempt to resolve the hostname using a [DNS-SRV] Service of
516 "xmpp-client" (for client-to-server connections) or "xmpp-server"
517 (for server-to-server connections) and Proto of "tcp", resulting
518 in resource records such as "_xmpp-client._tcp.example.com." or
519 "_xmpp-server._tcp.example.com."; the IP address and port at
520 which the initiating entity attempts to connect to the receiving
521 entity shall be those specified in the SRV lookup result.
522 2. If the SRV lookup fails, the fallback SHOULD be a normal IPv4 or
523 [IPv6] address record resolution to determine the IP address,
524 where the port used is the "xmpp-client" port of 5222 for client-
525 to-server connectionsn or the "xmpp-server" port 5269 for client-
526 to-server connections.
527 3. However, the fallback MAY be a DNS TXT lookup (see [DNS-TXT]) for
528 alternative connection methods, for example as described in
529 [XEP-0156].
531 TCP connections are handled differently in client-to-server
532 communications and server-to-server communications. Specifically:
534 o Because a client is subordinate to a server and therefore a client
535 authenticates to the server but the server does not authenticate
536 to the client, it is necessary to have only one TCP connection
537 between client and server. Thus the server MUST allow the client
538 to share a single TCP connection for XML stanzas sent from client
539 to server and from server to client (i.e., the inital stream and
540 response stream as specified under XML Streams (Section 5)).
541 o Because two servers are peers and therefore each peers must
542 authenticate with the other, the servers MUST use two TCP
543 connections: one for XML stanzas sent from the first server to the
544 second server and another (initiated by the second server) for
545 stanzas from the second server to the first server.
547 5. XML Streams
549 5.1. Overview
551 Two fundamental concepts make possible the rapid, asynchronous
552 exchange of relatively small payloads of structured information
553 between presence-aware entities: XML streams and XML stanzas. These
554 terms are defined as follows:
556 Definition of XML Stream: An XML STREAM is a container for the
557 exchange of XML elements between any two entities over a network.
558 The start of an XML stream is denoted unambiguously by an opening
559 XML tag (with appropriate attributes and namespace
560 declarations), while the end of the XML stream is denoted
561 unambiguously by a closing XML tag. During the life of
562 the stream, the entity that initiated it can send an unbounded
563 number of XML elements over the stream, either elements used to
564 negotiate the stream (e.g., to complete TLS negotiation
565 (Section 6) or SASL negotiation (Section 7)) or XML stanzas. The
566 "initial stream" is negotiated from the initiating entity (usually
567 a client or server) to the receiving entity (usually a server),
568 and can be seen as corresponding to the initiating entity's
569 "connection" with the receiving entity. The initial stream
570 enables unidirectional communication from the initiating entity to
571 the receiving entity; in order to enable information exchange from
572 the receiving entity to the initiating entity, the receiving
573 entity MUST negotiate a stream in the opposite direction (the
574 "response stream").
575 Definition of XML Stanza: An XML STANZA is a discrete semantic unit
576 of structured information that is sent from one entity to another
577 over an XML stream, and is the basic unit of meaning in XMPP. An
578 XML stanza exists at the direct child level of the root
579 element and is said to be well-balanced if it matches the
580 production [43] content of [XML]. The start of any XML stanza is
581 denoted unambiguously by the element start tag at depth=1 of the
582 XML stream (e.g., ), and the end of any XML stanza is
583 denoted unambiguously by the corresponding close tag at depth=1
584 (e.g., ); a server MUST NOT process, deliver, or route
585 a partial stanza and MUST NOT attach meaning to the transmission
586 timing of any part of a stanza (before receipt of the close tag).
587 The only XML stanzas defined herein are the ,
588 , and elements qualified by the default namespace
589 for the stream, as described under XML Stanzas (Section 9); an XML
590 element sent for the purpose of TLS negotiation (Section 6), SASL
591 negotiation (Section 7), or server dialback (Appendix C) is not
592 considered to be an XML stanza. An XML stanza MAY contain child
593 elements (with accompanying attributes, elements, and XML
594 character data) as necessary in order to convey the desired
595 information, which MAY be qualified by any XML namespace (see
596 [XML-NAMES]).
598 Consider the example of a client's connection to a server. In order
599 to connect to a server, a client MUST initiate an XML stream by
600 sending an opening tag to the server, optionally preceded by
601 a text declaration specifying the XML version and the character
602 encoding supported (see Inclusion of Text Declaration (Section 12.4)
603 and Character Encoding (Section 12.5)). Subject to local policies
604 and service provisioning, the server SHOULD then reply with a second
605 XML stream back to the client, again optionally preceded by a text
606 declaration. Once the client has completed SASL negotiation
607 (Section 7), the client MAY send an unbounded number of XML stanzas
608 over the stream to any recipient on the network. When the client
609 desires to close the stream, it simply sends a closing tag
610 to the server; for details, see Section 5.6.
612 Those who are accustomed to thinking of XML in a document-centric
613 manner may wish to view a client's connection to a server as
614 consisting of two open-ended XML documents: one from the client to
615 the server and one from the server to the client. From this
616 perspective, the root element can be considered the
617 document entity for each "document", and the two "documents" are
618 built up through the accumulation of XML stanzas sent over the two
619 XML streams. However, this perspective is a convenience only; XMPP
620 does not deal in documents but in XML streams and XML stanzas.
622 In essence, then, an XML stream acts as an envelope for all the XML
623 stanzas sent during a connection. We can represent this in a
624 simplistic fashion as follows:
626 |--------------------|
627 | |
628 |--------------------|
629 | |
630 | |
631 | |
632 |--------------------|
633 | |
634 | |
635 | |
636 |--------------------|
637 | |
638 | |
639 | |
640 |--------------------|
641 | ... |
642 |--------------------|
643 | |
644 |--------------------|
646 5.2. Stream Security
648 When negotiating XML streams in XMPP 1.0, TLS SHOULD be used as
649 defined under TLS negotiation (Section 6) and SASL MUST be used as
650 defined under SASL negotiation (Section 7). The initial stream and
651 the response stream MUST be secured separately, although security in
652 both directions MAY be established via mechanisms that provide mutual
653 authentication. An entity SHOULD NOT attempt to send XML Stanzas
654 (Section 9) over the stream before the stream has been authenticated,
655 but if it does, then the other entity MUST NOT accept such stanzas
656 and SHOULD return a stream error and then terminate
657 both the XML stream and the underlying TCP connection; note well that
658 this applies to XML stanzas only (i.e., , , and
659 elements qualified by the default namespace) and not to XML
660 elements used for stream negotiation (e.g., elements used to complete
661 TLS negotiation (Section 6) or SASL negotiation (Section 7)).
663 5.3. Stream Attributes
665 The attributes of the stream element are as follows:
667 o from -- In client-to-server communications, the 'from' attribute
668 SHOULD be included in the XML stream header sent from the
669 initiating entity to the receiving entity and (if included) MUST
670 be set to the account name (i.e., "bare JID" = ) of
671 the entity controlling the client. In server-to-server
672 communications, the 'from' attribute SHOULD be included in the XML
673 stream header sent from the initiating entity to the receiving
674 entity and (if included) MUST be set to a hostname serviced by the
675 initiating entity. In both client-to-server and server-to-server
676 communications, the 'from' attribute MUST be included in the XML
677 stream header by which the receiving entity responds to the
678 initiating entity and MUST be set to a hostname serviced by the
679 receiving entity that is granting access to the initiating entity.
680 Note: Each entity MUST verify the identity of the other entity
681 before exchanging XML stanzas with it (see the Client-to-Server
682 Communications (Section 15.3) and Server-to-Server Communications
683 (Section 15.4) sections of this document for details).
684 o to -- In both client-to-server and server-to-server
685 communications, the 'to' attribute SHOULD be included in the XML
686 stream header sent from the initiating entity to the receiving
687 entity and (if included) MUST be set to a hostname serviced by the
688 receiving entity. In client-to-server communications, if the
689 client included a 'from' address in the initial stream header then
690 the server SHOULD include a 'to' attribute in the XML stream
691 header by which it replies to the client and (if included) MUST
692 set the 'to' attribute to the bare JID specified in the 'from'
693 attribute of the XML stream header sent from the initiating entity
694 to the receiving entity. In server-to-server communications, if
695 the initiating entity included a 'from' address in the initial
696 stream header then the receiving entity SHOULD include a 'to'
697 attribute in the XML stream header by which it replies to the
698 initiating entity and (if included) MUST set the 'to' attribute to
699 the hostname specified in the 'from' attribute of the XML stream
700 header sent from the initiating entity to the receiving entity.
701 Note: Each entity MUST verify the identity of the other entity
702 before exchanging XML stanzas with it (see the Client-to-Server
703 Communications (Section 15.3) and Server-to-Server Communications
704 (Section 15.4) sections of this document for details).
706 o id -- The 'id' attribute SHOULD be used only in the XML stream
707 header from the receiving entity to the initiating entity. This
708 attribute is a unique identifier created by the receiving entity
709 to function as a identifier for the initiating entity's streams
710 with the receiving entity, and MUST be unique within the receiving
711 application (normally a server). Note well that the stream ID may
712 be security-critical and therefore MUST be both unpredictable and
713 nonrepeating (see [RANDOM] for recommendations regarding
714 randomness for security purposes). There SHOULD NOT be an 'id'
715 attribute on the XML stream header sent from the initiating entity
716 to the receiving entity; however, if an 'id' attribute is
717 included, it SHOULD be silently ignored by the receiving entity.
718 o xml:lang -- An 'xml:lang' attribute (as defined in Section 2.12 of
719 [XML]) SHOULD be included by the initiating entity on the header
720 for the initial stream to specify the default language of any
721 human-readable XML character data it sends over that stream. If
722 the attribute is included, the receiving entity SHOULD remember
723 that value as the default for both the initial stream and the
724 response stream; if the attribute is not included, the receiving
725 entity SHOULD use a configurable default value for both streams,
726 which it MUST communicate in the header for the response stream.
727 For all stanzas sent over the initial stream, if the initiating
728 entity does not include an 'xml:lang' attribute, the receiving
729 entity SHOULD apply the default value; if the initiating entity
730 does include an 'xml:lang' attribute, the receiving entity MUST
731 NOT modify or delete it (see also xml:lang (Section 9.1.5)). The
732 value of the 'xml:lang' attribute MUST be an NMTOKEN (as defined
733 in Section 2.3 of [XML]) and MUST conform to the format defined in
734 [LANGTAGS].
735 o version -- The presence of the version attribute set to a value of
736 at least "1.0" signals support for the stream-related protocols
737 (including stream features) defined in this specification.
738 Detailed rules regarding the generation and handling of this
739 attribute are defined in the text that follows.
741 We can summarize as follows:
743 +----------+--------------------------+-------------------------+
744 | | initiating to receiving | receiving to initiating |
745 +----------+--------------------------+-------------------------+
746 | to | JID of receiver | JID of initiator |
747 | from | JID of initiator | JID of receiver |
748 | id | silently ignored | stream identifier |
749 | xml:lang | default language | default language |
750 | version | XMPP 1.0 supported | XMPP 1.0 supported |
751 +----------+--------------------------+-------------------------+
753 Note: The attributes of the root element are not prepended
754 by a 'stream:' prefix because, in accordance with Section 5.3 of XML
755 namespaces specification [XML-NAMES], the default namespace does not
756 apply to attribute names.
758 5.3.1. Version Support
760 The version of XMPP specified herein is "1.0"; in particular, this
761 encapsulates the stream-related protocols (TLS negotiation
762 (Section 6), SASL negotiation (Section 7), and Stream Errors
763 (Section 5.8)), as well as the semantics of the three defined XML
764 stanza types (, , and ). The numbering
765 scheme for XMPP versions is ".". The major and minor
766 numbers MUST be treated as separate integers and each number MAY be
767 incremented higher than a single digit. Thus, "XMPP 2.4" would be a
768 lower version than "XMPP 2.13", which in turn would be lower than
769 "XMPP 12.3". Leading zeros (e.g., "XMPP 6.01") MUST be ignored by
770 recipients and MUST NOT be sent.
772 The major version number should be incremented only if the stream and
773 stanza formats or required actions have changed so dramatically that
774 an older version entity would not be able to interoperate with a
775 newer version entity if it simply ignored the elements and attributes
776 it did not understand and took the actions specified in the older
777 specification. The minor version number indicates new capabilities,
778 and MUST be ignored by an entity with a smaller minor version number,
779 but used for informational purposes by the entity with the larger
780 minor version number. For example, a minor version number might
781 indicate the ability to process a newly defined value of the 'type'
782 attribute for message, presence, or IQ stanzas; the entity with the
783 larger minor version number would simply note that its correspondent
784 would not be able to understand that value of the 'type' attribute
785 and therefore would not send it.
787 The following rules apply to the generation and handling of the
788 'version' attribute within stream headers by implementations:
790 1. The initiating entity MUST set the value of the 'version'
791 attribute on the initial stream header to the highest version
792 number it supports (e.g., if the highest version number it
793 supports is that defined in this specification, it MUST set the
794 value to "1.0").
795 2. The receiving entity MUST set the value of the 'version'
796 attribute on the response stream header to either the value
797 supplied by the initiating entity or the highest version number
798 supported by the receiving entity, whichever is lower. The
799 receiving entity MUST perform a numeric comparison on the major
800 and minor version numbers, not a string match on
801 ".".
803 3. If the version number included in the response stream header is
804 at least one major version lower than the version number included
805 in the initial stream header and newer version entities cannot
806 interoperate with older version entities as described above, the
807 initiating entity SHOULD generate an
808 stream error and terminate the XML stream and underlying TCP
809 connection.
810 4. If either entity receives a stream header with no 'version'
811 attribute, the entity MUST consider the version supported by the
812 other entity to be "0.9" and SHOULD NOT include a 'version'
813 attribute in the stream header it sends in reply.
815 5.4. Namespace Declarations
817 The stream element MUST possess both a streams namespace declaration
818 and a default namespace declaration (as "namespace declaration" is
819 defined in the [XML-NAMES]). For detailed information regarding the
820 streams namespace and default namespace, see Namespace Names and
821 Prefixes (Section 12.2).
823 5.5. Stream Features
825 If the initiating entity includes the 'version' attribute set to a
826 value of at least "1.0" in the initial stream header, the receiving
827 entity MUST send a child element (prefixed by the streams
828 namespace prefix) to the initiating entity in order to announce any
829 stream-level features that can be negotiated (or capabilities that
830 otherwise need to be advertised). Currently, this is used only to
831 advertise TLS negotiation (Section 6), SASL negotiation (Section 7),
832 resource binding (Section 8), and server dialback (Appendix C) as
833 defined herein; however, the stream features functionality can be
834 used to advertise other negotiable features as well. If an entity
835 does not understand or support some features, it SHOULD silently
836 ignore them. If one or more security features (e.g., TLS and SASL)
837 need to be successfully negotiated before a non-security-related
838 feature (e.g., Resource Binding) can be offered, the non-security-
839 related feature SHOULD NOT be included in the stream features that
840 are advertised before the relevant security features have been
841 negotiated. If a feature must be negotiated before the initiating
842 entity may proceed, that feature SHOULD include a child
843 element.
845 5.6. Closing Streams
847 At any time after XML streams have been negotiated between two
848 entities, either entity MAY close its stream to the other entity
849 (even in the absence of a stream error) by sending a closing stream
850 tag:
852
854 The entity that sends the closing stream tag SHOULD wait for the
855 other entity to also close its stream:
857
859 However, the entity that sends the first closing stream tag MAY
860 consider both streams to be void if the other entity does not send
861 its closing stream tag within a reasonable amount of time (where the
862 definition of "reasonable" is up to the implementation or
863 deployment).
865 After an entity sends a closing stream tag, it MUST NOT send further
866 data over that stream.
868 After the entity that sent the first closing stream tag receives a
869 reciprocal closing stream tag from the other entity, it MUST
870 terminate the underlying TCP connection.
872 5.7. Reconnection
874 It can happen that an XMPP server goes offline while servicing
875 connections from clients and from other servers. Because the number
876 of such connections can be quite large, the reconnection algorithm
877 employed by entities that seek to reconnect can have a significant
878 impact on software and network performance. The following guidelines
879 are RECOMMENDED:
881 o The time to live (TTL) specified in Domain Name System records
882 SHOULD be honored, even if DNS results are cached; if the TTL has
883 not expired, an entity that seeks to reconnect SHOULD NOT re-
884 resolve DNS before reconnecting.
885 o The time that expires before an entity first seeks to reconnect
886 SHOULD be randomized (e.g., so that all clients do not attempt to
887 reconnect 30 seconds after being disconnected).
888 o If the first reconnection attempt does not succeed, an entity
889 SHOULD back off exponentially on the time between subsequent
890 reconnection attempts.
892 5.8. Stream Errors
894 The root stream element MAY contain an child element that is
895 prefixed by the streams namespace prefix. The error child MUST be
896 sent by a compliant entity (usually a server rather than a client) if
897 it perceives that a stream-level error has occurred.
899 5.8.1. Rules
901 The following rules apply to stream-level errors:
903 o It is assumed that all stream-level errors are unrecoverable;
904 therefore, if an error occurs at the level of the stream, the
905 entity that detects the error MUST send a stream error to the
906 other entity, send a closing tag, and terminate the
907 underlying TCP connection.
908 o If the error occurs while the stream is being set up, the
909 receiving entity MUST still send the opening tag, include
910 the element as a child of the stream element, send the
911 closing tag, and terminate the underlying TCP
912 connection. In this case, if the initiating entity provides an
913 unknown host in the 'to' attribute (or provides no 'to' attribute
914 at all), the server SHOULD provide the server's authoritative
915 hostname in the 'from' attribute of the stream header sent before
916 termination.
918 5.8.2. Syntax
920 The syntax for stream errors is as follows:
922
923
924 [
926 OPTIONAL descriptive text
927 ]
928 [OPTIONAL application-specific condition element]
929
931 The element:
933 o MUST contain a child element corresponding to one of the defined
934 stanza error conditions defined in the text that follows; this
935 element MUST be qualified by the
936 'urn:ietf:params:xml:ns:xmpp-streams' namespace
937 o MAY contain a child containing XML character data that
938 describes the error in more detail; this element MUST be qualified
939 by the 'urn:ietf:params:xml:ns:xmpp-streams' namespace and SHOULD
940 possess an 'xml:lang' attribute specifying the natural language of
941 the XML character data
942 o MAY contain a child element for an application-specific error
943 condition; this element MUST be qualified by an application-
944 defined namespace, and its structure is defined by that namespace
946 The element is OPTIONAL. If included, it SHOULD be used only
947 to provide descriptive or diagnostic information that supplements the
948 meaning of a defined condition or application-specific condition. It
949 SHOULD NOT be interpreted programmatically by an application. It
950 SHOULD NOT be used as the error message presented to a user, but MAY
951 be shown in addition to the error message associated with the
952 included condition element (or elements).
954 5.8.3. Defined Conditions
956 The following stream-level error conditions are defined:
958 o -- the entity has sent XML that cannot be processed;
959 this error MAY be used instead of the more specific XML-related
960 errors, such as , ,
961 , , and , although the more specific errors are preferred.
963 o -- the entity has sent a namespace prefix
964 that is unsupported, or has sent no namespace prefix on an element
965 that requires such a prefix (see XML Namespace Names and Prefixes
966 (Section 12.2)).
967 o -- the server is closing the active stream for this
968 entity because a new stream has been initiated that conflicts with
969 the existing stream.
970 o -- the entity has not generated any traffic
971 over the stream for some period of time (configurable according to
972 a local service policy).
973 o -- the value of the 'to' attribute provided by the
974 initiating entity in the stream header corresponds to a hostname
975 that is no longer hosted by the server.
976 o -- the value of the 'to' attribute provided by the
977 initiating entity in the stream header does not correspond to a
978 hostname that is hosted by the server.
979 o -- a stanza sent between two servers lacks
980 a 'to' or 'from' attribute (or the attribute has no value).
981 o -- the server has experienced a
982 misconfiguration or an otherwise-undefined internal error that
983 prevents it from servicing the stream.
984 o -- the JID or hostname provided in a 'from'
985 address does not match an authorized JID or validated domain
986 negotiated between servers via SASL or dialback, or between a
987 client and a server via authentication and resource binding.
988 o -- the stream ID or dialback ID is invalid or does
989 not match an ID previously provided.
990 o -- the streams namespace name is something
991 other than "http://etherx.jabber.org/streams" or the dialback
992 namespace name is something other than "jabber:server:dialback"
993 (see XML Namespace Names and Prefixes (Section 12.2)).
995 o -- the entity has sent invalid XML over the stream
996 to a server that performs validation (see Validation
997 (Section 12.3)).
998 o -- the entity has attempted to send XML stanzas
999 before the stream has been authenticated, or otherwise is not
1000 authorized to perform an action related to stream negotiation; the
1001 receiving entity MUST NOT process the offending stanza before
1002 sending the stream error.
1003 o -- the entity has violated some local service
1004 policy (e.g., the entity is on a provisioned blacklist); the
1005 server MAY choose to specify the policy in the element or
1006 an application-specific condition element.
1007 o -- the server is unable to properly
1008 connect to a remote entity that is required for authentication or
1009 authorization.
1010 o -- the server lacks the system resources
1011 necessary to service the stream.
1012 o -- the entity has attempted to send restricted
1013 XML features such as a comment, processing instruction, DTD,
1014 entity reference, or unescaped character (see Restrictions
1015 (Section 12.1)).
1016 o -- the server will not provide service to the
1017 initiating entity but is redirecting traffic to another host; the
1018 XML character data of the element returned by
1019 the server SHOULD specify the alternate hostname or IP address at
1020 which to connect, which SHOULD be a valid domain identifier but
1021 may also include a port number; if no port is specified, the
1022 initiating entity SHOULD perform a [DNS-SRV] lookup on the
1023 provided domain identifier but MAY assume that it can connect to
1024 that domain identifier at the standard XMPP ports (5222 for
1025 client-to-server connections and 5269 for server-to-server
1026 connections).
1027 o -- the server is being shut down and all active
1028 streams are being closed.
1029 o -- the error condition is not one of those
1030 defined by the other conditions in this list; this error condition
1031 SHOULD be used only in conjunction with an application-specific
1032 condition.
1033 o -- the initiating entity has encoded the
1034 stream in an encoding that is not supported by the server (see
1035 Character Encoding (Section 12.5)).
1036 o -- the initiating entity has sent a
1037 first-level child of the stream that is not supported by the
1038 server.
1039 o -- the value of the 'version' attribute
1040 provided by the initiating entity in the stream header specifies a
1041 version of XMPP that is not supported by the server; the server
1042 MAY specify the version(s) it supports in the element.
1044 o -- the initiating entity has sent XML that
1045 is not well-formed as defined by [XML].
1047 5.8.4. Application-Specific Conditions
1049 As noted, an application MAY provide application-specific stream
1050 error information by including a properly-namespaced child in the
1051 error element. The application-specific element SHOULD supplement or
1052 further qualify a defined element. Thus the element will
1053 contain two or three child elements:
1055
1056
1058
1059 Some special application diagnostic information!
1060
1061
1062
1063
1065 5.9. Simplified Stream Examples
1067 This section contains two simplified examples of a stream-based
1068 connection of a client on a server (where the "C" lines are sent from
1069 the client to the server, and the "S" lines are sent from the server
1070 to the client); these examples are included for the purpose of
1071 illustrating the concepts introduced thus far.
1073 A basic connection:
1075 C:
1076
1083 S:
1084
1092 ... encryption, authentication, and resource binding ...
1093 C:
1096 C: Art thou not Romeo, and a Montague?
1097 C:
1098 S:
1101 S: Neither, fair saint, if either thee dislike.
1102 S:
1103 C:
1104 S:
1105 A connection gone bad:
1107 C:
1108
1115 S:
1116
1124 ... encryption, authentication, and resource binding ...
1125 C:
1126 Bad XML, no closing body tag!
1127
1128 S:
1129
1131
1132 S:
1134 More detailed examples are provided under Section 10.
1136 6. TLS Negotiation
1138 6.1. Overview
1140 XMPP includes a method for securing the stream from tampering and
1141 eavesdropping. This channel encryption method makes use of the
1142 Transport Layer Security (TLS) protocol [TLS], along with a
1143 "STARTTLS" extension that is modelled after similar extensions for
1144 the [IMAP], [POP3], and [ACAP] protocols as described in [USINGTLS].
1145 The namespace name for the STARTTLS extension is
1146 'urn:ietf:params:xml:ns:xmpp-tls'.
1148 An administrator of a given domain MAY require the use of TLS for
1149 client-to-server communications, server-to-server communications, or
1150 both. Clients SHOULD use TLS to secure the streams prior to
1151 attempting the completion of SASL negotiation (Section 7), and
1152 servers SHOULD use TLS between two domains for the purpose of
1153 securing server-to-server communications.
1155 The following rules apply:
1157 1. An initiating entity that complies with this specification MUST
1158 include the 'version' attribute set to a value of "1.0" in the
1159 initial stream header.
1160 2. If the TLS negotiation occurs between two servers,
1161 communications MUST NOT proceed until the Domain Name System
1162 (DNS) hostnames asserted by the servers have been resolved (see
1163 Server-to-Server Communications (Section 15.4)).
1164 3. When a receiving entity that complies with this specification
1165 receives an initial stream header that includes the 'version'
1166 attribute set to a value of at least "1.0", after sending a
1167 stream header in reply (including the version flag), it MUST
1168 include a element (qualified by the
1169 'urn:ietf:params:xml:ns:xmpp-tls' namespace) along with the list
1170 of other stream features it supports.
1171 4. If the initiating entity chooses to use TLS, TLS negotiation
1172 MUST be completed before proceeding to SASL negotiation; this
1173 order of negotiation is required to help safeguard
1174 authentication information sent during SASL negotiation, as well
1175 as to make it possible to base the use of the SASL EXTERNAL
1176 mechanism on a certificate provided during prior TLS
1177 negotiation.
1178 5. During TLS negotiation, an entity MUST NOT send any white space
1179 characters (matching production [3] content of [XML]) within the
1180 root stream element as separators between elements (any white
1181 space characters shown in the TLS examples that follow are
1182 included for the sake of readability only); this prohibition
1183 helps to ensure proper security layer byte precision.
1184 6. The receiving entity MUST consider the TLS negotiation to have
1185 begun immediately after sending the closing ">" character of the
1186 element to the initiating entity. The initiating
1187 entity MUST consider the TLS negotiation to have begun
1188 immediately after receiving the closing ">" character of the
1189 element from the receiving entity.
1190 7. The initiating entity MUST validate the certificate presented by
1191 the receiving entity; see Certificate Validation (Section 15.2)
1192 regarding certificate validation procedures.
1193 8. Certificates MUST be checked against the hostname as provided by
1194 the initiating entity (e.g., a user), not the hostname as
1195 resolved via the Domain Name System; e.g., if the user specifies
1196 a hostname of "example.net" but a [DNS-SRV] lookup returned
1197 "im.example.net", the certificate MUST be checked as
1198 "example.net". If a JID for an XMPP client (e.g., an end user
1199 account) is represented in a certificate, it MUST be represented
1200 as a UTF8String within an otherName entity inside the
1201 subjectAltName, using the [ASN.1] Object Identifier "id-on-
1202 xmppAddr" specified in Section 6.1.1 of this document. If a JID
1203 for an XMPP server is represented in a certificate, it SHOULD be
1204 represented as a UTF8String within an otherName entity inside
1205 the subjectAltName, using the [ASN.1] Object Identifier "id-on-
1206 xmppAddr" specified in Section 6.1.1 of this document; however,
1207 the JID for an XMPP server MAY also or instead be represented as
1208 a subjectAltName extension of type dNSName, where the dNSName
1209 may contain the wildcard character '*', which applies only to
1210 the left-most domain name component or component fragment and is
1211 considered to match any single component or component fragment
1212 (e.g., *.example.com matches foo.example.com but not
1213 bar.foo.example.com, and im*.example.net matches im1.example.net
1214 and im2.example.net but not chat.example.net).
1215 9. If the TLS negotiation is successful, the initiating entity MUST
1216 send a new stream header to the receiving entity.
1217 10. If the TLS negotiation is successful, the receiving entity MUST
1218 discard any knowledge obtained in an insecure manner from the
1219 initiating entity before TLS takes effect.
1220 11. If the TLS negotiation is successful, the initiating entity MUST
1221 discard any knowledge obtained in an insecure manner from the
1222 receiving entity before TLS takes effect.
1223 12. If the TLS negotiation is successful, the receiving entity MUST
1224 NOT offer the STARTTLS extension to the initiating entity along
1225 with the other stream features that are offered after the new
1226 stream header is received and responded to.
1227 13. If the TLS negotiation is successful, the initiating entity MUST
1228 continue with SASL negotiation.
1229 14. If the TLS negotiation results in failure, the receiving entity
1230 MUST terminate both the XML stream and the underlying TCP
1231 connection.
1232 15. See Mandatory-to-Implement Technologies (Section 15.7) regarding
1233 mechanisms that MUST be supported.
1235 6.1.1. ASN.1 Object Identifier for XMPP Address
1237 The [ASN.1] Object Identifier "id-on-xmppAddr" described above is
1238 defined as follows:
1240 id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
1241 dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
1243 id-on OBJECT IDENTIFIER ::= { id-pkix 8 } -- other name forms
1245 id-on-xmppAddr OBJECT IDENTIFIER ::= { id-on 5 }
1247 XmppAddr ::= UTF8String
1248 This Object Identifier MAY also be represented in dotted display
1249 format (i.e., "1.3.6.1.5.5.7.8.5") or in the Uniform Resource Name
1250 notation specified in [URN-OID] (i.e., "urn:oid:1.3.6.1.5.5.7.8.5").
1252 Thus for example the JID "example.com" as included in a certificate
1253 might be formatted as "subjectAltName=otherName:
1254 1.3.6.1.5.5.7.8.5;UTF8:example.com".
1256 6.2. Narrative
1258 When an initiating entity secures a stream with a receiving entity
1259 using TLS, the steps involved are as follows:
1261 1. The initiating entity opens a TCP connection and initiates the
1262 stream by sending the opening XML stream header to the receiving
1263 entity, including the 'version' attribute set to a value of at
1264 least "1.0".
1265 2. The receiving entity responds by opening a TCP connection and
1266 sending an XML stream header to the initiating entity, including
1267 the 'version' attribute set to a value of at least "1.0".
1268 3. The receiving entity offers the STARTTLS extension to the
1269 initiating entity by including it with the list of other
1270 supported stream features (if successful TLS negotiation is
1271 required for interaction with the receiving entity, it SHOULD
1272 signal that fact by including a element as a child of
1273 the element); the receiving entity SHOULD also
1274 include a list of supported SASL mechanisms in the stream
1275 features.
1276 4. The initiating entity issues the STARTTLS command (i.e., a
1277 element qualified by the
1278 'urn:ietf:params:xml:ns:xmpp-tls' namespace) to instruct the
1279 receiving entity that it wishes to begin a TLS negotiation to
1280 secure the stream.
1281 5. The receiving entity MUST reply with either a element
1282 or a element qualified by the
1283 'urn:ietf:params:xml:ns:xmpp-tls' namespace. If the failure case
1284 occurs, the receiving entity MUST terminate both the XML stream
1285 and the underlying TCP connection (failure cases include when the
1286 initiating entity sends a malformed STARTTLS command, when the
1287 receiving entity does not offer TLS negotiation either
1288 temporarily or permanently, and when the receiving entity cannot
1289 complete TLS negotiation because of an internal error). If the
1290 proceed case occurs, the entities MUST attempt to complete the
1291 TLS negotiation over the TCP connection and MUST NOT send any
1292 further XML data until the TLS negotiation is complete.
1293 6. The initiating entity and receiving entity attempt to complete a
1294 TLS negotiation in accordance with [TLS].
1296 7. If the TLS negotiation is unsuccessful, the receiving entity MUST
1297 terminate the TCP connection. If the TLS negotiation is
1298 successful, the initiating entity MUST initiate a new stream by
1299 sending an opening XML stream header to the receiving entity (it
1300 is not necessary to send a closing tag first, since the
1301 receiving entity and initiating entity MUST consider the original
1302 stream to be closed upon successful TLS negotiation).
1303 8. Upon receiving the new stream header from the initiating entity,
1304 the receiving entity MUST respond by sending a new XML stream
1305 header to the initiating entity along with the available features
1306 (but not including the STARTTLS feature) and SHOULD include an
1307 updated list of SASL mechanisms so that the initiating entity can
1308 detect any changes to the list of SASL mechanisms supported by
1309 the receiving entity.
1311 Examples of TLS negotiation are provided under Section 10.
1313 7. SASL Negotiation
1315 7.1. Overview
1317 XMPP includes a method for authenticating a stream by means of an
1318 XMPP-specific profile of the Simple Authentication and Security Layer
1319 protocol (see [SASL]). SASL provides a generalized method for adding
1320 authentication support to connection-based protocols, and XMPP uses a
1321 generic XML namespace profile for SASL that conforms to the profiling
1322 requirements of [SASL].
1324 The following rules apply:
1326 1. If the SASL negotiation occurs between two servers,
1327 communications MUST NOT proceed until the Domain Name System
1328 (DNS) hostnames asserted by the servers have been resolved (see
1329 Server-to-Server Communications (Section 15.4)).
1330 2. If the initiating entity is capable of SASL negotiation, it MUST
1331 include the 'version' attribute set to a value of at least "1.0"
1332 in the initial stream header.
1333 3. If the receiving entity is capable of SASL negotiation, it MUST
1334 advertise one or more authentication mechanisms within a
1335 element qualified by the
1336 'urn:ietf:params:xml:ns:xmpp-sasl' namespace in reply to the
1337 opening stream tag received from the initiating entity (if the
1338 opening stream tag included the 'version' attribute set to a
1339 value of at least "1.0").
1340 4. During SASL negotiation, an entity MUST NOT send any white space
1341 characters (matching production [3] content of [XML]) within the
1342 root stream element as separators between elements (any white
1343 space characters shown in the SASL examples that follow are
1344 included for the sake of readability only); this prohibition
1345 helps to ensure proper security layer byte precision.
1346 5. Any XML character data contained within the XML elements used
1347 during SASL negotiation MUST be encoded using base64, where the
1348 encoding adheres to the definition in Section 4 of RFC 3548
1349 [BASE64].
1350 6. If the receiving entity does not include a 'realm' value, the
1351 initiating entity must default it to the domain identifier
1352 portion of the receiving entity's JID.
1353 7. If provision of a "simple username" is supported by the selected
1354 SASL mechanism (e.g., this is supported by the DIGEST-MD5 and
1355 CRAM-MD5 mechanisms but not by the EXTERNAL and GSSAPI
1356 mechanisms), during authentication the initiating entity SHOULD
1357 provide as the simple username its sending domain (IP address or
1358 fully qualified domain name as contained in a domain identifier)
1359 in the case of server-to-server communications or its registered
1360 account name (user or node name as contained in an XMPP node
1361 identifier) in the case of client-to-server communications. In
1362 either case, the initiating entity MUST ensure that the username
1363 adheres to the [NAMEPREP] or Nodeprep (Appendix A) profile of
1364 [STRINGPREP] (as appropriate) before sending it to the receiving
1365 entity. (Note: Account provisioning is out of scope for this
1366 specification; possible methods for account provisioning include
1367 account creation by a server administrator and in-band account
1368 registration using the 'jabber:iq:register' namespace as
1369 documented in [XEP-0077].)
1370 8. If the initiating entity wishes to act on behalf of another
1371 entity and the selected SASL mechanism supports transmission of
1372 an authorization identity, the initiating entity MUST provide an
1373 authorization identity during SASL negotiation. If the
1374 initiating entity does not wish to act on behalf of another
1375 entity, it MUST NOT provide an authorization identity. As
1376 specified in [SASL], the initiating entity MUST NOT provide an
1377 authorization identity unless the authorization identity is
1378 different from the default authorization identity derived from
1379 the authentication identity. If provided, the value of the
1380 authorization identity MUST be of the form (i.e., a
1381 domain identifier only) for servers and of the form
1382 (i.e., node identifier and domain identifier) for
1383 clients.
1384 9. If the SASL negotiation is successful, the initiating entity
1385 MUST send a new stream header to the receiving entity.
1386 10. Upon successful SASL negotiation that involves negotiation of a
1387 security layer, the receiving entity MUST discard any knowledge
1388 obtained from the initiating entity which was not obtained from
1389 the SASL negotiation itself; the receiving entity SHOULD also
1390 send new stream features (including an updated list of SASL
1391 mechanisms) so that the initiating entity can detect any changes
1392 to the list of mechanisms supported by the receiving entity.
1393 11. Upon successful SASL negotiation that involves negotiation of a
1394 security layer, the initiating entity MUST discard any knowledge
1395 obtained from the receiving entity which was not obtained from
1396 the SASL negotiation itself.
1397 12. See Mandatory-to-Implement Technologies (Section 15.7) regarding
1398 mechanisms that MUST be supported; naturally, other SASL
1399 mechanisms MAY be supported as well (best practices for the use
1400 of several SASL mechanisms in the context of XMPP are described
1401 in [XEP-0175] and [XEP-0178]).
1403 7.2. Narrative
1405 When an initiating entity authenticates with a receiving entity using
1406 SASL, the steps involved are as follows:
1408 1. The initiating entity requests SASL authentication by including
1409 the 'version' attribute in the opening XML stream header sent to
1410 the receiving entity, with the value set to "1.0".
1411 2. After sending an XML stream header in reply, the receiving entity
1412 advertises a list of available SASL authentication mechanisms as
1413 stream features; each of these is a element included
1414 as a child within a container element qualified by
1415 the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace, which in turn
1416 is a child of a element in the streams namespace. If
1417 TLS negotiation (Section 6) needs to be completed before a
1418 particular authentication mechanism may be used, the receiving
1419 entity MUST NOT provide that mechanism in the list of available
1420 SASL authentication mechanisms prior to TLS negotiation. If the
1421 initiating entity presents a valid certificate during prior TLS
1422 negotiation, the receiving entity SHOULD offer the SASL EXTERNAL
1423 mechanism to the initiating entity during SASL negotiation (refer
1424 to [SASL]), although the EXTERNAL mechanism MAY be offered under
1425 other circumstances as well. If successful SASL negotiation is
1426 required for interaction with the receiving entity, it SHOULD
1427 signal that fact by including a element as a child of
1428 the element.
1429 3. The initiating entity selects a mechanism by sending an
1430 element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl'
1431 namespace to the receiving entity and including an appropriate
1432 value for the 'mechanism' attribute. This element MAY contain
1433 XML character data (in SASL terminology, the "initial response")
1434 if the mechanism supports or requires it; if the initiating
1435 entity needs to send a zero-length initial response, it MUST
1436 transmit the response as a single equals sign ("="), which
1437 indicates that the response is present but contains no data.
1439 4. If necessary, the receiving entity challenges the initiating
1440 entity by sending to the initiating entity a element
1441 qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace;
1442 this element MAY contain XML character data (which MUST be
1443 computed in accordance with the definition of the SASL mechanism
1444 chosen by the initiating entity).
1445 5. The initiating entity responds to the challenge by sending to the
1446 receiving entity a element qualified by the
1447 'urn:ietf:params:xml:ns:xmpp-sasl' namespace; this element MAY
1448 contain XML character data (which MUST be computed in accordance
1449 with the definition of the SASL mechanism chosen by the
1450 initiating entity).
1451 6. If necessary, the receiving entity sends more challenges and the
1452 initiating entity sends more responses.
1454 This series of challenge/response pairs continues until one of three
1455 things happens:
1457 1. The initiating entity aborts the handshake by sending an
1458 element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl'
1459 namespace to the receiving entity. Upon receiving an
1460 element, the receiving entity SHOULD allow a configurable but
1461 reasonable number of retries (at least 2 and no more than 5),
1462 after which it MUST terminate the TCP connection; this enables
1463 the initiating entity (e.g., an end-user client) to tolerate
1464 incorrectly-provided credentials (e.g., a mistyped password)
1465 without being forced to reconnect.
1466 2. The receiving entity reports failure of the handshake by sending
1467 a element qualified by the
1468 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating
1469 entity (the particular cause of failure SHOULD be communicated in
1470 an appropriate child element of the element as defined
1471 under SASL Errors (Section 7.4)). If the failure case occurs,
1472 the receiving entity SHOULD allow a configurable but reasonable
1473 number of retries (at least 2), after which it MUST terminate the
1474 TCP connection; this enables the initiating entity (e.g., an end-
1475 user client) to tolerate incorrectly-provided credentials (e.g.,
1476 a mistyped password) without being forced to reconnect.
1477 3. The receiving entity reports success of the handshake by sending
1478 a element qualified by the
1479 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating
1480 entity; this element MAY contain XML character data (in SASL
1481 terminology, "additional data with success") if required by the
1482 chosen SASL mechanism; if the receiving entity needs to send
1483 additional data of zero length, it MUST transmit the data as a
1484 single equals sign ("="). Upon receiving the element,
1485 the initiating entity MUST initiate a new stream by sending an
1486 opening XML stream header to the receiving entity (it is not
1487 necessary to send a closing tag first, since the
1488 receiving entity and initiating entity MUST consider the original
1489 stream to be closed upon sending or receiving the
1490 element). Upon receiving the new stream header from the
1491 initiating entity, the receiving entity MUST respond by sending a
1492 new XML stream header to the initiating entity, along with any
1493 available features or an empty element (to signify
1494 that no additional features are available); any such additional
1495 features not defined herein MUST be defined by the relevant
1496 extension to XMPP. As noted, if SASL negotiation involved
1497 establishment of a security layer, the receiving entity SHOULD
1498 send an updated list of SASL mechanisms so that the initiating
1499 entity can detect any changes to the list of mechanisms supported
1500 by the receiving entity.
1502 7.3. SASL Definition
1504 The profiling requirements of [SASL] require that the following
1505 information be supplied by a protocol definition:
1507 service name: "xmpp"
1508 initiation sequence: After the initiating entity provides an opening
1509 XML stream header and the receiving entity replies in kind, the
1510 receiving entity provides a list of acceptable authentication
1511 methods. The initiating entity chooses one method from the list
1512 and sends it to the receiving entity as the value of the
1513 'mechanism' attribute possessed by an element, optionally
1514 including an initial response to avoid a round trip.
1515 exchange sequence: Challenges and responses are carried through the
1516 exchange of elements from receiving entity to
1517 initiating entity and elements from initiating entity
1518 to receiving entity. The receiving entity reports failure by
1519 sending a element and success by sending a
1520 element; the initiating entity aborts the exchange by sending an
1521 element. Upon successful negotiation, both sides
1522 consider the original XML stream to be closed and new stream
1523 headers are sent by both entities.
1524 security layer negotiation: The security layer takes effect
1525 immediately after sending the closing ">" character of the
1526 element for the receiving entity, and immediately after
1527 receiving the closing ">" character of the element for
1528 the initiating entity. The order of layers is first [TCP], then
1529 [TLS], then [SASL], then XMPP.
1530 use of the authorization identity: The authorization identity may be
1531 used by xmpp to denote the non-default of a client
1532 or the sending of a server; an empty string is equivalent
1533 to an absent authorization identity.
1535 7.4. SASL Errors
1537 The following SASL-related error conditions are defined:
1539 o -- The receiving entity acknowledges an
1540 element sent by the initiating entity; sent in reply to the
1541 element.
1542 o -- The data provided by the initiating
1543 entity could not be processed because the [BASE64] encoding is
1544 incorrect (e.g., because the encoding does not adhere to the
1545 definition in Section 4 of [BASE64]); sent in reply to a
1546 element or an element with initial response
1547 data.
1548 o -- The authzid provided by the initiating
1549 entity is invalid, either because it is incorrectly formatted or
1550 because the initiating entity does not have permissions to
1551 authorize that ID; sent in reply to a element or an
1552 element with initial response data.
1553 o -- The initiating entity did not provide a
1554 mechanism or requested a mechanism that is not supported by the
1555 receiving entity; sent in reply to an element.
1556 o -- The challenge or response is malformed
1557 (e.g., the element includes an initial response but the
1558 mechanism does not allow that); sent in reply to an ,
1559 , , or element.
1560 o -- The mechanism requested by the initiating
1561 entity is weaker than server policy permits for that initiating
1562 entity; sent in reply to a element or an
1563 element with initial response data.
1564 o -- The authentication failed because the
1565 initiating entity did not provide proper credentials (this
1566 includes but is not limited to the case of an unknown username,
1567 and no differentiation is made between an unknown username and
1568 incorrect credentials); sent in reply to a element or
1569 an element with initial response data.
1570 o -- The authentication failed because of
1571 a temporary error condition within the receiving entity, and the
1572 initiating entity should try again later; sent in reply to an
1573 element or element.
1575 Examples of SASL negotiation are provided under Section 10.
1577 8. Resource Binding
1579 After a client authenticates with a server, it MUST bind a specific
1580 resource to the stream so that the server can properly address the
1581 client (see addresses (Section 3)) and route XML stanzas to and from
1582 the client (see stanza delivery rules (Section 11)). That is, there
1583 MUST be a resource identifier associated with the "bare JID"
1584 () of the client; this ensures that the address for use
1585 over that stream is a "full JID" of the form .
1586 After binding a resource to the stream, the client is referred to as
1587 a CONNECTED RESOURCE.
1589 Upon receiving a success indication within the SASL negotiation, the
1590 client MUST send a new stream header to the server, to which the
1591 server MUST respond with a stream header as well as a list of
1592 available stream features. Specifically, if the server requires the
1593 client to bind a resource to the stream after successful SASL
1594 negotiation, it MUST include a element qualified by the
1595 'urn:ietf:params:xml:ns:xmpp-bind' namespace in the stream features
1596 list it presents to the client upon sending the header for the
1597 response stream sent after successful SASL negotiation (but not
1598 before); this element SHOULD include an empty
1599 element as well.
1601 Server advertises resource binding feature to client:
1603
1611
1612
1613
1614
1615
1617 Upon being so informed that resource binding is required, the client
1618 MUST bind a resource to the stream by sending to the server an IQ
1619 stanza of type "set" (see IQ Semantics (Section 9.2.3)) containing
1620 data qualified by the 'urn:ietf:params:xml:ns:xmpp-bind' namespace.
1622 If the client wishes to allow the server to generate the resource
1623 identifier on its behalf, it sends an IQ stanza of type "set" that
1624 contains an empty element.
1626 Client asks server to bind a resource:
1628
1629
1630
1632 A server that supports resource binding MUST be able to generate a
1633 resource identifier on behalf of a client. A resource identifier
1634 generated by the server MUST be currently unique for that
1635 .
1637 If the client wishes to specify the resource identifier, it MUST send
1638 an IQ stanza of type "set" that contains the desired resource
1639 identifier as the non-zero-length XML character data of a
1640 element that is a child of the element.
1642 Client binds a resource:
1644
1645
1646 balcony
1647
1648
1650 Once the server has generated a resource identifier for the client or
1651 accepted the resource identifier provided by the client, it MUST
1652 return an IQ stanza of type "result" to the client, which MUST
1653 include a child element that specifies the full JID for the
1654 connected resource as determined by the server.
1656 Server informs client of successful resource binding:
1658
1659
1660 juliet@example.com/balcony
1661
1662
1664 A server SHOULD accept the resource identifier provided by the
1665 client, but MAY override it with a resource identifier that the
1666 server generates; in this case, the server SHOULD NOT return a stanza
1667 error (e.g., ) to the client but instead SHOULD
1668 communicate the generated resource identifier to the client in the IQ
1669 result as shown above.
1671 When a client supplies a resource identifier, the following stanza
1672 error conditions are possible (see Stanza Errors (Section 9.3)):
1674 o The provided resource identifier cannot be processed by the
1675 server, e.g. because it is not in accordance with Resourceprep
1676 (Appendix B).
1677 o The client is not allowed to bind a resource to the stream (e.g.,
1678 because the node or user has reached a limit on the number of
1679 connected resources allowed).
1680 o The provided resource identifier is already in use but the server
1681 does not allow binding of multiple connected resources with the
1682 same identifier.
1684 The protocol for these error conditions is as follows.
1686 Resource identifier cannot be processed:
1688
1689
1690 someresource
1691
1692
1693
1694
1695
1697 Client is not allowed to bind a resource:
1699
1700
1701 someresource
1702
1703
1704
1705
1706
1708 If there is already a connected resource of the same name, the server
1709 MUST do one of the following:
1711 1. Not accept the resource identifier provided by the client but
1712 instead override it with a resource identifier that the server
1713 generates.
1714 2. Terminate the current resource and allow the newly-requested
1715 resource.
1716 3. Disallow the newly-requested resource and maintain the current
1717 resource.
1719 Which of these the server does is up to the implementation, although
1720 it is RECOMMENDED to implement case #1. In case #2, the server MUST
1721 send a stream error to the current resource, terminate
1722 the XML stream and underlying TCP connection for the current
1723 resource, and return a IQ stanza of type "result" (indicating
1724 success) to the newly-requested resource. In case #3, the server
1725 MUST either (a) return a server-generated resource name or (b) send a
1726 stanza error to the newly-requested resource but maintain
1727 the XML stream for that connection so that the newly-requested
1728 resource has an opportunity to negotiate a non-conflicting resource
1729 identifier before sending another request for resource binding.
1731 Resource identifier is in use:
1733
1734
1735 someresource
1736
1737
1738
1739
1740
1742 If, before completing the resource binding step, the client attempts
1743 to send an outbound XML stanza (i.e., a stanza not directed to the
1744 server itself or to the client's own account), the server MUST NOT
1745 process the stanza and SHOULD return a stanza error
1746 to the client.
1748 8.1. Binding Multiple Resources
1750 A server MAY support binding of multiple resources to the same
1751 stream. This functionality is desirable in certain environments
1752 (e.g., for devices that are unable to open more than one TCP
1753 connection or when a machine runs an XMPP client daemon that is used
1754 by multiple applications). If a server supports binding of multiple
1755 resources to a stream, it MUST enable a client to unbind resources.
1756 This shall be completed by sending an IQ-set with a child element of
1757 qualified by the 'urn:ietf:params:xml:ns:xmpp-bind'
1758 namespace, which in turn has a child element of whose XML
1759 character data specifies the resource to be unbound:
1761
1762
1763 someresource
1764
1765
1767 If the server does not understand the element, it MUST
1768 return an error of . Otherwise, if there is no such
1769 resource for that stream, the server MUST return an error of . When the client unbinds the only resource associated
1771 with the stream, the server SHOULD close the stream and terminate the
1772 TCP connection.
1774 A server SHOULD advertise its support for the
1775 'urn:ietf:params:xml:ns:xmpp-bind' namespace by returning an
1776 appropriate stream feature as follows:
1778
1779
1780
1781
1783 When a client binds multiple resources to the same stream, proper
1784 management of 'from' addresses is imperative. In particular, a
1785 client MUST specify a 'from' address on every stanza it sends over a
1786 stream to which it has bound multiple resources, where the 'from'
1787 address is the full JID () associated with
1788 the relevant resource. If a client does not specify a 'from' address
1789 on a stanza it sends over a stream to which it has bound multiple
1790 resources (or if it specifies as the 'from' address a full JID other
1791 than one of the bound resources), the server MUST return the stanza
1792 to the client with an stanza error.
1794 Naturally, the rules regarding validation of asserted 'from'
1795 addresses still apply (see Section 11).
1797 9. XML Stanzas
1799 After a client has connected to a server or two servers have
1800 connected to each other, either party can send XML stanzas over the
1801 negotiated stream. Three kinds of XML stanza are defined for the
1802 'jabber:client' and 'jabber:server' namespaces: ,
1803 , and . In addition, there are five common
1804 attributes for these kinds of stanza. These common attributes, as
1805 well as the basic semantics of the three stanza kinds, are defined
1806 herein; more detailed information regarding the syntax of XML stanzas
1807 for instant messaging and presence applications is provided in
1808 [XMPP-IM], and for other applications in the relevant XMPP extension
1809 specifications.
1811 An XML stanza is the basic unit of meaning in XMPP. A server MUST
1812 NOT process, deliver, or route a partial stanza and a server MUST NOT
1813 attach meaning to the transmission timing of any child element within
1814 a stanza.
1816 9.1. Common Attributes
1818 The following five attributes are common to message, presence, and IQ
1819 stanzas:
1821 9.1.1. to
1823 The 'to' attribute specifies the JID of the intended recipient for
1824 the stanza.
1826 In the 'jabber:client' namespace, a stanza with a specific intended
1827 recipient MUST possess a 'to' attribute, whereas a stanza sent from a
1828 client to a server for direct processing by that server (e.g.,
1829 presence sent to the server for broadcasting to other entities)
1830 SHOULD NOT possess a 'to' attribute.
1832 In the 'jabber:server' namespace, a stanza MUST possess a 'to'
1833 attribute; if a server receives a stanza that does not meet this
1834 restriction, it MUST generate an stream error
1835 condition and terminate both the XML stream and the underlying TCP
1836 connection with the offending server.
1838 If the value of the 'to' attribute is invalid or cannot be contacted,
1839 the entity discovering that fact (usually the sender's or recipient's
1840 server) MUST return an appropriate error to the sender, setting the
1841 'from' attribute of the error stanza to the value provided in the
1842 'to' attribute of the offending stanza.
1844 9.1.2. from
1846 The 'from' attribute specifies the JID of the sender.
1848 When a server receives an XML stanza within the context of an
1849 authenticated stream qualified by the 'jabber:client' namespace, it
1850 MUST do one of the following:
1851 1. validate that the value of the 'from' attribute provided by the
1852 client is that of a connected resource for the associated entity
1853 2. add a 'from' address to the stanza whose value is the full JID
1854 () determined by the server for the
1855 connected resource that generated the stanza (see Determination
1856 of Addresses (Section 3.5)), or the bare JID () in
1857 the case of subscription-related presence stanzas (see [XMPP-IM]
1858 for details)
1860 If a client attempts to send an XML stanza for which the value of the
1861 'from' attribute does not exactly match one of the connected
1862 resources for that entity, the server SHOULD return an stream error to the client. If a client attempts to send an
1864 XML stanza over a stream that is not yet authenticated, the server
1865 SHOULD return a stream error to the client. If
1866 generated, both of these conditions MUST result in closure of the
1867 stream and termination of the underlying TCP connection; this helps
1868 to prevent a denial of service attack launched from a rogue client.
1870 When a server generates a stanza from the server itself for delivery
1871 to a connected client (e.g., in the context of data storage services
1872 provided by the server on behalf of the client), the stanza MUST
1873 either (1) not include a 'from' attribute or (2) include a 'from'
1874 attribute whose value is the account's bare JID () or
1875 connected resource's full JID (). A server
1876 MUST NOT send to the client a stanza without a 'from' attribute if
1877 the stanza was not generated by the server itself. When a client
1878 receives a stanza that does not include a 'from' attribute, it MUST
1879 assume that the stanza is from the server to which the client is
1880 connected.
1882 In the 'jabber:server' namespace, a stanza MUST possess a 'from'
1883 attribute; if a server receives a stanza that does not meet this
1884 restriction, it MUST generate an stream error
1885 condition. Furthermore, the domain identifier portion of the JID
1886 contained in the 'from' attribute MUST match the hostname of the
1887 sending server (or any validated domain thereof, such as a validated
1888 local domain hosted by the sending server) as communicated in the
1889 SASL negotiation, dialback negotiation or other means; if a server
1890 receives a stanza that does not meet this restriction, it MUST
1891 generate an stream error condition. Both of these
1892 conditions MUST result in closure of the stream and termination of
1893 the underlying TCP connection; this helps to prevent a denial of
1894 service attack launched from a rogue server.
1896 9.1.3. id
1898 The optional 'id' attribute MAY be used by a sending entity for
1899 internal tracking of stanzas that it sends and receives (especially
1900 for tracking the request-response interaction inherent in the
1901 semantics of IQ stanzas). It is OPTIONAL for the value of the 'id'
1902 attribute to be unique globally, within a domain, or within a stream.
1903 The semantics of IQ stanzas impose additional restrictions; see IQ
1904 Semantics (Section 9.2.3).
1906 9.1.4. type
1908 The 'type' attribute specifies detailed information about the purpose
1909 or context of the message, presence, or IQ stanza. The particular
1910 allowable values for the 'type' attribute vary depending on whether
1911 the stanza is a message, presence, or IQ; the values for message and
1912 presence stanzas are specific to instant messaging and presence
1913 applications and therefore are defined in [XMPP-IM], whereas the
1914 values for IQ stanzas specify the role of an IQ stanza in a
1915 structured request-response "conversation" and thus are defined under
1916 IQ Semantics (Section 9.2.3) below. The only 'type' value common to
1917 all three stanzas is "error"; see Stanza Errors (Section 9.3).
1919 9.1.5. xml:lang
1921 A stanza SHOULD possess an 'xml:lang' attribute (as defined in
1922 Section 2.12 of [XML]) if the stanza contains XML character data that
1923 is intended to be presented to a human user (as explained in
1924 [CHARSET], "internationalization is for humans"). The value of the
1925 'xml:lang' attribute specifies the default language of any such
1926 human-readable XML character data, which MAY be overridden by the
1927 'xml:lang' attribute of a specific child element. If a stanza does
1928 not possess an 'xml:lang' attribute, an implementation MUST assume
1929 that the default language is that specified for the stream as defined
1930 under Stream Attributes (Section 5.3) above. The value of the 'xml:
1931 lang' attribute MUST be an NMTOKEN and MUST conform to the format
1932 defined in [LANGTAGS].
1934 9.2. Basic Semantics
1936 9.2.1. Message Semantics
1938 The stanza kind can be seen as a "push" mechanism whereby
1939 one entity pushes information to another entity, similar to the
1940 communications that occur in a system such as email. All message
1941 stanzas SHOULD possess a 'to' attribute that specifies the intended
1942 recipient of the message; upon receiving such a stanza, a server
1943 SHOULD route or deliver it to the intended recipient (see Server
1944 Rules for Handling XML Stanzas (Section 11) for general routing and
1945 delivery rules related to XML stanzas).
1947 9.2.2. Presence Semantics
1949 The element can be seen as a specialized broadcast or
1950 "publish-subscribe" mechanism, whereby multiple entities receive
1951 information about an entity to which they have subscribed (in this
1952 case, network availability information). In general, a publishing
1953 entity SHOULD send a presence stanza with no 'to' attribute, in which
1954 case the server to which the entity is connected SHOULD broadcast or
1955 multiplex that stanza to all subscribing entities. However, a
1956 publishing entity MAY also send a presence stanza with a 'to'
1957 attribute, in which case the server SHOULD route or deliver that
1958 stanza to the intended recipient. See Server Rules for Handling XML
1959 Stanzas (Section 11) for general routing and delivery rules related
1960 to XML stanzas, and [XMPP-IM] for rules specific to presence
1961 applications.
1963 9.2.3. IQ Semantics
1965 Info/Query, or IQ, is a request-response mechanism, similar in some
1966 ways to [HTTP]. The semantics of IQ enable an entity to make a
1967 request of, and receive a response from, another entity. The data
1968 content of the request and response is defined by the schema or other
1969 structural definition associated with the XML namespace that
1970 qualifies the direct child element of the IQ element (see extended
1971 namespaces (Section 9.4)), and the interaction is tracked by the
1972 requesting entity through use of the 'id' attribute. Thus, IQ
1973 interactions follow a common pattern of structured data exchange such
1974 as get/result or set/result (although an error may be returned in
1975 reply to a request if appropriate):
1977 Requesting Responding
1978 Entity Entity
1979 ---------- ----------
1980 | |
1981 | |
1982 | ------------------------> |
1983 | |
1984 | |
1985 | <------------------------ |
1986 | |
1987 | |
1988 | ------------------------> |
1989 | |
1990 | |
1991 | <------------------------ |
1992 | |
1994 In order to enforce these semantics, the following rules apply:
1996 1. The 'id' attribute is REQUIRED for IQ stanzas.
1997 2. The 'type' attribute is REQUIRED for IQ stanzas. The value MUST
1998 be one of the following:
1999 * get -- The stanza is a request for information or
2000 requirements.
2001 * set -- The stanza provides required data, sets new values, or
2002 replaces existing values.
2003 * result -- The stanza is a response to a successful get or set
2004 request.
2005 * error -- An error has occurred regarding processing or
2006 delivery of a previously-sent get or set (see Stanza Errors
2007 (Section 9.3)).
2009 3. An entity that receives an IQ request of type "get" or "set" MUST
2010 reply with an IQ response of type "result" or "error" (the
2011 response MUST preserve the 'id' attribute of the request).
2012 4. An entity that receives a stanza of type "result" or "error" MUST
2013 NOT respond to the stanza by sending a further IQ response of
2014 type "result" or "error"; however, as shown above, the requesting
2015 entity MAY send another request (e.g., an IQ of type "set" in
2016 order to provide required information discovered through a get/
2017 result pair).
2018 5. An IQ stanza of type "get" or "set" MUST contain one and only one
2019 child element that specifies the semantics of the particular
2020 request or response.
2021 6. An IQ stanza of type "result" MUST include zero or one child
2022 elements.
2023 7. An IQ stanza of type "error" SHOULD include the child element
2024 contained in the associated "get" or "set" and MUST include an
2025 child; for details, see Stanza Errors (Section 9.3).
2027 9.3. Stanza Errors
2029 Stanza-related errors are handled in a manner similar to stream
2030 errors (Section 5.8). However, unlike stream errors, stanza errors
2031 are recoverable; therefore error stanzas include hints regarding
2032 actions that the original sender can take in order to remedy the
2033 error.
2035 9.3.1. Rules
2037 The following rules apply to stanza-related errors:
2039 o The receiving or processing entity that detects an error condition
2040 in relation to a stanza SHOULD return an "error stanza" (and MUST
2041 do so for IQ stanzas), where such an "error stanza" is a stanza of
2042 the same kind (message, presence, or IQ) whose 'type' attribute is
2043 set to a value of "error".
2044 o The entity that generates an error stanza SHOULD include the
2045 original XML sent so that the sender can inspect and, if
2046 necessary, correct the XML before attempting to resend.
2047 o An error stanza MUST contain an child element.
2048 o An child MUST NOT be included if the 'type' attribute has
2049 a value other than "error" (or if there is no 'type' attribute).
2050 o An entity that receives an error stanza MUST NOT respond to the
2051 stanza with a further error stanza; this helps to prevent looping.
2053 9.3.2. Syntax
2055 The syntax for stanza-related errors is as follows:
2057
2058 [RECOMMENDED to include sender XML here]
2059
2060
2061 [
2063 OPTIONAL descriptive text
2064 ]
2065 [OPTIONAL application-specific condition element]
2066
2067
2069 The "stanza-kind" is one of message, presence, or iq.
2071 The value of the element's 'type' attribute MUST be one of
2072 the following:
2074 o cancel -- do not retry (the error is unrecoverable)
2075 o continue -- proceed (the condition was only a warning)
2076 o modify -- retry after changing the data sent
2077 o auth -- retry after providing credentials
2078 o wait -- retry after waiting (the error is temporary)
2080 The element:
2082 o MUST contain a child element corresponding to one of the defined
2083 stanza error conditions specified below; this element MUST be
2084 qualified by the 'urn:ietf:params:xml:ns:xmpp-stanzas' namespace.
2085 o MAY contain a child containing XML character data that
2086 describes the error in more detail; this element MUST be qualified
2087 by the 'urn:ietf:params:xml:ns:xmpp-stanzas' namespace and SHOULD
2088 possess an 'xml:lang' attribute.
2089 o MAY contain a child element for an application-specific error
2090 condition; this element MUST be qualified by an application-
2091 defined namespace, and its structure is defined by that namespace.
2093 The element is OPTIONAL. If included, it SHOULD be used only
2094 to provide descriptive or diagnostic information that supplements the
2095 meaning of a defined condition or application-specific condition. It
2096 SHOULD NOT be interpreted programmatically by an application. It
2097 SHOULD NOT be used as the error message presented to a user, but MAY
2098 be shown in addition to the error message associated with the
2099 included condition element (or elements).
2101 Finally, to maintain backward compatibility, the schema (specified in
2102 [XMPP-IM]) allows the optional inclusion of a 'code' attribute on the
2103 element; for details, see [XEP-0086].
2105 9.3.3. Defined Conditions
2107 The following conditions are defined for use in stanza errors.
2109 o -- the sender has sent XML that is malformed or
2110 that cannot be processed (e.g., an IQ stanza that includes an
2111 unrecognized value of the 'type' attribute); the associated error
2112 type SHOULD be "modify".
2113 o -- access cannot be granted because an existing
2114 resource exists with the same name or address; the associated
2115 error type SHOULD be "cancel".
2116 o -- the feature requested is not
2117 implemented by the recipient or server and therefore cannot be
2118 processed; the associated error type SHOULD be "cancel" or
2119 "modify".
2120 o -- the requesting entity does not possess the
2121 required permissions to perform the action; the associated error
2122 type SHOULD be "auth".
2123 o -- the recipient or server can no longer be contacted at
2124 this address (the error stanza MAY contain a new address in the
2125 XML character data of the element); the associated error
2126 type SHOULD be "cancel" or "modify".
2127 o -- the server could not process the
2128 stanza because of a misconfiguration or an otherwise-undefined
2129 internal server error; the associated error type SHOULD be "wait".
2130 o -- the addressed JID or item requested cannot be
2131 found; the associated error type SHOULD be "cancel".
2132 o -- the sending entity has provided or
2133 communicated an XMPP address (e.g., a value of the 'to' attribute)
2134 or aspect thereof (e.g., a resource identifier) that does not
2135 adhere to the syntax defined under Addresses (Section 3); the
2136 associated error type SHOULD be "modify".
2137 o -- the recipient or server understands the
2138 request but is refusing to process it because it does not meet
2139 criteria defined by the recipient or server (e.g., a local policy
2140 regarding stanza size limits or acceptable words in messages); the
2141 associated error type SHOULD be "modify".
2142 o -- the recipient or server does not allow any
2143 entity to perform the action (e.g., sending to entities at a
2144 blacklisted domain); the associated error type SHOULD be "cancel".
2145 o -- the sender must provide proper credentials
2146 before being allowed to perform the action, or has provided
2147 improper credentials; the associated error type SHOULD be "auth".
2148 o -- the item requested has not changed since it was
2149 last requested; the associated error type SHOULD be "continue".
2150 o -- the requesting entity is not authorized to
2151 access the requested service because payment is required; the
2152 associated error type SHOULD be "auth".
2154 o -- the intended recipient is temporarily
2155 unavailable; the associated error type SHOULD be "wait" (note: an
2156 application MUST NOT return this error if doing so would provide
2157 information about the intended recipient's network availability to
2158 an entity that is not authorized to know such information).
2159 o -- the recipient or server is redirecting requests for
2160 this information to another entity, usually temporarily (the error
2161 stanza SHOULD contain the alternate address, which MUST be a valid
2162 JID, in the XML character data of the element); the
2163 associated error type SHOULD be "modify".
2164 o -- the requesting entity is not
2165 authorized to access the requested service because prior
2166 registration is required; the associated error type SHOULD be
2167 "auth".
2168 o -- a remote server or service specified
2169 as part or all of the JID of the intended recipient does not
2170 exist; the associated error type SHOULD be "cancel".
2171 o -- a remote server or service specified
2172 as part or all of the JID of the intended recipient (or required
2173 to fulfill a request) could not be contacted within a reasonable
2174 amount of time; the associated error type SHOULD be "wait".
2175 o -- the server or recipient lacks the system
2176 resources necessary to service the request; the associated error
2177 type SHOULD be "wait".
2178 o -- the server or recipient does not
2179 currently provide the requested service; the associated error type
2180 SHOULD be "cancel".
2181 o -- the requesting entity is not
2182 authorized to access the requested service because a subscription
2183 is required; the associated error type SHOULD be "auth".
2184 o -- the error condition is not one of those
2185 defined by the other conditions in this list; any error type may
2186 be associated with this condition, and it SHOULD be used only in
2187 conjunction with an application-specific condition.
2188 o -- the recipient or server understood the
2189 request but was not expecting it at this time (e.g., the request
2190 was out of order); the associated error type SHOULD be "wait" or
2191 "modify".
2192 o -- the stanza 'from' address specified by a
2193 remote server or connected client is not known to the receiving
2194 server or is not valid for the stream; the associated error type
2195 SHOULD be "modify".
2197 9.3.4. Application-Specific Conditions
2199 As noted, an application MAY provide application-specific stanza
2200 error information by including a properly-namespaced child in the
2201 error element. The application-specific element SHOULD supplement or
2202 further qualify a defined element. Thus, the element will
2203 contain two or three child elements:
2205
2206
2207
2208
2209
2210
2212
2213
2214
2216
2218 Some special application diagnostic information...
2219
2220
2221
2222
2224 9.4. Extended Namespaces
2226 While the message, presence, and IQ stanza kinds provide basic
2227 semantics for messaging, availability, and request-response
2228 interactions, XMPP uses XML namespaces to extend the stanzas for the
2229 purpose of providing additional functionality. Thus a message or
2230 presence stanza MAY contain one or more optional child elements
2231 specifying content that extends the meaning of the message (e.g., an
2232 XHTML-formatted version of the message body as described in
2233 [XEP-0071]), and an IQ stanza MAY contain one such child element.
2234 This child element MAY have any name and MUST possess an 'xmlns'
2235 namespace declaration (other than "jabber:client", "jabber:server",
2236 or "http://etherx.jabber.org/streams") that defines all data
2237 contained within the child element. Such a child element is said to
2238 be defined by an EXTENDED NAMESPACE.
2240 Support for any given extended namespace is OPTIONAL on the part of
2241 any implementation. If an entity does not understand such a
2242 namespace, the entity's expected behavior depends on whether the
2243 entity is (1) the recipient or (2) an entity that is routing the
2244 stanza to the recipient:
2246 Recipient: If a recipient receives a stanza that contains a child
2247 element it does not understand, it SHOULD ignore that specific XML
2248 data, i.e., it SHOULD not process it or present it to a user or
2249 associated application (if any). In particular:
2250 * If an entity receives a message or presence stanza that
2251 contains XML data qualified by a namespace it does not
2252 understand, the portion of the stanza that is in the unknown
2253 namespace SHOULD be ignored.
2254 * If an entity receives a message stanza whose only child element
2255 is qualified by a namespace it does not understand, it MUST
2256 ignore the entire stanza.
2257 * If an entity receives an IQ stanza of type "get" or "set"
2258 containing a child element qualified by a namespace it does not
2259 understand, the entity SHOULD return an IQ stanza of type
2260 "error" with an error condition of .
2261 Router: If a routing entity (usually a server) handles a stanza that
2262 contains a child element it does not understand, it SHOULD ignore
2263 the associated XML data by passing it on untouched to the
2264 recipient.
2266 10. Examples
2268 10.1. Client-to-Server
2270 The following examples show the data flow for a client negotiating an
2271 XML stream with a server, exchanging XML stanzas, and closing the
2272 negotiated stream. The server is "example.com", the server requires
2273 use of TLS, the client authenticates via the SASL DIGEST-MD5
2274 mechanism as "juliet@example.com", and the client binds the resource
2275 "balcony" to the stream. (Note: The alternate steps shown below are
2276 provided to illustrate the protocol for failure cases; they are not
2277 exhaustive and would not necessarily be triggered by the data sent in
2278 the examples.)
2280 Step 1: Client initiates stream to server:
2282
2290 Step 2: Server responds by sending a stream header to client:
2292
2301 Step 3: Server sends stream features to client (STARTTLS extension
2302 and authentication mechanisms):
2304
2305
2306
2307
2308
2310 Step 4: Client sends STARTTLS command to server:
2312
2314 Step 5: Server informs client that it is allowed to proceed:
2316
2318 Step 5 (alt): Server informs client that TLS negotiation has failed
2319 and closes both XML stream and TCP connection:
2321
2322
2324 Step 6: Client and server attempt to complete TLS negotiation over
2325 the existing TCP connection (see [TLS] for details).
2327 Step 7: If TLS negotiation is successful, client initiates a new
2328 stream to server:
2330
2338 Step 7 (alt): If TLS negotiation is unsuccessful, server closes TCP
2339 connection.
2341 Step 8: Server responds by sending a stream header to client along
2342 with any available stream features (notice that the server now shows
2343 a different set of SASL mechanisms; here the server accepts the SASL
2344 PLAIN mechanism once the stream has been secured via TLS):
2346
2354
2355
2356 DIGEST-MD5
2357 PLAIN
2358
2359
2360
2362 Step 9: Client selects an authentication mechanism, in this case
2363 [DIGEST-MD5] with an empty authorization identity ("="):
2365 =
2368 Step 10: Server sends a [BASE64] encoded challenge to client:
2370
2371 cmVhbG09ImV4YW1wbGUuY29tIixub25jZT0iT0E2TUc5dEVRR20yaGgiLHFvcD0i
2372 YXV0aCIsY2hhcnNldD11dGYtOCxhbGdvcml0aG09bWQ1LXNlc3MK
2373
2375 The decoded challenge is:
2377 realm="example.com",nonce="OA6MG9tEQGm2hh",
2378 qop="auth",charset=utf-8,algorithm=md5-sess
2380 Note: When the server sends a DIGEST-MD5 challenge to the client, the
2381 qop list must be quoted since it is a list rather than a single item
2382 (even if there is only one item in the list); however, when the
2383 client sends its response to the server (see below), the qop must not
2384 be quoted since it is a single item rather than a list.
2386 Step 10 (alt): Server returns error to client:
2388
2389
2390
2391
2393 Step 11: Client sends a [BASE64] encoded response to the challenge:
2395
2396 dXNlcm5hbWU9Imp1bGlldCIscmVhbG09ImV4YW1wbGUuY29tIixub25jZT0iT0E2
2397 TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5jPTAwMDAwMDAx
2398 LHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5jb20iLHJlc3BvbnNl
2399 PWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNoYXJzZXQ9dXRmLTgK
2400
2402 The decoded response is:
2404 username="juliet",realm="example.com",
2405 nonce="OA6MG9tEQGm2hh",cnonce="OA6MHXh6VqTrRk",
2406 nc=00000001,qop=auth,digest-uri="xmpp/example.com",
2407 response=d388dad90d4bbd760a152321f2143af7,charset=utf-8
2409 Step 12: Server informs client of success and includes [BASE64]
2410 encoded value for subsequent authentication:
2412
2413 cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo=
2414
2416 The decoded value for subsequent authentication is:
2418 rspauth=ea40f60335c427b5527b84dbabcdfffd
2420 Step 12 (alt): Server returns error to client:
2422
2423
2424
2425
2426 Step 13: Client initiates a new stream to server:
2428
2436 Step 14: Server responds by sending a stream header to client along
2437 with supported features (in this case resource binding):
2439
2447
2448
2449
2450
2451
2453 Upon being so informed that resource binding is required, the client
2454 MUST bind a resource to the stream; here we assume that the client
2455 binds a resource called "balcony".
2457 Step 15: Client binds a resource:
2459
2460
2461 balcony
2462
2463
2464 Step 16: Server informs client of successful resource binding:
2466
2469
2470 juliet@example.com/balcony
2471
2472
2474 Now the client is allowed to send XML stanzas over the negotiated
2475 stream.
2477 Client sends XML stanza to other entity:
2479
2482 Art thou not Romeo, and a Montague?
2483
2485 If necessary, sender's server negotiates XML streams with intended
2486 recipient's server (see Server-to-Server Examples (Section 10.2)).
2488 The intended recipient replies and the message is delivered to the
2489 client.
2491 Client receives XML stanza from other entity:
2493
2496 Neither, fair saint, if either thee dislike.
2497
2499 Desiring to send no further messages, the client closes the stream.
2501 Client closes the stream:
2503
2505 Consistent with the recommended stream closing handshake, server
2506 closes stream as well:
2508 Server closes the stream:
2510
2511 Client now terminates the underlying TCP connection.
2513 10.2. Server-to-Server Examples
2515 The following examples show the data flow for a server negotiating an
2516 XML stream with another server, exchanging XML stanzas, and closing
2517 the negotiated stream. The initiating server ("Server1") is
2518 "example.com"; the receiving server ("Server2") is example.net and it
2519 requires use of TLS; example.com presents a certificate and
2520 authenticates via the SASL EXTERNAL mechanism. (Note: The alternate
2521 steps shown below are provided to illustrate the protocol for failure
2522 cases; they are not exhaustive and would not necessarily be triggered
2523 by the data sent in the examples.)
2525 Step 1: Server1 initiates stream to Server2:
2527
2534 Step 2: Server2 responds by sending a stream tag to Server1:
2536
2544 Step 3: Server2 sends stream features to Server1 (STARTTLS extension
2545 and authentication mechanisms):
2547
2548
2549
2550
2551
2553 Step 4: Server1 sends the STARTTLS command to Server2:
2555
2556 Step 5: Server2 informs Server1 that it is allowed to proceed:
2558
2560 Step 5 (alt): Server2 informs Server1 that TLS negotiation has failed
2561 and closes stream:
2563
2564
2566 Step 6: Server1 and Server2 attempt to complete TLS negotiation via
2567 TCP.
2569 Step 7: If TLS negotiation is successful, Server1 initiates a new
2570 stream to Server2:
2572
2579 Step 7 (alt): If TLS negotiation is unsuccessful, Server2 closes TCP
2580 connection.
2582 Step 8: Server2 responds by sending a stream header to Server1 along
2583 with available stream features (notice that Server2 now prefers the
2584 SASL EXTERNAL mechanism):
2586
2593
2594
2595 EXTERNAL
2596 DIGEST-MD5
2597
2598
2599
2600 Step 9: Server1 selects the EXTERNAL mechanism, in this case with an
2601 authorization identity encoded according to [BASE64]:
2603 ZXhhbXBsZS5jb20K
2606 The decoded authorization identity is "example.com".
2608 Step 10: Server2 determines that the authorization identity provided
2609 by Server1 matches the valid id-xmppAddr-on or Common Name in the
2610 presented certificate and therefore returns success:
2612
2614 Step 11 (alt): Server2 informs Server1 of failed authentication:
2616
2617
2618
2619
2621 Step 12: Server1 initiates a new stream to Server2:
2623
2630 Step 13: Server2 responds by sending a stream header to Server1 along
2631 with any additional features (or, in this case, an empty features
2632 element):
2634
2641
2643 Now Server1 is allowed to send XML stanzas to Server2 over the
2644 negotiated stream; here we assume that the transferred stanzas are
2645 those shown earlier for client-to-server communications.
2647 Server1 sends XML stanza to Server2:
2649
2652 Art thou not Romeo, and a Montague?
2653
2655 The intended recipient replies and the message is delivered from
2656 Server2 to Server1.
2658 Server2 sends XML stanza to Server1:
2660
2663 Neither, fair saint, if either thee dislike.
2664
2666 Desiring to send no further messages, Server1 closes the stream. (In
2667 practice, the stream would most likely remain open for some time,
2668 since Server1 and Server2 do not immediately know if the stream will
2669 be needed for further communications.)
2671 Server1 closes the stream:
2673
2675 Consistent with the recommended stream closing handshake, Server2
2676 closes stream as well:
2678 Server2 closes the stream:
2680
2682 Server1 now terminates the underlying TCP connection.
2684 11. Server Rules for Handling XML Stanzas
2686 Compliant server implementations MUST ensure in-order processing of
2687 XML stanzas between any two entities. This includes stanzas sent by
2688 a client to its server for direct processing by the server.
2690 Beyond the requirement for in-order processing, each server
2691 implementation will contain its own "delivery tree" for handling
2692 stanzas it receives. Such a tree determines whether a stanza needs
2693 to be routed to another domain, processed direct, or delivered to a
2694 resource associated with a connected node. The following rules
2695 apply.
2697 11.1. No 'to' Address
2699 If the stanza possesses no 'to' attribute, the server SHOULD process
2700 it directly on behalf of the entity that sent it. Because all
2701 stanzas received from other servers MUST possess a 'to' attribute,
2702 this rule applies only to stanzas received from a registered entity
2703 (such as a client) that is connected to the server. If the server
2704 receives a presence stanza with no 'to' attribute, the server SHOULD
2705 broadcast it to the entities that are subscribed to the sending
2706 entity's presence, if applicable (the semantics of presence broadcast
2707 for presence applications are defined in [XMPP-IM]). If the server
2708 receives an IQ stanza of type "get" or "set" with no 'to' attribute
2709 and it understands the namespace that qualifies the content of the
2710 stanza, it MUST either process the stanza directly on behalf of
2711 sending entity (where the meaning of "process" is determined by the
2712 semantics of the qualifying namespace) or return an error to the
2713 sending entity.
2715 11.2. Foreign Domain
2717 If the hostname of the domain identifier portion of the JID contained
2718 in the 'to' attribute does not match one of the configured hostnames
2719 of the server itself or a configured local domain thereof, the server
2720 SHOULD route the stanza to the foreign domain (subject to local
2721 service provisioning and security policies regarding inter-domain
2722 communication, since such communication is OPTIONAL). There are two
2723 possible cases:
2725 A server-to-server stream already exists between the two domains:
2726 The sender's server routes the stanza to the authoritative server
2727 for the foreign domain over the existing stream
2728 There exists no server-to-server stream between the two domains: The
2729 sender's server (1) resolves the hostname of the foreign domain
2730 (as defined under Server-to-Server Communications (Section 15.4)),
2731 (2) negotiates a server-to-server stream between the two domains
2732 (as defined under TLS negotiation (Section 6) and SASL negotiation
2733 (Section 7)), and (3) routes the stanza to the authoritative
2734 server for the foreign domain over the newly-established stream
2736 If routing to the recipient's server is unsuccessful, the sender's
2737 server MUST return an error to the sender; if the recipient's server
2738 can be contacted but delivery by the recipient's server to the
2739 recipient is unsuccessful, the recipient's server MUST return an
2740 error to the sender by way of the sender's server.
2742 11.3. Local Domain
2744 If the hostname of the domain identifier portion of the JID contained
2745 in the 'to' attribute matches one of the configured hostnames of the
2746 server, or one of the configured local domains hosted by the server,
2747 the server MUST either process the stanza itself or route the stanza
2748 to a specialized service that is responsible for that local domain,
2749 or return an error to the sender (if the service providing the local
2750 domain is not available).
2752 11.4. Mere Domain or Specific Resource
2754 If the hostname of the domain identifier portion of the JID contained
2755 in the 'to' attribute matches a configured hostname of the server
2756 itself and the JID contained in the 'to' attribute is of the form
2757 or , the server (or a defined resource
2758 thereof) MUST either process the stanza as appropriate for the stanza
2759 kind or return an error stanza to the sender.
2761 11.5. Node in Same Domain
2763 If the hostname of the domain identifier portion of the JID contained
2764 in the 'to' attribute matches a configured hostname of the server
2765 itself and the JID contained in the 'to' attribute is of the form
2766 or , the server SHOULD deliver
2767 the stanza to the intended recipient of the stanza as represented by
2768 the JID contained in the 'to' attribute. The following rules apply:
2770 1. If the JID contains a resource identifier (i.e., is of the form
2771 ) and there exists a connected resource
2772 that exactly matches the full JID, the recipient's server SHOULD
2773 deliver the stanza to the stream or connection that exactly
2774 matches the resource identifier.
2775 2. If the JID contains a resource identifier and there exists no
2776 connected resource that exactly matches the full JID, the
2777 recipient's server SHOULD return a stanza
2778 error to the sender.
2779 3. If the JID is of the form and there exists at least
2780 one connected resource for the node, the recipient's server
2781 SHOULD deliver the stanza to at least one of the connected
2782 resources, according to application-specific rules.
2784 Particular XMPP applications MAY specify delivery rules that modify
2785 or supplement the foregoing rules; for example, a set of delivery
2786 rules for instant messaging and presence applications is defined in
2787 [XMPP-IM].
2789 12. XML Usage
2791 12.1. Restrictions
2793 XMPP is a simplified and specialized protocol for streaming XML
2794 elements in order to exchange structured information in close to real
2795 time. Because XMPP does not require the parsing of arbitrary and
2796 complete XML documents, there is no requirement that XMPP needs to
2797 support the full feature set of [XML]. In particular, the following
2798 restrictions apply.
2800 With regard to XML generation, an XMPP implementation MUST NOT inject
2801 into an XML stream any of the following:
2803 o comments (as defined in Section 2.5 of [XML])
2804 o processing instructions (Section 2.6 therein)
2805 o internal or external DTD subsets (Section 2.8 therein)
2806 o internal or external entity references (Section 4.2 therein) with
2807 the exception of predefined entities (Section 4.6 therein)
2808 o character data or attribute values containing unescaped characters
2809 that map to the predefined entities (Section 4.6 therein); such
2810 characters MUST be escaped
2812 With regard to XML processing, if an XMPP implementation receives
2813 such restricted XML data, it MUST return a stream
2814 error.
2816 12.2. XML Namespace Names and Prefixes
2818 XML namespaces (see [XML-NAMES]) are used within all XMPP-compliant
2819 XML to create strict boundaries of data ownership. The basic
2820 function of namespaces is to separate different vocabularies of XML
2821 elements that are structurally mixed together. Ensuring that XMPP-
2822 compliant XML is namespace-aware enables any allowable XML to be
2823 structurally mixed with any data element within XMPP. Rules for XML
2824 namespace names and prefixes are defined in the following
2825 subsections.
2827 12.2.1. Streams Namespace
2829 A streams namespace declaration is REQUIRED in all XML stream
2830 headers. The name of the streams namespace MUST be
2831 'http://etherx.jabber.org/streams'. The element names of the
2832 element and its and children MUST be
2833 qualified by the streams namespace prefix in all instances. An
2834 implementation SHOULD generate only the 'stream:' prefix for these
2835 elements, and for historical reasons MAY accept only the 'stream:'
2836 prefix.
2838 12.2.2. Default Namespace
2840 A default namespace declaration is REQUIRED and is used in all XML
2841 streams in order to define the allowable first-level children of the
2842 root stream element. This namespace declaration MUST be the same for
2843 the initial stream and the response stream so that both streams are
2844 qualified consistently. The default namespace declaration applies to
2845 the stream and all stanzas sent within a stream (unless explicitly
2846 qualified by another namespace, or by the prefix of the streams
2847 namespace or the dialback namespace).
2849 A server implementation MUST support the following two default
2850 namespaces (for historical reasons, some implementations MAY support
2851 only these two default namespaces):
2853 o jabber:client -- this default namespace is declared when the
2854 stream is used for communications between a client and a server
2855 o jabber:server -- this default namespace is declared when the
2856 stream is used for communications between two servers
2858 A client implementation MUST support the 'jabber:client' default
2859 namespace, and for historical reasons MAY support only that default
2860 namespace.
2862 An implementation MUST NOT generate namespace prefixes for elements
2863 qualified by the default namespace if the default namespace is
2864 'jabber:client' or 'jabber:server'. An implementation SHOULD NOT
2865 generate namespace prefixes for elements qualified by content (as
2866 opposed to stream) namespaces other than 'jabber:client' and 'jabber:
2867 server'.
2869 Note: The 'jabber:client' and 'jabber:server' namespaces are nearly
2870 identical but are used in different contexts (client-to-server
2871 communications for 'jabber:client' and server-to-server
2872 communications for 'jabber:server'). The only difference between the
2873 two is that the 'to' and 'from' attributes are OPTIONAL on stanzas
2874 sent within 'jabber:client', whereas they are REQUIRED on stanzas
2875 sent within 'jabber:server'. If a compliant implementation accepts a
2876 stream that is qualified by the 'jabber:client' or 'jabber:server'
2877 namespace, it MUST support the common attributes (Section 9.1) and
2878 basic semantics (Section 9.2) of all three core stanza kinds
2879 (message, presence, and IQ).
2881 12.2.3. Dialback Namespace
2883 A dialback namespace declaration is REQUIRED for all elements used in
2884 server dialback (Appendix C). The name of the dialback namespace
2885 MUST be 'jabber:server:dialback'. All elements qualified by this
2886 namespace MUST be prefixed. An implementation SHOULD generate only
2887 the 'db:' prefix for such elements and MAY accept only the 'db:'
2888 prefix.
2890 12.3. Validation
2892 A server is not responsible for validating the XML elements forwarded
2893 to a client or another server; an implementation MAY choose to
2894 provide only validated data elements but this is OPTIONAL (although
2895 an implementation MUST NOT accept XML that is not well-formed).
2896 Clients SHOULD NOT rely on the ability to send data which does not
2897 conform to the schemas, and SHOULD ignore any non-conformant elements
2898 or attributes on the incoming XML stream. Validation of XML streams
2899 and stanzas is OPTIONAL, and schemas are included herein for
2900 descriptive purposes only.
2902 12.4. Inclusion of Text Declaration
2904 Implementations SHOULD send a text declaration before sending a
2905 stream header. Applications MUST follow the rules in [XML] regarding
2906 the circumstances under which a text declaration is included.
2908 12.5. Character Encoding
2910 Implementations MUST support the [UTF-8] transformation of Universal
2911 Character Set ([UCS2]) characters, as required by [CHARSET].
2912 Implementations MUST NOT attempt to use any other encoding.
2914 12.6. White Space
2916 Except where explicitly disallowed (i.e., during TLS negotiation
2917 (Section 6) and SASL negotiation [SASL]), either entity MAY send
2918 white space characters (matching production [3] content of [XML])
2919 within the root stream element as separators between XML stanzas or
2920 between any other first-level elements sent over the stream; one
2921 common use for sending such white space characters is to check the
2922 viability of the underlying TCP connection after a period of
2923 inactivity.
2925 13. Compliance Requirements
2927 This section summarizes the specific aspects of the Extensible
2928 Messaging and Presence Protocol that MUST be supported by servers and
2929 clients in order to be considered compliant implementations, as well
2930 as additional protocol aspects that SHOULD be supported. For
2931 compliance purposes, we draw a distinction between core protocols
2932 (which MUST be supported by any server or client, regardless of the
2933 specific application) and instant messaging and presence protocols
2934 (which MUST be supported only by instant messaging and presence
2935 applications built on top of the core protocols). Compliance
2936 requirements that apply to all servers and clients are specified in
2937 this section; compliance requirements for instant messaging and
2938 presence applications are specified in the corresponding section of
2939 [XMPP-IM].
2941 13.1. Servers
2943 In addition to all defined requirements with regard to security, XML
2944 usage, and internationalization, a server MUST support the following
2945 core protocols in order to be considered compliant:
2947 o Conformance with [IDNA] for domain identifiers, the Nodeprep
2948 (Appendix A) profile of [STRINGPREP] for node identifiers, and the
2949 Resourceprep (Appendix B) profile of [STRINGPREP] for resource
2950 identifiers, and enforcement thereof for clients that authenticate
2951 with the server.
2952 o XML streams (Section 5), including TLS negotiation (Section 6),
2953 SASL negotiation (Section 7), and Resource Binding (Section 8)
2954 o The basic semantics of the three defined stanza kinds (i.e.,
2955 , , and ) as specified in stanza
2956 semantics (Section 9.2)
2957 o Generation (and, where appropriate, handling) of error syntax and
2958 semantics related to streams, TLS, SASL, and XML stanzas
2960 In addition, for historical reasons a server SHOULD support the
2961 following core protocol:
2963 o Server dialback (Appendix C)
2965 13.2. Clients
2967 A client MUST support the following core protocols in order to be
2968 considered compliant:
2970 o XML streams (Section 5), including TLS negotiation (Section 6),
2971 SASL negotiation (Section 7), and Resource Binding (Section 8)
2972 o The basic semantics of the three defined stanza kinds (i.e.,
2973 , , and ) as specified in stanza
2974 semantics (Section 9.2)
2975 o Handling (and, where appropriate, generation) of error syntax and
2976 semantics related to streams, TLS, SASL, and XML stanzas
2978 In addition, a client SHOULD support the following core protocols:
2980 o Conformance with [IDNA] for domain identifiers, the Nodeprep
2981 (Appendix A) profile of [STRINGPREP] for node identifiers, and the
2982 Resourceprep (Appendix B) profile of [STRINGPREP] for resource
2983 identifiers.
2985 14. Internationalization Considerations
2987 XML streams MUST be encoded in UTF-8 as specified under Character
2988 Encoding (Section 12.5). As specified under Stream Attributes
2989 (Section 5.3), an XML stream SHOULD include an 'xml:lang' attribute
2990 specifying the default language for any XML character data sent over
2991 the stream that is intended to be presented to a human user. As
2992 specified under xml:lang (Section 9.1.5), an XML stanza SHOULD
2993 include an 'xml:lang' attribute if the stanza contains XML character
2994 data that is intended to be presented to a human user. A server
2995 SHOULD apply the default 'xml:lang' attribute to stanzas it routes or
2996 delivers on behalf of connected entities, and MUST NOT modify or
2997 delete 'xml:lang' attributes stanzas it receives from other entities.
2999 15. Security Considerations
3001 15.1. High Security
3003 For the purposes of XMPP communications (client-to-server and server-
3004 to-server), the term "high security" refers to the use of security
3005 technologies that provide both mutual authentication and integrity-
3006 checking; in particular, when using certificate-based authentication
3007 to provide high security, a chain-of-trust SHOULD be established out-
3008 of-band, although a shared certificate authority signing certificates
3009 could allow a previously unknown certificate to establish trust in-
3010 band. See Section 15.2 below regarding certificate validation
3011 procedures.
3013 Implementations MUST support high security. Service provisioning
3014 SHOULD use high security, subject to local security policies.
3016 15.2. Certificate Validation
3018 When an XMPP peer communicates with another peer securely, it MUST
3019 validate the peer's certificate. There are three possible cases:
3021 Case #1: The peer contains an End Entity certificate which appears
3022 to be certified by a chain of certificates terminating in a trust
3023 anchor (as described in Section 6.1 of [X509]).
3025 Case #2: The peer certificate is certified by a Certificate
3026 Authority not known to the validating peer.
3027 Case #3: The peer certificate is self-signed.
3029 In Case #1, the validating peer MUST do one of two things:
3030 1. Verify the peer certificate according to the rules of [X509].
3031 The certificate SHOULD then be checked against the expected
3032 identity of the peer following the rules described in [HTTP-TLS],
3033 except that if present an [ASN.1] Object Identifier of "id-on-
3034 xmppAddr" (represented as a UTF8String in an otherName entity
3035 inside the subjectAltName) MUST be used as the identity. If one
3036 of these checks fails, user-oriented clients MUST either notify
3037 the user (clients MAY give the user the opportunity to continue
3038 with the connection in any case) or terminate the connection with
3039 a bad certificate error. Automated clients SHOULD terminate the
3040 connection (with a bad certificate error) and log the error to an
3041 appropriate audit log. Automated clients MAY provide a
3042 configuration setting that disables this check, but MUST provide
3043 a setting that enables it.
3044 2. The peer SHOULD show the certificate to a user for approval,
3045 including the entire certificate chain. The peer MUST cache the
3046 certificate (or some non-forgeable representation such as a
3047 hash). In future connections, the peer MUST verify that the same
3048 certificate was presented and MUST notify the user if it has
3049 changed.
3051 In Case #2 and Case #3, implementations SHOULD act as in (2) above.
3053 15.3. Client-to-Server Communications
3055 A compliant client implementation MUST support both TLS and SASL for
3056 connections to a server.
3058 The TLS protocol for encrypting XML streams (defined under TLS
3059 negotiation (Section 6)) provides a reliable mechanism for helping to
3060 ensure the confidentiality and data integrity of data exchanged
3061 between two entities.
3063 The SASL protocol for authenticating XML streams (defined under SASL
3064 negotiation (Section 7)) provides a reliable mechanism for validating
3065 that a client connecting to a server is who it claims to be.
3067 Client-to-server communications MUST NOT proceed until the DNS
3068 hostname asserted by the server has been resolved as specified under
3069 TCP Binding (Section 4). If there is a mismatch between the hostname
3070 to which a client attempted to connect (e.g., "example.net") and the
3071 hostname to which the client actually connects (e.g.,
3072 "im.example.net"), the client MUST warn a human user about the
3073 mismatch and the human user MUST approve the connection before the
3074 client proceeds; however, the client MAY allow the user to add the
3075 presented hostname to a configured set of accepted hostnames in order
3076 to expedite future connections.
3078 The IP address and method of access of clients MUST NOT be made
3079 public by a server, nor are any connections other than the original
3080 server connection required. This helps to protect the client's
3081 server from direct attack or identification by third parties.
3083 15.4. Server-to-Server Communications
3085 A compliant server implementation MUST support both TLS and SASL for
3086 inter-domain communications. For historical reasons, a compliant
3087 implementation SHOULD also support Server Dialback (Appendix C).
3089 Because service provisioning is a matter of policy, it is OPTIONAL
3090 for any given domain to communicate with other domains, and server-
3091 to-server communications MAY be disabled by the administrator of any
3092 given deployment. If a particular domain enables inter-domain
3093 communications, it SHOULD enable high security.
3095 Administrators may want to require use of SASL for server-to-server
3096 communications in order to ensure both authentication and
3097 confidentiality (e.g., on an organization's private network).
3098 Compliant implementations SHOULD support SASL for this purpose.
3100 Server-to-server communications MUST NOT proceed until the DNS
3101 hostnames asserted by both servers have been resolved as specified
3102 under TCP Binding (Section 4).
3104 Server dialback helps protect against domain spoofing, thus making it
3105 more difficult to spoof XML stanzas. It is not a mechanism for
3106 authenticating, securing, or encrypting streams between servers as is
3107 done via SASL and TLS, and results in weak verification of server
3108 identities only. Furthermore, it is susceptible to DNS poisoning
3109 attacks unless [DNSSEC] is used, and even if the DNS information is
3110 accurate, dialback cannot protect from attacks where the attacker is
3111 capable of hijacking the IP address of the remote domain. Domains
3112 requiring robust security SHOULD use TLS and SASL. If SASL is used
3113 for server-to-server authentication, dialback SHOULD NOT be used
3114 since it is unnecessary.
3116 15.5. Order of Layers
3118 The order of layers in which protocols MUST be stacked is as follows:
3120 1. TCP
3121 2. TLS
3122 3. SASL
3123 4. XMPP
3125 The rationale for this order is that [TCP] is the base connection
3126 layer used by all of the protocols stacked on top of TCP, [TLS] is
3127 often provided at the operating system layer, [SASL] is often
3128 provided at the application layer, and XMPP is the application
3129 itself.
3131 15.6. Lack of SASL Channel Binding to TLS
3133 The SASL framework does not provide a mechanism to bind SASL
3134 authentication to a security layer providing confidentiality and
3135 integrity protection that was negotiated at a lower layer. This lack
3136 of a "channel binding" prevents SASL from being able to verify that
3137 the source and destination end points to which the lower layer's
3138 security is bound are equivalent to the end points that SASL is
3139 authenticating. If the end points are not identical, the lower
3140 layer's security cannot be trusted to protect data transmitted
3141 between the SASL authenticated entities. In such a situation, a SASL
3142 security layer should be negotiated that effectively ignores the
3143 presence of the lower layer security.
3145 15.7. Mandatory-to-Implement Technologies
3147 At a minimum, all implementations MUST support the following
3148 mechanisms:
3150 for authentication: the SASL [DIGEST-MD5] mechanism
3151 for confidentiality: TLS (using the TLS_RSA_WITH_3DES_EDE_CBC_SHA
3152 cipher)
3153 for both: TLS plus SASL PLAIN for client-to-server connections and
3154 TLS plus SASL EXTERNAL for server-to-server connections (using the
3155 TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher supporting peer certificates)
3157 Naturally, implementations MAY support other ciphers with TLS and MAY
3158 support other SASL mechanisms.
3160 15.8. Firewalls
3162 Communications using XMPP normally occur over [TCP] connections on
3163 port 5222 (client-to-server) or port 5269 (server-to-server), as
3164 registered with the IANA (see IANA Considerations (Section 16)). Use
3165 of these well-known ports allows administrators to easily enable or
3166 disable XMPP activity through existing and commonly-deployed
3167 firewalls.
3169 15.9. Use of base64 in SASL
3171 Both the client and the server MUST verify any [BASE64] data received
3172 during SASL negotiation (Section 7). An implementation MUST reject
3173 (not ignore) any characters that are not explicitly allowed by the
3174 base64 alphabet; this helps to guard against creation of a covert
3175 channel that could be used to "leak" information. An implementation
3176 MUST NOT break on invalid input and MUST reject any sequence of
3177 base64 characters containing the pad ('=') character if that
3178 character is included as something other than the last character of
3179 the data (e.g., "=AAA" or "BBBB=CCC"); this helps to guard against
3180 buffer overflow attacks and other attacks on the implementation.
3181 Base 64 encoding visually hides otherwise easily recognized
3182 information, such as passwords, but does not provide any
3183 computational confidentiality. Base 64 encoding MUST follow the
3184 definition in Section 4 of [BASE64].
3186 15.10. Stringprep Profiles
3188 XMPP makes use of the [NAMEPREP] profile of [STRINGPREP] for
3189 processing of domain identifiers; for security considerations related
3190 to Nameprep, refer to the appropriate section of [NAMEPREP].
3192 In addition, XMPP defines two profiles of [STRINGPREP]: Nodeprep
3193 (Appendix A) for node identifiers and Resourceprep (Appendix B) for
3194 resource identifiers.
3196 The Unicode and ISO/IEC 10646 repertoires have many characters that
3197 look similar. In many cases, users of security protocols might do
3198 visual matching, such as when comparing the names of trusted third
3199 parties. Because it is impossible to map similar-looking characters
3200 without a great deal of context, such as knowing the fonts used,
3201 stringprep does nothing to map similar-looking characters together,
3202 nor to prohibit some characters because they look like others.
3204 A node identifier can be employed as one part of an entity's address
3205 in XMPP. One common usage is as the username of an instant messaging
3206 user; another is as the name of a multi-user chat room; many other
3207 kinds of entities could use node identifiers as part of their
3208 addresses. The security of such services could be compromised based
3209 on different interpretations of the internationalized node
3210 identifier; for example, a user entering a single internationalized
3211 node identifier could access another user's account information, or a
3212 user could gain access to an otherwise restricted chat room or
3213 service.
3215 A resource identifier can be employed as one part of an entity's
3216 address in XMPP. One common usage is as the name for an instant
3217 messaging user's connected resource; another is as the nickname of a
3218 user in a multi-user chat room; many other kinds of entities could
3219 use resource identifiers as part of their addresses. The security of
3220 such services could be compromised based on different interpretations
3221 of the internationalized resource identifier; for example, a user
3222 could attempt to initiate multiple connections with the same name, or
3223 a user could send a message to someone other than the intended
3224 recipient in a multi-user chat room.
3226 16. IANA Considerations
3228 16.1. XML Namespace Name for TLS Data
3230 A URN sub-namespace for TLS-related data in the Extensible Messaging
3231 and Presence Protocol (XMPP) is defined as follows. (This namespace
3232 name adheres to the format defined in The IETF XML Registry
3233 [XML-REG].)
3235 URI: urn:ietf:params:xml:ns:xmpp-tls
3236 Specification: RFC 3920
3237 Description: This is the XML namespace name for TLS-related data in
3238 the Extensible Messaging and Presence Protocol (XMPP) as defined
3239 by RFC 3920.
3240 Registrant Contact: IETF, XMPP Working Group,
3242 16.2. XML Namespace Name for SASL Data
3244 A URN sub-namespace for SASL-related data in the Extensible Messaging
3245 and Presence Protocol (XMPP) is defined as follows. (This namespace
3246 name adheres to the format defined in [XML-REG].)
3248 URI: urn:ietf:params:xml:ns:xmpp-sasl
3249 Specification: RFC 3920
3250 Description: This is the XML namespace name for SASL-related data in
3251 the Extensible Messaging and Presence Protocol (XMPP) as defined
3252 by RFC 3920.
3253 Registrant Contact: IETF, XMPP Working Group,
3255 16.3. XML Namespace Name for Stream Errors
3257 A URN sub-namespace for stream-related error data in the Extensible
3258 Messaging and Presence Protocol (XMPP) is defined as follows. (This
3259 namespace name adheres to the format defined in [XML-REG].)
3260 URI: urn:ietf:params:xml:ns:xmpp-streams
3261 Specification: RFC 3920
3262 Description: This is the XML namespace name for stream-related error
3263 data in the Extensible Messaging and Presence Protocol (XMPP) as
3264 defined by RFC 3920.
3265 Registrant Contact: IETF, XMPP Working Group,
3267 16.4. XML Namespace Name for Resource Binding
3269 A URN sub-namespace for resource binding in the Extensible Messaging
3270 and Presence Protocol (XMPP) is defined as follows. (This namespace
3271 name adheres to the format defined in [XML-REG].)
3273 URI: urn:ietf:params:xml:ns:xmpp-bind
3274 Specification: RFC 3920
3275 Description: This is the XML namespace name for resource binding in
3276 the Extensible Messaging and Presence Protocol (XMPP) as defined
3277 by RFC 3920.
3278 Registrant Contact: IETF, XMPP Working Group,
3280 16.5. XML Namespace Name for Stanza Errors
3282 A URN sub-namespace for stanza-related error data in the Extensible
3283 Messaging and Presence Protocol (XMPP) is defined as follows. (This
3284 namespace name adheres to the format defined in [XML-REG].)
3286 URI: urn:ietf:params:xml:ns:xmpp-stanzas
3287 Specification: RFC 3920
3288 Description: This is the XML namespace name for stanza-related error
3289 data in the Extensible Messaging and Presence Protocol (XMPP) as
3290 defined by RFC 3920.
3291 Registrant Contact: IETF, XMPP Working Group,
3293 16.6. Nodeprep Profile of Stringprep
3295 The Nodeprep profile of stringprep is defined under Nodeprep
3296 (Appendix A). The IANA has registered Nodeprep in the stringprep
3297 profile registry.
3299 Name of this profile:
3301 Nodeprep
3303 RFC in which the profile is defined:
3305 RFC 3920
3307 Indicator whether or not this is the newest version of the profile:
3309 This is the first version of Nodeprep
3311 16.7. Resourceprep Profile of Stringprep
3313 The Resourceprep profile of stringprep is defined under Resourceprep
3314 (Appendix B). The IANA has registered Resourceprep in the stringprep
3315 profile registry.
3317 Name of this profile:
3319 Resourceprep
3321 RFC in which the profile is defined:
3323 RFC 3920
3325 Indicator whether or not this is the newest version of the profile:
3327 This is the first version of Resourceprep
3329 16.8. GSSAPI Service Name
3331 The IANA has registered "xmpp" as a GSSAPI [GSS-API] service name, as
3332 defined under SASL Definition (Section 7.3).
3334 16.9. Port Numbers
3336 The IANA has registered "xmpp-client" and "xmpp-server" as keywords
3337 for [TCP] ports 5222 and 5269 respectively.
3339 These ports SHOULD be used for client-to-server and server-to-server
3340 communications respectively, but their use is OPTIONAL.
3342 17. References
3344 17.1. Normative References
3346 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
3347 Specifications: ABNF", RFC 4234, October 2005.
3349 [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data
3350 Encodings", RFC 4648, October 2006.
3352 [CHARSET] Alvestrand, H., "IETF Policy on Character Sets and
3353 Languages", BCP 18, RFC 2277, January 1998.
3355 [DIGEST-MD5]
3356 Leach, P. and C. Newman, "Using Digest Authentication as a
3357 SASL Mechanism", RFC 2831, May 2000.
3359 [DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
3360 specifying the location of services (DNS SRV)", RFC 2782,
3361 February 2000.
3363 [DNS] Mockapetris, P., "Domain names - implementation and
3364 specification", STD 13, RFC 1035, November 1987.
3366 [GSS-API] Linn, J., "Generic Security Service Application Program
3367 Interface Version 2, Update 1", RFC 2743, January 2000.
3369 [HMAC] National Institute of Standards and Technology, "The
3370 Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB
3371 198, March 2002, .
3374 [HTTP-TLS]
3375 Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
3377 [IDNA] Faltstrom, P., Hoffman, P., and A. Costello,
3378 "Internationalizing Domain Names in Applications (IDNA)",
3379 RFC 3490, March 2003.
3381 [IPv6] Hinden, R. and S. Deering, "IP Version 6 Addressing
3382 Architecture", RFC 4291, February 2006.
3384 [LANGTAGS]
3385 Phillips, A. and M. Davis, "Tags for Identifying
3386 Languages", BCP 47, RFC 4646, September 2006.
3388 [NAMEPREP]
3389 Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
3390 Profile for Internationalized Domain Names (IDN)",
3391 RFC 3491, March 2003.
3393 [PUNYCODE]
3394 Costello, A., "Punycode: A Bootstring encoding of Unicode
3395 for Internationalized Domain Names in Applications
3396 (IDNA)", RFC 3492, March 2003.
3398 [RANDOM] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
3399 Requirements for Security", BCP 106, RFC 4086, June 2005.
3401 [SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and
3402 Security Layer (SASL)", RFC 4422, June 2006.
3404 [SHA] National Institute of Standards and Technology, "Secure
3405 Hash Standard", FIPS PUB 180-2, August 2002, .
3409 [STRINGPREP]
3410 Hoffman, P. and M. Blanchet, "Preparation of
3411 Internationalized Strings ("stringprep")", RFC 3454,
3412 December 2002.
3414 [TCP] Postel, J., "Transmission Control Protocol", STD 7,
3415 RFC 793, September 1981.
3417 [TERMS] Bradner, S., "Key words for use in RFCs to Indicate
3418 Requirement Levels", BCP 14, RFC 2119, March 1997.
3420 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security
3421 (TLS) Protocol Version 1.1", RFC 4346, April 2006.
3423 [UCS2] International Organization for Standardization,
3424 "Information Technology - Universal Multiple-octet coded
3425 Character Set (UCS) - Amendment 2: UCS Transformation
3426 Format 8 (UTF-8)", ISO Standard 10646-1 Addendum 2,
3427 October 1996.
3429 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
3430 10646", STD 63, RFC 3629, November 2003.
3432 [X509] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
3433 X.509 Public Key Infrastructure Certificate and
3434 Certificate Revocation List (CRL) Profile", RFC 3280,
3435 April 2002.
3437 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler,
3438 "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-
3439 xml, October 2000, .
3441 [XML-NAMES]
3442 Bray, T., Hollander, D., and A. Layman, "Namespaces in
3443 XML", W3C REC-xml-names, January 1999,
3444 .
3446 17.2. Informative References
3448 [ACAP] Newman, C. and J. Myers, "ACAP -- Application
3449 Configuration Access Protocol", RFC 2244, November 1997.
3451 [ASN.1] CCITT, "Recommendation X.208: Specification of Abstract
3452 Syntax Notation One (ASN.1)", 1988.
3454 [DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S.
3455 Rose, "DNS Security Introduction and Requirements",
3456 RFC 4033, March 2005.
3458 [DNS-TXT] Rosenbaum, R., "Using the Domain Name System To Store
3459 Arbitrary String Attributes", RFC 1464, May 1993.
3461 [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
3462 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
3463 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
3465 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
3466 4rev1", RFC 3501, March 2003.
3468 [IMP-REQS]
3469 Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging
3470 / Presence Protocol Requirements", RFC 2779,
3471 February 2000.
3473 [IRI] Duerst, M. and M. Suignard, "Internationalized Resource
3474 Identifiers (IRIs)", RFC 3987, January 2005.
3476 [LINKLOCAL]
3477 Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
3478 Configuration of IPv4 Link-Local Addresses", RFC 3927,
3479 May 2005.
3481 [MAILBOXES]
3482 Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND
3483 FUNCTIONS", RFC 2142, May 1997.
3485 [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
3486 STD 53, RFC 1939, May 1996.
3488 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
3489 April 2001.
3491 [STD13] Mockapetris, P., "Domain names - implementation and
3492 specification", STD 13, RFC 1035, November 1987.
3494 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
3495 Resource Identifier (URI): Generic Syntax", STD 66,
3496 RFC 3986, January 2005.
3498 [URN-OID] Mealling, M., "A URN Namespace of Object Identifiers",
3499 RFC 3061, February 2001.
3501 [USINGTLS]
3502 Newman, C., "Using TLS with IMAP, POP3 and ACAP",
3503 RFC 2595, June 1999.
3505 [XEP-0045]
3506 Saint-Andre, P., "Multi-User Chat", XSF XEP 0045,
3507 April 2007.
3509 [XEP-0071]
3510 Saint-Andre, P., "XHTML-IM", XSF XEP 0071, March 2007.
3512 [XEP-0077]
3513 Saint-Andre, P., "In-Band Registration", XSF XEP 0077,
3514 January 2006.
3516 [XEP-0086]
3517 Norris, R. and P. Saint-Andre, "Error Condition Mappings",
3518 XSF XEP 0086, February 2004.
3520 [XEP-0124]
3521 Paterson, I., Smith, D., and P. Saint-Andre,
3522 "Bidirectional-streams Over Synchronous HTTP (BOSH)", XSF
3523 XEP 0124, February 2007.
3525 [XEP-0156]
3526 Hildebrand, J. and P. Saint-Andre, "Discovering
3527 Alternative XMPP Connection Methods", XSF XEP 0156,
3528 January 2007.
3530 [XEP-0157]
3531 Saint-Andre, P. and J. Konieczny, "Contact Addresses for
3532 XMPP Services", XSF XEP 0157, January 2007.
3534 [XEP-0174]
3535 Saint-Andre, P., "Link-Local Messaging", XSF XEP 0174,
3536 March 2007.
3538 [XEP-0175]
3539 Saint-Andre, P., "Best Practices for Use of SASL
3540 ANONYMOUS", XSF XEP 0175, September 2006.
3542 [XEP-0178]
3543 Saint-Andre, P. and P. Millard, "Best Practices for Use of
3544 SASL EXTERNAL with Certificates", XSF XEP 0178,
3545 February 2007.
3547 [XEP-0206]
3548 Paterson, I., "XMPP Over BOSH", XSF XEP 0206,
3549 February 2007.
3551 [XML-REG] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
3552 January 2004.
3554 [XMPP-IM] Saint-Andre, P., "Extensible Messaging and Presence
3555 Protocol (XMPP): Instant Messaging and Presence",
3556 draft-saintandre-rfc3921bis-02 (work in progress),
3557 April 2007.
3559 [XMPP-URI]
3560 Saint-Andre, P., "Internationalized Resource Identifiers
3561 (IRIs) and Uniform Resource Identifiers (URIs) for the
3562 Extensible Messaging and Presence Protocol (XMPP)",
3563 draft-saintandre-rfc4622bis-00 (work in progress),
3564 April 2007.
3566 Appendix A. Nodeprep
3568 A.1. Introduction
3570 This appendix defines the "Nodeprep" profile of [STRINGPREP]. As
3571 such, it specifies processing rules that will enable users to enter
3572 internationalized node identifiers in the Extensible Messaging and
3573 Presence Protocol (XMPP) and have the highest chance of getting the
3574 content of the strings correct. (An XMPP node identifier is the
3575 optional portion of an XMPP address that precedes a domain identifier
3576 and the '@' separator; it is often but not exclusively associated
3577 with an instant messaging username.) These processing rules are
3578 intended only for XMPP node identifiers and are not intended for
3579 arbitrary text or any other aspect of an XMPP address.
3581 This profile defines the following, as required by [STRINGPREP]:
3583 o The intended applicability of the profile: internationalized node
3584 identifiers within XMPP
3585 o The character repertoire that is the input and output to
3586 stringprep: Unicode 3.2, specified in Section 2 of this Appendix
3588 o The mappings used: specified in Section 3
3589 o The Unicode normalization used: specified in Section 4
3590 o The characters that are prohibited as output: specified in Section
3591 5
3592 o Bidirectional character handling: specified in Section 6
3594 A.2. Character Repertoire
3596 This profile uses Unicode 3.2 with the list of unassigned code points
3597 being Table A.1, both defined in Appendix A of [STRINGPREP].
3599 A.3. Mapping
3601 This profile specifies mapping using the following tables from
3602 [STRINGPREP]:
3604 Table B.1
3605 Table B.2
3607 A.4. Normalization
3609 This profile specifies the use of Unicode normalization form KC, as
3610 described in [STRINGPREP].
3612 A.5. Prohibited Output
3614 This profile specifies the prohibition of using the following tables
3615 from [STRINGPREP].
3617 Table C.1.1
3618 Table C.1.2
3619 Table C.2.1
3620 Table C.2.2
3621 Table C.3
3622 Table C.4
3623 Table C.5
3624 Table C.6
3625 Table C.7
3626 Table C.8
3627 Table C.9
3629 In addition, the following Unicode characters are also prohibited:
3631 #x22 (")
3632 #x26 (&)
3633 #x27 (')
3634 #x2F (/)
3635 #x3A (:)
3636 #x3C (<)
3637 #x3E (>)
3638 #x40 (@)
3640 A.6. Bidirectional Characters
3642 This profile specifies checking bidirectional strings, as described
3643 in Section 6 of [STRINGPREP].
3645 Appendix B. Resourceprep
3647 B.1. Introduction
3649 This appendix defines the "Resourceprep" profile of [STRINGPREP]. As
3650 such, it specifies processing rules that will enable users to enter
3651 internationalized resource identifiers in the Extensible Messaging
3652 and Presence Protocol (XMPP) and have the highest chance of getting
3653 the content of the strings correct. (An XMPP resource identifier is
3654 the optional portion of an XMPP address that follows a domain
3655 identifier and the '/' separator.) These processing rules are
3656 intended only for XMPP resource identifiers and are not intended for
3657 arbitrary text or any other aspect of an XMPP address.
3659 This profile defines the following, as required by [STRINGPREP]:
3661 o The intended applicability of the profile: internationalized
3662 resource identifiers within XMPP
3663 o The character repertoire that is the input and output to
3664 stringprep: Unicode 3.2, specified in Section 2 of this Appendix
3665 o The mappings used: specified in Section 3
3666 o The Unicode normalization used: specified in Section 4
3667 o The characters that are prohibited as output: specified in Section
3668 5
3669 o Bidirectional character handling: specified in Section 6
3671 B.2. Character Repertoire
3673 This profile uses Unicode 3.2 with the list of unassigned code points
3674 being Table A.1, both defined in Appendix A of [STRINGPREP].
3676 B.3. Mapping
3678 This profile specifies mapping using the following tables from
3679 [STRINGPREP]:
3681 Table B.1
3683 B.4. Normalization
3685 This profile specifies the use of Unicode normalization form KC, as
3686 described in [STRINGPREP].
3688 B.5. Prohibited Output
3690 This profile specifies the prohibition of using the following tables
3691 from [STRINGPREP].
3693 Table C.1.2
3694 Table C.2.1
3695 Table C.2.2
3696 Table C.3
3697 Table C.4
3698 Table C.5
3699 Table C.6
3700 Table C.7
3701 Table C.8
3702 Table C.9
3704 B.6. Bidirectional Characters
3706 This profile specifies checking bidirectional strings, as described
3707 in Section 6 of [STRINGPREP].
3709 Appendix C. Server Dialback
3711 C.1. Overview
3713 Server dialback is a reverse DNS lookup method whose results are
3714 communicated over XML streams, thus making it more difficult to spoof
3715 XMPP server domains and XML stanzas sent over XML streams between
3716 servers. Server dialback is not a security mechanism, and results
3717 only in weak verification of server identities (see Server-to-Server
3718 Communications (Section 15.4) regarding this method's security
3719 characteristics). Domains requiring robust security SHOULD use TLS
3720 and SASL; see Server-to-Server Communications (Section 15.4) for
3721 details. If SASL is used for server-to-server authentication,
3722 dialback SHOULD NOT be used since it is unnecessary. Documentation
3723 of dialback is included mainly for the sake of backward-compatibility
3724 with existing implementations and deployments. However, depending on
3725 local policies, a service may wish to use dialback to provide weak
3726 identity verification in cases where SASL negotiation would not
3727 result in strong authentication (e.g., because the certificate
3728 presented by the peer service during TLS negotiation is self-signed
3729 and thus provides even weaker identity verification than DNS).
3731 The server dialback method is made possible by the existence of the
3732 Domain Name System (DNS), since one server can (normally) discover
3733 the authoritative server for a given domain. Because dialback
3734 depends on DNS, inter-domain communications MUST NOT proceed until
3735 the Domain Name System (DNS) hostnames asserted by the servers have
3736 been resolved (see Server-to-Server Communications (Section 15.4)).
3738 Server dialback is uni-directional, and results in weak identity
3739 verification for one stream in one direction. Because server
3740 dialback is not an authentication mechanism, mutual authentication is
3741 not possible via dialback. Therefore, server dialback MUST be
3742 completed in each direction in order to enable bi-directional
3743 communications between two domains.
3745 The method for generating and verifying the keys used in server
3746 dialback MUST take into account the hostnames being used, the stream
3747 ID generated by the receiving server, and a secret known by the
3748 authoritative server's network; see Appendix C.5 for the recommended
3749 algorithm.
3751 Any error that occurs during dialback negotiation MUST be considered
3752 a stream error, resulting in termination of the stream and of the
3753 underlying TCP connection. The possible error conditions are
3754 specified in the protocol description below.
3756 The following terminology applies:
3758 o ORIGINATING SERVER -- the server that is attempting to establish a
3759 connection between two domains.
3760 o RECEIVING SERVER -- the server that is trying to authenticate that
3761 the Originating Server represents the domain which it claims to
3762 be.
3763 o AUTHORITATIVE SERVER -- the server that answers to the DNS
3764 hostname asserted by the Originating Server; for basic
3765 environments this will be the Originating Server, but it could be
3766 a separate machine in the Originating Server's network.
3768 C.2. Order of Events
3770 The following is a brief summary of the order of events in dialback:
3772 1. The Originating Server establishes an XML stream with the
3773 Receiving Server.
3774 2. The Originating Server sends a 'key' value over the connection to
3775 the Receiving Server.
3776 3. The Receiving Server establishes an XML stream with the
3777 Authoritative Server.
3778 4. The Receiving Server sends the same 'key' value to the
3779 Authoritative Server for verification.
3780 5. The Authoritative Server replies that key is valid or invalid.
3781 6. The Receiving Server informs the Originating Server whether it is
3782 authenticated or not.
3784 We can represent this flow of events graphically as follows:
3786 Originating Receiving
3787 Server Server
3788 ----------- ---------
3789 | |
3790 | establish stream |
3791 | ----------------------> |
3792 | | Authoritative
3793 | send dialback key | Server
3794 | ----------------------> | -------------
3795 | | |
3796 | establish stream |
3797 | ----------------------> |
3798 | |
3799 | send verify request |
3800 | ----------------------> |
3801 | |
3802 | send verify response |
3803 | <---------------------- |
3804 |
3805 | report dialback result |
3806 | <---------------------- |
3807 | |
3809 C.3. Protocol
3811 This section describes the detailed protocol interaction between the
3812 Originating Server, the Receiving Server, and the Authoritative
3813 Server.
3815 This section uses the following domain names, IP addresses, stream
3816 IDs, and shared secret in the examples:
3818 o The Originating Server is "example.org" (there is no IP address
3819 associated with this domain since it is merely asserted by the
3820 Originating Server).
3821 o The Receiving Server is "xmpp.example.com" and its IP address is
3822 "192.0.2.0".
3823 o The Authoritative Server is "example.org" and its IP address is
3824 "192.0.2.1".
3825 o The stream ID of the stream from the Originating Server to the
3826 Receiving Server is "D60000229F".
3827 o The shared secret known by the Authoritative Server's network is
3828 "s3cr3tf0rd14lb4ck".
3829 o The stream ID of the stream from the Receiving Server to the
3830 Authoritative Server is "F92200006D".
3832 To assist the reader, the following conventions are used to clarify
3833 the flow of packets:
3835 o "O2R:" -- packets sent from the Originating Server to the
3836 Receiving Server.
3837 o "R2O:" -- packets sent from the Receiving Server to the
3838 Originating Server.
3839 o "R2A:" -- packets sent from the Receiving Server to the
3840 Authoritative Server.
3841 o "A2R:" -- packets sent from the Authoritative Server to the
3842 Receiving Server.
3844 The flow of events is as follows:
3846 1. The Originating Server (asserted to be "example.org") performs a
3847 DNS lookup for the Receiving Server (in accordance with the
3848 procedure described under Section 4) and establishes a TCP
3849 connection to the Receiving Server at the IP address and port
3850 discovered during the DNS lookup (here assumed to be "192.0.2.0"
3851 and "5269").
3852 2. The Originating Server sends a stream header to the Receiving
3853 Server:
3855 O2R:
3862 Note: The inclusion of the xmlns:db namespace declaration with
3863 the name shown indicates to the Receiving Server that the
3864 Originating Server supports server dialback. If any of the
3865 namespace names provided by the Originating Server is incorrect,
3866 then the Receiving Server MUST generate an
3867 stream error condition and terminate both the XML stream and the
3868 underlying TCP connection. If the value of the 'to' address
3869 provided by the Originating Server does not match a hostname
3870 serviced by the Receiving Server, then the Receiving Server MUST
3871 generate a stream error condition and terminate
3872 both the XML stream and the underlying TCP connection.
3873 3. The Receiving Server SHOULD send a stream header back to the
3874 Originating Server over the same TCP connection, including a
3875 unique ID for this interaction:
3877 R2O:
3885 Note: The Receiving Server SHOULD reply but MAY silently
3886 terminate the XML stream and underlying TCP connection depending
3887 on local security policies; however, if the Receiving Server
3888 desires to proceed, it MUST send a stream header back to the
3889 Originating Server. If any of the namespace names provided by
3890 the Receiving Server is incorrect, then the Originating Server
3891 MUST generate an stream error condition and
3892 terminate both the XML stream and the underlying TCP connection.
3893 If the value of the 'to' address provided by the Receiving
3894 Server does not match a hostname serviced by the Originating
3895 Server, then the Originating Server MUST generate a stream error condition and terminate both the XML
3897 stream and the underlying TCP connection.
3898 4. The Receiving Server SHOULD also send stream features to the
3899 Originating Server, including the dialback feature as described
3900 under Appendix C.6:
3902 R2O:
3903
3904
3905
3906
3908 5. The Originating Server MUST then send a dialback key to the
3909 Receiving Server:
3911 O2R:
3914 37c69b1cf07a3f67c04a5ef5902fa5114f2c76fe4a2686482ba5b89323075643
3915
3917 If the value of the 'to' address provided by the Originating
3918 Server does not match a hostname serviced by the Receiving
3919 Server, then the Receiving Server MUST generate a stream error condition and terminate both the XML
3921 stream and the underlying TCP connection. The key generated by
3922 the Originating Server MUST be based in part on the value of the
3923 ID provided by the Receiving Server in the previous step (here
3924 "D60000229F"), and in part on a secret shared by the Originating
3925 Server and the Authoritative Server (here "s3cr3tf0rd14lb4ck").
3926 Any verifiable method MAY be used to generate the key; however,
3927 the method specified under Appendix C.5 is RECOMMENDED. The key
3928 is not examined by the Receiving Server, since the key is
3929 validated by the Authoritative Server.
3930 6. The Receiving Server performs a DNS lookup for the Authoritative
3931 Server (in accordance with the procedure described under
3932 Section 4) and establishes a TCP connection to the Authoritative
3933 Server at the IP address and port discovered during the DNS
3934 lookup (here assumed to be "192.0.2.1" and "5269").
3935 7. The Receiving Server sends a stream header to the Authoritative
3936 Server:
3938 R2A:
3945 Note: If the namespace name is incorrect, then the Authoritative
3946 Server MUST generate an stream error
3947 condition and terminate both the XML stream and the underlying
3948 TCP connection. If the value of the 'to' address provided by
3949 the Receiving Server does not match a hostname serviced by the
3950 Authoritative Server, then the Authoritative Server MUST
3951 generate a stream error condition and terminate
3952 both the XML stream and the underlying TCP connection.
3953 8. The Authoritative Server sends the Receiving Server a stream
3954 header:
3956 A2R:
3964 Note: If any of the namespace names provided by the
3965 Authoritative Server is incorrect, then the Receiving Server
3966 MUST generate an stream error condition and
3967 terminate both the XML stream and the underlying TCP connection
3968 between it and the Authoritative Server. If the value of the
3969 'to' address provided by the Authoritative Server does not match
3970 a hostname serviced by the Receiving Server, then the Receiving
3971 Server MUST generate a stream error condition
3972 and terminate both the XML stream and the underlying TCP
3973 connection. If a stream error occurs between the Receiving
3974 Server and the Authoritative Server, then the Receiving Server
3975 MUST not only terminate the XML stream and the underlying TCP
3976 connection between it and the Authoritative Server but also
3977 terminate the XML stream and the underlying TCP connection
3978 between it and the Originating Server, generating a stream error for the latter stream.
3980 9. The Receiving Server sends the Authoritative Server a request
3981 for verification of a key:
3983 R2A:
3987 37c69b1cf07a3f67c04a5ef5902fa5114f2c76fe4a2686482ba5b89323075643
3988
3990 Note: Passed here are the hostnames of the Receiving Server
3991 ('from') and the Originating Server ('to'), the original
3992 identifier from the Receiving Server's stream header to the
3993 Originating Server in Step 3, and the key that the Originating
3994 Server sent to the Receiving Server in Step 5. Based on this
3995 information, as well as shared secret information within the
3996 Authoritative Server's network, the Authoritative Server
3997 determines whether the key is valid or invalid. If the value of
3998 the 'to' address does not match a hostname serviced by the
3999 Authoritative Server, then the Authoritative Server MUST
4000 generate a stream error condition and terminate
4001 both the XML stream and the underlying TCP connection. If the
4002 value of the 'from' address does not match the hostname sent by
4003 the Receiving Server in the 'from' address of the stream header
4004 it sent to the Authoritative Server in Step 7, then the
4005 Authoritative Server MUST generate an stream
4006 error condition and terminate both the XML stream and the
4007 underlying TCP connection.
4008 10. The Authoritative Server determines whether the key was valid or
4009 invalid and informs the Receiving Server of its determination:
4011 A2R:
4017 or
4019 A2R:
4025 Note: If the ID does not match that provided by the Receiving
4026 Server in Step 3, then the Receiving Server MUST generate an
4027 stream error condition and terminate both the XML
4028 stream and the underlying TCP connection. If the value of the
4029 'to' address does not match a hostname serviced by the Receiving
4030 Server, then the Receiving Server MUST generate a stream error condition and terminate both the XML
4032 stream and the underlying TCP connection. If the value of the
4033 'from' address does not match the hostname represented by the
4034 Originating Server in the 'from' address of the stream header it
4035 sent to the Receiving Server in Step 2, then the Receiving
4036 Server MUST generate an stream error condition
4037 and terminate both the XML stream and the underlying TCP
4038 connection. After returning the verification to the Receiving
4039 Server, the Authoritative Server SHOULD terminate the stream
4040 between them and the underlying TCP connection.
4041 11. The Receiving Server informs the Originating Server of the
4042 result:
4044 R2O:
4050 Note: At this point, the connection from the Originating Server
4051 to the Receiving Server has either been validated or reported as
4052 invalid. If the connection is invalid, then the Receiving
4053 Server MUST terminate both the XML stream and the underlying TCP
4054 connection between itself and the Originating Server. If the
4055 connection is valid, the Receiving Server has verified the
4056 identity of the Originating Server; as a result, the Originating
4057 Server may now send XML stanzas to the Receiving Server over the
4058 validated connection (i.e., over the "initial stream" from the
4059 Originating Server to the Receiving Server).
4061 Until the initial stream has been validated, the Receiving Server
4062 MUST silently drop all XML stanzas sent by the Originating Server to
4063 the Receiving Server.
4065 After successful dialback negotiation, the Receiving Server MUST
4066 verify that all XML stanzas received from the Originating Server
4067 include a 'from' attribute and a 'to' attribute; if a stanza does not
4068 meet this restriction, the Receiving Server MUST generate an
4069 stream error condition and terminate both the
4070 XML stream and the underlying TCP connection. Furthermore, the
4071 Receiving Server MUST verify that the 'from' attribute of stanzas
4072 received from the Originating Server includes a domain name that has
4073 been validated for the stream; if a stanza does not meet this
4074 restriction, the Receiving Server MUST generate an
4075 stream error condition and terminate both the XML stream and the
4076 underlying TCP connection. Both of these checks help to prevent
4077 spoofing related to particular stanzas.
4079 As mentioned, server dialback results in weak identity verification
4080 in one direction only (in the foregoing text, verification of the
4081 Originating Server by the Receiving Server). In order to proceed
4082 with bi-directional communication so that the Receiving Server may
4083 sent XML stanzas to the Originating Server, the Receiving Server MUST
4084 now also initiate a dialback negotiation with the Originating Server.
4086 C.4. Reuse of Negotiated Connections
4088 After the Receiving Server has validated the connection from the
4089 Originating Server, the Originating Server may wish to reuse that
4090 connection for validation of additional domains. One common
4091 motivation for such reuse is the existence of additional services
4092 associated with the Originating Server but hosted at subdomains of
4093 the Originating Server (the use of subdomains helps to ensure proper
4094 routing of XML stanzas to the hosted services). For example, the
4095 "example.org" XMPP server may host a groupchat service at
4096 "chat.example.org". In order to accept XML stanzas from rooms at
4097 "chat.example.org" intended for addresses at "xmpp.example.com", the
4098 "xmpp.example.com" will need to validate the "chat.example.org"
4099 domain (just as it already did for the "example.org" domain). Thus
4100 the "example.org" server would now initiate a dialback negotiation
4101 with "xmpp.example.com" but specify the Originating Server as
4102 "chat.example.org". Several optimizations are possible:
4104 o Because the "example.org" server already has a validated
4105 connection open to the Receiving Server ("xmpp.example.com"), it
4106 MAY send a element with the key to be validated for
4107 the new Originating Server ("chat.example.org") over the XML
4108 stream that has already been negotiated, rather than opening a new
4109 TCP connection and XML stream. The Receiving Server SHOULD accept
4110 this element rather than returning an error to the Originating
4111 Server over the previously negotiated connection.
4112 o If the Receiving Server ("xmpp.example.com") has also negotiated a
4113 valid connection in the other direction (from the Receiving Server
4114 to the Originating Server), then that connection is ipso facto a
4115 connection to the Authoritative Server for the first negotiation.
4116 Therefore the receiving server can re-use that connection for
4117 exchange of the elements associated with the second
4118 negotiation. The Authoritative Server SHOULD accept this element
4119 rather than returning an error to the Receiving Server over the
4120 previously negotiated connection.
4122 These optimizations effectively enable "piggybacking" of the
4123 previously negotiated connections.
4125 C.5. Dialback Key Generation
4127 As mentioned, the dialback key is generated based on four different
4128 pieces of information:
4130 o the hostname of the Originating Server
4131 o the hostname of the Receiving Server
4132 o the Stream ID
4133 o a shared secret known by the Authoritative Server's network
4135 The stream ID is security-critical in server dialback and therefore
4136 MUST be both unpredictable and non-repeating (see [RANDOM] for
4137 recommendations regarding randomness for security purposes).
4139 It is RECOMMENDED for the dialback key to be the hexadecimal
4140 representation of a Keyed-Hash Message Authentication Code (see
4141 [HMAC]) that uses the SHA-256 algorithm (see [SHA]), as follows:
4143 HMAC-SHA256
4144 (
4145 SHA256(secret),
4146 {'Receiving Server' 'Originating Server' 'Stream ID'}
4147 )
4148 The shared secret SHOULD either be set up in a configuration option
4149 for each host or process within the Authoritative Server's network or
4150 generated as a random string when starting each host or process. The
4151 secret's length SHOULD be at least 128 bits or 16 characters long.
4153 Consider the following scenario:
4155 o The Originating Server is "example.org"
4156 o The Receiving Server is "xmpp.example.com"
4157 o The Stream ID is "D60000229F"
4158 o The secret is "s3cr3tf0rd14lb4ck"
4160 The resulting dialback key would be:
4162 HMAC-SHA256
4163 (
4164 SHA256(secret),
4165 {'Receiving Server' 'Originating Server' 'Stream ID'}
4166 )
4168 that is,
4170 HMAC-SHA256
4171 (SHA256('s3cr3tf0rd14lb4ck'),
4172 {'xmpp.example.net',' ','example.org',' ','D60000229F'})
4174 that is,
4176 HMAC-SHA256
4177 ('a7136eb1f46c9ef18c5e78c36ca257067c69b3d518285f0b18a96c33beae9acc',
4178 {'xmpp.example.com example.org D60000229F'})
4180 that is,
4182 37c69b1cf07a3f67c04a5ef5902fa5114f2c76fe4a2686482ba5b89323075643
4184 C.6. Advertisement
4186 Support for the server dialback protocol can be indicated in two
4187 ways:
4189 1. By inclusion of the server dialback feature in a given set of
4190 stream features.
4191 2. By inclusion of the dialback namespace declaration in the stream
4192 header.
4194 The former method is preferred, but the latter method is also
4195 specified herein for the purpose of backwards-compatibility with
4196 older "XMPP 0.9" deployments.
4198 The server dialback stream feature is advertised by including in any
4199 given set of stream features a element qualified by the
4200 'urn:xmpp:features:dialback' namespace; the element MAY
4201 also include an empty element, indicating that the entity
4202 sending the stream features requires dialback to be negotiated for
4203 the stream.
4205 Server2 informs Server1 that it supports (and requires) server
4206 dialback:
4208
4209
4210
4211
4212
4214 As mentioned, support for the server dialback protocol can also be
4215 advertised by including the dialback namespace declaration in a
4216 stream header.
4218
4225 No matter which method is used, a service SHOULD advertise support
4226 for server dialback only at a point in the stream negotiation when it
4227 will accept negotiation of server dialback for that stream. For
4228 example, if a service wishes to be backwards-compatible with older
4229 "XMPP 0.9" deployments, it SHOULD include the server dialback
4230 namespace declaration in the initial stream header it sends to other
4231 servers (so that "XMPP 0.9" servers can proceed with dialback in the
4232 absence of TLS and SASL authentication). However, in the midst of
4233 stream negotiation with an XMPP 1.0 or higher server, a service
4234 SHOULD advertise the dialback stream feature only at a point when
4235 negotiation of server dialback is allowed in accordance with local
4236 service policies (e.g., after TLS negotiation in the case when a
4237 self-signed certificate was presented by the Originating Server and
4238 local service policies stipulate that it is preferable to weakly
4239 identify the Originating Server via server dialback rather than
4240 depend on the self-signed certificate for identity verification).
4242 Appendix D. XML Schemas
4244 The following XML schemas are descriptive, not normative. For
4245 schemas defining the 'jabber:client' and 'jabber:server' namespaces,
4246 refer to [XMPP-IM].
4248 D.1. Streams namespace
4250
4252
4258
4259
4260
4262
4263
4264
4267
4268
4271
4274
4275
4276
4277
4278
4279
4280
4281
4282
4283
4284
4285
4286
4287
4288
4289
4290
4291
4292
4293
4294
4295
4296
4298
4299
4300
4301
4302
4304
4305
4306
4307
4308
4311
4312
4313
4315
4317 D.2. Stream error namespace
4319
4321
4327
4328
4329
4330
4331
4332
4333
4334
4335
4336
4337
4338
4339
4340
4341
4342
4343
4344
4345
4346
4347
4348
4349
4350
4352
4353
4354
4355
4356
4357
4358
4359
4360
4361
4362
4363
4364
4365
4366
4367
4368
4369
4370
4371
4372
4373
4374
4375
4376
4377
4378
4379
4381
4382
4383
4384
4385
4387
4388
4389
4390
4392
4393
4394
4395
4396
4398
4400 D.3. TLS namespace
4402
4404
4410
4411
4412
4413
4416
4417
4418
4420
4421
4423
4424
4425
4426
4427
4429
4431 D.4. SASL namespace
4433
4434
4440
4441
4442
4443
4446
4449
4450
4451
4453
4454
4455
4456
4457
4460
4461
4462
4463
4465
4466
4467
4468
4470
4471
4472
4473
4474
4475
4476
4477
4478
4479
4480
4481
4483
4484
4486
4487
4488
4489
4490
4492
4494 D.5. Resource binding namespace
4495
4497
4503
4504
4505
4506
4507
4508
4509
4510
4514
4515
4516
4517
4519
4520
4521
4522
4523
4524
4525
4527
4528
4529
4530
4531
4532
4534
4535
4536
4537
4538
4539
4541
4543 D.6. Dialback namespace
4544
4546
4552
4553
4554
4555
4556
4557
4558
4559
4560
4561
4562
4563
4564
4565
4566
4567
4568
4569
4571
4572
4573
4574
4575
4576
4577
4578
4579
4580
4581
4582
4583
4584
4585
4586
4587
4588
4589
4591
4593 D.7. Server dialback stream feature namespace
4595
4597
4603
4604
4605
4606
4610
4611
4613
4614
4615
4616
4617
4619
4621 D.8. Stanza error namespace
4623
4625
4631
4632
4633
4634
4635
4636
4637
4638
4639
4640
4641
4642
4643
4644
4645
4646
4647
4648
4649
4650
4651
4652
4654
4655
4656
4657
4658
4659
4660
4661
4662
4663
4664
4665
4666
4667
4668
4669
4670
4671
4672
4673
4674
4675
4676
4677
4678
4679
4681
4682
4683
4684
4685
4686
4687
4688
4690
4692
4693
4694
4695
4696
4698
4700 Appendix E. Contact Addresses
4702 Consistent with [MAILBOXES], an organization that offers an XMPP
4703 service SHOULD provide an Internet mailbox of "XMPP" for inquiries
4704 related to that service, where the host portion of the resulting
4705 mailto URI SHOULD be the organization's domain, not necessarily the
4706 domain of the XMPP service itself (e.g., the XMPP service might be
4707 offered at im.example.net but the Internet mailbox should be
4708 ).
4710 In addition, the XMPP service SHOULD provide a way to discover the
4711 XMPP contact address(es) of the service administrator(s), as
4712 specified in [XEP-0157].
4714 Appendix F. Differences From RFC 3920
4716 Based on consensus derived from implementation and deployment
4717 experience as well as formal interoperability testing, the following
4718 modifications were made from RFC 3920. In addition, several other
4719 changes were made to more clearly specify and explain the protocols.
4721 o Corrected the ABNF syntax for JIDs to prevent zero-length node
4722 identifiers, domain identifiers, and resource identifiers.
4723 o Corrected the nameprep processing rules to require use of the
4724 UseSTD3ASCIIRules flag.
4725 o Encouraged use of the 'from' and 'to' attributes stream headers.
4726 o More clearly specified stream closing handshake.
4727 o Specified recommended stream reconnection algorithm.
4728 o Specified return of stream error in response to
4729 receipt of restricted XML.
4730 o Specified that SASL mechanisms must be sent both before and after
4731 negotiation of TLS and of SASL security layers.
4732 o Specified that TLS plus SASL PLAIN is a mandatory-to-implement
4733 technology for client-to-server connections, since implementation
4734 of SASL EXTERNAL is uncommon in XMPP clients, in part because
4735 underlying security features such as X.509 certificates are not
4736 yet widely deployed.
4737 o Added the SASL error condition to handle an
4738 error case discussed in RFC 4422.
4739 o More clearly specified binding of multiple resources to the same
4740 stream.
4741 o Added the stanza error condition to enable
4742 potential ETags usage.
4743 o Added the stanza error condition to provide
4744 appropriate handling of stanzas when multiple resources are bound
4745 to the same stream.
4746 o Added section on advertisement of server dialback support,
4747 including server dialback stream feature.
4748 o Recommended use of HMAC-SHA256 for generation of server dialback
4749 key.
4751 Author's Address
4753 Peter Saint-Andre (editor)
4754 XMPP Standards Foundation
4756 Email: stpeter@jabber.org
4757 URI: xmpp:stpeter@jabber.org
4759 Full Copyright Statement
4761 Copyright (C) The IETF Trust (2007).
4763 This document is subject to the rights, licenses and restrictions
4764 contained in BCP 78, and except as set forth therein, the authors
4765 retain all their rights.
4767 This document and the information contained herein are provided on an
4768 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
4769 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
4770 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
4771 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
4772 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
4773 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
4775 Intellectual Property
4777 The IETF takes no position regarding the validity or scope of any
4778 Intellectual Property Rights or other rights that might be claimed to
4779 pertain to the implementation or use of the technology described in
4780 this document or the extent to which any license under such rights
4781 might or might not be available; nor does it represent that it has
4782 made any independent effort to identify any such rights. Information
4783 on the procedures with respect to rights in RFC documents can be
4784 found in BCP 78 and BCP 79.
4786 Copies of IPR disclosures made to the IETF Secretariat and any
4787 assurances of licenses to be made available, or the result of an
4788 attempt made to obtain a general license or permission for the use of
4789 such proprietary rights by implementers or users of this
4790 specification can be obtained from the IETF on-line IPR repository at
4791 http://www.ietf.org/ipr.
4793 The IETF invites any interested party to bring to its attention any
4794 copyrights, patents or patent applications, or other proprietary
4795 rights that may cover technology that may be required to implement
4796 this standard. Please address the information to the IETF at
4797 ietf-ipr@ietf.org.
4799 Acknowledgment
4801 Funding for the RFC Editor function is provided by the IETF
4802 Administrative Support Activity (IASA).