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