idnits 2.17.1
draft-saintandre-rfc3920bis-01.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 14.
-- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on
line 4736.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4747.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4754.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4760.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
== There are 1 instance of lines with non-RFC2606-compliant FQDNs in the
document.
-- 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 4269 has weird spacing: '...equence xmlns...'
== Line 4270 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 (January 26, 2007) is 6301 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 555
-- Looks like a reference, but probably isn't: '3' on line 2889
** Obsolete normative reference: RFC 4234 (ref. 'ABNF') (Obsoleted by RFC
5234)
** Obsolete normative reference: RFC 3548 (ref. 'BASE64') (Obsoleted by RFC
4648)
** 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 3513 (ref. 'IPv6') (Obsoleted by RFC
4291)
** Obsolete normative reference: RFC 3066 (ref. 'LANGTAGS') (Obsoleted by
RFC 4646, RFC 4647)
** Obsolete normative reference: RFC 3491 (ref. 'NAMEPREP') (Obsoleted by
RFC 5891)
** Obsolete normative reference: RFC 1750 (ref. 'RANDOM') (Obsoleted by RFC
4086)
-- 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 2535 (ref.
'DNSSEC') (Obsoleted by RFC 4033, RFC 4034, RFC 4035)
-- 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)
-- Obsolete informational reference (is this intentional?): RFC 3921 (ref.
'XMPP-IM') (Obsoleted by RFC 6121)
-- Obsolete informational reference (is this intentional?): RFC 4622 (ref.
'XMPP-URI') (Obsoleted by RFC 5122)
Summary: 14 errors (**), 0 flaws (~~), 8 warnings (==), 22 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 Expires: July 30, 2007 January 26, 2007
6 Extensible Messaging and Presence Protocol (XMPP): Core
7 draft-saintandre-rfc3920bis-01
9 Status of this Memo
11 By submitting this Internet-Draft, each author represents that any
12 applicable patent or other IPR claims of which he or she is aware
13 have been or will be disclosed, and any of which he or she becomes
14 aware will be disclosed, in accordance with Section 6 of BCP 79.
16 Internet-Drafts are working documents of the Internet Engineering
17 Task Force (IETF), its areas, and its working groups. Note that
18 other groups may also distribute working documents as Internet-
19 Drafts.
21 Internet-Drafts are draft documents valid for a maximum of six months
22 and may be updated, replaced, or obsoleted by other documents at any
23 time. It is inappropriate to use Internet-Drafts as reference
24 material or to cite them other than as "work in progress."
26 The list of current Internet-Drafts can be accessed at
27 http://www.ietf.org/ietf/1id-abstracts.txt.
29 The list of Internet-Draft Shadow Directories can be accessed at
30 http://www.ietf.org/shadow.html.
32 This Internet-Draft will expire on July 30, 2007.
34 Copyright Notice
36 Copyright (C) The IETF Trust (2007).
38 Abstract
40 This memo defines the core features of the Extensible Messaging and
41 Presence Protocol (XMPP), a technology for streaming Extensible
42 Markup Language (XML) elements in order to exchange structured
43 information in close to real time between any two network-aware
44 entities. XMPP provides a generalized, extensible framework for
45 incrementally exchanging XML data, upon which a variety of
46 applications can be built. The framework includes methods for stream
47 setup and teardown, channel encryption, authentication of a client to
48 a server and of one server to another server, and primitives for
49 push-style messages, publication of presence and availability
50 information, and request-response interactions between any two XMPP
51 entities. This document also specifies the format for XMPP
52 addresses, which are fully internationalizable.
54 This document obsoletes RFC 3920.
56 Table of Contents
58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
59 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
60 1.2. Functional Summary . . . . . . . . . . . . . . . . . . . 5
61 1.3. Conventions . . . . . . . . . . . . . . . . . . . . . . 6
62 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 6
63 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
64 2.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 7
65 2.3. Client . . . . . . . . . . . . . . . . . . . . . . . . . 7
66 2.4. Network . . . . . . . . . . . . . . . . . . . . . . . . 7
67 3. Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 8
68 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 8
69 3.2. Domain Identifier . . . . . . . . . . . . . . . . . . . 9
70 3.3. Node Identifier . . . . . . . . . . . . . . . . . . . . 9
71 3.4. Resource Identifier . . . . . . . . . . . . . . . . . . 10
72 3.5. Determination of Addresses . . . . . . . . . . . . . . . 10
73 4. TCP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 11
74 5. XML Streams . . . . . . . . . . . . . . . . . . . . . . . . . 12
75 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 12
76 5.2. Stream Security . . . . . . . . . . . . . . . . . . . . 14
77 5.3. Stream Attributes . . . . . . . . . . . . . . . . . . . 14
78 5.4. Namespace Declarations . . . . . . . . . . . . . . . . . 17
79 5.5. Stream Features . . . . . . . . . . . . . . . . . . . . 18
80 5.6. Closing Streams . . . . . . . . . . . . . . . . . . . . 18
81 5.7. Reconnection . . . . . . . . . . . . . . . . . . . . . . 19
82 5.8. Stream Errors . . . . . . . . . . . . . . . . . . . . . 19
83 5.9. Simplified Stream Examples . . . . . . . . . . . . . . . 23
84 6. TLS Negotiation . . . . . . . . . . . . . . . . . . . . . . . 24
85 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 24
86 6.2. Narrative . . . . . . . . . . . . . . . . . . . . . . . 27
87 7. SASL Negotiation . . . . . . . . . . . . . . . . . . . . . . 28
88 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 28
89 7.2. Narrative . . . . . . . . . . . . . . . . . . . . . . . 30
90 7.3. SASL Definition . . . . . . . . . . . . . . . . . . . . 32
91 7.4. SASL Errors . . . . . . . . . . . . . . . . . . . . . . 33
92 8. Resource Binding . . . . . . . . . . . . . . . . . . . . . . 33
93 8.1. Binding Multiple Resources . . . . . . . . . . . . . . . 37
94 9. XML Stanzas . . . . . . . . . . . . . . . . . . . . . . . . . 38
95 9.1. Common Attributes . . . . . . . . . . . . . . . . . . . 39
96 9.2. Basic Semantics . . . . . . . . . . . . . . . . . . . . 41
97 9.3. Stanza Errors . . . . . . . . . . . . . . . . . . . . . 43
98 9.4. Extended Namespaces . . . . . . . . . . . . . . . . . . 47
99 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 48
100 10.1. Client-to-Server . . . . . . . . . . . . . . . . . . . . 48
101 10.2. Server-to-Server Examples . . . . . . . . . . . . . . . 54
102 11. Server Rules for Handling XML Stanzas . . . . . . . . . . . . 57
103 11.1. No 'to' Address . . . . . . . . . . . . . . . . . . . . 58
104 11.2. Foreign Domain . . . . . . . . . . . . . . . . . . . . . 58
105 11.3. Subdomain . . . . . . . . . . . . . . . . . . . . . . . 59
106 11.4. Mere Domain or Specific Resource . . . . . . . . . . . . 59
107 11.5. Node in Same Domain . . . . . . . . . . . . . . . . . . 59
108 12. XML Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 60
109 12.1. Restrictions . . . . . . . . . . . . . . . . . . . . . . 60
110 12.2. XML Namespace Names and Prefixes . . . . . . . . . . . . 60
111 12.3. Validation . . . . . . . . . . . . . . . . . . . . . . . 62
112 12.4. Inclusion of Text Declaration . . . . . . . . . . . . . 62
113 12.5. Character Encoding . . . . . . . . . . . . . . . . . . . 62
114 12.6. White Space . . . . . . . . . . . . . . . . . . . . . . 62
115 13. Compliance Requirements . . . . . . . . . . . . . . . . . . . 62
116 13.1. Servers . . . . . . . . . . . . . . . . . . . . . . . . 63
117 13.2. Clients . . . . . . . . . . . . . . . . . . . . . . . . 63
118 14. Internationalization Considerations . . . . . . . . . . . . . 64
119 15. Security Considerations . . . . . . . . . . . . . . . . . . . 64
120 15.1. High Security . . . . . . . . . . . . . . . . . . . . . 64
121 15.2. Certificate Validation . . . . . . . . . . . . . . . . . 64
122 15.3. Client-to-Server Communications . . . . . . . . . . . . 65
123 15.4. Server-to-Server Communications . . . . . . . . . . . . 66
124 15.5. Order of Layers . . . . . . . . . . . . . . . . . . . . 66
125 15.6. Lack of SASL Channel Binding to TLS . . . . . . . . . . 67
126 15.7. Mandatory-to-Implement Technologies . . . . . . . . . . 67
127 15.8. Firewalls . . . . . . . . . . . . . . . . . . . . . . . 67
128 15.9. Use of base64 in SASL . . . . . . . . . . . . . . . . . 68
129 15.10. Stringprep Profiles . . . . . . . . . . . . . . . . . . 68
130 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69
131 16.1. XML Namespace Name for TLS Data . . . . . . . . . . . . 69
132 16.2. XML Namespace Name for SASL Data . . . . . . . . . . . . 69
133 16.3. XML Namespace Name for Stream Errors . . . . . . . . . . 69
134 16.4. XML Namespace Name for Resource Binding . . . . . . . . 70
135 16.5. XML Namespace Name for Stanza Errors . . . . . . . . . . 70
136 16.6. Nodeprep Profile of Stringprep . . . . . . . . . . . . . 70
137 16.7. Resourceprep Profile of Stringprep . . . . . . . . . . . 71
138 16.8. GSSAPI Service Name . . . . . . . . . . . . . . . . . . 71
139 16.9. Port Numbers . . . . . . . . . . . . . . . . . . . . . . 71
140 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 71
141 17.1. Normative References . . . . . . . . . . . . . . . . . . 71
142 17.2. Informative References . . . . . . . . . . . . . . . . . 73
143 Appendix A. Nodeprep . . . . . . . . . . . . . . . . . . . . . . 76
144 A.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 76
145 A.2. Character Repertoire . . . . . . . . . . . . . . . . . . 76
146 A.3. Mapping . . . . . . . . . . . . . . . . . . . . . . . . 76
147 A.4. Normalization . . . . . . . . . . . . . . . . . . . . . 77
148 A.5. Prohibited Output . . . . . . . . . . . . . . . . . . . 77
149 A.6. Bidirectional Characters . . . . . . . . . . . . . . . . 77
150 Appendix B. Resourceprep . . . . . . . . . . . . . . . . . . . . 77
151 B.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 77
152 B.2. Character Repertoire . . . . . . . . . . . . . . . . . . 78
153 B.3. Mapping . . . . . . . . . . . . . . . . . . . . . . . . 78
154 B.4. Normalization . . . . . . . . . . . . . . . . . . . . . 78
155 B.5. Prohibited Output . . . . . . . . . . . . . . . . . . . 78
156 B.6. Bidirectional Characters . . . . . . . . . . . . . . . . 79
157 Appendix C. Server Dialback . . . . . . . . . . . . . . . . . . 79
158 C.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 79
159 C.2. Order of Events . . . . . . . . . . . . . . . . . . . . 80
160 C.3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . 81
161 C.4. Reuse of Negotiated Connections . . . . . . . . . . . . 87
162 C.5. Dialback Key Generation . . . . . . . . . . . . . . . . 88
163 C.6. Advertisement . . . . . . . . . . . . . . . . . . . . . 89
164 Appendix D. XML Schemas . . . . . . . . . . . . . . . . . . . . 91
165 D.1. Streams namespace . . . . . . . . . . . . . . . . . . . 91
166 D.2. Stream error namespace . . . . . . . . . . . . . . . . . 92
167 D.3. TLS namespace . . . . . . . . . . . . . . . . . . . . . 94
168 D.4. SASL namespace . . . . . . . . . . . . . . . . . . . . . 94
169 D.5. Resource binding namespace . . . . . . . . . . . . . . . 96
170 D.6. Dialback namespace . . . . . . . . . . . . . . . . . . . 98
171 D.7. Server dialback stream feature namespace . . . . . . . . 100
172 D.8. Stanza error namespace . . . . . . . . . . . . . . . . . 100
173 Appendix E. Contact Addresses . . . . . . . . . . . . . . . . . 102
174 Appendix F. Differences From RFC 3920 . . . . . . . . . . . . . 102
175 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 103
176 Intellectual Property and Copyright Statements . . . . . . . . . 104
178 1. Introduction
180 1.1. Overview
182 The Extensible Messaging and Presence Protocol (XMPP) is an
183 Extensible Markup Language XML [XML] technology for near-real-time
184 messaging, presence, and request-response services. The basic syntax
185 and semantics were developed originally within the Jabber open-source
186 community, mainly in 1999. In 2002, the XMPP WG was chartered with
187 developing an adaptation of the core Jabber protocol that would be
188 suitable as an IETF instant messaging (IM) and presence technology.
189 As a result of work by the XMPP WG as well as implementation
190 experience and interoperability testing completed since the
191 publication of RFC 3920, this document defines the core features of
192 XMPP 1.0; the extensions required to provide the instant messaging
193 and presence functionality defined in [IMP-REQS] are specified in
194 [XMPP-IM].
196 This document obsoletes RFC 3920.
198 1.2. Functional Summary
200 The purpose of XMPP is to enable the exchange of relatively small
201 pieces of structured data (called "XML stanzas") over a network
202 between any two (or more) entities. XMPP is implemented using a
203 client-server architecture, wherein a client must connect to a server
204 in order to gain access to the network and thus be allowed to
205 exchange XML stanzas with other entities. The process whereby a
206 client connects to a server, exchanges XML stanzas, and ends the
207 connection is as follows:
209 1. Determine the hostname and port at which to connect
210 2. Open a TCP connection
211 3. Open an XML stream
212 4. Complete TLS negotiation for channel encryption (RECOMMENDED)
213 5. Complete SASL negotiation for authentication
214 6. Bind a resource to the stream
215 7. Exchange XML stanzas with other entities on the network
216 8. Close the stream when further communications are not needed or
217 desired
218 9. Close the TCP connection.
220 In the sections following discussion of XMPP architecture and XMPP
221 addresses, this document specifies how clients connect to servers and
222 specifies the basic semantics of XML stanzas, but does not define the
223 "payloads" of the XML stanzas that might be exchanged once a
224 connection is successfully established; instead, definition of such
225 semantics is provided by various XMPP extensions (e.g., [XMPP-IM] for
226 basic instant messaging and presence applications).
228 Within the client-server architecture used by XMPP, one server may
229 optionally connect to another server to enable inter-domain or inter-
230 server communication. For this to happen, the two servers must
231 negotiate a connection between themselves and then exchange XML
232 stanzas; the process for doing so is as follows:
234 1. Determine the hostname and port at which to connect
235 2. Open a TCP connection
236 3. Open an XML stream
237 4. Complete TLS negotiation for channel encryption (RECOMMENDED)
238 5. Complete SASL negotiation for authentication
239 6. Exchange XML stanzas both directly for the servers and indirectly
240 on behalf of entities associated with each server (e.g.,
241 connected clients)
242 7. Close the stream when further communications are not needed or
243 desired
244 8. Close the TCP connection.
246 Note: Depending on local policies, a service may wish to use server
247 dialback to provide weak verification in cases where SASL negotiation
248 would not result in strong authentication (e.g., because the
249 certificate presented by the peer service during TLS negotiation is
250 self-signed and thus provides only weak identity); for details, see
251 Appendix C.
253 1.3. Conventions
255 The following keywords are to be interpreted as described in [TERMS]:
256 "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD",
257 "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".
259 In examples, lines have been wrapped for improved readability.
261 2. Architecture
263 2.1. Overview
265 XMPP assumes a client-server architecture, wherein a client utilizing
266 XMPP accesses a server (normally over a [TCP] connection) and servers
267 can also communicate with each other over TCP connections.
268 Architectures that use the syntax of XML stanzas (Section 9) but that
269 establish peer-to-peer connections directly between clients using
270 technologies based on [LINKLOCAL] have been deployed, but such
271 architectures are not XMPP and are best described as "XMPP-like"; for
272 details, see [XEP-0174].
274 An architectural diagram for a typical deployment is shown here,
275 where the entities have the following significance:
277 o romeo@example.net -- an XMPP user.
278 o example.net -- an XMPP server.
279 o juliet@example.com -- an XMPP user.
280 o example.com -- an XMPP server.
282 example.net----------------------example.com
283 | |
284 | |
285 romeo@example.net juliet@example.com
287 2.2. Server
289 A server acts as an intelligent abstraction layer for XMPP
290 communications. Its primary responsibilities are:
292 o to manage connections from other entities, in the form of XML
293 streams (Section 5) to and from authorized clients, servers, and
294 other entities
295 o to route appropriately-addressed XML stanzas (Section 9) among
296 such entities over XML streams
298 Most XMPP-compliant servers also assume responsibility for the
299 storage of data that is used by clients (e.g., contact lists for
300 users of XMPP-based instant messaging and presence applications); in
301 this case, the XML data is processed directly by the server itself on
302 behalf of the client and is not routed to another entity.
304 2.3. Client
306 Most clients connect directly to a server over a [TCP] connection and
307 use XMPP to take full advantage of the functionality provided by a
308 server and any associated services. Multiple resources (e.g.,
309 devices or locations) MAY connect simultaneously to a server on
310 behalf of each authorized client, with each resource differentiated
311 by the resource identifier of an XMPP address (e.g.,
312 vs. ) as defined under Addresses
313 (Section 3) and Resource Binding (Section 8). The RECOMMENDED port
314 for connections between a client and a server is 5222, as registered
315 with the IANA (see Port Numbers (Section 16.9)).
317 2.4. Network
319 Because each server is identified by a network address and because
320 server-to-server communications are a straightforward extension of
321 the client-to-server protocol, in practice, the system consists of a
322 network of servers that inter-communicate. Thus, for example,
323 is able to exchange messages, presence, and
324 other information with . This pattern is familiar
325 from messaging protocols (such as [SMTP]) that make use of network
326 addressing standards. Communications between any two servers are
327 OPTIONAL. If enabled, such communications SHOULD occur over XML
328 streams that are bound to [TCP] connections. The RECOMMENDED port
329 for connections between servers is 5269, as registered with the IANA
330 (see Port Numbers (Section 16.9)).
332 3. Addresses
334 3.1. Overview
336 An entity is anything that can be considered a network endpoint
337 (i.e., an ID on the network) and that can communicate using XMPP.
338 All such entities are uniquely addressable on the network. For
339 historical reasons, the address of an XMPP entity is called a Jabber
340 Identifier or JID. A valid JID contains a set of ordered elements
341 formed of a domain identifier, node identifier, and resource
342 identifier.
344 The syntax for a JID is defined as follows using the Augmented
345 Backus-Naur Form as defined in [ABNF].
347 jid = [ node "@" ] domain [ "/" resource ]
348 node = 1*(nodepoint)
349 ; a "nodepoint" is a UTF-8 encoded Unicode code
350 ; point that satisfies the Nodeprep profile of
351 ; stringprep
352 domain = fqdn / address-literal / idnlabel
353 fqdn = (idnlabel 1*("." idnlabel))
354 ; an "idnlabel" is an internationalized domain
355 ; label as described in RFC 3490
356 address-literal = IPv4address / IPv6address
357 ; the "IPv4address" and "IPv6address" rules are
358 ; defined in Appendix B of RFC 3513
359 resource = 1*(resourcepoint)
360 ; a "resourcepoint" is a UTF-8 encoded Unicode
361 ; code point that satisfies the Resourceprep
362 ; profile of stringprep
364 All JIDs are based on the foregoing structure. One common use of
365 this structure is to identify a messaging and presence account, the
366 server that hosts the account, and a connected resource (e.g., a
367 specific device) in the form of . However,
368 node types other than clients are possible; for example, a specific
369 chat room offered by a multi-user chat service (see [XEP-0045]) could
370 be addressed as (where "room" is the name of the chat
371 room and "service" is the hostname of the multi-user chat service)
372 and a specific occupant of such a room could be addressed as
373 (where "nick" is the occupant's room nickname).
374 Many other JID types are possible (e.g., could be a
375 server-side script or service).
377 Each allowable portion of a JID (node identifier, domain identifier,
378 and resource identifier) MUST NOT be more than 1023 bytes in length,
379 resulting in a maximum total size (including the '@' and '/'
380 separators) of 3071 bytes.
382 Note: While the format of a JID is consistent with [URI], an entity's
383 address on an XMPP network MUST be a JID (without a URI scheme) and
384 not a [URI] or [IRI] as specified in [XMPP-URI]; the latter
385 specification is provided only for use by non-XMPP applications.
387 3.2. Domain Identifier
389 The DOMAIN IDENTIFIER is the primary identifier and is the only
390 REQUIRED element of a JID (a mere domain identifier is a valid JID).
391 It usually represents the network or "home" server to which other
392 entities connect for XML routing and data management capabilities.
393 However, the entity referenced by a domain identifier is not always a
394 server, and may be a service that is addressed as a subdomain of a
395 server that provides functionality above and beyond the capabilities
396 of a server (e.g., a multi-user chat service or a user directory).
398 The domain identifier for every server or service that will
399 communicate over a network MAY be an IP address but SHOULD be a fully
400 qualified domain name (see [DNS]). A domain identifier MUST be an
401 "internationalized domain name" as defined in [IDNA], to which the
402 [NAMEPREP] profile of [STRINGPREP] can be applied without failing.
403 Before comparing two domain identifiers, a server MUST (and a client
404 SHOULD) first apply the Nameprep profile to the labels (as defined in
405 [IDNA]) that make up each identifier. Note: When applying the
406 Nameprep profile, the UseSTD3ASCIIRules flag MUST be set to true.
408 3.3. Node Identifier
410 The NODE IDENTIFIER is an optional secondary identifier placed before
411 the domain identifier and separated from the latter by the '@'
412 character. It usually represents the entity requesting and using
413 network access provided by a server (i.e., a client), although it can
414 also represent other kinds of entities (e.g., a chat room associated
415 with a multi-user chat service). The entity represented by a node
416 identifier is addressed within the context of a specific domain;
417 within instant messaging and presence applications of XMPP, this
418 address is called a "bare JID" and is of the form .
420 A node identifier MUST be formatted such that the Nodeprep profile of
421 [STRINGPREP] can be applied without failing (see Appendix A). Before
422 comparing two node identifiers, a server MUST (and a client SHOULD)
423 first apply the Nodeprep profile to each identifier.
425 3.4. Resource Identifier
427 The RESOURCE IDENTIFIER is an optional tertiary identifier placed
428 after the domain identifier and separated from the latter by the '/'
429 character. A resource identifier may modify either a
430 address or a mere address. It usually represents a specific
431 connection (e.g., a device or location) or object (e.g., a
432 participant in a multi-user chat room) belonging to the entity
433 associated with a node identifier. A resource identifier is opaque
434 to both servers and other clients, and is typically defined by a
435 client implementation when it provides the information necessary to
436 complete Resource Binding (Section 8) (although it may be generated
437 by a server on behalf of a client), after which the entity is
438 referred to as a "connected resource" and its address is referrred to
439 as a "full JID" (). An entity MAY maintain
440 multiple connected resources simultaneously, with each connected
441 resource differentiated by a distinct resource identifier.
443 A resource identifier MUST be formatted such that the Resourceprep
444 profile of [STRINGPREP] can be applied without failing (see
445 Appendix B). Before comparing two resource identifiers, a server
446 MUST (and a client SHOULD) first apply the Resourceprep profile to
447 each identifier.
449 3.5. Determination of Addresses
451 After SASL negotiation (Section 7) and, if appropriate, Resource
452 Binding (Section 8), the receiving entity for a stream MUST determine
453 the initiating entity's JID.
455 For server-to-server communications, the initiating entity's JID
456 SHOULD be the authorization identity, derived from the authentication
457 identity, as defined by [SASL], if no authorization identity was
458 specified during SASL negotiation (Section 7).
460 For client-to-server communications, the "bare JID" ()
461 SHOULD be the authorization identity, derived from the authentication
462 identity, as defined in [SASL], if no authorization identity was
463 specified during SASL negotiation (Section 7); the resource
464 identifier portion of the "full JID" () SHOULD
465 be the resource identifier negotiated by the client and server during
466 Resource Binding (Section 8).
468 The receiving entity MUST ensure that the resulting JID (including
469 node identifier, domain identifier, resource identifier, and
470 separator characters) conforms to the rules and formats defined
471 earlier in this section; to meet this restriction, the receiving
472 entity may need to replace the JID sent by the initiating entity with
473 the canonicalized JID as determined by the receiving entity.
475 4. TCP Binding
477 Although there is no necessary coupling of an XML stream to a [TCP]
478 connection (e.g., two entities could connect to each other via
479 another transport, e.g. [HTTP] as specified in [XEP-0124]), this
480 specification defines a binding of XMPP to TCP only.
482 Therefore, as XMPP is defined herein, an initiating entity (client or
483 server) MUST open a TCP connection at the receiving entity (server)
484 before it negotiates XML streams with the receiving entity. However,
485 prior to opening the TCP connection the initiating entity first MUST
486 resolve the Domain Name System (DNS) hostname associated with the
487 receiving entity and determine the appropriate TCP port for
488 communications with the receiving entity. The process is as follows:
490 1. Attempt to resolve the hostname using a [DNS-SRV] Service of
491 "xmpp-client" (for client-to-server connections) or "xmpp-server"
492 (for server-to-server connections) and Proto of "tcp", resulting
493 in resource records such as "_xmpp-client._tcp.example.com." or
494 "_xmpp-server._tcp.example.com."; the IP address and port at
495 which the initiating entity attempts to connect to the receiving
496 entity shall be those specified in the SRV lookup result.
497 2. If the SRV lookup fails, the fallback SHOULD be a normal IPv4 or
498 [IPv6] address record resolution to determine the IP address,
499 where the port used is the "xmpp-client" port of 5222 for client-
500 to-server connectionsn or the "xmpp-server" port 5269 for client-
501 to-server connections.
502 3. However, the fallback MAY be a DNS TXT lookup (see [DNS-TXT]) for
503 alternative connection methods, for example as described in
504 [XEP-0156].
506 TCP connections are handled differently in client-to-server
507 communications and server-to-server communications. Specifically:
509 o Because a client is subordinate to a server and therefore a client
510 authenticates to the server but the server does not authenticate
511 to the client, it is necessary to have only one TCP connection
512 between client and server. Thus the server MUST allow the client
513 to share a single TCP connection for XML stanzas sent from client
514 to server and from server to client (i.e., the inital stream and
515 response stream as specified under XML Streams (Section 5)).
516 o Because two servers are peers and therefore each peers must
517 authenticate with the other, the servers MUST use two TCP
518 connections: one for XML stanzas sent from the first server to the
519 second server and another (initiated by the second server) for
520 stanzas from the second server to the first server.
522 5. XML Streams
524 5.1. Overview
526 Two fundamental concepts make possible the rapid, asynchronous
527 exchange of relatively small payloads of structured information
528 between presence-aware entities: XML streams and XML stanzas. These
529 terms are defined as follows:
531 Definition of XML Stream: An XML STREAM is a container for the
532 exchange of XML elements between any two entities over a network.
533 The start of an XML stream is denoted unambiguously by an opening
534 XML tag (with appropriate attributes and namespace
535 declarations), while the end of the XML stream is denoted
536 unambiguously by a closing XML tag. During the life of
537 the stream, the entity that initiated it can send an unbounded
538 number of XML elements over the stream, either elements used to
539 negotiate the stream (e.g., to complete TLS negotiation
540 (Section 6) or SASL negotiation (Section 7)) or XML stanzas. The
541 "initial stream" is negotiated from the initiating entity (usually
542 a client or server) to the receiving entity (usually a server),
543 and can be seen as corresponding to the initiating entity's
544 "connection" with the receiving entity. The initial stream
545 enables unidirectional communication from the initiating entity to
546 the receiving entity; in order to enable information exchange from
547 the receiving entity to the initiating entity, the receiving
548 entity MUST negotiate a stream in the opposite direction (the
549 "response stream").
550 Definition of XML Stanza: An XML STANZA is a discrete semantic unit
551 of structured information that is sent from one entity to another
552 over an XML stream, and is the basic unit of meaning in XMPP. An
553 XML stanza exists at the direct child level of the root
554 element and is said to be well-balanced if it matches the
555 production [43] content of [XML]. The start of any XML stanza is
556 denoted unambiguously by the element start tag at depth=1 of the
557 XML stream (e.g., ), and the end of any XML stanza is
558 denoted unambiguously by the corresponding close tag at depth=1
559 (e.g., ); a server MUST NOT process, deliver, or route
560 a partial stanza and MUST NOT attach meaning to the transmission
561 timing of any part of a stanza (before receipt of the close tag).
562 The only XML stanzas defined herein are the ,
563 , and elements qualified by the default namespace
564 for the stream, as described under XML Stanzas (Section 9); an XML
565 element sent for the purpose of TLS negotiation (Section 6), SASL
566 negotiation (Section 7), or server dialback (Appendix C) is not
567 considered to be an XML stanza. An XML stanza MAY contain child
568 elements (with accompanying attributes, elements, and XML
569 character data) as necessary in order to convey the desired
570 information, which MAY be qualified by any XML namespace (see
571 [XML-NAMES]).
573 Consider the example of a client's connection to a server. In order
574 to connect to a server, a client MUST initiate an XML stream by
575 sending an opening tag to the server, optionally preceded by
576 a text declaration specifying the XML version and the character
577 encoding supported (see Inclusion of Text Declaration (Section 12.4)
578 and Character Encoding (Section 12.5)). Subject to local policies
579 and service provisioning, the server SHOULD then reply with a second
580 XML stream back to the client, again optionally preceded by a text
581 declaration. Once the client has completed SASL negotiation
582 (Section 7), the client MAY send an unbounded number of XML stanzas
583 over the stream to any recipient on the network. When the client
584 desires to close the stream, it simply sends a closing tag
585 to the server; for details, see Section 5.6.
587 Those who are accustomed to thinking of XML in a document-centric
588 manner may wish to view a client's connection to a server as
589 consisting of two open-ended XML documents: one from the client to
590 the server and one from the server to the client. From this
591 perspective, the root element can be considered the
592 document entity for each "document", and the two "documents" are
593 built up through the accumulation of XML stanzas sent over the two
594 XML streams. However, this perspective is a convenience only; XMPP
595 does not deal in documents but in XML streams and XML stanzas.
597 In essence, then, an XML stream acts as an envelope for all the XML
598 stanzas sent during a connection. We can represent this in a
599 simplistic fashion as follows:
601 |--------------------|
602 | |
603 |--------------------|
604 | |
605 | |
606 | |
607 |--------------------|
608 | |
609 | |
610 | |
611 |--------------------|
612 | |
613 | |
614 | |
615 |--------------------|
616 | ... |
617 |--------------------|
618 | |
619 |--------------------|
621 5.2. Stream Security
623 When negotiating XML streams in XMPP 1.0, TLS SHOULD be used as
624 defined under TLS negotiation (Section 6) and SASL MUST be used as
625 defined under SASL negotiation (Section 7). The initial stream and
626 the response stream MUST be secured separately, although security in
627 both directions MAY be established via mechanisms that provide mutual
628 authentication. An entity SHOULD NOT attempt to send XML Stanzas
629 (Section 9) over the stream before the stream has been authenticated,
630 but if it does, then the other entity MUST NOT accept such stanzas
631 and SHOULD return a stream error and then terminate
632 both the XML stream and the underlying TCP connection; note well that
633 this applies to XML stanzas only (i.e., , , and
634 elements qualified by the default namespace) and not to XML
635 elements used for stream negotiation (e.g., elements used to complete
636 TLS negotiation (Section 6) or SASL negotiation (Section 7)).
638 5.3. Stream Attributes
640 The attributes of the stream element are as follows:
642 o from -- In client-to-server communications, the 'from' attribute
643 SHOULD be included in the XML stream header sent from the
644 initiating entity to the receiving entity and (if included) MUST
645 be set to the account name (i.e., "bare JID" = ) of
646 the entity controlling the client. In server-to-server
647 communications, the 'from' attribute SHOULD be included in the XML
648 stream header sent from the initiating entity to the receiving
649 entity and (if included) MUST be set to a hostname serviced by the
650 initiating entity. In both client-to-server and server-to-server
651 communications, the 'from' attribute MUST be included in the XML
652 stream header by which the receiving entity responds to the
653 initiating entity and MUST be set to a hostname serviced by the
654 receiving entity that is granting access to the initiating entity.
655 Note: Each entity MUST verify the identity of the other entity
656 before exchanging XML stanzas with it (see the Client-to-Server
657 Communications (Section 15.3) and Server-to-Server Communications
658 (Section 15.4) sections of this document for details).
659 o to -- In both client-to-server and server-to-server
660 communications, the 'to' attribute SHOULD be included in the XML
661 stream header sent from the initiating entity to the receiving
662 entity and (if included) MUST be set to a hostname serviced by the
663 receiving entity. In client-to-server communications, if the
664 client included a 'from' address in the initial stream header then
665 the server SHOULD include a 'to' attribute in the XML stream
666 header by which it replies to the client and (if included) MUST
667 set the 'to' attribute to the bare JID specified in the 'from'
668 attribute of the XML stream header sent from the initiating entity
669 to the receiving entity. In server-to-server communications, if
670 the initiating entity included a 'from' address in the initial
671 stream header then the receiving entity SHOULD include a 'to'
672 attribute in the XML stream header by which it replies to the
673 initiating entity and (if included) MUST set the 'to' attribute to
674 the hostname specified in the 'from' attribute of the XML stream
675 header sent from the initiating entity to the receiving entity.
676 Note: Each entity MUST verify the identity of the other entity
677 before exchanging XML stanzas with it (see the Client-to-Server
678 Communications (Section 15.3) and Server-to-Server Communications
679 (Section 15.4) sections of this document for details).
680 o id -- The 'id' attribute SHOULD be used only in the XML stream
681 header from the receiving entity to the initiating entity. This
682 attribute is a unique identifier created by the receiving entity
683 to function as a identifier for the initiating entity's streams
684 with the receiving entity, and MUST be unique within the receiving
685 application (normally a server). Note well that the stream ID may
686 be security-critical and therefore MUST be both unpredictable and
687 nonrepeating (see [RANDOM] for recommendations regarding
688 randomness for security purposes). There SHOULD NOT be an 'id'
689 attribute on the XML stream header sent from the initiating entity
690 to the receiving entity; however, if an 'id' attribute is
691 included, it SHOULD be silently ignored by the receiving entity.
692 o xml:lang -- An 'xml:lang' attribute (as defined in Section 2.12 of
693 [XML]) SHOULD be included by the initiating entity on the header
694 for the initial stream to specify the default language of any
695 human-readable XML character data it sends over that stream. If
696 the attribute is included, the receiving entity SHOULD remember
697 that value as the default for both the initial stream and the
698 response stream; if the attribute is not included, the receiving
699 entity SHOULD use a configurable default value for both streams,
700 which it MUST communicate in the header for the response stream.
701 For all stanzas sent over the initial stream, if the initiating
702 entity does not include an 'xml:lang' attribute, the receiving
703 entity SHOULD apply the default value; if the initiating entity
704 does include an 'xml:lang' attribute, the receiving entity MUST
705 NOT modify or delete it (see also xml:lang (Section 9.1.5)). The
706 value of the 'xml:lang' attribute MUST be an NMTOKEN (as defined
707 in Section 2.3 of [XML]) and MUST conform to the format defined in
708 [LANGTAGS].
709 o version -- The presence of the version attribute set to a value of
710 at least "1.0" signals support for the stream-related protocols
711 (including stream features) defined in this specification.
712 Detailed rules regarding the generation and handling of this
713 attribute are defined in the text that follows.
715 We can summarize as follows:
717 +----------+--------------------------+-------------------------+
718 | | initiating to receiving | receiving to initiating |
719 +----------+--------------------------+-------------------------+
720 | to | JID of receiver | JID of initiator |
721 | from | JID of initiator | JID of receiver |
722 | id | silently ignored | stream identifier |
723 | xml:lang | default language | default language |
724 | version | XMPP 1.0 supported | XMPP 1.0 supported |
725 +----------+--------------------------+-------------------------+
727 Note: The attributes of the root element are not prepended
728 by a 'stream:' prefix because, in accordance with Section 5.3 of XML
729 namespaces specification [XML-NAMES], the default namespace does not
730 apply to attribute names.
732 5.3.1. Version Support
734 The version of XMPP specified herein is "1.0"; in particular, this
735 encapsulates the stream-related protocols (TLS negotiation
736 (Section 6), SASL negotiation (Section 7), and Stream Errors
737 (Section 5.8)), as well as the semantics of the three defined XML
738 stanza types (, , and ). The numbering
739 scheme for XMPP versions is ".". The major and minor
740 numbers MUST be treated as separate integers and each number MAY be
741 incremented higher than a single digit. Thus, "XMPP 2.4" would be a
742 lower version than "XMPP 2.13", which in turn would be lower than
743 "XMPP 12.3". Leading zeros (e.g., "XMPP 6.01") MUST be ignored by
744 recipients and MUST NOT be sent.
746 The major version number should be incremented only if the stream and
747 stanza formats or required actions have changed so dramatically that
748 an older version entity would not be able to interoperate with a
749 newer version entity if it simply ignored the elements and attributes
750 it did not understand and took the actions specified in the older
751 specification. The minor version number indicates new capabilities,
752 and MUST be ignored by an entity with a smaller minor version number,
753 but used for informational purposes by the entity with the larger
754 minor version number. For example, a minor version number might
755 indicate the ability to process a newly defined value of the 'type'
756 attribute for message, presence, or IQ stanzas; the entity with the
757 larger minor version number would simply note that its correspondent
758 would not be able to understand that value of the 'type' attribute
759 and therefore would not send it.
761 The following rules apply to the generation and handling of the
762 'version' attribute within stream headers by implementations:
764 1. The initiating entity MUST set the value of the 'version'
765 attribute on the initial stream header to the highest version
766 number it supports (e.g., if the highest version number it
767 supports is that defined in this specification, it MUST set the
768 value to "1.0").
769 2. The receiving entity MUST set the value of the 'version'
770 attribute on the response stream header to either the value
771 supplied by the initiating entity or the highest version number
772 supported by the receiving entity, whichever is lower. The
773 receiving entity MUST perform a numeric comparison on the major
774 and minor version numbers, not a string match on
775 ".".
776 3. If the version number included in the response stream header is
777 at least one major version lower than the version number included
778 in the initial stream header and newer version entities cannot
779 interoperate with older version entities as described above, the
780 initiating entity SHOULD generate an
781 stream error and terminate the XML stream and underlying TCP
782 connection.
783 4. If either entity receives a stream header with no 'version'
784 attribute, the entity MUST consider the version supported by the
785 other entity to be "0.9" and SHOULD NOT include a 'version'
786 attribute in the stream header it sends in reply.
788 5.4. Namespace Declarations
790 The stream element MUST possess both a streams namespace declaration
791 and a default namespace declaration (as "namespace declaration" is
792 defined in the [XML-NAMES]). For detailed information regarding the
793 streams namespace and default namespace, see Namespace Names and
794 Prefixes (Section 12.2).
796 5.5. Stream Features
798 If the initiating entity includes the 'version' attribute set to a
799 value of at least "1.0" in the initial stream header, the receiving
800 entity MUST send a child element (prefixed by the streams
801 namespace prefix) to the initiating entity in order to announce any
802 stream-level features that can be negotiated (or capabilities that
803 otherwise need to be advertised). Currently, this is used only to
804 advertise TLS negotiation (Section 6), SASL negotiation (Section 7),
805 resource binding (Section 8), and server dialback (Appendix C) as
806 defined herein; however, the stream features functionality can be
807 used to advertise other negotiable features as well. If an entity
808 does not understand or support some features, it SHOULD silently
809 ignore them. If one or more security features (e.g., TLS and SASL)
810 need to be successfully negotiated before a non-security-related
811 feature (e.g., Resource Binding) can be offered, the non-security-
812 related feature SHOULD NOT be included in the stream features that
813 are advertised before the relevant security features have been
814 negotiated. If a feature must be negotiated before the initiating
815 entity may proceed, that feature SHOULD include a child
816 element.
818 5.6. Closing Streams
820 At any time after XML streams have been negotiated between two
821 entities, either entity MAY close its stream to the other entity
822 (even in the absence of a stream error) by sending a closing stream
823 tag:
825
827 The entity that sends the closing stream tag SHOULD wait for the
828 other entity to also close its stream:
830
832 However, the entity that sends the first closing stream tag MAY
833 consider both streams to be void if the other entity does not send
834 its closing stream tag within a reasonable amount of time (where the
835 definition of "reasonable" is up to the implementation or
836 deployment).
838 After an entity sends a closing stream tag, it MUST NOT send further
839 data over that stream.
841 After the entity that sent the first closing stream tag receives a
842 reciprocal closing stream tag from the other entity, it MUST
843 terminate the underlying TCP connection.
845 5.7. Reconnection
847 It can happen that an XMPP server goes offline while servicing
848 connections from clients and from other servers. Because the number
849 of such connections can be quite large, the reconnection algorithm
850 employed by entities that seek to reconnect can have a significant
851 impact on software and network performance. The following guidelines
852 are RECOMMENDED:
854 o The time to live (TTL) specified in Domain Name System records
855 SHOULD be honored, even if DNS results are cached; if the TTL has
856 not expired, an entity that seeks to reconnect SHOULD NOT re-
857 resolve DNS before reconnecting.
858 o The time that expires before an entity first seeks to reconnect
859 SHOULD be randomized (e.g., so that all clients do not attempt to
860 reconnect 30 seconds after being disconnected).
861 o If the first reconnection attempt does not succeed, an entity
862 SHOULD back off exponentially on the time between subsequent
863 reconnection attempts.
865 5.8. Stream Errors
867 The root stream element MAY contain an child element that is
868 prefixed by the streams namespace prefix. The error child MUST be
869 sent by a compliant entity (usually a server rather than a client) if
870 it perceives that a stream-level error has occurred.
872 5.8.1. Rules
874 The following rules apply to stream-level errors:
876 o It is assumed that all stream-level errors are unrecoverable;
877 therefore, if an error occurs at the level of the stream, the
878 entity that detects the error MUST send a stream error to the
879 other entity, send a closing tag, and terminate the
880 underlying TCP connection.
881 o If the error occurs while the stream is being set up, the
882 receiving entity MUST still send the opening tag, include
883 the element as a child of the stream element, send the
884 closing tag, and terminate the underlying TCP
885 connection. In this case, if the initiating entity provides an
886 unknown host in the 'to' attribute (or provides no 'to' attribute
887 at all), the server SHOULD provide the server's authoritative
888 hostname in the 'from' attribute of the stream header sent before
889 termination.
891 5.8.2. Syntax
893 The syntax for stream errors is as follows:
895
896
897 [
899 OPTIONAL descriptive text
900 ]
901 [OPTIONAL application-specific condition element]
902
904 The element:
906 o MUST contain a child element corresponding to one of the defined
907 stanza error conditions defined in the text that follows; this
908 element MUST be qualified by the
909 'urn:ietf:params:xml:ns:xmpp-streams' namespace
910 o MAY contain a child containing XML character data that
911 describes the error in more detail; this element MUST be qualified
912 by the 'urn:ietf:params:xml:ns:xmpp-streams' namespace and SHOULD
913 possess an 'xml:lang' attribute specifying the natural language of
914 the XML character data
915 o MAY contain a child element for an application-specific error
916 condition; this element MUST be qualified by an application-
917 defined namespace, and its structure is defined by that namespace
919 The element is OPTIONAL. If included, it SHOULD be used only
920 to provide descriptive or diagnostic information that supplements the
921 meaning of a defined condition or application-specific condition. It
922 SHOULD NOT be interpreted programmatically by an application. It
923 SHOULD NOT be used as the error message presented to a user, but MAY
924 be shown in addition to the error message associated with the
925 included condition element (or elements).
927 5.8.3. Defined Conditions
929 The following stream-level error conditions are defined:
931 o -- the entity has sent XML that cannot be processed;
932 this error MAY be used instead of the more specific XML-related
933 errors, such as , ,
934 , , and , although the more specific errors are preferred.
936 o -- the entity has sent a namespace prefix
937 that is unsupported, or has sent no namespace prefix on an element
938 that requires such a prefix (see XML Namespace Names and Prefixes
939 (Section 12.2)).
940 o -- the server is closing the active stream for this
941 entity because a new stream has been initiated that conflicts with
942 the existing stream.
943 o -- the entity has not generated any traffic
944 over the stream for some period of time (configurable according to
945 a local service policy).
946 o -- the value of the 'to' attribute provided by the
947 initiating entity in the stream header corresponds to a hostname
948 that is no longer hosted by the server.
949 o -- the value of the 'to' attribute provided by the
950 initiating entity in the stream header does not correspond to a
951 hostname that is hosted by the server.
952 o -- a stanza sent between two servers lacks
953 a 'to' or 'from' attribute (or the attribute has no value).
954 o -- the server has experienced a
955 misconfiguration or an otherwise-undefined internal error that
956 prevents it from servicing the stream.
957 o -- the JID or hostname provided in a 'from'
958 address does not match an authorized JID or validated domain
959 negotiated between servers via SASL or dialback, or between a
960 client and a server via authentication and resource binding.
961 o -- the stream ID or dialback ID is invalid or does
962 not match an ID previously provided.
963 o -- the streams namespace name is something
964 other than "http://etherx.jabber.org/streams" or the dialback
965 namespace name is something other than "jabber:server:dialback"
966 (see XML Namespace Names and Prefixes (Section 12.2)).
967 o -- the entity has sent invalid XML over the stream
968 to a server that performs validation (see Validation
969 (Section 12.3)).
970 o -- the entity has attempted to send XML stanzas
971 before the stream has been authenticated, or otherwise is not
972 authorized to perform an action related to stream negotiation; the
973 receiving entity MUST NOT process the offending stanza before
974 sending the stream error.
975 o -- the entity has violated some local service
976 policy (e.g., the entity is on a provisioned blacklist); the
977 server MAY choose to specify the policy in the element or
978 an application-specific condition element.
979 o -- the server is unable to properly
980 connect to a remote entity that is required for authentication or
981 authorization.
982 o -- the server lacks the system resources
983 necessary to service the stream.
984 o -- the entity has attempted to send restricted
985 XML features such as a comment, processing instruction, DTD,
986 entity reference, or unescaped character (see Restrictions
987 (Section 12.1)).
988 o -- the server will not provide service to the
989 initiating entity but is redirecting traffic to another host; the
990 XML character data of the element returned by
991 the server SHOULD specify the alternate hostname or IP address at
992 which to connect, which SHOULD be a valid domain identifier but
993 may also include a port number; if no port is specified, the
994 initiating entity SHOULD perform a [DNS-SRV] lookup on the
995 provided domain identifier but MAY assume that it can connect to
996 that domain identifier at the standard XMPP ports (5222 for
997 client-to-server connections and 5269 for server-to-server
998 connections).
999 o -- the server is being shut down and all active
1000 streams are being closed.
1001 o -- the error condition is not one of those
1002 defined by the other conditions in this list; this error condition
1003 SHOULD be used only in conjunction with an application-specific
1004 condition.
1005 o -- the initiating entity has encoded the
1006 stream in an encoding that is not supported by the server (see
1007 Character Encoding (Section 12.5)).
1008 o -- the initiating entity has sent a
1009 first-level child of the stream that is not supported by the
1010 server.
1011 o -- the value of the 'version' attribute
1012 provided by the initiating entity in the stream header specifies a
1013 version of XMPP that is not supported by the server; the server
1014 MAY specify the version(s) it supports in the element.
1015 o -- the initiating entity has sent XML that
1016 is not well-formed as defined by [XML].
1018 5.8.4. Application-Specific Conditions
1020 As noted, an application MAY provide application-specific stream
1021 error information by including a properly-namespaced child in the
1022 error element. The application-specific element SHOULD supplement or
1023 further qualify a defined element. Thus the element will
1024 contain two or three child elements:
1026
1027
1029
1030 Some special application diagnostic information!
1031
1032
1033
1034
1036 5.9. Simplified Stream Examples
1038 This section contains two simplified examples of a stream-based
1039 connection of a client on a server (where the "C" lines are sent from
1040 the client to the server, and the "S" lines are sent from the server
1041 to the client); these examples are included for the purpose of
1042 illustrating the concepts introduced thus far.
1044 A basic connection:
1046 C:
1047
1054 S:
1055
1063 ... encryption, authentication, and resource binding ...
1064 C:
1067 C: Art thou not Romeo, and a Montague?
1068 C:
1069 S:
1072 S: Neither, fair saint, if either thee dislike.
1073 S:
1074 C:
1075 S:
1076 A connection gone bad:
1078 C:
1079
1086 S:
1087
1095 ... encryption, authentication, and resource binding ...
1096 C:
1097 Bad XML, no closing body tag!
1098
1099 S:
1100
1102
1103 S:
1105 More detailed examples are provided under Section 10.
1107 6. TLS Negotiation
1109 6.1. Overview
1111 XMPP includes a method for securing the stream from tampering and
1112 eavesdropping. This channel encryption method makes use of the
1113 Transport Layer Security (TLS) protocol [TLS], along with a
1114 "STARTTLS" extension that is modelled after similar extensions for
1115 the [IMAP], [POP3], and [ACAP] protocols as described in [USINGTLS].
1116 The namespace name for the STARTTLS extension is
1117 'urn:ietf:params:xml:ns:xmpp-tls'.
1119 An administrator of a given domain MAY require the use of TLS for
1120 client-to-server communications, server-to-server communications, or
1121 both. Clients SHOULD use TLS to secure the streams prior to
1122 attempting the completion of SASL negotiation (Section 7), and
1123 servers SHOULD use TLS between two domains for the purpose of
1124 securing server-to-server communications.
1126 The following rules apply:
1128 1. An initiating entity that complies with this specification MUST
1129 include the 'version' attribute set to a value of "1.0" in the
1130 initial stream header.
1131 2. If the TLS negotiation occurs between two servers,
1132 communications MUST NOT proceed until the Domain Name System
1133 (DNS) hostnames asserted by the servers have been resolved (see
1134 Server-to-Server Communications (Section 15.4)).
1135 3. When a receiving entity that complies with this specification
1136 receives an initial stream header that includes the 'version'
1137 attribute set to a value of at least "1.0", after sending a
1138 stream header in reply (including the version flag), it MUST
1139 include a element (qualified by the
1140 'urn:ietf:params:xml:ns:xmpp-tls' namespace) along with the list
1141 of other stream features it supports.
1142 4. If the initiating entity chooses to use TLS, TLS negotiation
1143 MUST be completed before proceeding to SASL negotiation; this
1144 order of negotiation is required to help safeguard
1145 authentication information sent during SASL negotiation, as well
1146 as to make it possible to base the use of the SASL EXTERNAL
1147 mechanism on a certificate provided during prior TLS
1148 negotiation.
1149 5. During TLS negotiation, an entity MUST NOT send any white space
1150 characters (matching production [3] content of [XML]) within the
1151 root stream element as separators between elements (any white
1152 space characters shown in the TLS examples that follow are
1153 included for the sake of readability only); this prohibition
1154 helps to ensure proper security layer byte precision.
1155 6. The receiving entity MUST consider the TLS negotiation to have
1156 begun immediately after sending the closing ">" character of the
1157 element to the initiating entity. The initiating
1158 entity MUST consider the TLS negotiation to have begun
1159 immediately after receiving the closing ">" character of the
1160 element from the receiving entity.
1161 7. The initiating entity MUST validate the certificate presented by
1162 the receiving entity; see Certificate Validation (Section 15.2)
1163 regarding certificate validation procedures.
1164 8. Certificates MUST be checked against the hostname as provided by
1165 the initiating entity (e.g., a user), not the hostname as
1166 resolved via the Domain Name System; e.g., if the user specifies
1167 a hostname of "example.net" but a [DNS-SRV] lookup returned
1168 "im.example.net", the certificate MUST be checked as
1169 "example.net". If a JID for an XMPP client (e.g., an end user
1170 account) is represented in a certificate, it MUST be represented
1171 as a UTF8String within an otherName entity inside the
1172 subjectAltName, using the [ASN.1] Object Identifier "id-on-
1173 xmppAddr" specified in Section 6.1.1 of this document. If a JID
1174 for an XMPP server is represented in a certificate, it SHOULD be
1175 represented as a UTF8String within an otherName entity inside
1176 the subjectAltName, using the [ASN.1] Object Identifier "id-on-
1177 xmppAddr" specified in Section 6.1.1 of this document; however,
1178 the JID for an XMPP server MAY also or instead be represented as
1179 a subjectAltName extension of type dNSName, where the dNSName
1180 may contain the wildcard character '*', which applies only to
1181 the left-most domain name component or component fragment and is
1182 considered to match any single component or component fragment
1183 (e.g., *.example.com matches foo.example.com but not
1184 bar.foo.example.com, and im*.example.net matches im1.example.net
1185 and im2.example.net but not chat.example.net).
1186 9. If the TLS negotiation is successful, the initiating entity MUST
1187 send a new stream header to the receiving entity.
1188 10. If the TLS negotiation is successful, the receiving entity MUST
1189 discard any knowledge obtained in an insecure manner from the
1190 initiating entity before TLS takes effect.
1191 11. If the TLS negotiation is successful, the initiating entity MUST
1192 discard any knowledge obtained in an insecure manner from the
1193 receiving entity before TLS takes effect.
1194 12. If the TLS negotiation is successful, the receiving entity MUST
1195 NOT offer the STARTTLS extension to the initiating entity along
1196 with the other stream features that are offered after the new
1197 stream header is received and responded to.
1198 13. If the TLS negotiation is successful, the initiating entity MUST
1199 continue with SASL negotiation.
1200 14. If the TLS negotiation results in failure, the receiving entity
1201 MUST terminate both the XML stream and the underlying TCP
1202 connection.
1203 15. See Mandatory-to-Implement Technologies (Section 15.7) regarding
1204 mechanisms that MUST be supported.
1206 6.1.1. ASN.1 Object Identifier for XMPP Address
1208 The [ASN.1] Object Identifier "id-on-xmppAddr" described above is
1209 defined as follows:
1211 id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
1212 dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
1214 id-on OBJECT IDENTIFIER ::= { id-pkix 8 } -- other name forms
1216 id-on-xmppAddr OBJECT IDENTIFIER ::= { id-on 5 }
1218 XmppAddr ::= UTF8String
1219 This Object Identifier MAY also be represented in dotted display
1220 format (i.e., "1.3.6.1.5.5.7.8.5") or in the Uniform Resource Name
1221 notation specified in [URN-OID] (i.e., "urn:oid:1.3.6.1.5.5.7.8.5").
1223 Thus for example the JID "example.com" as included in a certificate
1224 might be formatted as "subjectAltName=otherName:
1225 1.3.6.1.5.5.7.8.5;UTF8:example.com".
1227 6.2. Narrative
1229 When an initiating entity secures a stream with a receiving entity
1230 using TLS, the steps involved are as follows:
1232 1. The initiating entity opens a TCP connection and initiates the
1233 stream by sending the opening XML stream header to the receiving
1234 entity, including the 'version' attribute set to a value of at
1235 least "1.0".
1236 2. The receiving entity responds by opening a TCP connection and
1237 sending an XML stream header to the initiating entity, including
1238 the 'version' attribute set to a value of at least "1.0".
1239 3. The receiving entity offers the STARTTLS extension to the
1240 initiating entity by including it with the list of other
1241 supported stream features (if successful TLS negotiation is
1242 required for interaction with the receiving entity, it SHOULD
1243 signal that fact by including a element as a child of
1244 the element); the receiving entity SHOULD also
1245 include a list of supported SASL mechanisms in the stream
1246 features.
1247 4. The initiating entity issues the STARTTLS command (i.e., a
1248 element qualified by the
1249 'urn:ietf:params:xml:ns:xmpp-tls' namespace) to instruct the
1250 receiving entity that it wishes to begin a TLS negotiation to
1251 secure the stream.
1252 5. The receiving entity MUST reply with either a element
1253 or a element qualified by the
1254 'urn:ietf:params:xml:ns:xmpp-tls' namespace. If the failure case
1255 occurs, the receiving entity MUST terminate both the XML stream
1256 and the underlying TCP connection (failure cases include when the
1257 initiating entity sends a malformed STARTTLS command, when the
1258 receiving entity does not offer TLS negotiation either
1259 temporarily or permanently, and when the receiving entity cannot
1260 complete TLS negotiation because of an internal error). If the
1261 proceed case occurs, the entities MUST attempt to complete the
1262 TLS negotiation over the TCP connection and MUST NOT send any
1263 further XML data until the TLS negotiation is complete.
1264 6. The initiating entity and receiving entity attempt to complete a
1265 TLS negotiation in accordance with [TLS].
1267 7. If the TLS negotiation is unsuccessful, the receiving entity MUST
1268 terminate the TCP connection. If the TLS negotiation is
1269 successful, the initiating entity MUST initiate a new stream by
1270 sending an opening XML stream header to the receiving entity (it
1271 is not necessary to send a closing tag first, since the
1272 receiving entity and initiating entity MUST consider the original
1273 stream to be closed upon successful TLS negotiation).
1274 8. Upon receiving the new stream header from the initiating entity,
1275 the receiving entity MUST respond by sending a new XML stream
1276 header to the initiating entity along with the available features
1277 (but not including the STARTTLS feature) and SHOULD include an
1278 updated list of SASL mechanisms so that the initiating entity can
1279 detect any changes to the list of SASL mechanisms supported by
1280 the receiving entity.
1282 Examples of TLS negotiation are provided under Section 10.
1284 7. SASL Negotiation
1286 7.1. Overview
1288 XMPP includes a method for authenticating a stream by means of an
1289 XMPP-specific profile of the Simple Authentication and Security Layer
1290 protocol (see [SASL]). SASL provides a generalized method for adding
1291 authentication support to connection-based protocols, and XMPP uses a
1292 generic XML namespace profile for SASL that conforms to the profiling
1293 requirements of [SASL].
1295 The following rules apply:
1297 1. If the SASL negotiation occurs between two servers,
1298 communications MUST NOT proceed until the Domain Name System
1299 (DNS) hostnames asserted by the servers have been resolved (see
1300 Server-to-Server Communications (Section 15.4)).
1301 2. If the initiating entity is capable of SASL negotiation, it MUST
1302 include the 'version' attribute set to a value of at least "1.0"
1303 in the initial stream header.
1304 3. If the receiving entity is capable of SASL negotiation, it MUST
1305 advertise one or more authentication mechanisms within a
1306 element qualified by the
1307 'urn:ietf:params:xml:ns:xmpp-sasl' namespace in reply to the
1308 opening stream tag received from the initiating entity (if the
1309 opening stream tag included the 'version' attribute set to a
1310 value of at least "1.0").
1311 4. During SASL negotiation, an entity MUST NOT send any white space
1312 characters (matching production [3] content of [XML]) within the
1313 root stream element as separators between elements (any white
1314 space characters shown in the SASL examples that follow are
1315 included for the sake of readability only); this prohibition
1316 helps to ensure proper security layer byte precision.
1317 5. Any XML character data contained within the XML elements used
1318 during SASL negotiation MUST be encoded using base64, where the
1319 encoding adheres to the definition in Section 3 of RFC 3548
1320 [BASE64].
1321 6. If the receiving entity does not include a 'realm' value, the
1322 initiating entity must default it to the domain identifier
1323 portion of the receiving entity's JID.
1324 7. If provision of a "simple username" is supported by the selected
1325 SASL mechanism (e.g., this is supported by the DIGEST-MD5 and
1326 CRAM-MD5 mechanisms but not by the EXTERNAL and GSSAPI
1327 mechanisms), during authentication the initiating entity SHOULD
1328 provide as the simple username its sending domain (IP address or
1329 fully qualified domain name as contained in a domain identifier)
1330 in the case of server-to-server communications or its registered
1331 account name (user or node name as contained in an XMPP node
1332 identifier) in the case of client-to-server communications. In
1333 either case, the initiating entity MUST ensure that the username
1334 adheres to the [NAMEPREP] or Nodeprep (Appendix A) profile of
1335 [STRINGPREP] (as appropriate) before sending it to the receiving
1336 entity. (Note: Account provisioning is out of scope for this
1337 specification; possible methods for account provisioning include
1338 account creation by a server administrator and in-band account
1339 registration using the 'jabber:iq:register' namespace as
1340 documented in [XEP-0077].)
1341 8. If the initiating entity wishes to act on behalf of another
1342 entity and the selected SASL mechanism supports transmission of
1343 an authorization identity, the initiating entity MUST provide an
1344 authorization identity during SASL negotiation. If the
1345 initiating entity does not wish to act on behalf of another
1346 entity, it MUST NOT provide an authorization identity. As
1347 specified in [SASL], the initiating entity MUST NOT provide an
1348 authorization identity unless the authorization identity is
1349 different from the default authorization identity derived from
1350 the authentication identity. If provided, the value of the
1351 authorization identity MUST be of the form (i.e., a
1352 domain identifier only) for servers and of the form
1353 (i.e., node identifier and domain identifier) for
1354 clients.
1355 9. If the SASL negotiation is successful, the initiating entity
1356 MUST send a new stream header to the receiving entity.
1357 10. Upon successful SASL negotiation that involves negotiation of a
1358 security layer, the receiving entity MUST discard any knowledge
1359 obtained from the initiating entity which was not obtained from
1360 the SASL negotiation itself; the receiving entity SHOULD also
1361 send new stream features (including an updated list of SASL
1362 mechanisms) so that the initiating entity can detect any changes
1363 to the list of mechanisms supported by the receiving entity.
1364 11. Upon successful SASL negotiation that involves negotiation of a
1365 security layer, the initiating entity MUST discard any knowledge
1366 obtained from the receiving entity which was not obtained from
1367 the SASL negotiation itself.
1368 12. See Mandatory-to-Implement Technologies (Section 15.7) regarding
1369 mechanisms that MUST be supported; naturally, other SASL
1370 mechanisms MAY be supported as well (best practices for the use
1371 of several SASL mechanisms in the context of XMPP are described
1372 in [XEP-0175] and [XEP-0178]).
1374 7.2. Narrative
1376 When an initiating entity authenticates with a receiving entity using
1377 SASL, the steps involved are as follows:
1379 1. The initiating entity requests SASL authentication by including
1380 the 'version' attribute in the opening XML stream header sent to
1381 the receiving entity, with the value set to "1.0".
1382 2. After sending an XML stream header in reply, the receiving entity
1383 advertises a list of available SASL authentication mechanisms as
1384 stream features; each of these is a element included
1385 as a child within a container element qualified by
1386 the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace, which in turn
1387 is a child of a element in the streams namespace. If
1388 TLS negotiation (Section 6) needs to be completed before a
1389 particular authentication mechanism may be used, the receiving
1390 entity MUST NOT provide that mechanism in the list of available
1391 SASL authentication mechanisms prior to TLS negotiation. If the
1392 initiating entity presents a valid certificate during prior TLS
1393 negotiation, the receiving entity SHOULD offer the SASL EXTERNAL
1394 mechanism to the initiating entity during SASL negotiation (refer
1395 to [SASL]), although the EXTERNAL mechanism MAY be offered under
1396 other circumstances as well. If successful SASL negotiation is
1397 required for interaction with the receiving entity, it SHOULD
1398 signal that fact by including a element as a child of
1399 the element.
1400 3. The initiating entity selects a mechanism by sending an
1401 element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl'
1402 namespace to the receiving entity and including an appropriate
1403 value for the 'mechanism' attribute. This element MAY contain
1404 XML character data (in SASL terminology, the "initial response")
1405 if the mechanism supports or requires it; if the initiating
1406 entity needs to send a zero-length initial response, it MUST
1407 transmit the response as a single equals sign ("="), which
1408 indicates that the response is present but contains no data.
1410 4. If necessary, the receiving entity challenges the initiating
1411 entity by sending to the initiating entity a element
1412 qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace;
1413 this element MAY contain XML character data (which MUST be
1414 computed in accordance with the definition of the SASL mechanism
1415 chosen by the initiating entity).
1416 5. The initiating entity responds to the challenge by sending to the
1417 receiving entity a element qualified by the
1418 'urn:ietf:params:xml:ns:xmpp-sasl' namespace; this element MAY
1419 contain XML character data (which MUST be computed in accordance
1420 with the definition of the SASL mechanism chosen by the
1421 initiating entity).
1422 6. If necessary, the receiving entity sends more challenges and the
1423 initiating entity sends more responses.
1425 This series of challenge/response pairs continues until one of three
1426 things happens:
1428 1. The initiating entity aborts the handshake by sending an
1429 element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl'
1430 namespace to the receiving entity. Upon receiving an
1431 element, the receiving entity SHOULD allow a configurable but
1432 reasonable number of retries (at least 2), after which it MUST
1433 terminate the TCP connection; this enables the initiating entity
1434 (e.g., an end-user client) to tolerate incorrectly-provided
1435 credentials (e.g., a mistyped password) without being forced to
1436 reconnect.
1437 2. The receiving entity reports failure of the handshake by sending
1438 a element qualified by the
1439 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating
1440 entity (the particular cause of failure SHOULD be communicated in
1441 an appropriate child element of the element as defined
1442 under SASL Errors (Section 7.4)). If the failure case occurs,
1443 the receiving entity SHOULD allow a configurable but reasonable
1444 number of retries (at least 2), after which it MUST terminate the
1445 TCP connection; this enables the initiating entity (e.g., an end-
1446 user client) to tolerate incorrectly-provided credentials (e.g.,
1447 a mistyped password) without being forced to reconnect.
1448 3. The receiving entity reports success of the handshake by sending
1449 a element qualified by the
1450 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating
1451 entity; this element MAY contain XML character data (in SASL
1452 terminology, "additional data with success") if required by the
1453 chosen SASL mechanism; if the receiving entity needs to send
1454 additional data of zero length, it MUST transmit the data as a
1455 single equals sign ("="). Upon receiving the element,
1456 the initiating entity MUST initiate a new stream by sending an
1457 opening XML stream header to the receiving entity (it is not
1458 necessary to send a closing tag first, since the
1459 receiving entity and initiating entity MUST consider the original
1460 stream to be closed upon sending or receiving the
1461 element). Upon receiving the new stream header from the
1462 initiating entity, the receiving entity MUST respond by sending a
1463 new XML stream header to the initiating entity, along with any
1464 available features or an empty element (to signify
1465 that no additional features are available); any such additional
1466 features not defined herein MUST be defined by the relevant
1467 extension to XMPP. As noted, if SASL negotiation involved
1468 establishment of a security layer, the receiving entity SHOULD
1469 send an updated list of SASL mechanisms so that the initiating
1470 entity can detect any changes to the list of mechanisms supported
1471 by the receiving entity.
1473 7.3. SASL Definition
1475 The profiling requirements of [SASL] require that the following
1476 information be supplied by a protocol definition:
1478 service name: "xmpp"
1479 initiation sequence: After the initiating entity provides an opening
1480 XML stream header and the receiving entity replies in kind, the
1481 receiving entity provides a list of acceptable authentication
1482 methods. The initiating entity chooses one method from the list
1483 and sends it to the receiving entity as the value of the
1484 'mechanism' attribute possessed by an element, optionally
1485 including an initial response to avoid a round trip.
1486 exchange sequence: Challenges and responses are carried through the
1487 exchange of elements from receiving entity to
1488 initiating entity and elements from initiating entity
1489 to receiving entity. The receiving entity reports failure by
1490 sending a element and success by sending a
1491 element; the initiating entity aborts the exchange by sending an
1492 element. Upon successful negotiation, both sides
1493 consider the original XML stream to be closed and new stream
1494 headers are sent by both entities.
1495 security layer negotiation: The security layer takes effect
1496 immediately after sending the closing ">" character of the
1497 element for the receiving entity, and immediately after
1498 receiving the closing ">" character of the element for
1499 the initiating entity. The order of layers is first [TCP], then
1500 [TLS], then [SASL], then XMPP.
1501 use of the authorization identity: The authorization identity may be
1502 used by xmpp to denote the non-default of a client
1503 or the sending of a server; an empty string is equivalent
1504 to an absent authorization identity.
1506 7.4. SASL Errors
1508 The following SASL-related error conditions are defined:
1510 o -- The receiving entity acknowledges an
1511 element sent by the initiating entity; sent in reply to the
1512 element.
1513 o -- The data provided by the initiating
1514 entity could not be processed because the [BASE64] encoding is
1515 incorrect (e.g., because the encoding does not adhere to the
1516 definition in Section 3 of [BASE64]); sent in reply to a
1517 element or an element with initial response
1518 data.
1519 o -- The authzid provided by the initiating
1520 entity is invalid, either because it is incorrectly formatted or
1521 because the initiating entity does not have permissions to
1522 authorize that ID; sent in reply to a element or an
1523 element with initial response data.
1524 o -- The initiating entity did not provide a
1525 mechanism or requested a mechanism that is not supported by the
1526 receiving entity; sent in reply to an element.
1527 o -- The challenge or response is malformed
1528 (e.g., the element includes an initial response but the
1529 mechanism does not allow that); sent in reply to an ,
1530 , , or element.
1531 o -- The mechanism requested by the initiating
1532 entity is weaker than server policy permits for that initiating
1533 entity; sent in reply to a element or an
1534 element with initial response data.
1535 o -- The authentication failed because the
1536 initiating entity did not provide proper credentials (this
1537 includes but is not limited to the case of an unknown username,
1538 and no differentiation is made between an unknown username and
1539 incorrect credentials); sent in reply to a element or
1540 an element with initial response data.
1541 o -- The authentication failed because of
1542 a temporary error condition within the receiving entity, and the
1543 initiating entity should try again later; sent in reply to an
1544 element or element.
1546 Examples of SASL negotiation are provided under Section 10.
1548 8. Resource Binding
1550 After a client authenticates with a server, it MUST bind a specific
1551 resource to the stream so that the server can properly address the
1552 client (see addresses (Section 3)) and route XML stanzas to and from
1553 the client (see stanza delivery rules (Section 11)). That is, there
1554 MUST be a resource identifier associated with the "bare JID"
1555 () of the client; this ensures that the address for use
1556 over that stream is a "full JID" of the form .
1557 After binding a resource to the stream, the client is referred to as
1558 a CONNECTED RESOURCE.
1560 Upon receiving a success indication within the SASL negotiation, the
1561 client MUST send a new stream header to the server, to which the
1562 server MUST respond with a stream header as well as a list of
1563 available stream features. Specifically, if the server requires the
1564 client to bind a resource to the stream after successful SASL
1565 negotiation, it MUST include a element qualified by the
1566 'urn:ietf:params:xml:ns:xmpp-bind' namespace in the stream features
1567 list it presents to the client upon sending the header for the
1568 response stream sent after successful SASL negotiation (but not
1569 before); this element SHOULD include an empty
1570 element as well.
1572 Server advertises resource binding feature to client:
1574
1582
1583
1584
1585
1586
1588 Upon being so informed that resource binding is required, the client
1589 MUST bind a resource to the stream by sending to the server an IQ
1590 stanza of type "set" (see IQ Semantics (Section 9.2.3)) containing
1591 data qualified by the 'urn:ietf:params:xml:ns:xmpp-bind' namespace.
1593 If the client wishes to allow the server to generate the resource
1594 identifier on its behalf, it sends an IQ stanza of type "set" that
1595 contains an empty element.
1597 Client asks server to bind a resource:
1599
1600
1601
1603 A server that supports resource binding MUST be able to generate a
1604 resource identifier on behalf of a client. A resource identifier
1605 generated by the server MUST be currently unique for that
1606 .
1608 If the client wishes to specify the resource identifier, it MUST send
1609 an IQ stanza of type "set" that contains the desired resource
1610 identifier as the non-zero-length XML character data of a
1611 element that is a child of the element.
1613 Client binds a resource:
1615
1616
1617 balcony
1618
1619
1621 Once the server has generated a resource identifier for the client or
1622 accepted the resource identifier provided by the client, it MUST
1623 return an IQ stanza of type "result" to the client, which MUST
1624 include a child element that specifies the full JID for the
1625 connected resource as determined by the server.
1627 Server informs client of successful resource binding:
1629
1630
1631 juliet@example.com/balcony
1632
1633
1635 A server SHOULD accept the resource identifier provided by the
1636 client, but MAY override it with a resource identifier that the
1637 server generates; in this case, the server SHOULD NOT return a stanza
1638 error (e.g., ) to the client but instead SHOULD
1639 communicate the generated resource identifier to the client in the IQ
1640 result as shown above.
1642 When a client supplies a resource identifier, the following stanza
1643 error conditions are possible (see Stanza Errors (Section 9.3)):
1645 o The provided resource identifier cannot be processed by the
1646 server, e.g. because it is not in accordance with Resourceprep
1647 (Appendix B).
1648 o The client is not allowed to bind a resource to the stream (e.g.,
1649 because the node or user has reached a limit on the number of
1650 connected resources allowed).
1651 o The provided resource identifier is already in use but the server
1652 does not allow binding of multiple connected resources with the
1653 same identifier.
1655 The protocol for these error conditions is as follows.
1657 Resource identifier cannot be processed:
1659
1660
1661 someresource
1662
1663
1664
1665
1666
1668 Client is not allowed to bind a resource:
1670
1671
1672 someresource
1673
1674
1675
1676
1677
1679 If there is already a connected resource of the same name, the server
1680 MUST do one of the following:
1682 1. Not accept the resource identifier provided by the client but
1683 instead override it with a resource identifier that the server
1684 generates.
1685 2. Terminate the current resource and allow the newly-requested
1686 resource.
1687 3. Disallow the newly-requested resource and maintain the current
1688 resource.
1690 Which of these the server does is up to the implementation, although
1691 it is RECOMMENDED to implement case #1. In case #2, the server MUST
1692 send a stream error to the current resource, terminate
1693 the XML stream and underlying TCP connection for the current
1694 resource, and return a IQ stanza of type "result" (indicating
1695 success) to the newly-requested resource. In case #3, the server
1696 MUST either (a) return a server-generated resource name or (b) send a
1697 stanza error to the newly-requested resource but maintain
1698 the XML stream for that connection so that the newly-requested
1699 resource has an opportunity to negotiate a non-conflicting resource
1700 identifier before sending another request for resource binding.
1702 Resource identifier is in use:
1704
1705
1706 someresource
1707
1708
1709
1710
1711
1713 If, before completing the resource binding step, the client attempts
1714 to send an outbound XML stanza (i.e., a stanza not directed to the
1715 server itself or to the client's own account), the server MUST NOT
1716 process the stanza and SHOULD return a stanza error
1717 to the client.
1719 8.1. Binding Multiple Resources
1721 A server MAY support binding of multiple resources to the same
1722 stream. This functionality is desirable in certain environments
1723 (e.g., for devices that are unable to open more than one TCP
1724 connection or when a machine runs an XMPP client daemon that is used
1725 by multiple applications). If a server supports binding of multiple
1726 resources to a stream, it MUST enable a client to unbind resources.
1727 This shall be completed by sending an IQ-set with a child element of
1728 qualified by the 'urn:ietf:params:xml:ns:xmpp-bind'
1729 namespace, which in turn has a child element of whose XML
1730 character data specifies the resource to be unbound:
1732
1733
1734 someresource
1735
1736
1738 If the server does not understand the element, it MUST
1739 return an error of . Otherwise, if there is no such
1740 resource for that stream, the server MUST return an error of . When the client unbinds the only resource associated
1742 with the stream, the server SHOULD close the stream and terminate the
1743 TCP connection.
1745 A server SHOULD advertise its support for the
1746 'urn:ietf:params:xml:ns:xmpp-bind' namespace by returning an
1747 appropriate stream feature as follows:
1749
1750
1751
1752
1754 When a client binds multiple resources to the same stream, proper
1755 management of 'from' addresses is imperative. In particular, a
1756 client MUST specify a 'from' address on every stanza it sends over a
1757 stream to which it has bound multiple resources, where the 'from'
1758 address is the full JID () associated with
1759 the relevant resource. If a client does not specify a 'from' address
1760 on a stanza it sends over a stream to which it has bound multiple
1761 resources (or if it specifies as the 'from' address a full JID other
1762 than one of the bound resources), the server MUST return the stanza
1763 to the client with an stanza error.
1765 Naturally, the rules regarding validation of asserted 'from'
1766 addresses still apply (see Section 11).
1768 9. XML Stanzas
1770 After a client has connected to a server or two servers have
1771 connected to each other, either party can send XML stanzas over the
1772 negotiated stream. Three kinds of XML stanza are defined for the
1773 'jabber:client' and 'jabber:server' namespaces: ,
1774 , and . In addition, there are five common
1775 attributes for these kinds of stanza. These common attributes, as
1776 well as the basic semantics of the three stanza kinds, are defined
1777 herein; more detailed information regarding the syntax of XML stanzas
1778 for instant messaging and presence applications is provided in
1779 [XMPP-IM], and for other applications in the relevant XMPP extension
1780 specifications.
1782 An XML stanza is the basic unit of meaning in XMPP. A server MUST
1783 NOT process, deliver, or route a partial stanza and a server MUST NOT
1784 attach meaning to the transmission timing of any child element within
1785 a stanza.
1787 9.1. Common Attributes
1789 The following five attributes are common to message, presence, and IQ
1790 stanzas:
1792 9.1.1. to
1794 The 'to' attribute specifies the JID of the intended recipient for
1795 the stanza.
1797 In the 'jabber:client' namespace, a stanza with a specific intended
1798 recipient MUST possess a 'to' attribute, whereas a stanza sent from a
1799 client to a server for direct processing by that server (e.g.,
1800 presence sent to the server for broadcasting to other entities)
1801 SHOULD NOT possess a 'to' attribute.
1803 In the 'jabber:server' namespace, a stanza MUST possess a 'to'
1804 attribute; if a server receives a stanza that does not meet this
1805 restriction, it MUST generate an stream error
1806 condition and terminate both the XML stream and the underlying TCP
1807 connection with the offending server.
1809 If the value of the 'to' attribute is invalid or cannot be contacted,
1810 the entity discovering that fact (usually the sender's or recipient's
1811 server) MUST return an appropriate error to the sender, setting the
1812 'from' attribute of the error stanza to the value provided in the
1813 'to' attribute of the offending stanza.
1815 9.1.2. from
1817 The 'from' attribute specifies the JID of the sender.
1819 When a server receives an XML stanza within the context of an
1820 authenticated stream qualified by the 'jabber:client' namespace, it
1821 MUST do one of the following:
1822 1. validate that the value of the 'from' attribute provided by the
1823 client is that of a connected resource for the associated entity
1824 2. add a 'from' address to the stanza whose value is the full JID
1825 () determined by the server for the
1826 connected resource that generated the stanza (see Determination
1827 of Addresses (Section 3.5)), or the bare JID () in
1828 the case of subscription-related presence stanzas (see [XMPP-IM]
1829 for details)
1831 If a client attempts to send an XML stanza for which the value of the
1832 'from' attribute does not exactly match one of the connected
1833 resources for that entity, the server SHOULD return an stream error to the client. If a client attempts to send an
1835 XML stanza over a stream that is not yet authenticated, the server
1836 SHOULD return a stream error to the client. If
1837 generated, both of these conditions MUST result in closure of the
1838 stream and termination of the underlying TCP connection; this helps
1839 to prevent a denial of service attack launched from a rogue client.
1841 When a server generates a stanza from the server itself for delivery
1842 to a connected client (e.g., in the context of data storage services
1843 provided by the server on behalf of the client), the stanza MUST
1844 either (1) not include a 'from' attribute or (2) include a 'from'
1845 attribute whose value is the account's bare JID () or
1846 connected resource's full JID (). A server
1847 MUST NOT send to the client a stanza without a 'from' attribute if
1848 the stanza was not generated by the server itself. When a client
1849 receives a stanza that does not include a 'from' attribute, it MUST
1850 assume that the stanza is from the server to which the client is
1851 connected.
1853 In the 'jabber:server' namespace, a stanza MUST possess a 'from'
1854 attribute; if a server receives a stanza that does not meet this
1855 restriction, it MUST generate an stream error
1856 condition. Furthermore, the domain identifier portion of the JID
1857 contained in the 'from' attribute MUST match the hostname of the
1858 sending server (or any validated domain thereof, such as a validated
1859 subdomain of the sending server's hostname or another validated
1860 domain hosted by the sending server) as communicated in the SASL
1861 negotiation or dialback negotiation; if a server receives a stanza
1862 that does not meet this restriction, it MUST generate an stream error condition. Both of these conditions MUST result
1864 in closure of the stream and termination of the underlying TCP
1865 connection; this helps to prevent a denial of service attack launched
1866 from a rogue server.
1868 9.1.3. id
1870 The optional 'id' attribute MAY be used by a sending entity for
1871 internal tracking of stanzas that it sends and receives (especially
1872 for tracking the request-response interaction inherent in the
1873 semantics of IQ stanzas). It is OPTIONAL for the value of the 'id'
1874 attribute to be unique globally, within a domain, or within a stream.
1875 The semantics of IQ stanzas impose additional restrictions; see IQ
1876 Semantics (Section 9.2.3).
1878 9.1.4. type
1880 The 'type' attribute specifies detailed information about the purpose
1881 or context of the message, presence, or IQ stanza. The particular
1882 allowable values for the 'type' attribute vary depending on whether
1883 the stanza is a message, presence, or IQ; the values for message and
1884 presence stanzas are specific to instant messaging and presence
1885 applications and therefore are defined in [XMPP-IM], whereas the
1886 values for IQ stanzas specify the role of an IQ stanza in a
1887 structured request-response "conversation" and thus are defined under
1888 IQ Semantics (Section 9.2.3) below. The only 'type' value common to
1889 all three stanzas is "error"; see Stanza Errors (Section 9.3).
1891 9.1.5. xml:lang
1893 A stanza SHOULD possess an 'xml:lang' attribute (as defined in
1894 Section 2.12 of [XML]) if the stanza contains XML character data that
1895 is intended to be presented to a human user (as explained in
1896 [CHARSET], "internationalization is for humans"). The value of the
1897 'xml:lang' attribute specifies the default language of any such
1898 human-readable XML character data, which MAY be overridden by the
1899 'xml:lang' attribute of a specific child element. If a stanza does
1900 not possess an 'xml:lang' attribute, an implementation MUST assume
1901 that the default language is that specified for the stream as defined
1902 under Stream Attributes (Section 5.3) above. The value of the 'xml:
1903 lang' attribute MUST be an NMTOKEN and MUST conform to the format
1904 defined in [LANGTAGS].
1906 9.2. Basic Semantics
1908 9.2.1. Message Semantics
1910 The stanza kind can be seen as a "push" mechanism whereby
1911 one entity pushes information to another entity, similar to the
1912 communications that occur in a system such as email. All message
1913 stanzas SHOULD possess a 'to' attribute that specifies the intended
1914 recipient of the message; upon receiving such a stanza, a server
1915 SHOULD route or deliver it to the intended recipient (see Server
1916 Rules for Handling XML Stanzas (Section 11) for general routing and
1917 delivery rules related to XML stanzas).
1919 9.2.2. Presence Semantics
1921 The element can be seen as a specialized broadcast or
1922 "publish-subscribe" mechanism, whereby multiple entities receive
1923 information about an entity to which they have subscribed (in this
1924 case, network availability information). In general, a publishing
1925 entity SHOULD send a presence stanza with no 'to' attribute, in which
1926 case the server to which the entity is connected SHOULD broadcast or
1927 multiplex that stanza to all subscribing entities. However, a
1928 publishing entity MAY also send a presence stanza with a 'to'
1929 attribute, in which case the server SHOULD route or deliver that
1930 stanza to the intended recipient. See Server Rules for Handling XML
1931 Stanzas (Section 11) for general routing and delivery rules related
1932 to XML stanzas, and [XMPP-IM] for rules specific to presence
1933 applications.
1935 9.2.3. IQ Semantics
1937 Info/Query, or IQ, is a request-response mechanism, similar in some
1938 ways to [HTTP]. The semantics of IQ enable an entity to make a
1939 request of, and receive a response from, another entity. The data
1940 content of the request and response is defined by the schema or other
1941 structural definition associated with the XML namespace that
1942 qualifies the direct child element of the IQ element (see extended
1943 namespaces (Section 9.4)), and the interaction is tracked by the
1944 requesting entity through use of the 'id' attribute. Thus, IQ
1945 interactions follow a common pattern of structured data exchange such
1946 as get/result or set/result (although an error may be returned in
1947 reply to a request if appropriate):
1949 Requesting Responding
1950 Entity Entity
1951 ---------- ----------
1952 | |
1953 | |
1954 | ------------------------> |
1955 | |
1956 | |
1957 | <------------------------ |
1958 | |
1959 | |
1960 | ------------------------> |
1961 | |
1962 | |
1963 | <------------------------ |
1964 | |
1966 In order to enforce these semantics, the following rules apply:
1968 1. The 'id' attribute is REQUIRED for IQ stanzas.
1969 2. The 'type' attribute is REQUIRED for IQ stanzas. The value MUST
1970 be one of the following:
1971 * get -- The stanza is a request for information or
1972 requirements.
1973 * set -- The stanza provides required data, sets new values, or
1974 replaces existing values.
1975 * result -- The stanza is a response to a successful get or set
1976 request.
1978 * error -- An error has occurred regarding processing or
1979 delivery of a previously-sent get or set (see Stanza Errors
1980 (Section 9.3)).
1981 3. An entity that receives an IQ request of type "get" or "set" MUST
1982 reply with an IQ response of type "result" or "error" (the
1983 response MUST preserve the 'id' attribute of the request).
1984 4. An entity that receives a stanza of type "result" or "error" MUST
1985 NOT respond to the stanza by sending a further IQ response of
1986 type "result" or "error"; however, as shown above, the requesting
1987 entity MAY send another request (e.g., an IQ of type "set" in
1988 order to provide required information discovered through a get/
1989 result pair).
1990 5. An IQ stanza of type "get" or "set" MUST contain one and only one
1991 child element that specifies the semantics of the particular
1992 request or response.
1993 6. An IQ stanza of type "result" MUST include zero or one child
1994 elements.
1995 7. An IQ stanza of type "error" SHOULD include the child element
1996 contained in the associated "get" or "set" and MUST include an
1997 child; for details, see Stanza Errors (Section 9.3).
1999 9.3. Stanza Errors
2001 Stanza-related errors are handled in a manner similar to stream
2002 errors (Section 5.8). However, unlike stream errors, stanza errors
2003 are recoverable; therefore error stanzas include hints regarding
2004 actions that the original sender can take in order to remedy the
2005 error.
2007 9.3.1. Rules
2009 The following rules apply to stanza-related errors:
2011 o The receiving or processing entity that detects an error condition
2012 in relation to a stanza SHOULD return an "error stanza" (and MUST
2013 do so for IQ stanzas), where such an "error stanza" is a stanza of
2014 the same kind (message, presence, or IQ) whose 'type' attribute is
2015 set to a value of "error".
2016 o The entity that generates an error stanza SHOULD include the
2017 original XML sent so that the sender can inspect and, if
2018 necessary, correct the XML before attempting to resend.
2019 o An error stanza MUST contain an child element.
2020 o An child MUST NOT be included if the 'type' attribute has
2021 a value other than "error" (or if there is no 'type' attribute).
2022 o An entity that receives an error stanza MUST NOT respond to the
2023 stanza with a further error stanza; this helps to prevent looping.
2025 9.3.2. Syntax
2027 The syntax for stanza-related errors is as follows:
2029
2030 [RECOMMENDED to include sender XML here]
2031
2032
2033 [
2035 OPTIONAL descriptive text
2036 ]
2037 [OPTIONAL application-specific condition element]
2038
2039
2041 The "stanza-kind" is one of message, presence, or iq.
2043 The value of the element's 'type' attribute MUST be one of
2044 the following:
2046 o cancel -- do not retry (the error is unrecoverable)
2047 o continue -- proceed (the condition was only a warning)
2048 o modify -- retry after changing the data sent
2049 o auth -- retry after providing credentials
2050 o wait -- retry after waiting (the error is temporary)
2052 The element:
2054 o MUST contain a child element corresponding to one of the defined
2055 stanza error conditions specified below; this element MUST be
2056 qualified by the 'urn:ietf:params:xml:ns:xmpp-stanzas' namespace.
2057 o MAY contain a child containing XML character data that
2058 describes the error in more detail; this element MUST be qualified
2059 by the 'urn:ietf:params:xml:ns:xmpp-stanzas' namespace and SHOULD
2060 possess an 'xml:lang' attribute.
2061 o MAY contain a child element for an application-specific error
2062 condition; this element MUST be qualified by an application-
2063 defined namespace, and its structure is defined by that namespace.
2065 The element is OPTIONAL. If included, it SHOULD be used only
2066 to provide descriptive or diagnostic information that supplements the
2067 meaning of a defined condition or application-specific condition. It
2068 SHOULD NOT be interpreted programmatically by an application. It
2069 SHOULD NOT be used as the error message presented to a user, but MAY
2070 be shown in addition to the error message associated with the
2071 included condition element (or elements).
2073 Finally, to maintain backward compatibility, the schema (specified in
2074 [XMPP-IM]) allows the optional inclusion of a 'code' attribute on the
2075 element; for details, see [XEP-0086].
2077 9.3.3. Defined Conditions
2079 The following conditions are defined for use in stanza errors.
2081 o -- the sender has sent XML that is malformed or
2082 that cannot be processed (e.g., an IQ stanza that includes an
2083 unrecognized value of the 'type' attribute); the associated error
2084 type SHOULD be "modify".
2085 o -- access cannot be granted because an existing
2086 resource exists with the same name or address; the associated
2087 error type SHOULD be "cancel".
2088 o -- the feature requested is not
2089 implemented by the recipient or server and therefore cannot be
2090 processed; the associated error type SHOULD be "cancel" or
2091 "modify".
2092 o -- the requesting entity does not possess the
2093 required permissions to perform the action; the associated error
2094 type SHOULD be "auth".
2095 o -- the recipient or server can no longer be contacted at
2096 this address (the error stanza MAY contain a new address in the
2097 XML character data of the element); the associated error
2098 type SHOULD be "cancel" or "modify".
2099 o -- the server could not process the
2100 stanza because of a misconfiguration or an otherwise-undefined
2101 internal server error; the associated error type SHOULD be "wait".
2102 o -- the addressed JID or item requested cannot be
2103 found; the associated error type SHOULD be "cancel".
2104 o -- the sending entity has provided or
2105 communicated an XMPP address (e.g., a value of the 'to' attribute)
2106 or aspect thereof (e.g., a resource identifier) that does not
2107 adhere to the syntax defined under Addresses (Section 3); the
2108 associated error type SHOULD be "modify".
2109 o -- the recipient or server understands the
2110 request but is refusing to process it because it does not meet
2111 criteria defined by the recipient or server (e.g., a local policy
2112 regarding stanza size limits or acceptable words in messages); the
2113 associated error type SHOULD be "modify".
2114 o -- the recipient or server does not allow any
2115 entity to perform the action (e.g., sending to entities at a
2116 blacklisted domain); the associated error type SHOULD be "cancel".
2117 o -- the sender must provide proper credentials
2118 before being allowed to perform the action, or has provided
2119 improper credentials; the associated error type SHOULD be "auth".
2121 o -- the item requested has not changed since it was
2122 last requested; the associated error type SHOULD be "continue".
2123 o -- the requesting entity is not authorized to
2124 access the requested service because payment is required; the
2125 associated error type SHOULD be "auth".
2126 o -- the intended recipient is temporarily
2127 unavailable; the associated error type SHOULD be "wait" (note: an
2128 application MUST NOT return this error if doing so would provide
2129 information about the intended recipient's network availability to
2130 an entity that is not authorized to know such information).
2131 o -- the recipient or server is redirecting requests for
2132 this information to another entity, usually temporarily (the error
2133 stanza SHOULD contain the alternate address, which MUST be a valid
2134 JID, in the XML character data of the element); the
2135 associated error type SHOULD be "modify".
2136 o -- the requesting entity is not
2137 authorized to access the requested service because prior
2138 registration is required; the associated error type SHOULD be
2139 "auth".
2140 o -- a remote server or service specified
2141 as part or all of the JID of the intended recipient does not
2142 exist; the associated error type SHOULD be "cancel".
2143 o -- a remote server or service specified
2144 as part or all of the JID of the intended recipient (or required
2145 to fulfill a request) could not be contacted within a reasonable
2146 amount of time; the associated error type SHOULD be "wait".
2147 o -- the server or recipient lacks the system
2148 resources necessary to service the request; the associated error
2149 type SHOULD be "wait".
2150 o -- the server or recipient does not
2151 currently provide the requested service; the associated error type
2152 SHOULD be "cancel".
2153 o -- the requesting entity is not
2154 authorized to access the requested service because a subscription
2155 is required; the associated error type SHOULD be "auth".
2156 o -- the error condition is not one of those
2157 defined by the other conditions in this list; any error type may
2158 be associated with this condition, and it SHOULD be used only in
2159 conjunction with an application-specific condition.
2160 o -- the recipient or server understood the
2161 request but was not expecting it at this time (e.g., the request
2162 was out of order); the associated error type SHOULD be "wait" or
2163 "modify".
2164 o -- the stanza 'from' address specified by a
2165 remote server or connected client is not known to the receiving
2166 server or is not valid for the stream; the associated error type
2167 SHOULD be "modify".
2169 9.3.4. Application-Specific Conditions
2171 As noted, an application MAY provide application-specific stanza
2172 error information by including a properly-namespaced child in the
2173 error element. The application-specific element SHOULD supplement or
2174 further qualify a defined element. Thus, the element will
2175 contain two or three child elements:
2177
2178
2179
2180
2181
2182
2184
2185
2186
2188
2190 Some special application diagnostic information...
2191
2192
2193
2194
2196 9.4. Extended Namespaces
2198 While the message, presence, and IQ stanza kinds provide basic
2199 semantics for messaging, availability, and request-response
2200 interactions, XMPP uses XML namespaces to extend the stanzas for the
2201 purpose of providing additional functionality. Thus a message or
2202 presence stanza MAY contain one or more optional child elements
2203 specifying content that extends the meaning of the message (e.g., an
2204 XHTML-formatted version of the message body as described in
2205 [XEP-0071]), and an IQ stanza MAY contain one such child element.
2206 This child element MAY have any name and MUST possess an 'xmlns'
2207 namespace declaration (other than "jabber:client", "jabber:server",
2208 or "http://etherx.jabber.org/streams") that defines all data
2209 contained within the child element. Such a child element is said to
2210 be defined by an EXTENDED NAMESPACE.
2212 Support for any given extended namespace is OPTIONAL on the part of
2213 any implementation. If an entity does not understand such a
2214 namespace, the entity's expected behavior depends on whether the
2215 entity is (1) the recipient or (2) an entity that is routing the
2216 stanza to the recipient:
2218 Recipient: If a recipient receives a stanza that contains a child
2219 element it does not understand, it SHOULD ignore that specific XML
2220 data, i.e., it SHOULD not process it or present it to a user or
2221 associated application (if any). In particular:
2222 * If an entity receives a message or presence stanza that
2223 contains XML data qualified by a namespace it does not
2224 understand, the portion of the stanza that is in the unknown
2225 namespace SHOULD be ignored.
2226 * If an entity receives a message stanza whose only child element
2227 is qualified by a namespace it does not understand, it MUST
2228 ignore the entire stanza.
2229 * If an entity receives an IQ stanza of type "get" or "set"
2230 containing a child element qualified by a namespace it does not
2231 understand, the entity SHOULD return an IQ stanza of type
2232 "error" with an error condition of .
2233 Router: If a routing entity (usually a server) handles a stanza that
2234 contains a child element it does not understand, it SHOULD ignore
2235 the associated XML data by passing it on untouched to the
2236 recipient.
2238 10. Examples
2240 10.1. Client-to-Server
2242 The following examples show the data flow for a client negotiating an
2243 XML stream with a server, exchanging XML stanzas, and closing the
2244 negotiated stream. The server is "example.com", the server requires
2245 use of TLS, the client authenticates via the SASL DIGEST-MD5
2246 mechanism as "juliet@example.com", and the client binds the resource
2247 "balcony" to the stream. (Note: The alternate steps shown below are
2248 provided to illustrate the protocol for failure cases; they are not
2249 exhaustive and would not necessarily be triggered by the data sent in
2250 the examples.)
2252 Step 1: Client initiates stream to server:
2254
2262 Step 2: Server responds by sending a stream header to client:
2264
2273 Step 3: Server sends stream features to client (STARTTLS extension
2274 and authentication mechanisms):
2276
2277
2278
2279
2280
2282 Step 4: Client sends STARTTLS command to server:
2284
2286 Step 5: Server informs client that it is allowed to proceed:
2288
2290 Step 5 (alt): Server informs client that TLS negotiation has failed
2291 and closes both XML stream and TCP connection:
2293
2294
2296 Step 6: Client and server attempt to complete TLS negotiation over
2297 the existing TCP connection (see [TLS] for details).
2299 Step 7: If TLS negotiation is successful, client initiates a new
2300 stream to server:
2302
2310 Step 7 (alt): If TLS negotiation is unsuccessful, server closes TCP
2311 connection.
2313 Step 8: Server responds by sending a stream header to client along
2314 with any available stream features (notice that the server now shows
2315 a different set of SASL mechanisms; here the server accepts the SASL
2316 PLAIN mechanism once the stream has been secured via TLS):
2318
2326
2327
2328 DIGEST-MD5
2329 PLAIN
2330
2331
2332
2334 Step 9: Client selects an authentication mechanism, in this case
2335 [DIGEST-MD5] with an empty authorization identity ("="):
2337 =
2340 Step 10: Server sends a [BASE64] encoded challenge to client:
2342
2343 cmVhbG09ImV4YW1wbGUuY29tIixub25jZT0iT0E2TUc5dEVRR20yaGgiLHFvcD0i
2344 YXV0aCIsY2hhcnNldD11dGYtOCxhbGdvcml0aG09bWQ1LXNlc3MK
2345
2347 The decoded challenge is:
2349 realm="example.com",nonce="OA6MG9tEQGm2hh",
2350 qop="auth",charset=utf-8,algorithm=md5-sess
2352 Note: When the server sends a DIGEST-MD5 challenge to the client, the
2353 qop list must be quoted since it is a list rather than a single item
2354 (even if there is only one item in the list); however, when the
2355 client sends its response to the server (see below), the qop must not
2356 be quoted since it is a single item rather than a list.
2358 Step 10 (alt): Server returns error to client:
2360
2361
2362
2363
2365 Step 11: Client sends a [BASE64] encoded response to the challenge:
2367
2368 dXNlcm5hbWU9Imp1bGlldCIscmVhbG09ImV4YW1wbGUuY29tIixub25jZT0iT0E2
2369 TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5jPTAwMDAwMDAx
2370 LHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5jb20iLHJlc3BvbnNl
2371 PWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNoYXJzZXQ9dXRmLTgK
2372
2374 The decoded response is:
2376 username="juliet",realm="example.com",
2377 nonce="OA6MG9tEQGm2hh",cnonce="OA6MHXh6VqTrRk",
2378 nc=00000001,qop=auth,digest-uri="xmpp/example.com",
2379 response=d388dad90d4bbd760a152321f2143af7,charset=utf-8
2381 Step 12: Server informs client of success and includes [BASE64]
2382 encoded value for subsequent authentication:
2384
2385 cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo=
2386
2388 The decoded value for subsequent authentication is:
2390 rspauth=ea40f60335c427b5527b84dbabcdfffd
2392 Step 12 (alt): Server returns error to client:
2394
2395
2396
2397
2398 Step 13: Client initiates a new stream to server:
2400
2408 Step 14: Server responds by sending a stream header to client along
2409 with supported features (in this case resource binding):
2411
2419
2420
2421
2422
2423
2425 Upon being so informed that resource binding is required, the client
2426 MUST bind a resource to the stream; here we assume that the client
2427 binds a resource called "balcony".
2429 Step 15: Client binds a resource:
2431
2432
2433 balcony
2434
2435
2436 Step 16: Server informs client of successful resource binding:
2438
2441
2442 juliet@example.com/balcony
2443
2444
2446 Now the client is allowed to send XML stanzas over the negotiated
2447 stream.
2449 Client sends XML stanza to other entity:
2451
2454 Art thou not Romeo, and a Montague?
2455
2457 If necessary, sender's server negotiates XML streams with intended
2458 recipient's server (see Server-to-Server Examples (Section 10.2)).
2460 The intended recipient replies and the message is delivered to the
2461 client.
2463 Client receives XML stanza from other entity:
2465
2468 Neither, fair saint, if either thee dislike.
2469
2471 Desiring to send no further messages, the client closes the stream.
2473 Client closes the stream:
2475
2477 Consistent with the recommended stream closing handshake, server
2478 closes stream as well:
2480 Server closes the stream:
2482
2483 Client now terminates the underlying TCP connection.
2485 10.2. Server-to-Server Examples
2487 The following examples show the data flow for a server negotiating an
2488 XML stream with another server, exchanging XML stanzas, and closing
2489 the negotiated stream. The initiating server ("Server1") is
2490 "example.com"; the receiving server ("Server2") is example.net and it
2491 requires use of TLS; example.com presents a certificate and
2492 authenticates via the SASL EXTERNAL mechanism. (Note: The alternate
2493 steps shown below are provided to illustrate the protocol for failure
2494 cases; they are not exhaustive and would not necessarily be triggered
2495 by the data sent in the examples.)
2497 Step 1: Server1 initiates stream to Server2:
2499
2506 Step 2: Server2 responds by sending a stream tag to Server1:
2508
2516 Step 3: Server2 sends stream features to Server1 (STARTTLS extension
2517 and authentication mechanisms):
2519
2520
2521
2522
2523
2525 Step 4: Server1 sends the STARTTLS command to Server2:
2527
2528 Step 5: Server2 informs Server1 that it is allowed to proceed:
2530
2532 Step 5 (alt): Server2 informs Server1 that TLS negotiation has failed
2533 and closes stream:
2535
2536
2538 Step 6: Server1 and Server2 attempt to complete TLS negotiation via
2539 TCP.
2541 Step 7: If TLS negotiation is successful, Server1 initiates a new
2542 stream to Server2:
2544
2551 Step 7 (alt): If TLS negotiation is unsuccessful, Server2 closes TCP
2552 connection.
2554 Step 8: Server2 responds by sending a stream header to Server1 along
2555 with available stream features (notice that Server2 now prefers the
2556 SASL EXTERNAL mechanism):
2558
2565
2566
2567 EXTERNAL
2568 DIGEST-MD5
2569
2570
2571
2572 Step 9: Server1 selects the EXTERNAL mechanism, in this case with an
2573 authorization identity encoded according to [BASE64]:
2575 ZXhhbXBsZS5jb20K
2578 The decoded authorization identity is "example.com".
2580 Step 10: Server2 determines that the authorization identity provided
2581 by Server1 matches the valid id-xmppAddr-on or Common Name in the
2582 presented certificate and therefore returns success:
2584
2586 Step 11 (alt): Server2 informs Server1 of failed authentication:
2588
2589
2590
2591
2593 Step 12: Server1 initiates a new stream to Server2:
2595
2602 Step 13: Server2 responds by sending a stream header to Server1 along
2603 with any additional features (or, in this case, an empty features
2604 element):
2606
2613
2615 Now Server1 is allowed to send XML stanzas to Server2 over the
2616 negotiated stream; here we assume that the transferred stanzas are
2617 those shown earlier for client-to-server communications.
2619 Server1 sends XML stanza to Server2:
2621
2624 Art thou not Romeo, and a Montague?
2625
2627 The intended recipient replies and the message is delivered from
2628 Server2 to Server1.
2630 Server2 sends XML stanza to Server1:
2632
2635 Neither, fair saint, if either thee dislike.
2636
2638 Desiring to send no further messages, Server1 closes the stream. (In
2639 practice, the stream would most likely remain open for some time,
2640 since Server1 and Server2 do not immediately know if the stream will
2641 be needed for further communications.)
2643 Server1 closes the stream:
2645
2647 Consistent with the recommended stream closing handshake, Server2
2648 closes stream as well:
2650 Server2 closes the stream:
2652
2654 Server1 now terminates the underlying TCP connection.
2656 11. Server Rules for Handling XML Stanzas
2658 Compliant server implementations MUST ensure in-order processing of
2659 XML stanzas between any two entities. This includes stanzas sent by
2660 a client to its server for direct processing by the server.
2662 Beyond the requirement for in-order processing, each server
2663 implementation will contain its own "delivery tree" for handling
2664 stanzas it receives. Such a tree determines whether a stanza needs
2665 to be routed to another domain, processed direct, or delivered to a
2666 resource associated with a connected node. The following rules
2667 apply.
2669 11.1. No 'to' Address
2671 If the stanza possesses no 'to' attribute, the server SHOULD process
2672 it directly on behalf of the entity that sent it. Because all
2673 stanzas received from other servers MUST possess a 'to' attribute,
2674 this rule applies only to stanzas received from a registered entity
2675 (such as a client) that is connected to the server. If the server
2676 receives a presence stanza with no 'to' attribute, the server SHOULD
2677 broadcast it to the entities that are subscribed to the sending
2678 entity's presence, if applicable (the semantics of presence broadcast
2679 for presence applications are defined in [XMPP-IM]). If the server
2680 receives an IQ stanza of type "get" or "set" with no 'to' attribute
2681 and it understands the namespace that qualifies the content of the
2682 stanza, it MUST either process the stanza directly on behalf of
2683 sending entity (where the meaning of "process" is determined by the
2684 semantics of the qualifying namespace) or return an error to the
2685 sending entity.
2687 11.2. Foreign Domain
2689 If the hostname of the domain identifier portion of the JID contained
2690 in the 'to' attribute does not match one of the configured hostnames
2691 of the server itself or a configured subdomain thereof, the server
2692 SHOULD route the stanza to the foreign domain (subject to local
2693 service provisioning and security policies regarding inter-domain
2694 communication, since such communication is OPTIONAL). There are two
2695 possible cases:
2697 A server-to-server stream already exists between the two domains:
2698 The sender's server routes the stanza to the authoritative server
2699 for the foreign domain over the existing stream
2700 There exists no server-to-server stream between the two domains: The
2701 sender's server (1) resolves the hostname of the foreign domain
2702 (as defined under Server-to-Server Communications (Section 15.4)),
2703 (2) negotiates a server-to-server stream between the two domains
2704 (as defined under TLS negotiation (Section 6) and SASL negotiation
2705 (Section 7)), and (3) routes the stanza to the authoritative
2706 server for the foreign domain over the newly-established stream
2708 If routing to the recipient's server is unsuccessful, the sender's
2709 server MUST return an error to the sender; if the recipient's server
2710 can be contacted but delivery by the recipient's server to the
2711 recipient is unsuccessful, the recipient's server MUST return an
2712 error to the sender by way of the sender's server.
2714 11.3. Subdomain
2716 If the hostname of the domain identifier portion of the JID contained
2717 in the 'to' attribute matches a subdomain of one of the configured
2718 hostnames of the server itself, the server MUST either process the
2719 stanza itself or route the stanza to a specialized service that is
2720 responsible for that subdomain (if the subdomain is configured), or
2721 return an error to the sender (if the subdomain is not configured).
2723 11.4. Mere Domain or Specific Resource
2725 If the hostname of the domain identifier portion of the JID contained
2726 in the 'to' attribute matches a configured hostname of the server
2727 itself and the JID contained in the 'to' attribute is of the form
2728 or , the server (or a defined resource
2729 thereof) MUST either process the stanza as appropriate for the stanza
2730 kind or return an error stanza to the sender.
2732 11.5. Node in Same Domain
2734 If the hostname of the domain identifier portion of the JID contained
2735 in the 'to' attribute matches a configured hostname of the server
2736 itself and the JID contained in the 'to' attribute is of the form
2737 or , the server SHOULD deliver
2738 the stanza to the intended recipient of the stanza as represented by
2739 the JID contained in the 'to' attribute. The following rules apply:
2741 1. If the JID contains a resource identifier (i.e., is of the form
2742 ) and there exists a connected resource
2743 that exactly matches the full JID, the recipient's server SHOULD
2744 deliver the stanza to the stream or connection that exactly
2745 matches the resource identifier.
2746 2. If the JID contains a resource identifier and there exists no
2747 connected resource that exactly matches the full JID, the
2748 recipient's server SHOULD return a stanza
2749 error to the sender.
2750 3. If the JID is of the form and there exists at least
2751 one connected resource for the node, the recipient's server
2752 SHOULD deliver the stanza to at least one of the connected
2753 resources, according to application-specific rules.
2755 Particular XMPP applications MAY specify delivery rules that modify
2756 or supplement the foregoing rules; for example, a set of delivery
2757 rules for instant messaging and presence applications is defined in
2758 [XMPP-IM].
2760 12. XML Usage
2762 12.1. Restrictions
2764 XMPP is a simplified and specialized protocol for streaming XML
2765 elements in order to exchange structured information in close to real
2766 time. Because XMPP does not require the parsing of arbitrary and
2767 complete XML documents, there is no requirement that XMPP needs to
2768 support the full feature set of [XML]. In particular, the following
2769 restrictions apply.
2771 With regard to XML generation, an XMPP implementation MUST NOT inject
2772 into an XML stream any of the following:
2774 o comments (as defined in Section 2.5 of [XML])
2775 o processing instructions (Section 2.6 therein)
2776 o internal or external DTD subsets (Section 2.8 therein)
2777 o internal or external entity references (Section 4.2 therein) with
2778 the exception of predefined entities (Section 4.6 therein)
2779 o character data or attribute values containing unescaped characters
2780 that map to the predefined entities (Section 4.6 therein); such
2781 characters MUST be escaped
2783 With regard to XML processing, if an XMPP implementation receives
2784 such restricted XML data, it MUST return a stream
2785 error.
2787 12.2. XML Namespace Names and Prefixes
2789 XML namespaces (see [XML-NAMES]) are used within all XMPP-compliant
2790 XML to create strict boundaries of data ownership. The basic
2791 function of namespaces is to separate different vocabularies of XML
2792 elements that are structurally mixed together. Ensuring that XMPP-
2793 compliant XML is namespace-aware enables any allowable XML to be
2794 structurally mixed with any data element within XMPP. Rules for XML
2795 namespace names and prefixes are defined in the following
2796 subsections.
2798 12.2.1. Streams Namespace
2800 A streams namespace declaration is REQUIRED in all XML stream
2801 headers. The name of the streams namespace MUST be
2802 'http://etherx.jabber.org/streams'. The element names of the
2803 element and its and children MUST be
2804 qualified by the streams namespace prefix in all instances. An
2805 implementation SHOULD generate only the 'stream:' prefix for these
2806 elements, and for historical reasons MAY accept only the 'stream:'
2807 prefix.
2809 12.2.2. Default Namespace
2811 A default namespace declaration is REQUIRED and is used in all XML
2812 streams in order to define the allowable first-level children of the
2813 root stream element. This namespace declaration MUST be the same for
2814 the initial stream and the response stream so that both streams are
2815 qualified consistently. The default namespace declaration applies to
2816 the stream and all stanzas sent within a stream (unless explicitly
2817 qualified by another namespace, or by the prefix of the streams
2818 namespace or the dialback namespace).
2820 A server implementation MUST support the following two default
2821 namespaces (for historical reasons, some implementations MAY support
2822 only these two default namespaces):
2824 o jabber:client -- this default namespace is declared when the
2825 stream is used for communications between a client and a server
2826 o jabber:server -- this default namespace is declared when the
2827 stream is used for communications between two servers
2829 A client implementation MUST support the 'jabber:client' default
2830 namespace, and for historical reasons MAY support only that default
2831 namespace.
2833 An implementation MUST NOT generate namespace prefixes for elements
2834 qualified by the default namespace if the default namespace is
2835 'jabber:client' or 'jabber:server'. An implementation SHOULD NOT
2836 generate namespace prefixes for elements qualified by content (as
2837 opposed to stream) namespaces other than 'jabber:client' and 'jabber:
2838 server'.
2840 Note: The 'jabber:client' and 'jabber:server' namespaces are nearly
2841 identical but are used in different contexts (client-to-server
2842 communications for 'jabber:client' and server-to-server
2843 communications for 'jabber:server'). The only difference between the
2844 two is that the 'to' and 'from' attributes are OPTIONAL on stanzas
2845 sent within 'jabber:client', whereas they are REQUIRED on stanzas
2846 sent within 'jabber:server'. If a compliant implementation accepts a
2847 stream that is qualified by the 'jabber:client' or 'jabber:server'
2848 namespace, it MUST support the common attributes (Section 9.1) and
2849 basic semantics (Section 9.2) of all three core stanza kinds
2850 (message, presence, and IQ).
2852 12.2.3. Dialback Namespace
2854 A dialback namespace declaration is REQUIRED for all elements used in
2855 server dialback (Appendix C). The name of the dialback namespace
2856 MUST be 'jabber:server:dialback'. All elements qualified by this
2857 namespace MUST be prefixed. An implementation SHOULD generate only
2858 the 'db:' prefix for such elements and MAY accept only the 'db:'
2859 prefix.
2861 12.3. Validation
2863 A server is not responsible for validating the XML elements forwarded
2864 to a client or another server; an implementation MAY choose to
2865 provide only validated data elements but this is OPTIONAL (although
2866 an implementation MUST NOT accept XML that is not well-formed).
2867 Clients SHOULD NOT rely on the ability to send data which does not
2868 conform to the schemas, and SHOULD ignore any non-conformant elements
2869 or attributes on the incoming XML stream. Validation of XML streams
2870 and stanzas is OPTIONAL, and schemas are included herein for
2871 descriptive purposes only.
2873 12.4. Inclusion of Text Declaration
2875 Implementations SHOULD send a text declaration before sending a
2876 stream header. Applications MUST follow the rules in [XML] regarding
2877 the circumstances under which a text declaration is included.
2879 12.5. Character Encoding
2881 Implementations MUST support the [UTF-8] transformation of Universal
2882 Character Set ([UCS2]) characters, as required by [CHARSET].
2883 Implementations MUST NOT attempt to use any other encoding.
2885 12.6. White Space
2887 Except where explicitly disallowed (i.e., during TLS negotiation
2888 (Section 6) and SASL negotiation [SASL]), either entity MAY send
2889 white space characters (matching production [3] content of [XML])
2890 within the root stream element as separators between XML stanzas or
2891 between any other first-level elements sent over the stream; one
2892 common use for sending such white space characters is to check the
2893 viability of the underlying TCP connection after a period of
2894 inactivity.
2896 13. Compliance Requirements
2898 This section summarizes the specific aspects of the Extensible
2899 Messaging and Presence Protocol that MUST be supported by servers and
2900 clients in order to be considered compliant implementations, as well
2901 as additional protocol aspects that SHOULD be supported. For
2902 compliance purposes, we draw a distinction between core protocols
2903 (which MUST be supported by any server or client, regardless of the
2904 specific application) and instant messaging and presence protocols
2905 (which MUST be supported only by instant messaging and presence
2906 applications built on top of the core protocols). Compliance
2907 requirements that apply to all servers and clients are specified in
2908 this section; compliance requirements for instant messaging and
2909 presence applications are specified in the corresponding section of
2910 [XMPP-IM].
2912 13.1. Servers
2914 In addition to all defined requirements with regard to security, XML
2915 usage, and internationalization, a server MUST support the following
2916 core protocols in order to be considered compliant:
2918 o Application of the [NAMEPREP], Nodeprep (Appendix A), and
2919 Resourceprep (Appendix B) profiles of [STRINGPREP] to addresses
2920 (including ensuring that domain identifiers are internationalized
2921 domain names as defined in [IDNA])
2922 o XML streams (Section 5), including TLS negotiation (Section 6),
2923 SASL negotiation (Section 7), and Resource Binding (Section 8)
2924 o The basic semantics of the three defined stanza kinds (i.e.,
2925 , , and ) as specified in stanza
2926 semantics (Section 9.2)
2927 o Generation (and, where appropriate, handling) of error syntax and
2928 semantics related to streams, TLS, SASL, and XML stanzas
2930 In addition, for historical reasons a server SHOULD support the
2931 following core protocol:
2933 o Server dialback (Appendix C)
2935 13.2. Clients
2937 A client MUST support the following core protocols in order to be
2938 considered compliant:
2940 o XML streams (Section 5), including TLS negotiation (Section 6),
2941 SASL negotiation (Section 7), and Resource Binding (Section 8)
2942 o The basic semantics of the three defined stanza kinds (i.e.,
2943 , , and ) as specified in stanza
2944 semantics (Section 9.2)
2945 o Handling (and, where appropriate, generation) of error syntax and
2946 semantics related to streams, TLS, SASL, and XML stanzas
2948 In addition, a client SHOULD support the following core protocols:
2950 o Generation of addresses to which the [NAMEPREP], Nodeprep
2951 (Appendix A), and Resourceprep (Appendix B) profiles of
2952 [STRINGPREP] can be applied without failing
2954 14. Internationalization Considerations
2956 XML streams MUST be encoded in UTF-8 as specified under Character
2957 Encoding (Section 12.5). As specified under Stream Attributes
2958 (Section 5.3), an XML stream SHOULD include an 'xml:lang' attribute
2959 specifying the default language for any XML character data sent over
2960 the stream that is intended to be presented to a human user. As
2961 specified under xml:lang (Section 9.1.5), an XML stanza SHOULD
2962 include an 'xml:lang' attribute if the stanza contains XML character
2963 data that is intended to be presented to a human user. A server
2964 SHOULD apply the default 'xml:lang' attribute to stanzas it routes or
2965 delivers on behalf of connected entities, and MUST NOT modify or
2966 delete 'xml:lang' attributes stanzas it receives from other entities.
2968 15. Security Considerations
2970 15.1. High Security
2972 For the purposes of XMPP communications (client-to-server and server-
2973 to-server), the term "high security" refers to the use of security
2974 technologies that provide both mutual authentication and integrity-
2975 checking; in particular, when using certificate-based authentication
2976 to provide high security, a chain-of-trust SHOULD be established out-
2977 of-band, although a shared certificate authority signing certificates
2978 could allow a previously unknown certificate to establish trust in-
2979 band. See Section 15.2 below regarding certificate validation
2980 procedures.
2982 Implementations MUST support high security. Service provisioning
2983 SHOULD use high security, subject to local security policies.
2985 15.2. Certificate Validation
2987 When an XMPP peer communicates with another peer securely, it MUST
2988 validate the peer's certificate. There are three possible cases:
2990 Case #1: The peer contains an End Entity certificate which appears
2991 to be certified by a chain of certificates terminating in a trust
2992 anchor (as described in Section 6.1 of [X509]).
2994 Case #2: The peer certificate is certified by a Certificate
2995 Authority not known to the validating peer.
2996 Case #3: The peer certificate is self-signed.
2998 In Case #1, the validating peer MUST do one of two things:
2999 1. Verify the peer certificate according to the rules of [X509].
3000 The certificate SHOULD then be checked against the expected
3001 identity of the peer following the rules described in [HTTP-TLS],
3002 except that if present an [ASN.1] Object Identifier of "id-on-
3003 xmppAddr" (represented as a UTF8String in an otherName entity
3004 inside the subjectAltName) MUST be used as the identity. If one
3005 of these checks fails, user-oriented clients MUST either notify
3006 the user (clients MAY give the user the opportunity to continue
3007 with the connection in any case) or terminate the connection with
3008 a bad certificate error. Automated clients SHOULD terminate the
3009 connection (with a bad certificate error) and log the error to an
3010 appropriate audit log. Automated clients MAY provide a
3011 configuration setting that disables this check, but MUST provide
3012 a setting that enables it.
3013 2. The peer SHOULD show the certificate to a user for approval,
3014 including the entire certificate chain. The peer MUST cache the
3015 certificate (or some non-forgeable representation such as a
3016 hash). In future connections, the peer MUST verify that the same
3017 certificate was presented and MUST notify the user if it has
3018 changed.
3020 In Case #2 and Case #3, implementations SHOULD act as in (2) above.
3022 15.3. Client-to-Server Communications
3024 A compliant client implementation MUST support both TLS and SASL for
3025 connections to a server.
3027 The TLS protocol for encrypting XML streams (defined under TLS
3028 negotiation (Section 6)) provides a reliable mechanism for helping to
3029 ensure the confidentiality and data integrity of data exchanged
3030 between two entities.
3032 The SASL protocol for authenticating XML streams (defined under SASL
3033 negotiation (Section 7)) provides a reliable mechanism for validating
3034 that a client connecting to a server is who it claims to be.
3036 Client-to-server communications MUST NOT proceed until the DNS
3037 hostname asserted by the server has been resolved as specified under
3038 TCP Binding (Section 4). If there is a mismatch between the hostname
3039 to which a client attempted to connect (e.g., "example.net") and the
3040 hostname to which the client actually connects (e.g.,
3041 "im.example.net"), the client MUST warn a human user about the
3042 mismatch and the human user MUST approve the connection before the
3043 client proceeds; however, the client MAY allow the user to add the
3044 presented hostname to a configured set of accepted hostnames in order
3045 to expedite future connections.
3047 The IP address and method of access of clients MUST NOT be made
3048 public by a server, nor are any connections other than the original
3049 server connection required. This helps to protect the client's
3050 server from direct attack or identification by third parties.
3052 15.4. Server-to-Server Communications
3054 A compliant server implementation MUST support both TLS and SASL for
3055 inter-domain communications. For historical reasons, a compliant
3056 implementation SHOULD also support Server Dialback (Appendix C).
3058 Because service provisioning is a matter of policy, it is OPTIONAL
3059 for any given domain to communicate with other domains, and server-
3060 to-server communications MAY be disabled by the administrator of any
3061 given deployment. If a particular domain enables inter-domain
3062 communications, it SHOULD enable high security.
3064 Administrators may want to require use of SASL for server-to-server
3065 communications in order to ensure both authentication and
3066 confidentiality (e.g., on an organization's private network).
3067 Compliant implementations SHOULD support SASL for this purpose.
3069 Server-to-server communications MUST NOT proceed until the DNS
3070 hostnames asserted by both servers have been resolved as specified
3071 under TCP Binding (Section 4).
3073 Server dialback helps protect against domain spoofing, thus making it
3074 more difficult to spoof XML stanzas. It is not a mechanism for
3075 authenticating, securing, or encrypting streams between servers as is
3076 done via SASL and TLS, and results in weak verification of server
3077 identities only. Furthermore, it is susceptible to DNS poisoning
3078 attacks unless [DNSSEC] is used, and even if the DNS information is
3079 accurate, dialback cannot protect from attacks where the attacker is
3080 capable of hijacking the IP address of the remote domain. Domains
3081 requiring robust security SHOULD use TLS and SASL. If SASL is used
3082 for server-to-server authentication, dialback SHOULD NOT be used
3083 since it is unnecessary.
3085 15.5. Order of Layers
3087 The order of layers in which protocols MUST be stacked is as follows:
3089 1. TCP
3090 2. TLS
3091 3. SASL
3092 4. XMPP
3094 The rationale for this order is that [TCP] is the base connection
3095 layer used by all of the protocols stacked on top of TCP, [TLS] is
3096 often provided at the operating system layer, [SASL] is often
3097 provided at the application layer, and XMPP is the application
3098 itself.
3100 15.6. Lack of SASL Channel Binding to TLS
3102 The SASL framework does not provide a mechanism to bind SASL
3103 authentication to a security layer providing confidentiality and
3104 integrity protection that was negotiated at a lower layer. This lack
3105 of a "channel binding" prevents SASL from being able to verify that
3106 the source and destination end points to which the lower layer's
3107 security is bound are equivalent to the end points that SASL is
3108 authenticating. If the end points are not identical, the lower
3109 layer's security cannot be trusted to protect data transmitted
3110 between the SASL authenticated entities. In such a situation, a SASL
3111 security layer should be negotiated that effectively ignores the
3112 presence of the lower layer security.
3114 15.7. Mandatory-to-Implement Technologies
3116 At a minimum, all implementations MUST support the following
3117 mechanisms:
3119 for authentication: the SASL [DIGEST-MD5] mechanism
3120 for confidentiality: TLS (using the TLS_RSA_WITH_3DES_EDE_CBC_SHA
3121 cipher)
3122 for both: TLS plus SASL PLAIN for client-to-server connections and
3123 TLS plus SASL EXTERNAL for server-to-server connections (using the
3124 TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher supporting peer certificates)
3126 Naturally, implementations MAY support other ciphers with TLS and MAY
3127 support other SASL mechanisms.
3129 15.8. Firewalls
3131 Communications using XMPP normally occur over [TCP] connections on
3132 port 5222 (client-to-server) or port 5269 (server-to-server), as
3133 registered with the IANA (see IANA Considerations (Section 16)). Use
3134 of these well-known ports allows administrators to easily enable or
3135 disable XMPP activity through existing and commonly-deployed
3136 firewalls.
3138 15.9. Use of base64 in SASL
3140 Both the client and the server MUST verify any [BASE64] data received
3141 during SASL negotiation. An implementation MUST reject (not ignore)
3142 any characters that are not explicitly allowed by the base64
3143 alphabet; this helps to guard against creation of a covert channel
3144 that could be used to "leak" information. An implementation MUST NOT
3145 break on invalid input and MUST reject any sequence of base64
3146 characters containing the pad ('=') character if that character is
3147 included as something other than the last character of the data
3148 (e.g., "=AAA" or "BBBB=CCC"); this helps to guard against buffer
3149 overflow attacks and other attacks on the implementation. Base 64
3150 encoding visually hides otherwise easily recognized information, such
3151 as passwords, but does not provide any computational confidentiality.
3152 Base 64 encoding MUST follow the definition in Section 3 of [BASE64].
3154 15.10. Stringprep Profiles
3156 XMPP makes use of the [NAMEPREP] profile of [STRINGPREP] for
3157 processing of domain identifiers; for security considerations related
3158 to Nameprep, refer to the appropriate section of [NAMEPREP].
3160 In addition, XMPP defines two profiles of [STRINGPREP]: Nodeprep
3161 (Appendix A) for node identifiers and Resourceprep (Appendix B) for
3162 resource identifiers.
3164 The Unicode and ISO/IEC 10646 repertoires have many characters that
3165 look similar. In many cases, users of security protocols might do
3166 visual matching, such as when comparing the names of trusted third
3167 parties. Because it is impossible to map similar-looking characters
3168 without a great deal of context, such as knowing the fonts used,
3169 stringprep does nothing to map similar-looking characters together,
3170 nor to prohibit some characters because they look like others.
3172 A node identifier can be employed as one part of an entity's address
3173 in XMPP. One common usage is as the username of an instant messaging
3174 user; another is as the name of a multi-user chat room; many other
3175 kinds of entities could use node identifiers as part of their
3176 addresses. The security of such services could be compromised based
3177 on different interpretations of the internationalized node
3178 identifier; for example, a user entering a single internationalized
3179 node identifier could access another user's account information, or a
3180 user could gain access to an otherwise restricted chat room or
3181 service.
3183 A resource identifier can be employed as one part of an entity's
3184 address in XMPP. One common usage is as the name for an instant
3185 messaging user's connected resource; another is as the nickname of a
3186 user in a multi-user chat room; many other kinds of entities could
3187 use resource identifiers as part of their addresses. The security of
3188 such services could be compromised based on different interpretations
3189 of the internationalized resource identifier; for example, a user
3190 could attempt to initiate multiple connections with the same name, or
3191 a user could send a message to someone other than the intended
3192 recipient in a multi-user chat room.
3194 16. IANA Considerations
3196 16.1. XML Namespace Name for TLS Data
3198 A URN sub-namespace for TLS-related data in the Extensible Messaging
3199 and Presence Protocol (XMPP) is defined as follows. (This namespace
3200 name adheres to the format defined in The IETF XML Registry
3201 [XML-REG].)
3203 URI: urn:ietf:params:xml:ns:xmpp-tls
3204 Specification: RFC 3920
3205 Description: This is the XML namespace name for TLS-related data in
3206 the Extensible Messaging and Presence Protocol (XMPP) as defined
3207 by RFC 3920.
3208 Registrant Contact: IETF, XMPP Working Group,
3210 16.2. XML Namespace Name for SASL Data
3212 A URN sub-namespace for SASL-related data in the Extensible Messaging
3213 and Presence Protocol (XMPP) is defined as follows. (This namespace
3214 name adheres to the format defined in [XML-REG].)
3216 URI: urn:ietf:params:xml:ns:xmpp-sasl
3217 Specification: RFC 3920
3218 Description: This is the XML namespace name for SASL-related data in
3219 the Extensible Messaging and Presence Protocol (XMPP) as defined
3220 by RFC 3920.
3221 Registrant Contact: IETF, XMPP Working Group,
3223 16.3. XML Namespace Name for Stream Errors
3225 A URN sub-namespace for stream-related error data in the Extensible
3226 Messaging and Presence Protocol (XMPP) is defined as follows. (This
3227 namespace name adheres to the format defined in [XML-REG].)
3228 URI: urn:ietf:params:xml:ns:xmpp-streams
3229 Specification: RFC 3920
3230 Description: This is the XML namespace name for stream-related error
3231 data in the Extensible Messaging and Presence Protocol (XMPP) as
3232 defined by RFC 3920.
3233 Registrant Contact: IETF, XMPP Working Group,
3235 16.4. XML Namespace Name for Resource Binding
3237 A URN sub-namespace for resource binding in the Extensible Messaging
3238 and Presence Protocol (XMPP) is defined as follows. (This namespace
3239 name adheres to the format defined in [XML-REG].)
3241 URI: urn:ietf:params:xml:ns:xmpp-bind
3242 Specification: RFC 3920
3243 Description: This is the XML namespace name for resource binding in
3244 the Extensible Messaging and Presence Protocol (XMPP) as defined
3245 by RFC 3920.
3246 Registrant Contact: IETF, XMPP Working Group,
3248 16.5. XML Namespace Name for Stanza Errors
3250 A URN sub-namespace for stanza-related error data in the Extensible
3251 Messaging and Presence Protocol (XMPP) is defined as follows. (This
3252 namespace name adheres to the format defined in [XML-REG].)
3254 URI: urn:ietf:params:xml:ns:xmpp-stanzas
3255 Specification: RFC 3920
3256 Description: This is the XML namespace name for stanza-related error
3257 data in the Extensible Messaging and Presence Protocol (XMPP) as
3258 defined by RFC 3920.
3259 Registrant Contact: IETF, XMPP Working Group,
3261 16.6. Nodeprep Profile of Stringprep
3263 The Nodeprep profile of stringprep is defined under Nodeprep
3264 (Appendix A). The IANA has registered Nodeprep in the stringprep
3265 profile registry.
3267 Name of this profile:
3269 Nodeprep
3271 RFC in which the profile is defined:
3273 RFC 3920
3275 Indicator whether or not this is the newest version of the profile:
3277 This is the first version of Nodeprep
3279 16.7. Resourceprep Profile of Stringprep
3281 The Resourceprep profile of stringprep is defined under Resourceprep
3282 (Appendix B). The IANA has registered Resourceprep in the stringprep
3283 profile registry.
3285 Name of this profile:
3287 Resourceprep
3289 RFC in which the profile is defined:
3291 RFC 3920
3293 Indicator whether or not this is the newest version of the profile:
3295 This is the first version of Resourceprep
3297 16.8. GSSAPI Service Name
3299 The IANA has registered "xmpp" as a GSSAPI [GSS-API] service name, as
3300 defined under SASL Definition (Section 7.3).
3302 16.9. Port Numbers
3304 The IANA has registered "xmpp-client" and "xmpp-server" as keywords
3305 for [TCP] ports 5222 and 5269 respectively.
3307 These ports SHOULD be used for client-to-server and server-to-server
3308 communications respectively, but their use is OPTIONAL.
3310 17. References
3312 17.1. Normative References
3314 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
3315 Specifications: ABNF", RFC 4234, October 2005.
3317 [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data
3318 Encodings", RFC 3548, July 2003.
3320 [CHARSET] Alvestrand, H., "IETF Policy on Character Sets and
3321 Languages", BCP 18, RFC 2277, January 1998.
3323 [DIGEST-MD5]
3324 Leach, P. and C. Newman, "Using Digest Authentication as a
3325 SASL Mechanism", RFC 2831, May 2000.
3327 [DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
3328 specifying the location of services (DNS SRV)", RFC 2782,
3329 February 2000.
3331 [DNS] Mockapetris, P., "Domain names - implementation and
3332 specification", STD 13, RFC 1035, November 1987.
3334 [GSS-API] Linn, J., "Generic Security Service Application Program
3335 Interface Version 2, Update 1", RFC 2743, January 2000.
3337 [HMAC] National Institute of Standards and Technology, "The
3338 Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB
3339 198, March 2002, .
3342 [HTTP-TLS]
3343 Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
3345 [IDNA] Faltstrom, P., Hoffman, P., and A. Costello,
3346 "Internationalizing Domain Names in Applications (IDNA)",
3347 RFC 3490, March 2003.
3349 [IPv6] Hinden, R. and S. Deering, "Internet Protocol Version 6
3350 (IPv6) Addressing Architecture", RFC 3513, April 2003.
3352 [LANGTAGS]
3353 Alvestrand, H., "Tags for the Identification of
3354 Languages", BCP 47, RFC 3066, January 2001.
3356 [NAMEPREP]
3357 Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
3358 Profile for Internationalized Domain Names (IDN)",
3359 RFC 3491, March 2003.
3361 [RANDOM] Eastlake, D., Crocker, S., and J. Schiller, "Randomness
3362 Recommendations for Security", RFC 1750, December 1994.
3364 [SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and
3365 Security Layer (SASL)", RFC 4422, June 2006.
3367 [SHA] National Institute of Standards and Technology, "Secure
3368 Hash Standard", FIPS PUB 180-2, August 2002, .
3372 [STRINGPREP]
3373 Hoffman, P. and M. Blanchet, "Preparation of
3374 Internationalized Strings ("stringprep")", RFC 3454,
3375 December 2002.
3377 [TCP] Postel, J., "Transmission Control Protocol", STD 7,
3378 RFC 793, September 1981.
3380 [TERMS] Bradner, S., "Key words for use in RFCs to Indicate
3381 Requirement Levels", BCP 14, RFC 2119, March 1997.
3383 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security
3384 (TLS) Protocol Version 1.1", RFC 4346, April 2006.
3386 [UCS2] International Organization for Standardization,
3387 "Information Technology - Universal Multiple-octet coded
3388 Character Set (UCS) - Amendment 2: UCS Transformation
3389 Format 8 (UTF-8)", ISO Standard 10646-1 Addendum 2,
3390 October 1996.
3392 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
3393 10646", STD 63, RFC 3629, November 2003.
3395 [X509] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
3396 X.509 Public Key Infrastructure Certificate and
3397 Certificate Revocation List (CRL) Profile", RFC 3280,
3398 April 2002.
3400 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler,
3401 "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-
3402 xml, October 2000, .
3404 [XML-NAMES]
3405 Bray, T., Hollander, D., and A. Layman, "Namespaces in
3406 XML", W3C REC-xml-names, January 1999,
3407 .
3409 17.2. Informative References
3411 [ACAP] Newman, C. and J. Myers, "ACAP -- Application
3412 Configuration Access Protocol", RFC 2244, November 1997.
3414 [ASN.1] CCITT, "Recommendation X.208: Specification of Abstract
3415 Syntax Notation One (ASN.1)", 1988.
3417 [DNSSEC] Eastlake, D., "Domain Name System Security Extensions",
3418 RFC 2535, March 1999.
3420 [DNS-TXT] Rosenbaum, R., "Using the Domain Name System To Store
3421 Arbitrary String Attributes", RFC 1464, May 1993.
3423 [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
3424 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
3425 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
3427 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
3428 4rev1", RFC 3501, March 2003.
3430 [IMP-REQS]
3431 Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging
3432 / Presence Protocol Requirements", RFC 2779,
3433 February 2000.
3435 [IRI] Duerst, M. and M. Suignard, "Internationalized Resource
3436 Identifiers (IRIs)", RFC 3987, January 2005.
3438 [LINKLOCAL]
3439 Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
3440 Configuration of IPv4 Link-Local Addresses", RFC 3927,
3441 May 2005.
3443 [MAILBOXES]
3444 Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND
3445 FUNCTIONS", RFC 2142, May 1997.
3447 [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
3448 STD 53, RFC 1939, May 1996.
3450 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
3451 April 2001.
3453 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
3454 Resource Identifier (URI): Generic Syntax", STD 66,
3455 RFC 3986, January 2005.
3457 [URN-OID] Mealling, M., "A URN Namespace of Object Identifiers",
3458 RFC 3061, February 2001.
3460 [USINGTLS]
3461 Newman, C., "Using TLS with IMAP, POP3 and ACAP",
3462 RFC 2595, June 1999.
3464 [XEP-0045]
3465 Saint-Andre, P., "Multi-User Chat", XSF XEP 0045,
3466 September 2006.
3468 [XEP-0071]
3469 Saint-Andre, P., "XHTML-IM", XSF XEP 0071, January 2006.
3471 [XEP-0077]
3472 Saint-Andre, P., "In-Band Registration", XSF XEP 0077,
3473 January 2006.
3475 [XEP-0086]
3476 Norris, R. and P. Saint-Andre, "Error Condition Mappings",
3477 XSF XEP 0086, February 2004.
3479 [XEP-0124]
3480 Paterson, I., Smith, D., and P. Saint-Andre, "HTTP
3481 Binding", XSF XEP 0124, April 2006.
3483 [XEP-0156]
3484 Hildebrand, J. and P. Saint-Andre, "A DNS TXT Resource
3485 Record Format for XMPP Connection Methods", XSF XEP 0156,
3486 May 2005.
3488 [XEP-0157]
3489 Saint-Andre, P. and J. Konieczny, "Contact Addresses for
3490 XMPP Services", XSF XEP 0157, January 2007.
3492 [XEP-0174]
3493 Saint-Andre, P., "Link-Local Messaging", XSF XEP 0174,
3494 December 2006.
3496 [XEP-0175]
3497 Saint-Andre, P., "Best Practices for Use of SASL
3498 ANONYMOUS", XSF XEP 0175, September 2006.
3500 [XEP-0178]
3501 Saint-Andre, P. and P. Millard, "Best Practices for Use of
3502 SASL EXTERNAL", XSF XEP 0178, January 2007.
3504 [XML-REG] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
3505 January 2004.
3507 [XMPP-IM] Saint-Andre, P., "Extensible Messaging and Presence
3508 Protocol (XMPP): Instant Messaging and Presence",
3509 RFC 3921, October 2004.
3511 [XMPP-URI]
3512 Saint-Andre, P., "Internationalized Resource Identifiers
3513 (IRIs) and Uniform Resource Identifiers (URIs) for the
3514 Extensible Messaging and Presence Protocol (XMPP)",
3515 RFC 4622, August 2006.
3517 Appendix A. Nodeprep
3519 A.1. Introduction
3521 This appendix defines the "Nodeprep" profile of [STRINGPREP]. As
3522 such, it specifies processing rules that will enable users to enter
3523 internationalized node identifiers in the Extensible Messaging and
3524 Presence Protocol (XMPP) and have the highest chance of getting the
3525 content of the strings correct. (An XMPP node identifier is the
3526 optional portion of an XMPP address that precedes a domain identifier
3527 and the '@' separator; it is often but not exclusively associated
3528 with an instant messaging username.) These processing rules are
3529 intended only for XMPP node identifiers and are not intended for
3530 arbitrary text or any other aspect of an XMPP address.
3532 This profile defines the following, as required by [STRINGPREP]:
3534 o The intended applicability of the profile: internationalized node
3535 identifiers within XMPP
3536 o The character repertoire that is the input and output to
3537 stringprep: Unicode 3.2, specified in Section 2 of this Appendix
3538 o The mappings used: specified in Section 3
3539 o The Unicode normalization used: specified in Section 4
3540 o The characters that are prohibited as output: specified in Section
3541 5
3542 o Bidirectional character handling: specified in Section 6
3544 A.2. Character Repertoire
3546 This profile uses Unicode 3.2 with the list of unassigned code points
3547 being Table A.1, both defined in Appendix A of [STRINGPREP].
3549 A.3. Mapping
3551 This profile specifies mapping using the following tables from
3552 [STRINGPREP]:
3554 Table B.1
3555 Table B.2
3557 A.4. Normalization
3559 This profile specifies the use of Unicode normalization form KC, as
3560 described in [STRINGPREP].
3562 A.5. Prohibited Output
3564 This profile specifies the prohibition of using the following tables
3565 from [STRINGPREP].
3567 Table C.1.1
3568 Table C.1.2
3569 Table C.2.1
3570 Table C.2.2
3571 Table C.3
3572 Table C.4
3573 Table C.5
3574 Table C.6
3575 Table C.7
3576 Table C.8
3577 Table C.9
3579 In addition, the following Unicode characters are also prohibited:
3581 #x22 (")
3582 #x26 (&)
3583 #x27 (')
3584 #x2F (/)
3585 #x3A (:)
3586 #x3C (<)
3587 #x3E (>)
3588 #x40 (@)
3590 A.6. Bidirectional Characters
3592 This profile specifies checking bidirectional strings, as described
3593 in Section 6 of [STRINGPREP].
3595 Appendix B. Resourceprep
3597 B.1. Introduction
3599 This appendix defines the "Resourceprep" profile of [STRINGPREP]. As
3600 such, it specifies processing rules that will enable users to enter
3601 internationalized resource identifiers in the Extensible Messaging
3602 and Presence Protocol (XMPP) and have the highest chance of getting
3603 the content of the strings correct. (An XMPP resource identifier is
3604 the optional portion of an XMPP address that follows a domain
3605 identifier and the '/' separator.) These processing rules are
3606 intended only for XMPP resource identifiers and are not intended for
3607 arbitrary text or any other aspect of an XMPP address.
3609 This profile defines the following, as required by [STRINGPREP]:
3611 o The intended applicability of the profile: internationalized
3612 resource identifiers within XMPP
3613 o The character repertoire that is the input and output to
3614 stringprep: Unicode 3.2, specified in Section 2 of this Appendix
3615 o The mappings used: specified in Section 3
3616 o The Unicode normalization used: specified in Section 4
3617 o The characters that are prohibited as output: specified in Section
3618 5
3619 o Bidirectional character handling: specified in Section 6
3621 B.2. Character Repertoire
3623 This profile uses Unicode 3.2 with the list of unassigned code points
3624 being Table A.1, both defined in Appendix A of [STRINGPREP].
3626 B.3. Mapping
3628 This profile specifies mapping using the following tables from
3629 [STRINGPREP]:
3631 Table B.1
3633 B.4. Normalization
3635 This profile specifies the use of Unicode normalization form KC, as
3636 described in [STRINGPREP].
3638 B.5. Prohibited Output
3640 This profile specifies the prohibition of using the following tables
3641 from [STRINGPREP].
3643 Table C.1.2
3644 Table C.2.1
3645 Table C.2.2
3646 Table C.3
3647 Table C.4
3648 Table C.5
3649 Table C.6
3650 Table C.7
3651 Table C.8
3652 Table C.9
3654 B.6. Bidirectional Characters
3656 This profile specifies checking bidirectional strings, as described
3657 in Section 6 of [STRINGPREP].
3659 Appendix C. Server Dialback
3661 C.1. Overview
3663 Server dialback is a reverse DNS lookup method whose results are
3664 communicated over XML streams, thus making it more difficult to spoof
3665 XMPP server domains and XML stanzas sent over XML streams between
3666 servers. Server dialback is not a security mechanism, and results
3667 only in weak verification of server identities (see Server-to-Server
3668 Communications (Section 15.4) regarding this method's security
3669 characteristics). Domains requiring robust security SHOULD use TLS
3670 and SASL; see Server-to-Server Communications (Section 15.4) for
3671 details. If SASL is used for server-to-server authentication,
3672 dialback SHOULD NOT be used since it is unnecessary. Documentation
3673 of dialback is included mainly for the sake of backward-compatibility
3674 with existing implementations and deployments. However, depending on
3675 local policies, a service may wish to use dialback to provide weak
3676 identity verification in cases where SASL negotiation would not
3677 result in strong authentication (e.g., because the certificate
3678 presented by the peer service during TLS negotiation is self-signed
3679 and thus provides even weaker identity verification than DNS).
3681 The server dialback method is made possible by the existence of the
3682 Domain Name System (DNS), since one server can (normally) discover
3683 the authoritative server for a given domain. Because dialback
3684 depends on DNS, inter-domain communications MUST NOT proceed until
3685 the Domain Name System (DNS) hostnames asserted by the servers have
3686 been resolved (see Server-to-Server Communications (Section 15.4)).
3688 Server dialback is uni-directional, and results in weak identity
3689 verification for one stream in one direction. Because server
3690 dialback is not an authentication mechanism, mutual authentication is
3691 not possible via dialback. Therefore, server dialback MUST be
3692 completed in each direction in order to enable bi-directional
3693 communications between two domains.
3695 The method for generating and verifying the keys used in server
3696 dialback MUST take into account the hostnames being used, the stream
3697 ID generated by the receiving server, and a secret known by the
3698 authoritative server's network; see Appendix C.5 for the recommended
3699 algorithm.
3701 Any error that occurs during dialback negotiation MUST be considered
3702 a stream error, resulting in termination of the stream and of the
3703 underlying TCP connection. The possible error conditions are
3704 specified in the protocol description below.
3706 The following terminology applies:
3708 o ORIGINATING SERVER -- the server that is attempting to establish a
3709 connection between two domains.
3710 o RECEIVING SERVER -- the server that is trying to authenticate that
3711 the Originating Server represents the domain which it claims to
3712 be.
3713 o AUTHORITATIVE SERVER -- the server that answers to the DNS
3714 hostname asserted by the Originating Server; for basic
3715 environments this will be the Originating Server, but it could be
3716 a separate machine in the Originating Server's network.
3718 C.2. Order of Events
3720 The following is a brief summary of the order of events in dialback:
3722 1. The Originating Server establishes a connection to the Receiving
3723 Server.
3724 2. The Originating Server sends a 'key' value over the connection to
3725 the Receiving Server.
3726 3. The Receiving Server establishes a connection to the
3727 Authoritative Server.
3728 4. The Receiving Server sends the same 'key' value to the
3729 Authoritative Server.
3730 5. The Authoritative Server replies that key is valid or invalid.
3731 6. The Receiving Server informs the Originating Server whether it is
3732 authenticated or not.
3734 We can represent this flow of events graphically as follows:
3736 Originating Receiving
3737 Server Server
3738 ----------- ---------
3739 | |
3740 | establish connection |
3741 | ----------------------> |
3742 | |
3743 | send stream header |
3744 | ----------------------> |
3745 | |
3746 | send stream header |
3747 | <---------------------- |
3748 | | Authoritative
3749 | send dialback key | Server
3750 | ----------------------> | -------------
3751 | | |
3752 | establish connection |
3753 | ----------------------> |
3754 | |
3755 | send stream header |
3756 | ----------------------> |
3757 | |
3758 | send stream header |
3759 | <---------------------- |
3760 | |
3761 | send verify request |
3762 | ----------------------> |
3763 | |
3764 | send verify response |
3765 | <---------------------- |
3766 |
3767 | report dialback result |
3768 | <---------------------- |
3769 | |
3771 C.3. Protocol
3773 This section describes the detailed protocol interaction between the
3774 Originating Server, the Receiving Server, and the Authoritative
3775 Server.
3777 This section uses the following domain names, IP addresses, stream
3778 IDs, and shared secret in the examples:
3780 o The Originating Server is "example.org" (there is no IP address
3781 associated with this domain since it is merely asserted by the
3782 Originating Server).
3784 o The Receiving Server is "xmpp.example.com" and its IP address is
3785 "192.0.2.0".
3786 o The Authoritative Server is "example.org" and its IP address is
3787 "192.0.2.1".
3788 o The stream ID of the stream from the Originating Server to the
3789 Receiving Server is "D60000229F".
3790 o The shared secret known by the Authoritative Server's network is
3791 "s3cr3tf0rd14lb4ck".
3792 o The stream ID of the stream from the Receiving Server to the
3793 Authoritative Server is "F92200006D".
3795 To assist the reader, the following conventions are used to clarify
3796 the flow of packets:
3798 o "O2R:" -- packets sent from the Originating Server to the
3799 Receiving Server.
3800 o "R2O:" -- packets sent from the Receiving Server to the
3801 Originating Server.
3802 o "R2A:" -- packets sent from the Receiving Server to the
3803 Authoritative Server.
3804 o "A2R:" -- packets sent from the Authoritative Server to the
3805 Receiving Server.
3807 The flow of events is as follows:
3809 1. The Originating Server (asserted to be "example.org") performs a
3810 DNS lookup for the Receiving Server (in accordance with the
3811 procedure described under Section 4) and establishes a TCP
3812 connection to the Receiving Server at the IP address and port
3813 discovered during the DNS lookup (here assumed to be "192.0.2.0"
3814 and "5269").
3815 2. The Originating Server sends a stream header to the Receiving
3816 Server:
3818 O2R:
3825 Note: The inclusion of the xmlns:db namespace declaration with
3826 the name shown indicates to the Receiving Server that the
3827 Originating Server supports server dialback. If any of the
3828 namespace names provided by the Originating Server is incorrect,
3829 then the Receiving Server MUST generate an
3830 stream error condition and terminate both the XML stream and the
3831 underlying TCP connection. If the value of the 'to' address
3832 provided by the Originating Server does not match a hostname
3833 serviced by the Receiving Server, then the Receiving Server MUST
3834 generate a stream error condition and terminate
3835 both the XML stream and the underlying TCP connection.
3836 3. The Receiving Server SHOULD send a stream header back to the
3837 Originating Server over the same TCP connection, including a
3838 unique ID for this interaction:
3840 R2O:
3848 Note: The Receiving Server SHOULD reply but MAY silently
3849 terminate the XML stream and underlying TCP connection depending
3850 on local security policies; however, if the Receiving Server
3851 desires to proceed, it MUST send a stream header back to the
3852 Originating Server. If any of the namespace names provided by
3853 the Receiving Server is incorrect, then the Originating Server
3854 MUST generate an stream error condition and
3855 terminate both the XML stream and the underlying TCP connection.
3856 If the value of the 'to' address provided by the Receiving
3857 Server does not match a hostname serviced by the Originating
3858 Server, then the Originating Server MUST generate a stream error condition and terminate both the XML
3860 stream and the underlying TCP connection.
3861 4. The Receiving Server SHOULD also send stream features to the
3862 Originating Server, including the dialback feature as described
3863 under Appendix C.6:
3865 R2O:
3866
3867
3868
3869
3871 5. The Originating Server MUST then send a dialback key to the
3872 Receiving Server:
3874 O2R:
3877 37c69b1cf07a3f67c04a5ef5902fa5114f2c76fe4a2686482ba5b89323075643
3878
3880 If the value of the 'to' address provided by the Originating
3881 Server does not match a hostname serviced by the Receiving
3882 Server, then the Receiving Server MUST generate a stream error condition and terminate both the XML
3884 stream and the underlying TCP connection. The key generated by
3885 the Originating Server MUST be based in part on the value of the
3886 ID provided by the Receiving Server in the previous step (here
3887 "D60000229F"), and in part on a secret shared by the Originating
3888 Server and the Authoritative Server (here "s3cr3tf0rd14lb4ck").
3889 Any verifiable method MAY be used to generate the key; however,
3890 the method specified under Appendix C.5 is RECOMMENDED. The key
3891 is not examined by the Receiving Server, since the key is
3892 validated by the Authoritative Server.
3893 6. The Receiving Server performs a DNS lookup for the Authoritative
3894 Server (in accordance with the procedure described under
3895 Section 4) and establishes a TCP connection to the Authoritative
3896 Server at the IP address and port discovered during the DNS
3897 lookup (here assumed to be "192.0.2.1" and "5269").
3898 7. The Receiving Server sends a stream header to the Authoritative
3899 Server:
3901 R2A:
3908 Note: If the namespace name is incorrect, then the Authoritative
3909 Server MUST generate an stream error
3910 condition and terminate both the XML stream and the underlying
3911 TCP connection. If the value of the 'to' address provided by
3912 the Receiving Server does not match a hostname serviced by the
3913 Authoritative Server, then the Authoritative Server MUST
3914 generate a stream error condition and terminate
3915 both the XML stream and the underlying TCP connection.
3916 8. The Authoritative Server sends the Receiving Server a stream
3917 header:
3919 A2R:
3927 Note: If any of the namespace names provided by the
3928 Authoritative Server is incorrect, then the Receiving Server
3929 MUST generate an stream error condition and
3930 terminate both the XML stream and the underlying TCP connection
3931 between it and the Authoritative Server. If the value of the
3932 'to' address provided by the Authoritative Server does not match
3933 a hostname serviced by the Receiving Server, then the Receiving
3934 Server MUST generate a stream error condition
3935 and terminate both the XML stream and the underlying TCP
3936 connection. If a stream error occurs between the Receiving
3937 Server and the Authoritative Server, then the Receiving Server
3938 MUST not only terminate the XML stream and the underlying TCP
3939 connection between it and the Authoritative Server but also
3940 terminate the XML stream and the underlying TCP connection
3941 between it and the Originating Server, generating a stream error for the latter stream.
3943 9. The Receiving Server sends the Authoritative Server a request
3944 for verification of a key:
3946 R2A:
3950 37c69b1cf07a3f67c04a5ef5902fa5114f2c76fe4a2686482ba5b89323075643
3951
3953 Note: Passed here are the hostnames of the Receiving Server
3954 ('from') and the Originating Server ('to'), the original
3955 identifier from the Receiving Server's stream header to the
3956 Originating Server in Step 3, and the key that the Originating
3957 Server sent to the Receiving Server in Step 5. Based on this
3958 information, as well as shared secret information within the
3959 Authoritative Server's network, the Authoritative Server
3960 determines whether the key is valid or invalid. If the value of
3961 the 'to' address does not match a hostname serviced by the
3962 Authoritative Server, then the Authoritative Server MUST
3963 generate a stream error condition and terminate
3964 both the XML stream and the underlying TCP connection. If the
3965 value of the 'from' address does not match the hostname sent by
3966 the Receiving Server in the 'from' address of the stream header
3967 it sent to the Authoritative Server in Step 7, then the
3968 Authoritative Server MUST generate an stream
3969 error condition and terminate both the XML stream and the
3970 underlying TCP connection.
3971 10. The Authoritative Server determines whether the key was valid or
3972 invalid and informs the Receiving Server of its determination:
3974 A2R:
3980 or
3982 A2R:
3988 Note: If the ID does not match that provided by the Receiving
3989 Server in Step 3, then the Receiving Server MUST generate an
3990 stream error condition and terminate both the XML
3991 stream and the underlying TCP connection. If the value of the
3992 'to' address does not match a hostname serviced by the Receiving
3993 Server, then the Receiving Server MUST generate a stream error condition and terminate both the XML
3995 stream and the underlying TCP connection. If the value of the
3996 'from' address does not match the hostname represented by the
3997 Originating Server in the 'from' address of the stream header it
3998 sent to the Receiving Server in Step 2, then the Receiving
3999 Server MUST generate an stream error condition
4000 and terminate both the XML stream and the underlying TCP
4001 connection. After returning the verification to the Receiving
4002 Server, the Authoritative Server SHOULD terminate the stream
4003 between them and the underlying TCP connection.
4004 11. The Receiving Server informs the Originating Server of the
4005 result:
4007 R2O:
4013 Note: At this point, the connection from the Originating Server
4014 to the Receiving Server has either been validated or reported as
4015 invalid. If the connection is invalid, then the Receiving
4016 Server MUST terminate both the XML stream and the underlying TCP
4017 connection between itself and the Originating Server. If the
4018 connection is valid, the Receiving Server has verified the
4019 identity of the Originating Server; as a result, the Originating
4020 Server may now send XML stanzas to the Receiving Server over the
4021 validated connection (i.e., over the "initial stream" from the
4022 Originating Server to the Receiving Server).
4024 Until the initial stream has been validated, the Receiving Server
4025 MUST silently drop all XML stanzas sent by the Originating Server to
4026 the Receiving Server.
4028 After successful dialback negotiation, the Receiving Server MUST
4029 verify that all XML stanzas received from the Originating Server
4030 include a 'from' attribute and a 'to' attribute; if a stanza does not
4031 meet this restriction, the Receiving Server MUST generate an
4032 stream error condition and terminate both the
4033 XML stream and the underlying TCP connection. Furthermore, the
4034 Receiving Server MUST verify that the 'from' attribute of stanzas
4035 received from the Originating Server includes a domain name that has
4036 been validated for the stream; if a stanza does not meet this
4037 restriction, the Receiving Server MUST generate an
4038 stream error condition and terminate both the XML stream and the
4039 underlying TCP connection. Both of these checks help to prevent
4040 spoofing related to particular stanzas.
4042 As mentioned, server dialback results in weak identity verification
4043 in one direction only (in the foregoing text, verification of the
4044 Originating Server by the Receiving Server). In order to proceed
4045 with bi-directional communication so that the Receiving Server may
4046 sent XML stanzas to the Originating Server, the Receiving Server MUST
4047 now also initiate a dialback negotiation with the Originating Server.
4049 C.4. Reuse of Negotiated Connections
4051 After the Receiving Server has validated the connection from the
4052 Originating Server, the Originating Server may wish to reuse that
4053 connection for validation of additional domains. One common
4054 motivation for such reuse is the existence of additional services
4055 associated with the Originating Server but hosted at subdomains of
4056 the Originating Server (the use of subdomains helps to ensure proper
4057 routing of XML stanzas to the hosted services). For example, the
4058 "example.org" XMPP server may host a groupchat service at
4059 "chat.example.org". In order to accept XML stanzas from rooms at
4060 "chat.example.org" intended for addresses at "xmpp.example.com", the
4061 "xmpp.example.com" will need to validate the "chat.example.org"
4062 domain (just as it already did for the "example.org" domain). Thus
4063 the "example.org" server would now initiate a dialback negotiation
4064 with "xmpp.example.com" but specify the Originating Server as
4065 "chat.example.org". Several optimizations are possible:
4067 o Because the "example.org" server already has a validated
4068 connection open to the Receiving Server ("xmpp.example.com"), it
4069 MAY send a element with the key to be validated for
4070 the new Originating Server ("chat.example.org") over the XML
4071 stream that has already been negotiated, rather than opening a new
4072 TCP connection and XML stream. The Receiving Server SHOULD accept
4073 this element rather than returning an error to the Originating
4074 Server over the previously negotiated connection.
4075 o If the Receiving Server ("xmpp.example.com") has also negotiated a
4076 valid connection in the other direction (from the Receiving Server
4077 to the Originating Server), then that connection is ipso facto a
4078 connection to the Authoritative Server for the first negotiation.
4079 Therefore the receiving server can re-use that connection for
4080 exchange of the elements associated with the second
4081 negotiation. The Authoritative Server SHOULD accept this element
4082 rather than returning an error to the Receiving Server over the
4083 previously negotiated connection.
4085 These optimizations effectively enable "piggybacking" of the
4086 previously negotiated connections.
4088 C.5. Dialback Key Generation
4090 As mentioned, the dialback key is generated based on four different
4091 pieces of information:
4093 o the hostname of the Originating Server
4094 o the hostname of the Receiving Server
4095 o the Stream ID
4096 o a shared secret known by the Authoritative Server's network
4098 The stream ID is security-critical in server dialback and therefore
4099 MUST be both unpredictable and non-repeating (see [RANDOM] for
4100 recommendations regarding randomness for security purposes).
4102 It is RECOMMENDED for the dialback key to be the hexadecimal
4103 representation of a Keyed-Hash Message Authentication Code (see
4104 [HMAC]) that uses the SHA-256 algorithm (see [SHA]), as follows:
4106 HMAC-SHA256
4107 (
4108 SHA256(secret),
4109 {'Receiving Server' 'Originating Server' 'Stream ID'}
4110 )
4111 The shared secret SHOULD either be set up in a configuration option
4112 for each host or process within the Authoritative Server's network or
4113 generated as a random string when starting each host or process. The
4114 secret's length SHOULD be at least 128 bits or 16 characters long.
4116 Consider the following scenario:
4118 o The Originating Server is "example.org"
4119 o The Receiving Server is "xmpp.example.com"
4120 o The Stream ID is "D60000229F"
4121 o The secret is "s3cr3tf0rd14lb4ck"
4123 The resulting dialback key would be:
4125 HMAC-SHA256
4126 (
4127 SHA256(secret),
4128 {'Receiving Server' 'Originating Server' 'Stream ID'}
4129 )
4131 that is,
4133 HMAC-SHA256
4134 (SHA256('s3cr3tf0rd14lb4ck'),
4135 {'xmpp.example.net',' ','example.org',' ','D60000229F'})
4137 that is,
4139 HMAC-SHA256
4140 ('a7136eb1f46c9ef18c5e78c36ca257067c69b3d518285f0b18a96c33beae9acc',
4141 {'xmpp.example.com example.org D60000229F'})
4143 that is,
4145 37c69b1cf07a3f67c04a5ef5902fa5114f2c76fe4a2686482ba5b89323075643
4147 C.6. Advertisement
4149 Support for the server dialback protocol can be indicated in two
4150 ways:
4152 1. By inclusion of the server dialback feature in a given set of
4153 stream features.
4154 2. By inclusion of the dialback namespace declaration in the stream
4155 header.
4157 The former method is preferred, but the latter method is also
4158 specified herein for the purpose of backwards-compatibility with
4159 older "XMPP 0.9" deployments.
4161 The server dialback stream feature is advertised by including in any
4162 given set of stream features a element qualified by the
4163 'urn:xmpp:features:dialback' namespace; the element MAY
4164 also include an empty element, indicating that the entity
4165 sending the stream features requires dialback to be negotiated for
4166 the stream.
4168 Server2 informs Server1 that it supports (and requires) server
4169 dialback:
4171
4172
4173
4174
4175
4177 As mentioned, support for the server dialback protocol can also be
4178 advertised by including the dialback namespace declaration in a
4179 stream header.
4181
4188 No matter which method is used, a service SHOULD advertise support
4189 for server dialback only at a point in the stream negotiation when it
4190 will accept negotiation of server dialback for that stream. For
4191 example, if a service wishes to be backwards-compatible with older
4192 "XMPP 0.9" deployments, it SHOULD include the server dialback
4193 namespace declaration in the initial stream header it sends to other
4194 servers (so that "XMPP 0.9" servers can proceed with dialback in the
4195 absence of TLS and SASL authentication). However, in the midst of
4196 stream negotiation with an XMPP 1.0 or higher server, a service
4197 SHOULD advertise the dialback stream feature only at a point when
4198 negotiation of server dialback is allowed in accordance with local
4199 service policies (e.g., after TLS negotiation in the case when a
4200 self-signed certificate was presented by the Originating Server and
4201 local service policies stipulate that it is preferable to weakly
4202 identify the Originating Server via server dialback rather than
4203 depend on the self-signed certificate for identity verification).
4205 Appendix D. XML Schemas
4207 The following XML schemas are descriptive, not normative. For
4208 schemas defining the 'jabber:client' and 'jabber:server' namespaces,
4209 refer to [XMPP-IM].
4211 D.1. Streams namespace
4213
4215
4221
4222
4223
4225
4226
4227
4230
4231
4234
4237
4238
4239
4240
4241
4242
4243
4244
4245
4246
4247
4248
4249
4250
4251
4252
4253
4254
4255
4256
4257
4258
4259
4261
4262
4263
4264
4265
4267
4268
4269
4270
4271
4274
4275
4276
4278
4280 D.2. Stream error namespace
4282
4284
4290
4291
4292
4293
4294
4295
4296
4297
4298
4299
4300
4301
4302
4303
4304
4305
4306
4307
4308
4309
4310
4311
4312
4313
4315
4316
4317
4318
4319
4320
4321
4322
4323
4324
4325
4326
4327
4328
4329
4330
4331
4332
4333
4334
4335
4336
4337
4338
4339
4340
4341
4342
4344
4345
4346
4347
4348
4350
4351
4352
4353
4355
4356
4357
4358
4359
4361
4363 D.3. TLS namespace
4365
4367
4373
4374
4375
4376
4379
4380
4381
4383
4384
4386
4387
4388
4389
4390
4392
4394 D.4. SASL namespace
4396
4397
4403
4404
4405
4406
4409
4412
4413
4414
4416
4417
4418
4419
4420
4423
4424
4425
4426
4428
4429
4430
4431
4433
4434
4435
4436
4437
4438
4439
4440
4441
4442
4443
4444
4446
4447
4449
4450
4451
4452
4453
4455
4457 D.5. Resource binding namespace
4458
4460
4466
4467
4468
4469
4470
4471
4472
4473
4477
4478
4479
4480
4482
4483
4484
4485
4486
4487
4488
4490
4491
4492
4493
4494
4495
4497
4498
4499
4500
4501
4502
4504
4506 D.6. Dialback namespace
4507
4509
4515
4516
4517
4518
4519
4520
4521
4522
4523
4524
4525
4526
4527
4528
4529
4530
4531
4532
4534
4535
4536
4537
4538
4539
4540
4541
4542
4543
4544
4545
4546
4547
4548
4549
4550
4551
4552
4554
4556 D.7. Server dialback stream feature namespace
4558
4560
4566
4567
4568
4569
4573
4574
4576
4577
4578
4579
4580
4582
4584 D.8. Stanza error namespace
4586
4588
4594
4595
4596
4597
4598
4599
4600
4601
4602
4603
4604
4605
4606
4607
4608
4609
4610
4611
4612
4613
4614
4615
4617
4618
4619
4620
4621
4622
4623
4624
4625
4626
4627
4628
4629
4630
4631
4632
4633
4634
4635
4636
4637
4638
4639
4640
4641
4642
4644
4645
4646
4647
4648
4649
4650
4651
4653
4655
4656
4657
4658
4659
4661
4663 Appendix E. Contact Addresses
4665 Consistent with [MAILBOXES], an organization that offers an XMPP
4666 service SHOULD provide an Internet mailbox of "XMPP" for inquiries
4667 related to that service, where the host portion of the resulting
4668 mailto URI SHOULD be the organization's domain, not necessarily the
4669 domain of the XMPP service itself (e.g., the XMPP service might be
4670 offered at im.example.net but the Internet mailbox should be
4671 ).
4673 In addition, the XMPP service SHOULD provide a way to discover the
4674 XMPP contact address(es) of the service administrator(s), as
4675 specified in [XEP-0157].
4677 Appendix F. Differences From RFC 3920
4679 Based on consensus derived from implementation and deployment
4680 experience as well as formal interoperability testing, the following
4681 modifications were made from RFC 3920. In addition, several other
4682 changes were made to more clearly specify and explain the protocols.
4684 o Corrected the ABNF syntax for JIDs to prevent zero-length node
4685 identifiers, domain identifiers, and resource identifiers.
4686 o Corrected the nameprep processing rules to require use of the
4687 UseSTD3ASCIIRules flag.
4688 o Encouraged use of the 'from' and 'to' attributes stream headers.
4689 o More clearly specified stream closing handshake.
4690 o Specified recommended stream reconnection algorithm.
4691 o Specified return of stream error in response to
4692 receipt of restricted XML.
4693 o Specified that SASL mechanisms must be sent both before and after
4694 negotiation of TLS and of SASL security layers.
4695 o Specified that TLS plus SASL PLAIN is a mandatory-to-implement
4696 technology for client-to-server connections, since implementation
4697 of SASL EXTERNAL is uncommon in XMPP clients, in part because
4698 underlying security features such as X.509 certificates are not
4699 yet widely deployed.
4700 o Added the SASL error condition to handle an
4701 error case discussed in RFC 4422.
4702 o More clearly specified binding of multiple resources to the same
4703 stream.
4704 o Added the stanza error condition to enable
4705 potential ETags usage.
4706 o Added the stanza error condition to provide
4707 appropriate handling of stanzas when multiple resources are bound
4708 to the same stream.
4709 o Added section on advertisement of server dialback support,
4710 including server dialback stream feature.
4711 o Recommended use of HMAC-SHA256 for generation of server dialback
4712 key.
4714 Author's Address
4716 Peter Saint-Andre (editor)
4717 XMPP Standards Foundation
4719 Email: stpeter@jabber.org
4720 URI: xmpp:stpeter@jabber.org
4722 Full Copyright Statement
4724 Copyright (C) The IETF Trust (2007).
4726 This document is subject to the rights, licenses and restrictions
4727 contained in BCP 78, and except as set forth therein, the authors
4728 retain all their rights.
4730 This document and the information contained herein are provided on an
4731 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
4732 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
4733 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
4734 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
4735 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
4736 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
4738 Intellectual Property
4740 The IETF takes no position regarding the validity or scope of any
4741 Intellectual Property Rights or other rights that might be claimed to
4742 pertain to the implementation or use of the technology described in
4743 this document or the extent to which any license under such rights
4744 might or might not be available; nor does it represent that it has
4745 made any independent effort to identify any such rights. Information
4746 on the procedures with respect to rights in RFC documents can be
4747 found in BCP 78 and BCP 79.
4749 Copies of IPR disclosures made to the IETF Secretariat and any
4750 assurances of licenses to be made available, or the result of an
4751 attempt made to obtain a general license or permission for the use of
4752 such proprietary rights by implementers or users of this
4753 specification can be obtained from the IETF on-line IPR repository at
4754 http://www.ietf.org/ipr.
4756 The IETF invites any interested party to bring to its attention any
4757 copyrights, patents or patent applications, or other proprietary
4758 rights that may cover technology that may be required to implement
4759 this standard. Please address the information to the IETF at
4760 ietf-ipr@ietf.org.
4762 Acknowledgment
4764 Funding for the RFC Editor function is provided by the IETF
4765 Administrative Support Activity (IASA).