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