idnits 2.17.00 (12 Aug 2021) /tmp/idnits25535/draft-ietf-xmpp-3920bis-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 7107 has weird spacing: '...equence xmlns...' == Line 7108 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). -- The document date (September 11, 2009) is 4634 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '3' on line 498 -- Looks like a reference, but probably isn't: '1' on line 1137 -- Looks like a reference, but probably isn't: '23' on line 5606 ** Obsolete normative reference: RFC 3490 (ref. 'IDNA') (Obsoleted by RFC 5890, RFC 5891) ** Obsolete normative reference: RFC 4646 (ref. 'LANGTAGS') (Obsoleted by RFC 5646) ** Obsolete normative reference: RFC 3491 (ref. 'NAMEPREP') (Obsoleted by RFC 5891) ** Obsolete normative reference: RFC 3454 (ref. 'STRINGPREP') (Obsoleted by RFC 7564) ** Obsolete normative reference: RFC 5246 (ref. 'TLS') (Obsoleted by RFC 8446) -- Possible downref: Non-RFC (?) normative reference: ref. 'UCS2' -- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE' -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' -- Possible downref: Non-RFC (?) normative reference: ref. 'XML-NAMES' -- Obsolete informational reference (is this intentional?): RFC 2831 (ref. 'DIGEST-MD5') (Obsoleted by RFC 6331) -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. 'HTTP') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 3920 (Obsoleted by RFC 6120) -- Obsolete informational reference (is this intentional?): RFC 3921 (Obsoleted by RFC 6121) == Outdated reference: draft-ietf-xmpp-3921bis has been published as RFC 6121 Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Saint-Andre 3 Internet-Draft Cisco 4 Obsoletes: 3920 (if approved) September 11, 2009 5 Intended status: Standards Track 6 Expires: March 15, 2010 8 Extensible Messaging and Presence Protocol (XMPP): Core 9 draft-ietf-xmpp-3920bis-02 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and 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 March 15, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document defines the core features of the Extensible Messaging 48 and Presence Protocol (XMPP), a technology for streaming Extensible 49 Markup Language (XML) elements for the purpose of exchanging 50 structured information in close to real time between any two or more 51 network-aware entities. XMPP provides a generalized, extensible 52 framework for incrementally exchanging XML data, upon which a variety 53 of applications can be built. The framework includes methods for 54 stream setup and teardown, channel encryption, authentication of a 55 client to a server and of one server to another server, and 56 primitives for push-style messages, publication of network 57 availability information ("presence"), and request-response 58 interactions. This document also specifies the format for XMPP 59 addresses, which are fully internationalizable. 61 This document obsoletes RFC 3920. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 9 66 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 9 67 1.2. Functional Summary . . . . . . . . . . . . . . . . . . . 10 68 1.3. Conventions . . . . . . . . . . . . . . . . . . . . . . 11 69 1.4. Acknowledgements . . . . . . . . . . . . . . . . . . . . 12 70 1.5. Discussion Venue . . . . . . . . . . . . . . . . . . . . 12 71 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 12 72 2.1. Global Addresses . . . . . . . . . . . . . . . . . . . . 13 73 2.2. Presence . . . . . . . . . . . . . . . . . . . . . . . . 13 74 2.3. Persistent Streams . . . . . . . . . . . . . . . . . . . 13 75 2.4. Structured Data . . . . . . . . . . . . . . . . . . . . 13 76 2.5. Distributed Network . . . . . . . . . . . . . . . . . . 14 77 3. Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 15 79 3.2. Domain Identifier . . . . . . . . . . . . . . . . . . . 16 80 3.3. Localpart . . . . . . . . . . . . . . . . . . . . . . . 18 81 3.4. Resource Identifier . . . . . . . . . . . . . . . . . . 18 82 3.5. Determination of Addresses . . . . . . . . . . . . . . . 19 83 4. TCP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 20 84 4.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . 20 85 4.2. Hostname Resolution . . . . . . . . . . . . . . . . . . 20 86 4.3. Client-to-Server Communication . . . . . . . . . . . . . 21 87 4.4. Server-to-Server Communication . . . . . . . . . . . . . 22 88 4.5. Reconnection . . . . . . . . . . . . . . . . . . . . . . 22 89 4.6. Reliability . . . . . . . . . . . . . . . . . . . . . . 22 90 4.7. Other Bindings . . . . . . . . . . . . . . . . . . . . . 23 91 5. XML Streams . . . . . . . . . . . . . . . . . . . . . . . . . 23 92 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 23 93 5.2. Stream Security . . . . . . . . . . . . . . . . . . . . 25 94 5.3. Stream Attributes . . . . . . . . . . . . . . . . . . . 26 95 5.3.1. from . . . . . . . . . . . . . . . . . . . . . . . . 26 96 5.3.2. to . . . . . . . . . . . . . . . . . . . . . . . . . 28 97 5.3.3. id . . . . . . . . . . . . . . . . . . . . . . . . . 29 98 5.3.4. xml:lang . . . . . . . . . . . . . . . . . . . . . . 29 99 5.3.5. version . . . . . . . . . . . . . . . . . . . . . . 31 100 5.3.6. Summary of Stream Attributes . . . . . . . . . . . . 32 101 5.4. Namespace Declarations . . . . . . . . . . . . . . . . . 32 102 5.5. Stream Features . . . . . . . . . . . . . . . . . . . . 33 103 5.6. Restarts During Stream Negotiation . . . . . . . . . . . 35 104 5.7. Closing a Stream . . . . . . . . . . . . . . . . . . . . 35 105 5.7.1. With Stream Error . . . . . . . . . . . . . . . . . 35 106 5.7.2. Without Stream Error . . . . . . . . . . . . . . . . 36 107 5.7.3. Handling of Idle Streams . . . . . . . . . . . . . . 36 108 5.8. Stream Errors . . . . . . . . . . . . . . . . . . . . . 37 109 5.8.1. Rules . . . . . . . . . . . . . . . . . . . . . . . 37 110 5.8.1.1. Stream Errors Are Unrecoverable . . . . . . . . . 37 111 5.8.1.2. Stream Errors Can Occur During Setup . . . . . . 38 112 5.8.1.3. Stream Errors When the Host is Unspecified or 113 Unknown . . . . . . . . . . . . . . . . . . . . . 38 114 5.8.1.4. Where Stream Errors Are Sent . . . . . . . . . . 39 115 5.8.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . 39 116 5.8.3. Defined Stream Error Conditions . . . . . . . . . . 40 117 5.8.3.1. bad-format . . . . . . . . . . . . . . . . . . . 40 118 5.8.3.2. bad-namespace-prefix . . . . . . . . . . . . . . 41 119 5.8.3.3. conflict . . . . . . . . . . . . . . . . . . . . 42 120 5.8.3.4. connection-timeout . . . . . . . . . . . . . . . 42 121 5.8.3.5. host-gone . . . . . . . . . . . . . . . . . . . . 43 122 5.8.3.6. host-unknown . . . . . . . . . . . . . . . . . . 43 123 5.8.3.7. improper-addressing . . . . . . . . . . . . . . . 44 124 5.8.3.8. internal-server-error . . . . . . . . . . . . . . 44 125 5.8.3.9. invalid-from . . . . . . . . . . . . . . . . . . 45 126 5.8.3.10. invalid-id . . . . . . . . . . . . . . . . . . . 45 127 5.8.3.11. invalid-namespace . . . . . . . . . . . . . . . . 46 128 5.8.3.12. invalid-xml . . . . . . . . . . . . . . . . . . . 46 129 5.8.3.13. not-authorized . . . . . . . . . . . . . . . . . 47 130 5.8.3.14. policy-violation . . . . . . . . . . . . . . . . 48 131 5.8.3.15. remote-connection-failed . . . . . . . . . . . . 49 132 5.8.3.16. resource-constraint . . . . . . . . . . . . . . . 49 133 5.8.3.17. restricted-xml . . . . . . . . . . . . . . . . . 50 134 5.8.3.18. see-other-host . . . . . . . . . . . . . . . . . 50 135 5.8.3.19. system-shutdown . . . . . . . . . . . . . . . . . 51 136 5.8.3.20. undefined-condition . . . . . . . . . . . . . . . 52 137 5.8.3.21. unsupported-encoding . . . . . . . . . . . . . . 52 138 5.8.3.22. unsupported-stanza-type . . . . . . . . . . . . . 53 139 5.8.3.23. unsupported-version . . . . . . . . . . . . . . . 53 140 5.8.3.24. xml-not-well-formed . . . . . . . . . . . . . . . 54 141 5.8.4. Application-Specific Conditions . . . . . . . . . . 55 142 5.9. Simplified Stream Examples . . . . . . . . . . . . . . . 55 143 6. STARTTLS Negotiation . . . . . . . . . . . . . . . . . . . . 57 144 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 58 145 6.2. Rules . . . . . . . . . . . . . . . . . . . . . . . . . 58 146 6.2.1. Data Formatting . . . . . . . . . . . . . . . . . . 58 147 6.2.2. Order of Negotiation . . . . . . . . . . . . . . . . 58 148 6.3. Process . . . . . . . . . . . . . . . . . . . . . . . . 59 149 6.3.1. Exchange of Stream Headers and Stream Features . . . 59 150 6.3.2. Initiation of STARTTLS Negotiation . . . . . . . . . 60 151 6.3.2.1. STARTTLS Command . . . . . . . . . . . . . . . . 60 152 6.3.2.2. Failure Case . . . . . . . . . . . . . . . . . . 60 153 6.3.2.3. Proceed Case . . . . . . . . . . . . . . . . . . 61 154 6.3.3. TLS Negotiation . . . . . . . . . . . . . . . . . . 61 155 6.3.3.1. Rules . . . . . . . . . . . . . . . . . . . . . . 61 156 6.3.3.2. TLS Failure . . . . . . . . . . . . . . . . . . . 62 157 6.3.3.3. TLS Success . . . . . . . . . . . . . . . . . . . 62 158 7. SASL Negotiation . . . . . . . . . . . . . . . . . . . . . . 63 159 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 63 160 7.2. Rules . . . . . . . . . . . . . . . . . . . . . . . . . 63 161 7.2.1. Mechanism Preferences . . . . . . . . . . . . . . . 63 162 7.2.2. Mechanism Offers . . . . . . . . . . . . . . . . . . 64 163 7.2.3. Data Formatting . . . . . . . . . . . . . . . . . . 64 164 7.2.4. Security Layers . . . . . . . . . . . . . . . . . . 65 165 7.2.5. Simple Usernames . . . . . . . . . . . . . . . . . . 65 166 7.2.6. Authorization Identities . . . . . . . . . . . . . . 65 167 7.2.7. Realms . . . . . . . . . . . . . . . . . . . . . . . 66 168 7.2.8. Round Trips . . . . . . . . . . . . . . . . . . . . 66 169 7.3. Process . . . . . . . . . . . . . . . . . . . . . . . . 66 170 7.3.1. Exchange of Stream Headers and Stream Features . . . 66 171 7.3.2. Initiation . . . . . . . . . . . . . . . . . . . . . 68 172 7.3.3. Challenge-Response Sequence . . . . . . . . . . . . 68 173 7.3.4. Abort . . . . . . . . . . . . . . . . . . . . . . . 69 174 7.3.5. Failure . . . . . . . . . . . . . . . . . . . . . . 69 175 7.3.6. Success . . . . . . . . . . . . . . . . . . . . . . 70 176 7.4. SASL Errors . . . . . . . . . . . . . . . . . . . . . . 71 177 7.4.1. aborted . . . . . . . . . . . . . . . . . . . . . . 72 178 7.4.2. account-disabled . . . . . . . . . . . . . . . . . . 72 179 7.4.3. credentials-expired . . . . . . . . . . . . . . . . 72 180 7.4.4. encryption-required . . . . . . . . . . . . . . . . 72 181 7.4.5. incorrect-encoding . . . . . . . . . . . . . . . . . 73 182 7.4.6. invalid-authzid . . . . . . . . . . . . . . . . . . 73 183 7.4.7. invalid-mechanism . . . . . . . . . . . . . . . . . 73 184 7.4.8. malformed-request . . . . . . . . . . . . . . . . . 74 185 7.4.9. mechanism-too-weak . . . . . . . . . . . . . . . . . 74 186 7.4.10. not-authorized . . . . . . . . . . . . . . . . . . . 74 187 7.4.11. temporary-auth-failure . . . . . . . . . . . . . . . 75 188 7.4.12. transition-needed . . . . . . . . . . . . . . . . . 75 189 7.5. SASL Definition . . . . . . . . . . . . . . . . . . . . 75 190 8. Resource Binding . . . . . . . . . . . . . . . . . . . . . . 76 191 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 76 192 8.2. Advertising Support . . . . . . . . . . . . . . . . . . 77 193 8.3. Generation of Resource Identifiers . . . . . . . . . . . 78 194 8.4. Server-Generated Resource Identifier . . . . . . . . . . 78 195 8.4.1. Success Case . . . . . . . . . . . . . . . . . . . . 78 196 8.4.2. Error Cases . . . . . . . . . . . . . . . . . . . . 79 197 8.4.2.1. Resource Constraint . . . . . . . . . . . . . . . 79 198 8.4.2.2. Not Allowed . . . . . . . . . . . . . . . . . . . 79 199 8.5. Client-Submitted Resource Identifier . . . . . . . . . . 79 200 8.5.1. Success Case . . . . . . . . . . . . . . . . . . . . 79 201 8.5.2. Error Cases . . . . . . . . . . . . . . . . . . . . 80 202 8.5.2.1. Bad Request . . . . . . . . . . . . . . . . . . . 80 203 8.5.2.2. Conflict . . . . . . . . . . . . . . . . . . . . 80 204 8.5.3. Retries . . . . . . . . . . . . . . . . . . . . . . 81 205 9. XML Stanzas . . . . . . . . . . . . . . . . . . . . . . . . . 82 206 9.1. Common Attributes . . . . . . . . . . . . . . . . . . . 82 207 9.1.1. to . . . . . . . . . . . . . . . . . . . . . . . . . 82 208 9.1.1.1. Client-to-Server Streams . . . . . . . . . . . . 82 209 9.1.1.2. Server-to-Server Streams . . . . . . . . . . . . 83 210 9.1.2. from . . . . . . . . . . . . . . . . . . . . . . . . 83 211 9.1.2.1. Client-to-Server Streams . . . . . . . . . . . . 83 212 9.1.2.2. Server-to-Server Streams . . . . . . . . . . . . 84 213 9.1.3. id . . . . . . . . . . . . . . . . . . . . . . . . . 84 214 9.1.4. type . . . . . . . . . . . . . . . . . . . . . . . . 85 215 9.1.5. xml:lang . . . . . . . . . . . . . . . . . . . . . . 85 216 9.2. Basic Semantics . . . . . . . . . . . . . . . . . . . . 86 217 9.2.1. Message Semantics . . . . . . . . . . . . . . . . . 86 218 9.2.2. Presence Semantics . . . . . . . . . . . . . . . . . 86 219 9.2.3. IQ Semantics . . . . . . . . . . . . . . . . . . . . 87 220 9.3. Stanza Errors . . . . . . . . . . . . . . . . . . . . . 88 221 9.3.1. Rules . . . . . . . . . . . . . . . . . . . . . . . 89 222 9.3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . 89 223 9.3.3. Defined Conditions . . . . . . . . . . . . . . . . . 90 224 9.3.3.1. bad-request . . . . . . . . . . . . . . . . . . . 90 225 9.3.3.2. conflict . . . . . . . . . . . . . . . . . . . . 91 226 9.3.3.3. feature-not-implemented . . . . . . . . . . . . . 91 227 9.3.3.4. forbidden . . . . . . . . . . . . . . . . . . . . 92 228 9.3.3.5. gone . . . . . . . . . . . . . . . . . . . . . . 92 229 9.3.3.6. internal-server-error . . . . . . . . . . . . . . 93 230 9.3.3.7. item-not-found . . . . . . . . . . . . . . . . . 93 231 9.3.3.8. jid-malformed . . . . . . . . . . . . . . . . . . 94 232 9.3.3.9. not-acceptable . . . . . . . . . . . . . . . . . 94 233 9.3.3.10. not-allowed . . . . . . . . . . . . . . . . . . . 95 234 9.3.3.11. not-authorized . . . . . . . . . . . . . . . . . 95 235 9.3.3.12. not-modified . . . . . . . . . . . . . . . . . . 96 236 9.3.3.13. payment-required . . . . . . . . . . . . . . . . 97 237 9.3.3.14. policy-violation . . . . . . . . . . . . . . . . 97 238 9.3.3.15. recipient-unavailable . . . . . . . . . . . . . . 98 239 9.3.3.16. redirect . . . . . . . . . . . . . . . . . . . . 98 240 9.3.3.17. registration-required . . . . . . . . . . . . . . 99 241 9.3.3.18. remote-server-not-found . . . . . . . . . . . . . 99 242 9.3.3.19. remote-server-timeout . . . . . . . . . . . . . . 100 243 9.3.3.20. resource-constraint . . . . . . . . . . . . . . . 100 244 9.3.3.21. service-unavailable . . . . . . . . . . . . . . . 101 245 9.3.3.22. subscription-required . . . . . . . . . . . . . . 101 246 9.3.3.23. undefined-condition . . . . . . . . . . . . . . . 102 247 9.3.3.24. unexpected-request . . . . . . . . . . . . . . . 103 248 9.3.4. Application-Specific Conditions . . . . . . . . . . 104 249 9.4. Extended Content . . . . . . . . . . . . . . . . . . . . 105 250 9.5. Stanza Size . . . . . . . . . . . . . . . . . . . . . . 106 251 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 107 252 10.1. Client-to-Server . . . . . . . . . . . . . . . . . . . . 107 253 10.1.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . 107 254 10.1.2. SASL . . . . . . . . . . . . . . . . . . . . . . . . 109 255 10.1.3. Resource Binding . . . . . . . . . . . . . . . . . . 110 256 10.1.4. Stanza Exchange . . . . . . . . . . . . . . . . . . 110 257 10.1.5. Close . . . . . . . . . . . . . . . . . . . . . . . 111 258 10.2. Server-to-Server Examples . . . . . . . . . . . . . . . 111 259 10.2.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . 112 260 10.2.2. SASL . . . . . . . . . . . . . . . . . . . . . . . . 113 261 10.2.3. Stanza Exchange . . . . . . . . . . . . . . . . . . 114 262 10.2.4. Close . . . . . . . . . . . . . . . . . . . . . . . 115 263 11. Server Rules for Processing XML Stanzas . . . . . . . . . . . 115 264 11.1. No 'to' Address . . . . . . . . . . . . . . . . . . . . 116 265 11.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 116 266 11.1.2. Message . . . . . . . . . . . . . . . . . . . . . . 116 267 11.1.3. Presence . . . . . . . . . . . . . . . . . . . . . . 116 268 11.1.4. IQ . . . . . . . . . . . . . . . . . . . . . . . . . 116 269 11.2. Local Domain . . . . . . . . . . . . . . . . . . . . . . 117 270 11.2.1. Mere Domain . . . . . . . . . . . . . . . . . . . . 117 271 11.2.2. Domain with Resource . . . . . . . . . . . . . . . . 117 272 11.2.3. Localpart at Domain . . . . . . . . . . . . . . . . 117 273 11.2.3.1. No Such User . . . . . . . . . . . . . . . . . . 117 274 11.2.3.2. Bare JID . . . . . . . . . . . . . . . . . . . . 118 275 11.2.3.3. Full JID . . . . . . . . . . . . . . . . . . . . 118 276 11.3. Remote Domain . . . . . . . . . . . . . . . . . . . . . 118 277 11.3.1. Existing Stream . . . . . . . . . . . . . . . . . . 118 278 11.3.2. No Existing Stream . . . . . . . . . . . . . . . . . 119 279 11.3.3. Error Handling . . . . . . . . . . . . . . . . . . . 119 280 12. XML Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 119 281 12.1. Restrictions . . . . . . . . . . . . . . . . . . . . . . 119 282 12.2. XML Namespace Names and Prefixes . . . . . . . . . . . . 120 283 12.2.1. Streams Namespace . . . . . . . . . . . . . . . . . 120 284 12.2.2. Default Namespace . . . . . . . . . . . . . . . . . 121 285 12.2.3. Extended Namespaces . . . . . . . . . . . . . . . . 122 286 12.3. Well-Formedness . . . . . . . . . . . . . . . . . . . . 123 287 12.4. Validation . . . . . . . . . . . . . . . . . . . . . . . 123 288 12.5. Inclusion of XML Declaration . . . . . . . . . . . . . . 124 289 12.6. Character Encoding . . . . . . . . . . . . . . . . . . . 124 290 12.7. Whitespace . . . . . . . . . . . . . . . . . . . . . . . 124 291 12.8. XML Versions . . . . . . . . . . . . . . . . . . . . . . 124 292 13. Compliance Requirements . . . . . . . . . . . . . . . . . . . 124 293 13.1. Servers . . . . . . . . . . . . . . . . . . . . . . . . 125 294 13.2. Clients . . . . . . . . . . . . . . . . . . . . . . . . 125 295 14. Internationalization Considerations . . . . . . . . . . . . . 126 296 15. Security Considerations . . . . . . . . . . . . . . . . . . . 126 297 15.1. High Security . . . . . . . . . . . . . . . . . . . . . 126 298 15.2. Certificates . . . . . . . . . . . . . . . . . . . . . . 127 299 15.2.1. Certificate Generation . . . . . . . . . . . . . . . 127 300 15.2.1.1. Server Certificates . . . . . . . . . . . . . . . 127 301 15.2.1.2. Client Certificates . . . . . . . . . . . . . . . 129 302 15.2.1.3. ASN.1 Object Identifier . . . . . . . . . . . . . 129 303 15.2.2. Certificate Validation . . . . . . . . . . . . . . . 130 304 15.2.2.1. Server Certificates . . . . . . . . . . . . . . . 130 305 15.2.2.2. Client Certificates . . . . . . . . . . . . . . . 132 306 15.2.2.3. Use of Certificates in XMPP Extensions . . . . . 133 307 15.3. Client-to-Server Communication . . . . . . . . . . . . . 133 308 15.4. Server-to-Server Communication . . . . . . . . . . . . . 134 309 15.5. Order of Layers . . . . . . . . . . . . . . . . . . . . 134 310 15.6. Mandatory-to-Implement Technologies . . . . . . . . . . 134 311 15.7. Hash Function Agility . . . . . . . . . . . . . . . . . 135 312 15.8. SASL Downgrade Attacks . . . . . . . . . . . . . . . . . 135 313 15.9. Lack of SASL Channel Binding to TLS . . . . . . . . . . 135 314 15.10. Use of base64 in SASL . . . . . . . . . . . . . . . . . 136 315 15.11. Stringprep Profiles . . . . . . . . . . . . . . . . . . 136 316 15.12. Address Spoofing . . . . . . . . . . . . . . . . . . . . 137 317 15.12.1. Address Forging . . . . . . . . . . . . . . . . . . 137 318 15.12.2. Address Mimicking . . . . . . . . . . . . . . . . . 138 319 15.13. Firewalls . . . . . . . . . . . . . . . . . . . . . . . 139 320 15.14. Denial of Service . . . . . . . . . . . . . . . . . . . 139 321 15.15. Presence Leaks . . . . . . . . . . . . . . . . . . . . . 140 322 15.16. Directory Harvesting . . . . . . . . . . . . . . . . . . 141 323 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 141 324 16.1. XML Namespace Name for TLS Data . . . . . . . . . . . . 141 325 16.2. XML Namespace Name for SASL Data . . . . . . . . . . . . 141 326 16.3. XML Namespace Name for Stream Errors . . . . . . . . . . 142 327 16.4. XML Namespace Name for Resource Binding . . . . . . . . 142 328 16.5. XML Namespace Name for Stanza Errors . . . . . . . . . . 142 329 16.6. Nodeprep Profile of Stringprep . . . . . . . . . . . . . 143 330 16.7. Resourceprep Profile of Stringprep . . . . . . . . . . . 143 331 16.8. GSSAPI Service Name . . . . . . . . . . . . . . . . . . 143 332 16.9. Port Numbers . . . . . . . . . . . . . . . . . . . . . . 143 333 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 144 334 17.1. Normative References . . . . . . . . . . . . . . . . . . 144 335 17.2. Informative References . . . . . . . . . . . . . . . . . 146 337 Appendix A. Nodeprep . . . . . . . . . . . . . . . . . . . . . . 150 338 A.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 150 339 A.2. Character Repertoire . . . . . . . . . . . . . . . . . . 151 340 A.3. Mapping . . . . . . . . . . . . . . . . . . . . . . . . 151 341 A.4. Normalization . . . . . . . . . . . . . . . . . . . . . 151 342 A.5. Prohibited Output . . . . . . . . . . . . . . . . . . . 151 343 A.6. Bidirectional Characters . . . . . . . . . . . . . . . . 152 344 A.7. Notes . . . . . . . . . . . . . . . . . . . . . . . . . 152 345 Appendix B. Resourceprep . . . . . . . . . . . . . . . . . . . . 152 346 B.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 153 347 B.2. Character Repertoire . . . . . . . . . . . . . . . . . . 153 348 B.3. Mapping . . . . . . . . . . . . . . . . . . . . . . . . 153 349 B.4. Normalization . . . . . . . . . . . . . . . . . . . . . 153 350 B.5. Prohibited Output . . . . . . . . . . . . . . . . . . . 153 351 B.6. Bidirectional Characters . . . . . . . . . . . . . . . . 154 352 Appendix C. XML Schemas . . . . . . . . . . . . . . . . . . . . 154 353 C.1. Streams Namespace . . . . . . . . . . . . . . . . . . . 154 354 C.2. Stream Error Namespace . . . . . . . . . . . . . . . . . 156 355 C.3. STARTTLS Namespace . . . . . . . . . . . . . . . . . . . 158 356 C.4. SASL Namespace . . . . . . . . . . . . . . . . . . . . . 158 357 C.5. Resource Binding Namespace . . . . . . . . . . . . . . . 161 358 C.6. Stanza Error Namespace . . . . . . . . . . . . . . . . . 161 359 Appendix D. Contact Addresses . . . . . . . . . . . . . . . . . 163 360 Appendix E. Account Provisioning . . . . . . . . . . . . . . . . 163 361 Appendix F. Differences From RFC 3920 . . . . . . . . . . . . . 164 362 Appendix G. Copying Conditions . . . . . . . . . . . . . . . . . 165 363 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 364 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 166 366 1. Introduction 368 1.1. Overview 370 The Extensible Messaging and Presence Protocol (XMPP) is an 371 application profile of the Extensible Markup Language [XML] for 372 streaming XML data in close to real time between any two (or more) 373 network-aware entities. XMPP is typically used to exchange messages, 374 share presence information, and engage in structured request-response 375 interactions. The basic syntax and semantics of XMPP were developed 376 originally within the Jabber open-source community, mainly in 1999. 377 In late 2002, the XMPP Working Group was chartered with developing an 378 adaptation of the core Jabber protocol that would be suitable as an 379 IETF instant messaging (IM) and presence technology. As a result of 380 work by the XMPP WG, [RFC3920] and [RFC3921] were published in 381 October 2004, representing the most complete definition of XMPP at 382 that time. 384 As a result of extensive implementation and deployment experience 385 with XMPP since 2004, as well as more formal interoperability testing 386 carried out under the auspices of the XMPP Standards Foundation 387 (XSF), this document reflects consensus from the XMPP developer 388 community regarding XMPP's core XML streaming technology. In 389 particular, this document incorporates the following backward- 390 compatible changes from RFC 3920: 392 o Incorporated corrections and errata 393 o Added examples throughout 394 o Clarified and more completely specified matters that were 395 underspecified 396 o Modified text to reflect updated technologies for which XMPP is a 397 using protocol, e.g., Transport Layer Security (TLS) and the 398 Simple Authentication and Security Layer (SASL) 399 o Defined several additional stream, stanza, and SASL error 400 conditions 401 o Removed the deprecated DIGEST-MD5 SASL mechanism [DIGEST-MD5] as a 402 mandatory-to-implement technology 403 o Added the TLS plus the SASL PLAIN mechanism [PLAIN] as a 404 mandatory-to-implement technology 405 o Defined of optional support for multiple resources over the same 406 connection 407 o Transferred historical documentation for the server dialback 408 protocol from this specification to a separate specification 410 Therefore, this document defines the core features of XMPP 1.0, thus 411 obsoleting RFC 3920. 413 Note: [XMPP-IM] defines the XMPP features needed to provide the 414 basic instant messaging and presence functionality that is 415 described in [IMP-REQS]. 417 1.2. Functional Summary 419 This non-normative section provides a developer-friendly, functional 420 summary of XMPP; refer to the sections that follow for a normative 421 definition of XMPP. 423 The purpose of XMPP is to enable the exchange of relatively small 424 pieces of structured data (called "XML stanzas") over a network 425 between any two (or more) entities. XMPP is implemented using a 426 client-server architecture, wherein a client needs to connect to a 427 server in order to gain access to the network and thus be allowed to 428 exchange XML stanzas with other entities (which can be associated 429 with other servers). The process whereby a client connects to a 430 server, exchanges XML stanzas, and ends the connection is: 432 1. Determine the hostname and port at which to connect 433 2. Open a TCP connection 434 3. Open an XML stream 435 4. Complete TLS negotiation for channel encryption (recommended) 436 5. Complete SASL negotiation for authentication 437 6. Bind a resource to the stream 438 7. Exchange an unbounded number of XML stanzas with other entities 439 on the network 440 8. Close the XML stream 441 9. Close the TCP connection 443 Within XMPP, one server can optionally connect to another server to 444 enable inter-domain or inter-server communication. For this to 445 happen, the two servers need to negotiate a connection between 446 themselves and then exchange XML stanzas; the process for doing so 447 is: 449 1. Determine the hostname and port at which to connect 450 2. Open a TCP connection 451 3. Open an XML stream 452 4. Complete TLS negotiation for channel encryption (recommended) 453 5. Complete SASL negotiation for authentication * 454 6. Exchange an unbounded number of XML stanzas both directly for the 455 servers and indirectly on behalf of entities associated with each 456 server (e.g., connected clients) 457 7. Close the XML stream 458 8. Close the TCP connection 459 * Note: Depending on local service policies, it is possible that a 460 deployed server will use the older server dialback protocol to 461 provide weak identity verification in cases where SASL negotiation 462 would not result in strong authentication (e.g., because TLS 463 negotiation was not mandated by the peer server, or because the 464 certificate presented by the peer server during TLS negotiation is 465 self-signed and thus provides only weak identity); for details, 466 see [XEP-0220]. 468 In the sections following discussion of XMPP architecture and XMPP 469 addresses, this document specifies how clients connect to servers and 470 specifies the basic semantics of XML stanzas. However, this document 471 does not define the "payloads" of the XML stanzas that might be 472 exchanged once a connection is successfully established; instead, 473 those payloads are defined by various XMPP extensions. For example, 474 [XMPP-IM] defines extensions for basic instant messaging and presence 475 functionality. In addition, various specifications produced in the 476 XSF's XEP series [XEP-0001] define extensions for a wide range of 477 more advanced functionality. 479 1.3. Conventions 481 The following capitalized keywords are to be interpreted as described 482 in [TERMS]: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; 483 "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", 484 "OPTIONAL". 486 Certain security-related terms are to be understood in the sense 487 defined in [SECTERMS]; such terms include, but are not limited to, 488 "assurance", "attack", "authentication", "authorization", 489 "certificate", "certification authority", "confidentiality", 490 "credential", "downgrade", "encryption", "fingerprint", "hash value", 491 "identity", "integrity", "signature", "security perimeter", "self- 492 signed certificate", "sign", "spoof", "tamper", "trust", "trust 493 anchor", "trust chain", "validate", "verify". Other security-related 494 terms (for example, "denial of service") are to be understood in the 495 sense defined in the referenced specifications. 497 The term "whitespace" is used to refer to any character that matches 498 production [3] content of [XML], i.e., any instance of SP, HT, CR, 499 and LF. 501 Following the "XML Notation" used in [IRI] to represent characters 502 that cannot be rendered in ASCII-only documents, some examples in 503 this document use the form "&#x...." as a notational device to 504 represent Unicode characters (e.g., the string "ř" stands for 505 the Unicode character LATIN SMALL LETTER R WITH CARON). 507 In examples, lines have been wrapped for improved readability, 508 "[...]" means elision, and the following prepended strings are used 509 (these prepended strings are not to be sent over the wire): 511 o C: = a client 512 o E: = any XMPP entity 513 o I: = an initiating entity 514 o P: = a peer server 515 o R: = a receiving entity 516 o S: = a server 517 o S1: = server1 518 o S2: = server2 520 1.4. Acknowledgements 522 The editor of this document finds it impossible to appropriately 523 acknowledge the many individuals who have provided comments regarding 524 the protocols defined herein. However, thanks are due to those who 525 have who have provided implementation feedback, bug reports, requests 526 for clarification, and suggestions for improvement since the 527 publication of the RFC this document supersedes. The editor has 528 endeavored to address all such feedback, but is solely responsible 529 for any remaining errors and ambiguities. 531 1.5. Discussion Venue 533 The document editor and the broader XMPP developer community welcome 534 discussion and comments related to the topics presented in this 535 document. The primary and preferred venue is the 536 mailing list, for which archives and subscription information are 537 available at . Related 538 discussions often occur on the mailing list, for 539 which archives and subscription information are available at 540 . 542 2. Architecture 544 XMPP provides a technology for the asynchronous, end-to-end exchange 545 of structured data by means of direct, persistent XML streams among a 546 distributed network of globally-addressable, presence-aware clients 547 and servers. Because this architectural style involves ubiquitous 548 knowledge of network availability and a conceptually unlimited number 549 of concurrent information transactions in the context of a given 550 client-to-server or server-to-server session, we label it 551 "Availability for Concurrent Transactions" (ACT) to distinguish it 552 from the "Representational State Transfer" [REST] architectural style 553 familiar from the World Wide Web. Although the architecture of XMPP 554 is similar in important ways to that of email (see [EMAIL-ARCH]), it 555 introduces several modifications to facilitate communication in close 556 to real time. The salient features of this ACTive architectural 557 style are as follows. 559 2.1. Global Addresses 561 As with email, XMPP uses globally-unique addresses (based on the 562 Domain Name System) in order to route and deliver messages over the 563 network. All XMPP entities are addressable on the network, most 564 particularly clients and servers but also various additional services 565 that can be accessed by clients and servers. In general, server 566 addresses are of the form "domain.tld" (e.g., "im.example.com"), 567 accounts hosted at a server are of the form "localpart@domain.tld" 568 (e.g., "juliet@im.example.com"), and a particular connected device or 569 resource that is currently authorized for interaction on behalf of an 570 account is of the form "localpart@domain.tld/resource" (e.g., 571 "juliet@im.example.com/balcony"). XMPP addresses are defined under 572 Section 3. 574 2.2. Presence 576 XMPP includes the ability for an entity to advertise its network 577 availability or "presence" to other entities. Such availability for 578 communication is signalled end-to-end via dedicated communication 579 primitives in XMPP (the stanza). Although knowledge of 580 network availability is not strictly necessary for the exchange of 581 XMPP messages, it facilitates real-time interaction because the 582 originator of a message can know before initiating communication that 583 the intended recipient is online and available. XMPP presence is 584 defined in [XMPP-IM]. 586 2.3. Persistent Streams 588 Availability for communication is also built into point-to-point 589 connections (e.g., a discrete client-to-server or server-to-server 590 connection) through the use of direct, persistent XML streams between 591 the entity that initiated the connection (either a client or a 592 server) and the entity that received the connection (a server). Thus 593 either party to a stream knows that it can immediately push data to 594 the other party for immediate routing or delivery. XML streams are 595 defined under Section 5. 597 2.4. Structured Data 599 The basic unit of meaning in XMPP is not an XML stream (which simply 600 provides the transport for point-to-point communication) but an XML 601 "stanza", which is essentially a fragment of XML that is sent over a 602 stream. The root element of a stanza includes routing attributes 603 (such as "from" and "to" addresses) and the child elements of the 604 stanza contain a payload for delivery to the intended recipient. XML 605 stanzas are defined under Section 9. 607 2.5. Distributed Network 609 In practice, XMPP consists of a network of clients and servers that 610 inter-communicate (however, communication between any two given 611 deployed servers is strictly OPTIONAL). Thus, for example, the user 612 associated with the server 613 might be able to exchange messages, presence, and other structured 614 data with the user associated with the server 615 . This pattern is familiar from messaging protocols 616 that make use of global addresses, such as the email network (see 617 [SMTP] and [EMAIL-ARCH]). As a result, end-to-end communication in 618 XMPP is logically peer-to-peer but physically client-to-server-to- 619 server-to-client, as illustrated in the following diagram. 621 example.net ---------------- im.example.com 622 | | 623 | | 624 romeo@example.net juliet@im.example.com 626 Note: Architectures that employ XML streams (Section 5) and XML 627 stanzas (Section 9) but that establish peer-to-peer connections 628 directly between clients using technologies based on [LINKLOCAL] 629 have been deployed, but such architectures are not described in 630 this specification and are best described as "XMPP-like"; for 631 details, see [XEP-0174]. In addition, XML streams can be 632 established end-to-end over any reliable transport, including 633 extensions to XMPP itself; however, such methods are out of scope 634 for this specification. 636 The following paragraphs describe the responsibilities of clients and 637 servers on the network. 639 A CLIENT is an entity that establishes an XML stream with a server by 640 authenticating using the credentials of a local account and that then 641 completes resource binding (Section 8) in order to enable delivery of 642 XML stanzas between the server and the client over the negotiated 643 stream. The client then uses XMPP to communicate with its server, 644 other clients, and any other entities on the network, where the 645 server is responsible for delivering stanzas to local entities or 646 routing them to remote entities. Multiple clients can connect 647 simultaneously to a server on behalf of the same local account, where 648 each client is differentiated by the resource identifier portion of 649 an XMPP address (e.g., vs. 650 ), as defined under Section 3 and Section 8. 652 A SERVER is an entity whose primary responsibilities are to: 654 o Manage XML streams (Section 5) with local clients and deliver XML 655 stanzas (Section 9) to those clients over the negotiated streams; 656 this includes responsibility for ensuring that a client needs to 657 authenticate with the server before being granted access to the 658 XMPP network. 659 o Subject to local service policies on server-to-server 660 communication, manage XML streams (Section 5) with remote servers 661 and route XML stanzas (Section 9) to those servers over the 662 negotiated streams. 664 Depending on the application, the secondary responsibilities of an 665 XMPP server can include: 667 o Storing XML data that is used by clients (e.g., contact lists for 668 users of XMPP-based instant messaging and presence applications as 669 defined in [XMPP-IM]); in this case, the relevant XML stanza is 670 handled directly by the server itself on behalf of the client and 671 is not routed to a remote server or delivered to a local entity. 672 o Hosting local services that also use XMPP as the basis for 673 communication but that provide additional functionality beyond 674 that defined in this document or in [XMPP-IM]; examples include 675 multi-user conferencing services as specified in [XEP-0045] and 676 publish-subscribe services as specified in [XEP-0060]. 678 3. Addresses 680 3.1. Overview 682 An ENTITY is anything that is network-addressable and that can 683 communicate using XMPP. For historical reasons, the native address 684 of an XMPP entity is called a JABBER IDENTIFIER or JID. A valid JID 685 contains a set of ordered elements formed of an XMPP localpart, 686 domain identifier, and resource identifier. 688 The syntax for a JID is defined as follows using the Augmented 689 Backus-Naur Form as specified in [ABNF]. 691 jid = [ localpart "@" ] domain [ "/" resource ] 692 localpart = 1*(nodepoint) 693 ; a "nodepoint" is a UTF-8 encoded Unicode code 694 ; point that satisfies the Nodeprep profile of 695 ; stringprep 696 domain = fqdn / address-literal 697 fqdn = *(ldhlabel ".") toplabel 698 ldhlabel = letdig [*61(ldh) letdig] 699 toplabel = ALPHA *61(ldh) letdig 700 letdig = ALPHA / DIGIT 701 ldh = ALPHA / DIGIT / "-" 702 address-literal = IPv4address / IPv6address 703 ; the "IPv4address" and "IPv6address" rules are 704 ; defined in RFC 3986 705 resource = 1*(resourcepoint) 706 ; a "resourcepoint" is a UTF-8 encoded Unicode 707 ; code point that satisfies the Resourceprep 708 ; profile of stringprep 710 All JIDs are based on the foregoing structure. One common use of 711 this structure is to identify a messaging and presence account, the 712 server that hosts the account, and a connected resource (e.g., a 713 specific device) in the form of . 714 However, localparts other than clients are possible; for example, a 715 specific chat room offered by a multi-user conference service (see 716 [XEP-0045]) could be addressed as (where "room" is the 717 name of the chat room and "service" is the hostname of the multi-user 718 conference service) and a specific occupant of such a room could be 719 addressed as (where "nick" is the occupant's room 720 nickname). Many other JID types are possible (e.g., could be a server-side script or service). 723 Each allowable portion of a JID (localpart, domain identifier, and 724 resource identifier) MUST NOT be more than 1023 bytes in length, 725 resulting in a maximum total size (including the '@' and '/' 726 separators) of 3071 bytes. 728 Note: While the format of a JID is consistent with [URI], an 729 entity's address on an XMPP network MUST be represented as a JID 730 (without a URI scheme) and not a [URI] or [IRI] as specified in 731 [XMPP-URI]; the latter specification is provided only for 732 identification and interaction outside the context of the XMPP 733 wire protocol itself. 735 3.2. Domain Identifier 737 The DOMAIN IDENTIFIER portion of a JID is that portion after the '@' 738 character (if any) and before the '/' character (if any); it is the 739 primary identifier and is the only REQUIRED element of a JID (a mere 740 domain identifier is a valid JID). Typically a domain identifier 741 identifies the "home" server to which clients connect for XML routing 742 and data management functionality. However, it is not necessary for 743 an XMPP domain identifier to identify an entity that provides core 744 XMPP server functionality (e.g., a domain identifier can identity an 745 entity such as a multi-user conference service, a publish-subscribe 746 service, or a user directory). 748 Note: A single server can service multiple domain identifiers, 749 i.e., multiple local domains; this is typically referred to as 750 virtual hosting. 752 The domain identifier for every server or service that will 753 communicate over a network SHOULD be a fully qualified domain name 754 (see [DNS]); while the domain identifier MAY be either an Internet 755 Protocol (IPv4 or IPv6) address or a text label that is resolvable on 756 a local network (commonly called an "unqualified hostname"), it is 757 possible that domain identifiers that are IP addresses will not be 758 acceptable to other services for the sake of interdomain 759 communication. Furthermore, domain identifiers that are unqualified 760 hostnames MUST NOT be used on public networks but MAY be used on 761 private networks. 763 Note: If the domain identifier includes a final character 764 considered to be a label separator (dot) by [IDNA] or [DNS], this 765 character MUST be stripped from the domain identifier before the 766 JID of which it is a part is used for the purpose of routing an 767 XML stanza, comparing against another JID, or constructing an 768 [XMPP-URI]; in particular, the character MUST be stripped before 769 any other canonicalization steps are taken, such as application of 770 the [NAMEPREP] profile of [STRINGPREP] or completion of the 771 ToASCII operation as described in [IDNA]. 773 A domain identifier MUST be an "internationalized domain name" as 774 defined in [IDNA], that is, "a domain name in which every label is an 775 internationalized label". When preparing a text label (consisting of 776 a sequence of Unicode code points) for representation as an 777 internationalized label in the process of constructing an XMPP domain 778 identifier or comparing two XMPP domain identifiers, an application 779 MUST ensure that for each text label it is possible to apply without 780 failing the ToASCII operation specified in [IDNA] with the 781 UseSTD3ASCIIRules flag set (thus forbidding ASCII code points other 782 than letters, digits, and hyphens). If the ToASCII operation can be 783 applied without failing, then the label is an internationalized 784 label. An internationalized domain name (and therefore an XMPP 785 domain identifier) is constructed from its constituent 786 internationalized labels by following the rules specified in [IDNA]. 788 Note: The ToASCII operation includes application of the [NAMEPREP] 789 profile of [STRINGPREP] and encoding using the algorithm specified 790 in [PUNYCODE]; for details, see [IDNA]. Although the output of 791 the ToASCII operation is not used in XMPP, it MUST be possible to 792 apply that operation without failing. 794 3.3. Localpart 796 The LOCALPART of a JID is an optional identifier placed before the 797 domain identifier and separated from the latter by the '@' character. 798 Typically a localpart uniquely identifies the entity requesting and 799 using network access provided by a server (i.e., a local account), 800 although it can also represent other kinds of entities (e.g., a chat 801 room associated with a multi-user conference service). The entity 802 represented by an XMPP localpart is addressed within the context of a 803 specific domain. 805 A localpart MUST NOT be zero bytes in length and, as for all portions 806 of a JID, MUST NOT be more than 1023 bytes in length. 808 A localpart MUST be formatted such that the Nodeprep profile of 809 [STRINGPREP] can be applied without failing (see Appendix A). Before 810 comparing two localparts, an application MUST first ensure that the 811 Nodeprep profile has been applied to each identifier (the profile 812 need not be applied each time a comparison is made, as long as it has 813 been applied before comparison). 815 3.4. Resource Identifier 817 The RESOURCE IDENTIFIER portion of a JID is an optional identifier 818 placed after the domain identifier and separated from the latter by 819 the '/' character. A resource identifier can modify either a 820 address or a mere address. Typically a 821 resource identifier uniquely identifies a specific connection (e.g., 822 a device or location) or object (e.g., a participant in a multi-user 823 conference room) belonging to the entity associated with an XMPP 824 localpart at a local domain. 826 When an XMPP address does not include a resource identifier (i.e., 827 when it is of the form or ), it is 828 referred to as a BARE JID. When an XMPP address includes a resource 829 identifier (i.e., when it is of the form or 830 ), is referred to as a FULL JID. 832 A resource identifier MUST NOT be zero bytes in length and, as for 833 all portions of a JID, MUST NOT be more than 1023 bytes in length. 835 A resource identifier MUST be formatted such that the Resourceprep 836 profile of [STRINGPREP] can be applied without failing (see 837 Appendix B). Before comparing two resource identifiers, an 838 application MUST first ensure that the Resourceprep profile has been 839 applied to each identifier (the profile need not be applied each time 840 a comparison is made, as long as it has been applied before 841 comparison). 843 Note: For historical reasons, the term "resource identifier" is 844 used in XMPP to refer to the optional portion of an XMPP address 845 that follows the domain identifier and the "/" separator 846 character; this use of the term "resource identifier" is not to be 847 confused with the meanings of "resource" and "identifier" provided 848 in Section 1.1 of [URI]. 850 XMPP entities SHOULD consider resource identifiers to be opaque 851 strings and SHOULD NOT impute meaning to any given resource 852 identifier. In paticular, the use of the '/' character as a 853 separator between the domain identifier and the resource identifier 854 does not imply that resource identifiers are hierarchical in the way 855 that, say, HTTP addresses are hierarchical; thus for example an XMPP 856 address of the form does not identify a 857 resource "bar" that exists below a resource "foo" in a hierarchy of 858 resources associated with the entity "localpart@domain". 860 3.5. Determination of Addresses 862 After the parties to an XML stream have completed the appropriate 863 aspects of stream negotiation (typically SASL negotiation (Section 7) 864 and, if appropriate, resource binding (Section 8)) the receiving 865 entity for a stream MUST determine the initiating entity's JID. 867 For server-to-server communication, the initiating server's JID MUST 868 be the authorization identity (as defined by [SASL]), either (1) as 869 directly communicated by the initiating server during SASL 870 negotiation (Section 7) or (2) as derived by the receiving server 871 from the authentication identity if no authorization identity was 872 specified during SASL negotiation (Section 7). (For information 873 about the determination of addresses in the absence of SASL 874 negotiation when the older server dialback protocol is used, see 875 [XEP-0220].) 877 For client-to-server communication, the client's bare JID 878 () MUST be the authorization identity (as defined 879 by [SASL]), either (1) as directly communicated by the client during 880 SASL negotiation (Section 7) or (2) as derived by the server from the 881 authentication identity if no authorization identity was specified 882 during SASL negotiation (Section 7). The resource identifier portion 883 of the full JID () MUST be the resource 884 identifier negotiated by the client and server during resource 885 binding (Section 8). 887 The receiving entity MUST ensure that the resulting JID (including 888 localpart, domain identifier, resource identifier, and separator 889 characters) conforms to the rules and formats defined earlier in this 890 section; to meet this restriction, the receiving entity MAY replace 891 the JID sent by the initiating entity with the canonicalized JID as 892 determined by the receiving entity. 894 4. TCP Binding 896 4.1. Scope 898 As XMPP is defined in this specification, an initiating entity 899 (client or server) MUST open a Transmission Control Protocol [TCP] 900 connection at the receiving entity (server) before it negotiates XML 901 streams with the receiving entity. The parties then maintain that 902 TCP connection for as long as the XML streams are in use. The rules 903 specified in the following sections apply to the TCP binding. 905 4.2. Hostname Resolution 907 Before opening the TCP connection, the initiating entity first MUST 908 resolve the Domain Name System (DNS) hostname associated with the 909 receiving entity and determine the appropriate TCP port for 910 communication with the receiving entity. The process is: 912 1. Attempt to resolve the hostname using (a) a [DNS-SRV] Service of 913 "xmpp-client" (for client-to-server connections) or "xmpp-server" 914 (for server-to-server connections) and (b) a Proto of "tcp", 915 resulting in resource records such as "_xmpp- 916 client._tcp.example.net." or "_xmpp-server._tcp.im.example.com.". 917 The result of the SRV lookup will be one or more combinations of 918 a port and hostname, which hostnames the initiating entity MUST 919 resolve according to returned SRV record weight (if the result of 920 the SRV lookup is a single RR with a Target of ".", i.e. the root 921 domain, the initiating entity MUST abort SRV processing but 922 SHOULD attempt a fallback resolution as described below). The 923 initiating entity uses the IP address(es) from the first 924 successfully resolved hostname (with the corresponding port 925 number returned by the SRV lookup) in order to connect to the 926 receiving entity. If the initiating entity fails to connect 927 using one of the IP addresses, the initiating entity uses the 928 next resolved IP address to connect. If the initiating entity 929 fails to connect using all resolved IP addresses, then the 930 initiating entity repeats the process of resolution and 931 connection for the next hostname returned by the SRV lookup. 932 2. If the SRV lookup aborts or fails, the fallback SHOULD be a 933 normal IPv4 or IPv6 address record resolution to determine the IP 934 address, where the port used is the "xmpp-client" port of 5222 935 for client-to-server connections or the "xmpp-server" port 5269 936 for server-to-server connections. 937 3. For client-to-server connections, the fallback MAY be a [DNS-TXT] 938 lookup for alternative connection methods, for example as 939 described in [XEP-0156]. 941 Note: If the initiating entity has been explicitly configured to 942 associate a particular hostname (and potentially port) with the 943 original hostname of the receiving entity (say, to "hardcode" an 944 association between an original hostname of example.net and a 945 configured hostname and of webcm.example.com:80), the initiating 946 entity SHALL use the configured name instead of performing the 947 foregoing resolution process on the original name. 949 Note: Many XMPP servers are implemented in such a way that they 950 can host additional services (beyond those defined in this 951 specification and [XMPP-IM]) at hostnames that are subdomains of 952 the hostname of the main XMPP service (e.g., 953 conference.example.net for a [XEP-0045] service associated with 954 the example.net XMPP service) or subdomains of the first-level 955 domain of the underlying host (e.g., muc.example.com for a 956 [XEP-0045] service associated with the im.example.com XMPP 957 service). If an entity from a remote domain wishes to use such 958 additional services, it would generate an appropriate XML stanza 959 and the remote domain itself would attempt to resolve the 960 service's hostname via an SRV lookup on resource records such as 961 "_xmpp-server._tcp.conference.example.net." or "_xmpp- 962 server._tcp.muc.example.com.". Therefore if a service wishes to 963 enable entities from remote domains to access these additional 964 services, it needs to advertise the appropriate "_xmpp-server" SRV 965 records in addition to the "_xmpp-server" record for its main XMPP 966 service. 968 4.3. Client-to-Server Communication 970 Because a client is subordinate to a server and therefore a client 971 authenticates to the server but the server does not necessarily 972 authenticate to the client, it is necessary to have only one TCP 973 connection between client and server. Thus the server MUST allow the 974 client to share a single TCP connection for XML stanzas sent from 975 client to server and from server to client (i.e., the inital stream 976 and response stream as specified under Section 5). 978 4.4. Server-to-Server Communication 980 Because two servers are peers and therefore each peer MUST 981 authenticate with the other, the servers MUST use two TCP 982 connections: one for XML stanzas sent from the first server to the 983 second server and another (initiated by the second server) for XML 984 stanzas from the second server to the first server. 986 This rule applies only to XML stanzas (Section 9). Therefore during 987 STARTTLS negotiation (Section 6) and SASL negotiation (Section 7) the 988 servers would use one TCP connection, but after stream setup that TCP 989 connection would be used only for the initiating server to send XML 990 stanzas to the receiving server. In order for the receiving server 991 to send XML stanzas to the initiating server, the receiving server 992 would need to reverse the roles and negotiate an XML stream from the 993 receiving server to the initiating server. 995 4.5. Reconnection 997 It can happen that an XMPP server goes offline while servicing TCP 998 connections from local clients and from other servers. Because the 999 number of such connections can be quite large, the reconnection 1000 algorithm employed by entities that seek to reconnect can have a 1001 significant impact on software and network performance. The 1002 following guidelines are RECOMMENDED: 1004 o The time to live (TTL) specified in Domain Name System records 1005 MUST be honored, even if DNS results are cached; if the TTL has 1006 not expired, an entity that seeks to reconnect MUST NOT re-resolve 1007 the server hostname before reconnecting. 1008 o The time that expires before an entity first seeks to reconnect 1009 MUST be randomized (e.g., so that all clients do not attempt to 1010 reconnect exactly 30 seconds after being disconnected). 1011 o If the first reconnection attempt does not succeed, an entity MUST 1012 back off increasingly on the time between subsequent reconnection 1013 attempts. 1015 Note: Because it is possible that a disconnected entity cannot 1016 determine the cause of disconnection (e.g., because there was no 1017 explicit stream error) or does not require a new stream for 1018 immediate communication (e.g., because the stream was idle and 1019 therefore timed out), it SHOULD NOT assume that is needs to 1020 reconnect immediately. 1022 4.6. Reliability 1024 The use of long-lived TCP connections in XMPP implies that the 1025 sending of XML stanzas over XML streams can be unreliable, since the 1026 parties to a long-lived TCP connection might not discover a 1027 connectivity disruption in a timely manner. At the XMPP application 1028 layer, long connectivity disruptions can result in undelivered 1029 stanzas. Although the core XMPP technology defined in this 1030 specification does not contain features to overcome this lack of 1031 reliability, there exist XMPP extensions for doing so (e.g., 1032 [XEP-0198]). 1034 4.7. Other Bindings 1036 There is no necessary coupling of an XML stream to a TCP connection. 1037 For example, two entities could connect to each other via another 1038 transport, such as [HTTP] as specified in [XEP-0124] and [XEP-0206]. 1039 Although this specification neither encourages nor discourages other 1040 bindings, it defines only a binding of XMPP to TCP. 1042 5. XML Streams 1044 5.1. Overview 1046 Two fundamental concepts make possible the rapid, asynchronous 1047 exchange of relatively small payloads of structured information 1048 between presence-aware entities: XML streams and XML stanzas. These 1049 terms are defined as follows. 1051 Definition of XML Stream: An XML STREAM is a container for the 1052 exchange of XML elements between any two entities over a network. 1053 The start of an XML stream is denoted unambiguously by an opening 1054 STREAM HEADER (i.e., an XML tag with appropriate 1055 attributes and namespace declarations), while the end of the XML 1056 stream is denoted unambiguously by a closing XML tag. 1057 During the life of the stream, the entity that initiated it can 1058 send an unbounded number of XML elements over the stream, either 1059 elements used to negotiate the stream (e.g., to complete TLS 1060 negotiation (Section 6) or SASL negotiation (Section 7)) or XML 1061 stanzas. The INITIAL STREAM is negotiated from the initiating 1062 entity (typically a client or server) to the receiving entity 1063 (typically a server), and can be seen as corresponding to the 1064 initiating entity's "connection" or "session" with the receiving 1065 entity. The initial stream enables unidirectional communication 1066 from the initiating entity to the receiving entity; in order to 1067 enable information exchange from the receiving entity to the 1068 initiating entity, the receiving entity MUST negotiate a stream in 1069 the opposite direction (the RESPONSE STREAM). 1071 Definition of XML Stanza: An XML STANZA is a discrete semantic unit 1072 of structured information that is sent from one entity to another 1073 over an XML stream, and is the basic unit of meaning in XMPP. An 1074 XML stanza exists at the direct child level of the root 1075 element; the start of any XML stanza is denoted unambiguously by 1076 the element start tag at depth=1 of the XML stream (e.g., 1077 ), and the end of any XML stanza is denoted 1078 unambiguously by the corresponding close tag at depth=1 (e.g., 1079 ). The only XML stanzas defined herein are the 1080 , , and elements qualified by the 1081 default namespace for the stream, as described under Section 9; 1082 for example, an XML element sent for the purpose of TLS 1083 negotiation (Section 6) or SASL negotiation (Section 7) is not 1084 considered to be an XML stanza, nor is a stream error or a stream 1085 feature. An XML stanza MAY contain child elements (with 1086 accompanying attributes, elements, and XML character data) as 1087 necessary in order to convey the desired information, which MAY be 1088 qualified by any XML namespace (see [XML-NAMES] as well as 1089 Section 9.4 herein). 1091 Consider the example of a client's connection to a server. In order 1092 to connect to a server, a client initiates an XML stream by sending a 1093 stream header to the server, optionally preceded by a text 1094 declaration specifying the XML version and the character encoding 1095 supported (see Section 12.5 and Section 12.6). Subject to local 1096 policies and service provisioning, the server then replies with a 1097 second XML stream back to the client, again optionally preceded by a 1098 text declaration. Once the client has completed SASL negotiation 1099 (Section 7) and resource binding (Section 8), the client can send an 1100 unbounded number of XML stanzas over the stream. When the client 1101 desires to close the stream, it simply sends a closing tag 1102 to the server as further described under Section 5.7. 1104 In essence, then, an XML stream acts as an envelope for all the XML 1105 stanzas sent during a connection. We can represent this in a 1106 simplistic fashion as follows. 1108 +--------------------+ 1109 | | 1110 |--------------------| 1111 | | 1112 | | 1113 | | 1114 |--------------------| 1115 | | 1116 | | 1117 | | 1118 |--------------------| 1119 | | 1120 | | 1121 | | 1122 |--------------------| 1123 | | 1124 | | 1125 | | 1126 |--------------------| 1127 | [ ... ] | 1128 |--------------------| 1129 | | 1130 +--------------------+ 1132 Note: Those who are accustomed to thinking of XML in a document- 1133 centric manner might view a client's connection to a server as 1134 consisting of two open-ended XML documents: one from the client to 1135 the server and one from the server to the client. On this 1136 analogy, the two XML streams can be considered equivalent to two 1137 "documents" (matching production [1] content of [XML]) that are 1138 built up through the accumulation of XML stanzas, the root 1139 element can be considered equivalent to the "document 1140 entity" for each "document" (as described in Section 4.8 of 1141 [XML]), and the XML stanzas sent over the streams can be 1142 considered equivalent to "fragments" of the "documents" as 1143 described in [XML-FRAG]. However, this perspective is merely an 1144 analogy; XMPP does not deal in documents and fragments but in 1145 streams and stanzas. 1147 5.2. Stream Security 1149 For the purpose of stream security, both Transport Layer Security 1150 (see Section 6) and the Simple Authentication and Security Layer (see 1151 Section 7) are mandatory to implement. Use of these technologies 1152 results in high security as described under Section 15.1. 1154 The initial stream and the response stream MUST be secured 1155 separately, although security in both directions MAY be established 1156 via mechanisms that provide mutual authentication. 1158 The initiating entity MUST NOT attempt to send XML stanzas 1159 (Section 9) over the stream before the stream has been authenticated. 1160 However, if it does attempt to do so, the receiving entity MUST NOT 1161 accept such stanzas and MUST return a stream error. 1162 This rule applies to XML stanzas only (i.e., , , 1163 and elements qualified by the default namespace) and not to XML 1164 elements used for stream negotiation (e.g., elements used to complete 1165 TLS negotiation (Section 6) or SASL negotiation (Section 7)). 1167 5.3. Stream Attributes 1169 The attributes of the root element are defined in the 1170 following sections. 1172 Note: The attributes of the root element are not 1173 prepended by a 'stream:' prefix because, as explained in 1174 [XML-NAMES], "[d]efault namespace declarations do not apply 1175 directly to attribute names; the interpretation of unprefixed 1176 attributes is determined by the element on which they appear." 1178 5.3.1. from 1180 The 'from' attribute communicates an XMPP identity of the entity 1181 sending the stream element. 1183 Note: It is possible for an entity to have more than one XMPP 1184 identity (e.g., in the case of a server that provides virtual 1185 hosting). It is also possible that an entity does not know the 1186 XMPP identity of the principal controlling the entity (e.g., 1187 because the XMPP identity is assigned at a level other than the 1188 XMPP application layer, as in the General Security Service 1189 Application Program Interface [GSS-API]). 1191 For initial stream headers in client-to-server communication, if the 1192 client knows the XMPP identity of the principal controlling the 1193 client (typically an account name of the form ), 1194 then it MAY include the 'from' attribute and set its value to that 1195 identity; if not, then it MUST NOT include the 'from' attribute. 1196 Note: Including the XMPP identity before the stream is protected via 1197 TLS can expose that identity to eavesdroppers. 1199 I: 1200 1208 For initial stream headers in server-to-server communication, a 1209 server MUST include the 'from' attribute and MUST set its value to a 1210 hostname serviced by the initiating entity. 1212 I: 1213 1221 For response stream headers in both client-to-server and server-to- 1222 server communication, the receiving entity MUST include the 'from' 1223 attribute and MUST set its value to a hostname serviced by the 1224 receiving entity (which MAY be a hostname other than that specified 1225 in the 'to' attribute of the initial stream header). 1227 R: 1228 1237 Whether or not the 'from' attribute is included, each entity MUST 1238 verify the identity of the other entity before exchanging XML stanzas 1239 with it (see Section 15.3 and Section 15.4). 1241 Note: It is possible that implementations based on an earlier 1242 revision of this specification will not include the 'from' address 1243 on stream headers; an entity SHOULD be liberal in accepting such 1244 stream headers. 1246 5.3.2. to 1248 For initial stream headers in both client-to-server and server-to- 1249 server communication, the initiating entity MUST include the 'to' 1250 attribute and MUST set its value to a hostname that the initiating 1251 entity knows or expects the receiving entity to service. 1253 I: 1254 1262 For response stream headers in client-to-server communication, if the 1263 client included a 'from' attribute in the initial stream header then 1264 the server MUST include a 'to' attribute in the response stream 1265 header and MUST set its value to the bare JID specified in the 'from' 1266 attribute of the initial stream header. If the client did not 1267 include a 'from' attribute in the initial stream header then the 1268 server MUST NOT include a 'to' attribute in the response stream 1269 header. 1271 R: 1272 1281 For response stream headers in server-to-server communication, the 1282 receiving entity MUST include a 'to' attribute in the response stream 1283 header and MUST set its value to the hostname specified in the 'from' 1284 attribute of the initial stream header. 1286 R: 1287 1296 Whether or not the 'to' attribute is included, each entity MUST 1297 verify the identity of the other entity before exchanging XML stanzas 1298 with it (see Section 15.3 and Section 15.4). 1300 Note: It is possible that implementations based on an earlier 1301 revision of this specification will not include the 'to' address 1302 on stream headers; an entity SHOULD be liberal in accepting such 1303 stream headers. 1305 5.3.3. id 1307 The 'id' attribute communicates a unique identifier for the stream. 1308 This identifier is called a STREAM ID. The stream ID MUST be 1309 generated by the receiving entity when it sends a response stream 1310 header, MUST BE unique within the receiving application (normally a 1311 server), and MUST be both unpredictable and nonrepeating because it 1312 can be security-critical (see [RANDOM] for recommendations regarding 1313 randomness for security purposes). 1315 For initial stream headers, the initiating entity MUST NOT include 1316 the 'id' attribute; however, if the 'id' attribute is included, the 1317 receiving entity MUST silently ignore it. 1319 For response stream headers, the receiving entity MUST include the 1320 'id' attribute. 1322 R: 1323 1332 5.3.4. xml:lang 1334 The 'xml:lang' attribute communicates an entity's preferred or 1335 default language for any human-readable XML character data to be sent 1336 over the stream. The syntax of this attribute is defined in Section 1337 2.12 of [XML]; in particular, the value of the 'xml:lang' attribute 1338 MUST conform to the NMTOKEN datatype (as defined in Section 2.3 of 1339 [XML]) and MUST conform to the language identifier format defined in 1340 [LANGTAGS]. 1342 For initial stream headers, the initiating entity SHOULD include the 1343 'xml:lang' attribute. 1345 I: 1346 1354 For response stream headers, the receiving entity MUST include the 1355 'xml:lang' attribute. If the initiating entity included an 'xml: 1356 lang' attribute in its initial stream header and the receiving entity 1357 supports that language in the human-readable XML character data that 1358 it generates and sends to the initiating entity (e.g., in the 1359 element for stream and stanza errors), the value of the 'xml:lang' 1360 attribute MUST be an identifier for the initiating entity's preferred 1361 language; if the receiving entity supports a language that closely 1362 matches the initiating entity's preferred language (e.g., "de" 1363 instead of "de-CH"), then the value of the 'xml:lang' attribute 1364 SHOULD be the identifier for the matching language but MAY be the 1365 identifier for the default language of the receiving entity; if the 1366 receiving entity does not support the initiating entity's preferred 1367 language or a closely matching language (or the initiating entity did 1368 not include the 'xml:lang' attribute in its initial stream header), 1369 then the value of the 'xml:lang' attribute MUST be the identifier for 1370 the default language of the receiving entity. 1372 R: 1373 1382 If the initiating entity included the 'xml:lang' attribute in its 1383 initial stream header, the receiving entity SHOULD remember that 1384 value as the default xml:lang for all stanzas sent by the initiating 1385 entity. As described under Section 9.1.5, the initiating entity MAY 1386 include the 'xml:lang' attribute in any XML stanzas it sends over the 1387 stream. If the initiating entity does not include the 'xml:lang' 1388 attribute in any such stanza, the receiving entity SHOULD add the 1389 'xml:lang' attribute to the stanza, whose value MUST be the 1390 identifier for the language preferred by the initiating entity (even 1391 if the receiving entity does not support that language for human- 1392 readable XML character data it generates and sends to the initiating 1393 entity, such as in stream or stanza errors). If the initiating 1394 entity includes the 'xml:lang' attribute in any such stanza, the 1395 receiving entity MUST NOT modify or delete it. 1397 5.3.5. version 1399 The inclusion of the version attribute set to a value of at least 1400 "1.0" signals support for the stream-related protocols defined in 1401 this specification, including (TLS negotiation (Section 6), SASL 1402 negotiation (Section 7), Section 5.5, and stream errors 1403 (Section 5.8). 1405 The version of XMPP specified herein is "1.0"; in particular, XMPP 1406 1.0 encapsulates the stream-related protocols as well as the basic 1407 semantics of the three defined XML stanza types (, 1408 , and ). 1410 The numbering scheme for XMPP versions is ".". The 1411 major and minor numbers MUST be treated as separate integers and each 1412 number MAY be incremented higher than a single digit. Thus, "XMPP 1413 2.4" would be a lower version than "XMPP 2.13", which in turn would 1414 be lower than "XMPP 12.3". Leading zeros (e.g., "XMPP 6.01") MUST be 1415 ignored by recipients and MUST NOT be sent. 1417 The major version number will be incremented only if the stream and 1418 stanza formats or required actions have changed so dramatically that 1419 an older version entity would not be able to interoperate with a 1420 newer version entity if it simply ignored the elements and attributes 1421 it did not understand and took the actions specified in the older 1422 specification. 1424 The minor version number will be incremented only if significant new 1425 capabilities have been added to the core protocol (e.g., a newly 1426 defined value of the 'type' attribute for message, presence, or IQ 1427 stanzas). The minor version number MUST be ignored by an entity with 1428 a smaller minor version number, but MAY be used for informational 1429 purposes by the entity with the larger minor version number (e.g., 1430 the entity with the larger minor version number would simply note 1431 that its correspondent would not be able to understand that value of 1432 the 'type' attribute and therefore would not send it). 1434 The following rules apply to the generation and handling of the 1435 'version' attribute within stream headers: 1437 1. The initiating entity MUST set the value of the 'version' 1438 attribute in the initial stream header to the highest version 1439 number it supports (e.g., if the highest version number it 1440 supports is that defined in this specification, it MUST set the 1441 value to "1.0"). 1442 2. The receiving entity MUST set the value of the 'version' 1443 attribute in the response stream header to either the value 1444 supplied by the initiating entity or the highest version number 1445 supported by the receiving entity, whichever is lower. The 1446 receiving entity MUST perform a numeric comparison on the major 1447 and minor version numbers, not a string match on 1448 ".". 1449 3. If the version number included in the response stream header is 1450 at least one major version lower than the version number included 1451 in the initial stream header and newer version entities cannot 1452 interoperate with older version entities as described, the 1453 initiating entity SHOULD generate an 1454 stream error. 1455 4. If either entity receives a stream header with no 'version' 1456 attribute, the entity MUST consider the version supported by the 1457 other entity to be "0.9" and SHOULD NOT include a 'version' 1458 attribute in the response stream header. 1460 5.3.6. Summary of Stream Attributes 1462 The following table summarizes the attributes of the root 1463 element. 1465 +----------+--------------------------+-------------------------+ 1466 | | initiating to receiving | receiving to initiating | 1467 +----------+--------------------------+-------------------------+ 1468 | to | JID of receiver | JID of initiator | 1469 | from | JID of initiator | JID of receiver | 1470 | id | silently ignored | stream identifier | 1471 | xml:lang | default language | default language | 1472 | version | XMPP 1.0+ supported | XMPP 1.0+ supported | 1473 +----------+--------------------------+-------------------------+ 1475 5.4. Namespace Declarations 1477 The stream element MUST possess both a streams namespace declaration 1478 and a default namespace declaration (as "namespace declaration" is 1479 defined in [XML-NAMES]). For detailed information regarding the 1480 streams namespace and default namespace, see Section 12.2. 1482 5.5. Stream Features 1484 If the initiating entity includes the 'version' attribute set to a 1485 value of at least "1.0" in the initial stream header, after sending 1486 the response stream header the receiving entity MUST send a 1487 child element (prefixed by the streams namespace prefix) 1488 to the initiating entity in order to announce any stream-level 1489 features that can be negotiated or capabilities that otherwise need 1490 to be advertised. 1492 R: 1493 1501 R: 1502 1503 1504 1505 1507 Stream features are used mainly to advertise TLS negotiation 1508 (Section 6), SASL negotiation (Section 7), and resource binding 1509 (Section 8); however, stream features also can be used to advertise 1510 features associated with various XMPP extensions. 1512 If it is mandatory for a feature to be successfully negotiated before 1513 the initiating entity will be allowed to proceed with the sending of 1514 XML stanzas or with further steps of the stream negotiation, the 1515 advertisement of that feature SHOULD include an empty 1516 child element but MAY include neither a element not an 1517 element (i.e., features default to required). 1519 R: 1520 1521 1522 1523 1525 If successful negotiation of a feature is discretionary, the 1526 advertisement of that feature MUST include an empty child 1527 element. 1529 R: 1530 1531 1532 1533 1535 If an entity does not understand or support a feature that has been 1536 advertised, it MUST still inspect the feature advertisement to 1537 determine if negotiation of the feature is mandatory. If negotiation 1538 of an unsupported feature is mandatory (as determined by inclusion of 1539 the child element or the absence of an child 1540 element), then the entity MUST abort the stream negotiation process. 1541 If negotiation of an unsupported feature is discretionary (as 1542 determined by inclusion of the child element or the 1543 absence of a child element), the entity MUST silently ignore the 1544 associated feature advertisement and proceed with the stream 1545 negotiation process. 1547 Note: Implementations based on an earlier revision of this 1548 specification do not include the child element and 1549 they include the child element only in the case of the 1550 STARTTLS feature. Entities MUST accept stream feature 1551 advertisements without the child elements, and SHOULD consider 1552 consider negotiation of such features to be discretionary. 1554 If it is necessary for a feature to be successfully negotiated before 1555 the initiating entity is allowed to proceed with the sending a non- 1556 security-related feature or with further steps of the stream 1557 negotiation, the receiving entity SHOULD NOT advertise any other 1558 stream features until the mandatory feature has been successfully 1559 negotiated; however, if the mandatory feature is security-critical 1560 (e.g., STARTTLS or SASL) then the receiving entity MUST NOT advertise 1561 any other stream features until the security-critical feature has 1562 been successfully negotiated. 1564 The order of child elements contained in any given 1565 element is not significant. 1567 After completing negotiation of any stream feature (even stream 1568 features that do not require a stream restart), the receiving entity 1569 MUST send an updated list of stream features to the initiating 1570 entity. However, if there are no features to be advertised then the 1571 receiving entity MUST send an empty element. 1573 R: 1574 1583 R: 1585 At any time after stream establishment, the receiving entity MAY send 1586 additional or modified stream feature advertisements (e.g., because a 1587 new feature has been enabled). 1589 5.6. Restarts During Stream Negotiation 1591 Certain stream features require the initiating entity to send a new 1592 initial stream header on successful negotiation of the feature (e.g., 1593 after successful negotiation of TLS or SASL). Both parties MUST 1594 consider the previous stream to be replaced on successful feature 1595 negotiation but MUST NOT terminate the underlying TCP connection; 1596 instead, the parties MUST reuse the existing connection, which might 1597 be in a new state (e.g., encrypted as a result of TLS negotiation). 1598 When the receiving entity receives the new initial stream header, it 1599 MUST generate a new stream ID (instead of re-using the old stream ID) 1600 before sending a new response stream header. 1602 5.7. Closing a Stream 1604 An XML stream between two entities can be closed because a stream 1605 error has occurred or in some cases in the absence of an error. 1606 Where feasible, it is preferable to close a stream only if a stream 1607 error has occurred. 1609 A stream is closed by sending a closing tag over the TCP 1610 connection. 1612 S: 1614 After an entity sends a closing stream tag, it MUST NOT send further 1615 data over that stream. 1617 5.7.1. With Stream Error 1619 If a stream error has occurred, the entity that detects the error 1620 MUST close the stream as described under Section 5.8.1. 1622 5.7.2. Without Stream Error 1624 At any time after XML streams have been negotiated between two 1625 entities, either entity MAY close its stream to the other party in 1626 the absence of a stream error by sending a closing stream tag. 1628 P: 1630 The entity that sends the closing stream tag SHOULD wait for the 1631 other party to also close its stream. 1633 S: 1635 However, the entity that sends the first closing stream tag MAY 1636 consider both streams to be void if the other party does not send its 1637 closing stream tag within a reasonable amount of time (where the 1638 definition of "reasonable" is a matter of implementation or 1639 deployment). 1641 After the entity that sent the first closing stream tag receives a 1642 reciprocal closing stream tag from the other party (or if it 1643 considers the stream to be void after a reasonable amount of time), 1644 it MUST terminate the underlying TCP connection or connections. 1646 5.7.3. Handling of Idle Streams 1648 An XML stream can become idle, i.e., neither entity has sent XMPP 1649 traffic over the stream for some period of time. The idle timeout 1650 period is a matter of implementation and local service policy; 1651 however, it is RECOMMENDED to be liberal in accepting idle streams, 1652 since experience has shown that doing so improves the reliability of 1653 communications over XMPP networks. In particular, it is typically 1654 more efficient to maintain a stream between two servers than it is to 1655 aggressively timeout such a stream, especially with regard to 1656 synchronization of presence information as described in [XMPP-IM]; 1657 therefore it is RECOMMENDED to maintain such a stream since 1658 experience has shown that server-to-server streams are cyclical and 1659 typically need to be re-established every 24 to 48 hours if they are 1660 timed out. 1662 An XML stream can appear idle at the XMPP level because the 1663 underlying TCP connection has become idle (e.g., a client's network 1664 connection has been lost). One common method for preventing a TCP 1665 connection from going idle or for detecting an idle TCP connection is 1666 to send a space character (U+0020) over the TCP connection between 1667 XML stanzas, which is allowed for XML streams as described under 1668 Section 12.7; the sending of such a space character is properly 1669 called a WHITESPACE KEEPALIVE (although the term "whitespace ping" is 1670 often used, in fact it is not a ping since no "pong" is possible). 1671 Other connection-testing methods include the application-level pings 1672 described in [XEP-0199] and the more comprehensive stream management 1673 protocol described in [XEP-0198]. Implementers are advised to 1674 support whichever connection-testing methods they deem appropriate, 1675 but to carefully weigh the network impact of such methods against the 1676 benefits of discovering idle streams in a timely manner. The length 1677 of time between the use of any particular connection test is a matter 1678 of implementation and local service policy; however, it is 1679 RECOMMENDED that any such test be performed not more than once every 1680 60 seconds. 1682 To close an idle stream with a local client or remote server, a 1683 server MUST close the stream without error as explained under 1684 Section 5.7.2. 1686 5.8. Stream Errors 1688 The root stream element MAY contain an child element that is 1689 prefixed by the streams namespace prefix. The error child shall be 1690 sent by a compliant entity if it perceives that a stream-level error 1691 has occurred. 1693 5.8.1. Rules 1695 The following rules apply to stream-level errors. 1697 5.8.1.1. Stream Errors Are Unrecoverable 1699 Stream-level errors are unrecoverable. Therefore, if an error occurs 1700 at the level of the stream, the entity that detects the error MUST 1701 send a element with an appropriate child element that 1702 specifies the error condition and at the same time send a closing 1703 tag. 1705 C: 1707 S: 1708 1710 1711 1713 The entity that generates the stream error then SHOULD immediately 1714 terminate the underlying TCP connection, although it MAY wait until 1715 after it receives a closing tag from the entity to which it 1716 sent the stream error. 1718 C: 1720 5.8.1.2. Stream Errors Can Occur During Setup 1722 If the error is triggered by the initial stream header, the receiving 1723 entity MUST still send the opening tag, include the 1724 element as a child of the stream element, and send the closing 1725 tag (preferably all at the same time). 1727 C: 1728 1736 S: 1737 1745 1746 1748 1749 1751 5.8.1.3. Stream Errors When the Host is Unspecified or Unknown 1753 If the initiating entity provides no 'to' attribute or provides an 1754 unknown host in the 'to' attribute and the error occurs during stream 1755 setup, the receiving entity SHOULD provide an authoritative hostname 1756 in the 'from' attribute of the stream header sent before termination, 1757 but absent such an authoritative hostname MAY instead simply populate 1758 the response stream's 'from' attribute with the value of the initial 1759 stream header's 'to' attribute (where the value of the 'from' 1760 attribute MAY be empty if the initiating entity provided no 'to' 1761 attribute). 1763 C: 1764 1772 S: 1773 1781 1782 1784 1785 1787 5.8.1.4. Where Stream Errors Are Sent 1789 When two XML streams are used between the initiating entity and the 1790 receiving entity (one in each direction) rather than using a single 1791 bidirectional stream, stanza errors triggered by stanzas sent over 1792 the outbound stream are returned on the inbound stream (since they 1793 are inbound stanzas from the perspective of the entity that sent the 1794 triggering stanza), whereas stream errors related to the outbound 1795 stream are returned on the outbound stream (since they are not 1796 inbound stanzas from the perspective of the entity that sent the 1797 triggering stanza but strictly related to the outbound stream 1798 itself); the same is true, naturally, of any stream errors that are 1799 related to the outbound stream but not triggered by an outbound 1800 stanza. 1802 5.8.2. Syntax 1804 The syntax for stream errors is as follows, where "defined-condition" 1805 is a placeholder for one of the conditions defined under 1806 Section 5.8.3. 1808 1809 1810 [ 1812 [ ... descriptive text ... ] 1813 ] 1814 [application-specific condition element] 1815 1817 The element: 1819 o MUST contain a child element corresponding to one of the defined 1820 stream error conditions (Section 5.8.3); this element MUST be 1821 qualified by the 'urn:ietf:params:xml:ns:xmpp-streams' namespace. 1822 o MAY contain a child element containing XML character data 1823 that describes the error in more detail; this element MUST be 1824 qualified by the 'urn:ietf:params:xml:ns:xmpp-streams' namespace 1825 and SHOULD possess an 'xml:lang' attribute specifying the natural 1826 language of the XML character data. 1827 o MAY contain a child element for an application-specific error 1828 condition; this element MUST be qualified by an application- 1829 defined namespace, and its structure is defined by that namespace 1830 (see Section 5.8.4). 1832 The element is OPTIONAL. If included, it MUST be used only 1833 to provide descriptive or diagnostic information that supplements the 1834 meaning of a defined condition or application-specific condition. It 1835 MUST NOT be interpreted programmatically by an application. It MUST 1836 NOT be used as the error message presented to a human user, but MAY 1837 be shown in addition to the error message associated with the defined 1838 condition element (and, optionally, the application-specific 1839 condition element). 1841 5.8.3. Defined Stream Error Conditions 1843 The following stream-level error conditions are defined. 1845 5.8.3.1. bad-format 1847 The entity has sent XML that cannot be processed. 1849 (In the following example, the client sends an XMPP message that is 1850 not well-formed XML.) 1851 C: 1852 No closing body tag! 1853 1855 S: 1856 1858 1859 1861 This error MAY be used instead of the more specific XML-related 1862 errors, such as , , , , and . However, 1864 the more specific errors are RECOMMENDED. 1866 5.8.3.2. bad-namespace-prefix 1868 The entity has sent a namespace prefix that is unsupported, or has 1869 sent no namespace prefix on an element that requires such a prefix 1870 (see Section 12.2). 1872 (In the following example, the client specifies a namespace prefix of 1873 "foobar" for the XML streams namespace.) 1875 C: 1876 1883 S: 1884 1892 1893 1895 1896 1898 5.8.3.3. conflict 1900 The server is either (1) closing the existing stream for this entity 1901 because a new stream has been initiated that conflicts with the 1902 existing stream, or (2) is refusing a new stream for this entity 1903 because allowing the new stream would conflict with an existing 1904 stream (e.g., because the server allows only a certain number of 1905 connections from the same IP address). 1907 C: 1908 1915 S: 1916 1924 1925 1927 1928 1930 5.8.3.4. connection-timeout 1932 The entity has not generated any traffic over the stream for some 1933 period of time (configurable according to a local service policy) and 1934 therefore the connection is being dropped. 1936 P: 1937 1939 1940 1942 5.8.3.5. host-gone 1944 The value of the 'to' attribute provided in the initial stream header 1945 corresponds to a hostname that is no longer serviced by the receiving 1946 entity. 1948 (In the following example, the peer specifies a 'to' address of 1949 "foo.im.example.com" when connecting to the "im.example.com" server, 1950 but the server no longer hosts a service at that address.) 1952 P: 1953 1960 S: 1961 1969 1970 1972 1973 1975 5.8.3.6. host-unknown 1977 The value of the 'to' attribute provided in the initial stream header 1978 does not correspond to a hostname that is serviced by the receiving 1979 entity. 1981 (In the following example, the peer specifies a 'to' address of 1982 "example.org" when connecting to the "im.example.com" server, but the 1983 server knows nothing of that address.) 1984 P: 1985 1992 S: 1993 2001 2002 2004 2005 2007 5.8.3.7. improper-addressing 2009 A stanza sent between two servers lacks a 'to' or 'from' attribute, 2010 the 'from' or 'to' attribute has no value, or the value is not a 2011 valid XMPP address. 2013 (In the following example, the peer sends a stanza without a 'to' 2014 address.) 2016 P: 2017 Wherefore art thou? 2018 2020 S: 2021 2023 2024 2026 5.8.3.8. internal-server-error 2028 The server has experienced a misconfiguration or an otherwise- 2029 undefined internal error that prevents it from servicing the stream. 2031 S: 2032 2034 2035 2037 5.8.3.9. invalid-from 2039 The JID or hostname provided in a 'from' address is not a valid JID 2040 or does not match an authorized JID or validated domain as negotiated 2041 between servers via SASL or server dialback, or as negotiated between 2042 a client and a server via authentication and resource binding. 2044 (In the following example, a peer that has authenticated only as 2045 "example.net" attempts to send a stanza from an address at 2046 "example.org".) 2048 P: 2049 Neither, fair saint, if either thee dislike. 2050 2052 S: 2053 2055 2056 2058 5.8.3.10. invalid-id 2060 The stream ID or server dialback ID is invalid or does not match an 2061 ID previously provided. 2063 (In the following example, the server dialback ID is invalid; see 2064 [XEP-0220].) 2066 P: 2072 S: 2073 2075 2076 2078 5.8.3.11. invalid-namespace 2080 The streams namespace name is something other than 2081 "http://etherx.jabber.org/streams" (see Section 12.2) or the default 2082 namespace is not supported (e.g., something other than "jabber: 2083 client" or "jabber:server"). 2085 (In the following example, the client specifies a streams namespace 2086 of 'http://wrong.namespace.example.org/'.) 2088 C: 2089 2096 S: 2097 2105 2106 2108 2109 2111 5.8.3.12. invalid-xml 2113 The entity has sent invalid XML over the stream to a server that 2114 performs validation (see Section 12.4). 2116 (In the following example, the peer attempts to send an IQ stanza of 2117 type "subscribe" but the XML schema defines no such value for the 2118 'type' attribute.) 2119 P: 2123 2124 2126 S: 2127 2129 2130 2132 5.8.3.13. not-authorized 2134 The entity has attempted to send XML stanzas before the stream has 2135 been authenticated, or otherwise is not authorized to perform an 2136 action related to stream negotiation; the receiving entity MUST NOT 2137 process the offending stanza before sending the stream error. 2139 (In the following example, the client attempts to send XML stanzas 2140 before authenticating with the server.) 2141 C: 2142 2149 S: 2150 2160 Wherefore art thou? 2161 2163 S: 2164 2166 2167 2169 5.8.3.14. policy-violation 2171 The entity has violated some local service policy (e.g., the stanza 2172 exceeds a configured size limit); the server MAY choose to specify 2173 the policy in the element or in an application-specific 2174 condition element. 2176 (In the following example, the client sends an XMPP message that is 2177 too large according to the server's local service policy.) 2179 C: 2180 [ ... the-emacs-manual ... ] 2181 2183 S: 2184 2186 2188 S: 2190 5.8.3.15. remote-connection-failed 2192 The server is unable to properly connect to a remote entity that is 2193 required for authentication or authorization, such as a remote 2194 authentication database or (in server dialback) the authoritative 2195 server. 2197 C: 2198 2205 S: 2206 2214 2215 2217 2218 2220 5.8.3.16. resource-constraint 2222 The server lacks the system resources necessary to service the 2223 stream. 2225 C: 2226 2233 S: 2234 2242 2243 2245 2246 2248 5.8.3.17. restricted-xml 2250 The entity has attempted to send restricted XML features such as a 2251 comment, processing instruction, DTD subset, or XML entity reference 2252 (see Section 12.1). 2254 (In the following example, the client sends an XMPP message 2255 containing an XML comment.) 2257 C: 2258 2259 This message has no subject. 2260 2262 S: 2263 2265 2266 2268 5.8.3.18. see-other-host 2270 The server will not provide service to the initiating entity but is 2271 redirecting traffic to another host; the XML character data of the 2272 element returned by the server SHOULD specify the 2273 alternate hostname or IP address at which to connect, which SHOULD be 2274 a valid domain identifier but MAY also include a port number. When 2275 it receives a see-other-host stream error, the initiating entity 2276 SHOULD cleanly handle the disconnection and then reconnect to the 2277 host specified in the element; if no port is 2278 specified, the initiating entity SHOULD perform a [DNS-SRV] lookup on 2279 the provided domain identifier but MAY assume that it can connect to 2280 that domain identifier at the standard XMPP ports (i.e., 5222 for 2281 client-to-server connections and 5269 for server-to-server 2282 connections). 2284 C: 2285 2292 S: 2293 2301 2302 2304 [2001:41D0:1:A49b::1]:9222 2305 2306 2307 2309 5.8.3.19. system-shutdown 2311 The server is being shut down and all active streams are being 2312 closed. 2314 S: 2315 2317 2318 2320 5.8.3.20. undefined-condition 2322 The error condition is not one of those defined by the other 2323 conditions in this list; this error condition SHOULD be used only in 2324 conjunction with an application-specific condition. 2326 S: 2327 2329 2330 2331 2333 5.8.3.21. unsupported-encoding 2335 The initiating entity has encoded the stream in an encoding that is 2336 not supported by the server (see Section 12.6) or has otherwise 2337 improperly encoded the stream (e.g., by violating the rules of the 2338 [UTF-8] encoding). 2340 (In the following example, the client attempts to encode data using 2341 UTF-16 instead of UTF-8.) 2343 C: 2344 2351 S: 2352 2361 2363 2364 2366 5.8.3.22. unsupported-stanza-type 2368 The initiating entity has sent a first-level child of the stream that 2369 is not supported by the server or consistent with the default 2370 namespace. 2372 (In the following example, the client attempts to send an XML stanza 2373 of when the default namespace is "jabber:client".) 2375 C: 2376 2377 2378 2379 Soliloquy 2380 2381 To be, or not to be: that is the question: 2382 Whether 'tis nobler in the mind to suffer 2383 The slings and arrows of outrageous fortune, 2384 Or to take arms against a sea of troubles, 2385 And by opposing end them? 2386 2387 2389 tag:denmark.example,2003:entry-32397 2390 2003-12-13T18:30:02Z 2391 2003-12-13T18:30:02Z 2392 2393 2394 2395 2397 S: 2398 2400 2401 2403 5.8.3.23. unsupported-version 2405 The value of the 'version' attribute provided by the initiating 2406 entity in the stream header specifies a version of XMPP that is not 2407 supported by the server; the server MAY specify the version(s) it 2408 supports in the element. 2410 (In the following example, the client specifies an XMPP version of 2411 "11.0" but the server supports only version "1.0" and "1.1".) 2412 C: 2413 2420 S: 2421 2430 2432 2433 1.0, 1.1 2434 2435 2436 2438 5.8.3.24. xml-not-well-formed 2440 The initiating entity has sent XML that violates the well-formedness 2441 rules of [XML] or [XML-NAMES]. 2443 (In the following example, the client sends an XMPP message that is 2444 not well-formed XML.) 2446 C: 2447 No closing body tag! 2448 2450 S: 2451 2453 2454 2456 5.8.4. Application-Specific Conditions 2458 As noted, an application MAY provide application-specific stream 2459 error information by including a properly-namespaced child in the 2460 error element. The application-specific element SHOULD supplement or 2461 further qualify a defined element. Thus the element will 2462 contain two or three child elements. 2464 C: 2465 2466 My keyboard layout is: 2468 QWERTYUIOP{}| 2469 ASDFGHJKL:" 2470 ZXCVBNM<>? 2471 2472 2474 S: 2475 2477 2478 Some special application diagnostic information! 2479 2480 2481 2482 2484 5.9. Simplified Stream Examples 2486 This section contains two simplified examples of a stream-based 2487 connection between a client and a server; these examples are included 2488 for the purpose of illustrating the concepts introduced thus far. 2490 A basic connection: 2492 C: 2493 2501 S: 2502 2511 [ ... channel encryption ... ] 2513 [ ... authentication ... ] 2515 [ ... resource binding ... ] 2517 C: 2520 Art thou not Romeo, and a Montague? 2521 2523 S: 2526 Neither, fair saint, if either thee dislike. 2527 2529 C: 2531 S: 2532 A connection gone bad: 2534 C: 2535 2543 S: 2544 2553 [ ... channel encryption ... ] 2555 [ ... authentication ... ] 2557 [ ... resource binding ... ] 2559 C: 2562 No closing body tag! 2563 2565 S: 2566 2568 2569 2571 More detailed examples are provided under Section 10. 2573 6. STARTTLS Negotiation 2574 6.1. Overview 2576 XMPP includes a method for securing the stream from tampering and 2577 eavesdropping. This channel encryption method makes use of the 2578 Transport Layer Security [TLS] protocol, specifically a "STARTTLS" 2579 extension that is modelled after similar extensions for the [IMAP], 2580 [POP3], and [ACAP] protocols as described in [USINGTLS]. The XML 2581 namespace name for the STARTTLS extension is 2582 'urn:ietf:params:xml:ns:xmpp-tls'. 2584 Support for STARTTLS is REQUIRED in XMPP client and server 2585 implementations. An administrator of a given deployment MAY require 2586 the use of TLS for client-to-server communication, server-to-server 2587 communication, or both. A deployed client SHOULD use TLS to secure 2588 its stream with a server prior to attempting the completion of SASL 2589 negotiation (Section 7), and deployed servers SHOULD use TLS between 2590 two domains for the purpose of securing server-to-server 2591 communication. 2593 6.2. Rules 2595 6.2.1. Data Formatting 2597 During STARTTLS negotiation, the entities MUST NOT send any 2598 whitespace within the root stream element as separators between XML 2599 elements (i.e., from the last character of the element 2600 qualified by the 'urn:ietf:params:xml:ns:xmpp-tls' namespace at 2601 depth=1 of the stream as sent by the initiating entity until the last 2602 character of the element qualified by the 2603 'urn:ietf:params:xml:ns:xmpp-tls' namespace at depth=1 of the stream 2604 as sent by the receiving entity). This prohibition helps to ensure 2605 proper security layer byte precision. Any such whitespace shown in 2606 the STARTTLS examples provided in this document is included only for 2607 the sake of readability. 2609 6.2.2. Order of Negotiation 2611 If the initiating entity chooses to use TLS, STARTTLS negotiation 2612 MUST be completed before proceeding to SASL negotiation (Section 7); 2613 this order of negotiation is required to help safeguard 2614 authentication information sent during SASL negotiation, as well as 2615 to make it possible to base the use of the SASL EXTERNAL mechanism on 2616 a certificate (or other credentials) provided during prior TLS 2617 negotiation. 2619 6.3. Process 2621 6.3.1. Exchange of Stream Headers and Stream Features 2623 The initiating entity resolves the hostname of the receiving entity 2624 as specified under Section 4, opens a TCP connection to the 2625 advertised port at the resolved IP address, and sends an initial 2626 stream header to the receiving entity; if the initiating entity is 2627 capable of STARTTLS negotiation, it MUST include the 'version' 2628 attribute set to a value of at least "1.0" in the initial stream 2629 header. 2631 I: 2639 The receiving entity MUST send a response stream header to the 2640 initiating entity over the TCP connection opened by the initiating 2641 entity; if the receiving entity is capable of STARTTLS negotiation, 2642 it MUST include the 'version' attribute set to a value of at least 2643 "1.0" in the response stream header. 2645 R: element qualified by the 2658 'urn:ietf:params:xml:ns:xmpp-tls' namespace. 2660 If the receiving entity considers STARTTLS negotiation to be 2661 discretionary, the element MUST contain an empty 2662 child element. 2664 R: 2665 2666 2667 2668 2670 If the receiving entity considers STARTTLS negotiation to be 2671 mandatory, the element MUST contain an empty 2672 child element. 2674 R: 2675 2676 2677 2678 2680 6.3.2. Initiation of STARTTLS Negotiation 2682 6.3.2.1. STARTTLS Command 2684 In order to begin the STARTTLS negotiation, the initiating entity 2685 issues the STARTTLS command (i.e., a element qualified by 2686 the 'urn:ietf:params:xml:ns:xmpp-tls' namespace) to instruct the 2687 receiving entity that it wishes to begin a STARTTLS negotiation to 2688 secure the stream. 2690 I: 2692 The receiving entity MUST reply with either a element 2693 (proceed case) or a element (failure case) qualified by 2694 the 'urn:ietf:params:xml:ns:xmpp-tls' namespace. 2696 6.3.2.2. Failure Case 2698 If the failure case occurs, the receiving entity MUST return a 2699 element qualified by the 'urn:ietf:params:xml:ns:xmpp-tls' 2700 namespace, terminate the XML stream, and terminate the underlying TCP 2701 connection. 2703 R: 2705 R: 2707 Causes for the failure case include but are not limited to: 2709 1. The initiating entity has sent a malformed STARTTLS command. 2711 2. The receiving entity does not offer STARTTLS negotiation either 2712 temporarily or permanently. 2713 3. The receiving entity cannot complete STARTTLS negotiation because 2714 of an internal error. 2716 Note: STARTTLS failure is not triggered by TLS errors such as bad 2717 certificate or unknown certificate authority; those errors are 2718 generated and handled during the TLS negotiation itself as 2719 described in [TLS]. 2721 If the failure case occurs, the initiating entity MAY attempt to 2722 reconnect as explained under Section 4.5. 2724 6.3.2.3. Proceed Case 2726 If the proceed case occurs, the receiving entity MUST return a 2727 element qualified by the 'urn:ietf:params:xml:ns:xmpp-tls' 2728 namespace. 2730 R: 2732 The receiving entity MUST consider the TLS negotiation to have begun 2733 immediately after sending the closing '>' character of the 2734 element to the initiating entity. The initiating entity MUST 2735 consider the TLS negotiation to have begun immediately after 2736 receiving the closing '>' character of the element from 2737 the receiving entity. 2739 The entities now proceed to TLS negotiation as explained in the next 2740 section. 2742 6.3.3. TLS Negotiation 2744 6.3.3.1. Rules 2746 In order to complete TLS negotiation over the TCP connection, the 2747 entities MUST follow the process defined in [TLS]. 2749 The following rules apply: 2751 1. The entities MUST NOT send any further XML data until the TLS 2752 negotiation has either failed or succeeded. 2753 2. The receiving entity MUST present a certificate. 2754 3. The receiving entity SHOULD send a certificate request to the 2755 initiating entity so that mutual authentication will be possible. 2756 4. The initiating entity MUST validate the certificate to determine 2757 if the TLS negotiation shall succeed; see Section 15.2.2 2758 regarding certificate validation procedures. 2760 5. The receiving entity SHOULD choose which certificate to present 2761 based on the 'to' attribute of the initial stream header. 2763 Note: See Section 15.6 regarding ciphers that MUST be supported 2764 for TLS; naturally, other ciphers MAY be supported as well. 2766 6.3.3.2. TLS Failure 2768 If the TLS negotiation results in failure, the receiving entity MUST 2769 terminate the TCP connection. 2771 The receiving entity MUST NOT send a closing tag before 2772 terminating the TCP connection, since the receiving entity and 2773 initiating entity MUST consider the original stream to be replaced 2774 upon failure of the TLS negotiation. 2776 6.3.3.3. TLS Success 2778 If the TLS negotiation is successful, then the entities MUST proceed 2779 as follows. 2781 1. The receiving entity MUST discard any knowledge obtained in an 2782 insecure manner from the initiating entity before TLS took 2783 effect. 2784 2. The initiating entity MUST discard any knowledge obtained in an 2785 insecure manner from the receiving entity before TLS took effect. 2786 3. The initiating entity MUST send a new initial stream header to 2787 the receiving entity over the encrypted connection. 2789 I: 2797 Note: The initiating entity MUST NOT send a closing tag 2798 before sending the new initial stream header, since the receiving 2799 entity and initiating entity MUST consider the original stream to 2800 be replaced upon success of the TLS negotiation. 2801 4. The receiving entity MUST respond with a new response stream 2802 header over the encrypted connection. 2804 R: 2819 2820 EXTERNAL 2821 PLAIN 2822 2823 2824 2826 7. SASL Negotiation 2828 7.1. Overview 2830 XMPP includes a method for authenticating a stream by means of an 2831 XMPP-specific profile of the Simple Authentication and Security Layer 2832 protocol (see [SASL]). SASL provides a generalized method for adding 2833 authentication support to connection-based protocols, and XMPP uses 2834 an XML namespace profile of SASL that conforms to the profiling 2835 requirements of [SASL]. 2837 Support for SASL negotiation is REQUIRED in XMPP client and server 2838 implementations. 2840 7.2. Rules 2842 7.2.1. Mechanism Preferences 2844 Any entity that will act as a SASL client or a SASL server MUST 2845 maintain an ordered list of its preferred SASL mechanisms according 2846 to the client or server, where the list is ordered by the perceived 2847 strength of the mechanisms. A server MUST offer and a client MUST 2848 try SASL mechanisms in the order of their perceived strength. For 2849 example, if the server offers the ordered list "PLAIN DIGEST-MD5 2850 GSSAPI" or "DIGEST-MD5 GSSAPI PLAIN" but the client's ordered list is 2851 "GSSAPI DIGEST-MD5", the client shall try GSSAPI first and then 2852 DIGEST-MD5 but shall never try PLAIN (since PLAIN is not on its 2853 list). 2855 7.2.2. Mechanism Offers 2857 If the receiving entity considers TLS negotiation (Section 6) to be 2858 mandatory before use of a particular SASL authentication mechanism 2859 will be acceptable, the receiving entity MUST NOT advertise that 2860 mechanism in its list of available SASL authentication mechanisms 2861 prior to successful TLS negotiation. 2863 If during prior TLS negotiation the initiating entity presented a 2864 certificate that is acceptable to the receiving entity for purposes 2865 of strong identity verification in accordance with local service 2866 policies, the receiving entity MUST offer the SASL EXTERNAL mechanism 2867 to the initiating entity during SASL negotiation (refer to [SASL]) 2868 and SHOULD prefer that mechanism. However, the EXTERNAL mechanism 2869 MAY be offered under other circumstances as well. 2871 See Section 15.6 regarding mechanisms that MUST be supported; 2872 naturally, other SASL mechanisms MAY be supported as well. Best 2873 practices for the use of several SASL mechanisms in the context of 2874 XMPP are described in [XEP-0175] and [XEP-0178]. 2876 7.2.3. Data Formatting 2878 The following data formattting rules apply to the SASL negotiation: 2880 1. During SASL negotiation, the entities MUST NOT send any 2881 whitespace within the root stream element as separators between 2882 XML elements (i.e., from the last character of the 2883 element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' 2884 namespace at depth=1 of the stream as sent by the initiating 2885 entity until the last character of the element 2886 qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace at 2887 depth=1 of the stream as sent by the receiving entity). This 2888 prohibition helps to ensure proper security layer byte precision. 2889 Any such whitespace shown in the SASL examples provided in this 2890 document is included only for the sake of readability. 2891 2. Any XML character data contained within the XML elements MUST be 2892 encoded using base64, where the encoding adheres to the 2893 definition in Section 4 of [BASE64] and where the padding bits 2894 are set to zero. 2895 3. As formally specified in the XML schema for the 2896 'urn:ietf:params:xml:ns:xmpp-sasl' namespace under Appendix C.4, 2897 the receiving entity MAY include one or more application-specific 2898 child elements inside the element to provide 2899 information that might be needed by the initiating entity in 2900 order to complete successful SASL negotiation using one or more 2901 of the offered mechanisms; however, the syntax and semantics of 2902 all such elements are out of scope for this specification. 2904 7.2.4. Security Layers 2906 Upon successful SASL negotiation that involves negotiation of a 2907 security layer, both the initiating entity and the receiving MUST 2908 discard any application-layer state (i.e, state from the XMPP layer, 2909 excluding state from the TLS negotiation or SASL negotiation). 2911 7.2.5. Simple Usernames 2913 It is possible that provision of a "simple username" is supported by 2914 the selected SASL mechanism (e.g., this is supported by the DIGEST- 2915 MD5 and CRAM-MD5 mechanisms but not by the EXTERNAL and GSSAPI 2916 mechanisms). The simple username provided during authentication MUST 2917 be as follows: 2919 Client-to-server communication: The initiating entity's registered 2920 account name, i.e., a user name as described under Section 3.3 2921 (this is not a bare JID of the form but only 2922 the localpart of the JID). The simple username MUST adhere to the 2923 Nodeprep (Appendix A) profile of [STRINGPREP]. 2924 Server-to-server communication: The initiating entity's sending 2925 domain, i.e., IP address or fully qualified domain name as 2926 contained in an XMPP domain identifier. The simple username MUST 2927 adhere to the [NAMEPREP] profile of [STRINGPREP]. 2929 7.2.6. Authorization Identities 2931 An authorization identity is an optional identity specified by the 2932 initiating entity, which is typically used by an administrator to 2933 perform some management task on behalf of another user. If the 2934 initiating entity wishes to act on behalf of another entity and the 2935 selected SASL mechanism supports transmission of an authorization 2936 identity, the initiating entity MUST provide an authorization 2937 identity during SASL negotiation. If the initiating entity does not 2938 wish to act on behalf of another entity, it MUST NOT provide an 2939 authorization identity. As specified in [SASL], the initiating 2940 entity MUST NOT provide an authorization identity unless the 2941 authorization identity is different from the default authorization 2942 identity derived from the authentication identity. If provided, the 2943 value of the authorization identity MUST be a bare JID of the form 2944 (i.e., an XMPP domain identifier only) for servers and a 2945 bare JID of the form (i.e., localpart and domain 2946 identifier) for clients. 2948 Note: The authorization identity communited during SASL 2949 negotiation is used to determine the canonical address for the 2950 initiating client or server according to the receiving server, as 2951 described under Section 3.5. 2953 7.2.7. Realms 2955 The receiving entity MAY include a realm when negotiating certain 2956 SASL mechanisms. If the receiving entity does not communicate a 2957 realm, the initiating entity MUST NOT assume that any realm exists. 2958 The realm MUST be used only for the purpose of authentication; in 2959 particular, an initiating entity MUST NOT attempt to derive an XMPP 2960 hostname from the realm information provided by the receiving entity. 2962 7.2.8. Round Trips 2964 [SASL] specifies that a using protocol such as XMPP can define two 2965 methods by which the protocol can save round trips where allowed for 2966 the SASL mechanism: 2968 1. When the SASL client (the XMPP "initiating entity") requests an 2969 authentication exchange, it can include "initial response" data 2970 with its request if appropriate for the SASL mechanism in use. 2971 In XMPP this is done by including the initial response as the XML 2972 character data of the element. 2973 2. At the end of the authentication exchange, the SASL server (the 2974 XMPP "receiving entity") can include "additional data with 2975 success" if appropriate for the SASL mechanism in use. In XMPP 2976 this is done by including the additional data as the XML 2977 character data of the element. 2979 For the sake of protocol efficiency, it is RECOMMENDED for XMPP 2980 clients and servers to use these methods, however they MUST support 2981 the less efficient modes as well. 2983 7.3. Process 2985 The process for SASL negotiation is as follows. 2987 7.3.1. Exchange of Stream Headers and Stream Features 2989 If SASL negotiation follows successful STARTTLS negotation 2990 (Section 6), then the SASL negotiation occurs over the encrypted 2991 stream that has already been negotiated. If not, the initiating 2992 entity resolves the hostname of the receiving entity as specified 2993 under Section 4, opens a TCP connection to the advertised port at the 2994 resolved IP address, and sends an initial stream header to the 2995 receiving entity; if the initiating entity is capable of STARTTLS 2996 negotiation, it MUST include the 'version' attribute set to a value 2997 of at least "1.0" in the initial stream header. 2999 I: 3007 The receiving entity MUST send a response stream header to the 3008 initiating entity; if the receiving entity is capable of SASL 3009 negotiation, it MUST include the 'version' attribute set to a value 3010 of at least "1.0" in the response stream header. 3012 R: element qualified by the 3025 'urn:ietf:params:xml:ns:xmpp-sasl' namespace. 3027 The element MUST contain one child element 3028 for each authentication mechanism the receiving entity offers to the 3029 initiating entity. The order of elements in the XML 3030 indicates the preference order of the SASL mechanisms according to 3031 the receiving entity; however the initiating entity MUST maintain its 3032 own preference order independent of the preference order of the 3033 receiving entity. 3035 R: 3036 3037 EXTERNAL 3038 PLAIN 3039 3040 3041 3043 If the receiving entity considers SASL negotiation to be 3044 discretionary, the element MUST contain an empty 3045 child element. 3047 R: 3048 3049 EXTERNAL 3050 PLAIN 3051 3052 3053 3055 If the receiving entity considers SASL negotiation to be mandatory, 3056 the element MUST contain an empty child 3057 element. 3059 R: 3060 3061 EXTERNAL 3062 PLAIN 3063 3064 3065 3067 7.3.2. Initiation 3069 In order to begin the SASL negotiation, the initiating entity sends 3070 an element qualified by the 3071 'urn:ietf:params:xml:ns:xmpp-sasl' namespace and includes an 3072 appropriate value for the 'mechanism' attribute. This element MAY 3073 contain XML character data (in SASL terminology, the "initial 3074 response") if the mechanism supports or requires it; if the 3075 initiating entity needs to send a zero-length initial response, it 3076 MUST transmit the response as a single equals sign character ("="), 3077 which indicates that the response is present but contains no data. 3079 I: UjBtMzBSMGNrcw== 3082 7.3.3. Challenge-Response Sequence 3084 If necessary, the receiving entity challenges the initiating entity 3085 by sending a element qualified by the 3086 'urn:ietf:params:xml:ns:xmpp-sasl' namespace; this element MAY 3087 contain XML character data (which MUST be generated in accordance 3088 with the definition of the SASL mechanism chosen by the initiating 3089 entity). 3091 The initiating entity responds to the challenge by sending a 3092 element qualified by the 3093 'urn:ietf:params:xml:ns:xmpp-sasl' namespace; this element MAY 3094 contain XML character data (which MUST be generated in accordance 3095 with the definition of the SASL mechanism chosen by the initiating 3096 entity). 3098 If necessary, the receiving entity sends more challenges and the 3099 initiating entity sends more responses. 3101 This series of challenge/response pairs continues until one of three 3102 things happens: 3104 o The initiating entity aborts the handshake. 3105 o The receiving entity reports failure of the handshake. 3106 o The receiving entity reports success of the handshake. 3108 These scenarios are described in the following sections. 3110 7.3.4. Abort 3112 The initiating entity aborts the handshake by sending an 3113 element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' 3114 namespace. 3116 I: 3118 Upon receiving an element, the receiving entity MUST return 3119 a element qualified by the 3120 'urn:ietf:params:xml:ns:xmpp-sasl' namespace and containing an 3121 child element. 3123 R: 3124 3125 3127 7.3.5. Failure 3129 The receiving entity reports failure of the handshake by sending a 3130 element qualified by the 3131 'urn:ietf:params:xml:ns:xmpp-sasl' namespace (the particular cause of 3132 failure MUST be communicated in an appropriate child element of the 3133 element as defined under Section 7.4). 3135 R: 3136 3137 3139 Where appropriate for the chosen SASL mechanism, the receiving entity 3140 SHOULD allow a configurable but reasonable number of retries (at 3141 least 2 and no more than 5); this enables the initiating entity 3142 (e.g., an end-user client) to tolerate incorrectly-provided 3143 credentials (e.g., a mistyped password) without being forced to 3144 reconnect. 3146 If the initiating entity attempts a reasonable number of retries with 3147 the same SASL mechanism and all attempts fail, it MAY fall back to 3148 the next mechanism in its ordered list by sending a new 3149 request to the receiving entity. If there are no remaining 3150 mechanisms in its list, the initiating entity SHOULD instead send an 3151 element to the receiving entity. 3153 If the initiating entity exceeds the number of retries, the receiving 3154 entity MUST return a stream error (which SHOULD be but MAY be ). 3157 7.3.6. Success 3159 The receiving entity reports success of the handshake by sending a 3160 element qualified by the 3161 'urn:ietf:params:xml:ns:xmpp-sasl' namespace; this element MAY 3162 contain XML character data (in SASL terminology, "additional data 3163 with success") if the chosen SASL mechanism supports or requires it; 3164 if the receiving entity needs to send additional data of zero length, 3165 it MUST transmit the data as a single equals sign character ("="). 3167 R: 3169 Note: The authorization identity communited during SASL 3170 negotiation is used to determine the canonical address for the 3171 initiating client or server according to the receiving server, as 3172 described under Section 3.5. 3174 Upon receiving the element, the initiating entity MUST 3175 initiate a new stream over the existing TCP connection by sending a 3176 new initial stream header to the receiving entity. 3178 I: tag 3187 before sending the new initial stream header, since the receiving 3188 entity and initiating entity MUST consider the original stream to 3189 be replaced upon sending or receiving the element. 3191 Upon receiving the new initial stream header from the initiating 3192 entity, the receiving entity MUST respond by sending a new response 3193 XML stream header to the initiating entity. 3195 R: 3204 The receiving entity MUST also send stream features, containing any 3205 further available features or containing no features (via an empty 3206 element). 3208 R: 3209 3210 3211 3212 3214 7.4. SASL Errors 3216 The syntax of SASL errors is as follows: 3218 3219 3220 [ 3221 OPTIONAL descriptive text 3222 ] 3223 3225 Where "defined-condition" is one of the SASL-related error conditions 3226 defined in the following sections. 3228 Inclusion of a defined condition is REQUIRED. 3230 Inclusion of the element is OPTIONAL, and can be used to 3231 provide application-specific information about the error condition, 3232 which information MAY be displayed to a human but only as a 3233 supplement to the defined condition. 3235 7.4.1. aborted 3237 The receiving entity acknowledges an element sent by the 3238 initiating entity; sent in reply to the element. 3240 I: 3242 R: 3243 3244 3246 7.4.2. account-disabled 3248 The account of the initiating entity has been temporarily disabled; 3249 sent in reply to an element (with or without initial response 3250 data) or a element. 3252 I: UjBtMzBSMGNrcw== 3255 R: 3256 3257 Call 212-555-1212 for assistance. 3258 3260 7.4.3. credentials-expired 3262 The authentication failed because the initiating entity provided 3263 credentials that have expired; sent in reply to a element 3264 or an element with initial response data. 3266 I: 3267 [ ... ] 3268 3270 R: 3271 3272 3274 7.4.4. encryption-required 3276 The mechanism requested by the initiating entity cannot be used 3277 unless the underlying stream is encrypted; sent in reply to an 3278 element (with or without initial response data). 3280 I: UjBtMzBSMGNrcw== 3283 R: 3284 3285 3287 7.4.5. incorrect-encoding 3289 The data provided by the initiating entity could not be processed 3290 because the [BASE64] encoding is incorrect (e.g., because the 3291 encoding does not adhere to the definition in Section 4 of [BASE64]); 3292 sent in reply to a element or an element with 3293 initial response data. 3295 I: [ ... ] 3298 R: 3299 3300 3302 7.4.6. invalid-authzid 3304 The authzid provided by the initiating entity is invalid, either 3305 because it is incorrectly formatted or because the initiating entity 3306 does not have permissions to authorize that ID; sent in reply to a 3307 element or an element with initial response data. 3309 I: 3310 [ ... ] 3311 3313 R: 3314 3315 3317 7.4.7. invalid-mechanism 3319 The initiating entity did not provide a mechanism or requested a 3320 mechanism that is not supported by the receiving entity; sent in 3321 reply to an element. 3323 I: 3326 R: 3327 3329 3331 7.4.8. malformed-request 3333 The request is malformed (e.g., the element includes initial 3334 response data but the mechanism does not allow that, or the data sent 3335 violates the syntax for the specified SASL mechanism); sent in reply 3336 to an , , , or element. 3338 (In the following example, the XML character data of the 3339 element contains more than 255 UTF-8-encoded Unicode characters and 3340 therefore violates the "token" production for the SASL ANONYMOUS 3341 mechanism as specified in [ANONYMOUS].) 3343 I: [ ... some-long-token ... ] 3346 R: 3347 3348 3350 7.4.9. mechanism-too-weak 3352 The mechanism requested by the initiating entity is weaker than 3353 server policy permits for that initiating entity; sent in reply to an 3354 element (with or without initial response data). 3356 I: UjBtMzBSMGNrcw== 3359 R: 3360 3361 3363 7.4.10. not-authorized 3365 The authentication failed because the initiating entity did not 3366 provide proper credentials or the receiving entity has detected an 3367 attack but wishes to disclose as little information as possible to 3368 the attacker; sent in reply to a element or an 3369 element with initial response data. 3371 I: 3372 [ ... ] 3373 3375 R: 3376 3378 3380 Note: This error condition includes but is not limited to the case 3381 of incorrect credentials or an unknown username. In order to 3382 discourage directory harvest attacks, no differentiation is made 3383 between incorrect credentials and an unknown username. 3385 7.4.11. temporary-auth-failure 3387 The authentication failed because of a temporary error condition 3388 within the receiving entity, and it is advisable for the initiating 3389 entity to try again later; sent in reply to an element or a 3390 element. 3392 I: 3393 [ ... ] 3394 3396 R: 3397 3398 3400 7.4.12. transition-needed 3402 The authentication failed because the mechanism cannot be used until 3403 the initiating entity provides (for one time only) a plaintext 3404 password so that the receiving entity can build a hashed password for 3405 use in future authentication attempts; sent in reply to an 3406 element with or without initial response data. 3408 I: [ ... ] 3411 R: 3412 3413 3415 Note: An XMPP client MUST treat a error with 3416 extreme caution, SHOULD NOT provide a plaintext password over an 3417 XML stream that is not encrypted via Transport Layer Security, and 3418 MUST warn a human user before allowing the user to provide a 3419 plaintext password over an unencrypted connection. 3421 7.5. SASL Definition 3423 The profiling requirements of [SASL] require that the following 3424 information be supplied by the definition of a using protocol. 3426 service name: "xmpp" 3427 initiation sequence: After the initiating entity provides an opening 3428 XML stream header and the receiving entity replies in kind, the 3429 receiving entity provides a list of acceptable authentication 3430 methods. The initiating entity chooses one method from the list 3431 and sends it to the receiving entity as the value of the 3432 'mechanism' attribute possessed by an element, optionally 3433 including an initial response to avoid a round trip. 3434 exchange sequence: Challenges and responses are carried through the 3435 exchange of elements from receiving entity to 3436 initiating entity and elements from initiating entity 3437 to receiving entity. The receiving entity reports failure by 3438 sending a element and success by sending a 3439 element; the initiating entity aborts the exchange by sending an 3440 element. Upon successful negotiation, both sides 3441 consider the original XML stream to be closed and new stream 3442 headers are sent by both entities. 3443 security layer negotiation: The security layer takes effect 3444 immediately after sending the closing '>' character of the 3445 element for the receiving entity, and immediately after 3446 receiving the closing '>' character of the element for 3447 the initiating entity. The order of layers is first [TCP], then 3448 [TLS], then [SASL], then XMPP. 3449 use of the authorization identity: The authorization identity can be 3450 used in XMPP to denote the non-default of a 3451 client or the sending of a server; an empty string is 3452 equivalent to an absent authorization identity. 3454 8. Resource Binding 3456 8.1. Overview 3458 After a client authenticates with a server, it MUST bind a specific 3459 resource to the stream so that the server can properly address the 3460 client (see Section 3). That is, there MUST be an XMPP resource 3461 identifier associated with the bare JID () of the 3462 client, so that the address for use over that stream is a full JID of 3463 the form . This ensures that the server 3464 can deliver XML stanzas to and receive XML stanzas from the client in 3465 relation to entities other than the server itself, as explained under 3466 Section 11 (the client could exchange stanzas with the server itself 3467 before binding a resource since the full JID is needed only for 3468 addressing outside the context of the stream negotiated between the 3469 client and the server, but this is not commonly done). 3471 After a client has bound a resource to the stream, it is referred to 3472 as a CONNECTED RESOURCE. A server SHOULD allow an entity to maintain 3473 multiple connected resources simultaneously, where each connected 3474 resource is associated with a distinct XML stream and differentiated 3475 from the other connected resources by a distinct resource identifier; 3476 however, a server MUST enable the administrator of an XMPP service to 3477 limit the number of connected resources in order to prevent certain 3478 denial of service attacks as described under Section 15.14. 3480 If, before completing the resource binding step, the client attempts 3481 to send an outbound XML stanza (i.e., a stanza not directed to the 3482 server itself or to the client's own account), the server MUST NOT 3483 process the stanza and MUST either ignore the stanza or return a 3484 stream error to the client. 3486 Support for resource binding is REQUIRED in XMPP client and server 3487 implementations. 3489 8.2. Advertising Support 3491 Upon sending a new response stream header to the client after 3492 successful SASL negotiation, the server MUST include a 3493 element qualified by the 'urn:ietf:params:xml:ns:xmpp-bind' namespace 3494 in the stream features it presents to the client; this 3495 element MUST include an empty element to explicitly 3496 indicate that it is mandatory for the client to complete resource 3497 binding at this stage of the stream negotiation process. 3499 Note: The server MUST NOT include the resource binding stream 3500 feature until after the client has authenticated, typically by 3501 means of successful SASL negotiation. 3503 S: 3512 S: 3513 3514 3515 3516 3518 Upon being so informed that resource binding is required, the client 3519 MUST bind a resource to the stream as described in the following 3520 sections. 3522 8.3. Generation of Resource Identifiers 3524 A resource identifier MUST at a minimum be unique among the connected 3525 resources for that . Enforcement of this policy is 3526 the responsibility of the server. 3528 A resource identifier can be security-critical. For example, if a 3529 malicious entity can guess a client's resource identifier then it 3530 might be able to determine if the client (and therefore the 3531 controlling principal) is online or offline, thus resulting in a 3532 presence leak as described under Section 15.15. To prevent that 3533 possibility, a client can either (1) generate a random resource 3534 identifier on its own or (2) ask the server to generate a resource 3535 identifier on its behalf, which MUST be random (see [RANDOM]). When 3536 generating a random resource identifier, it is RECOMMENDED that the 3537 resource identifier be a Universally Unique Identifier (UUID), for 3538 which the format specified in [UUID] is RECOMMENDED. 3540 8.4. Server-Generated Resource Identifier 3542 A server that supports resource binding MUST be able to generate an 3543 XMPP resource identifier on behalf of a client. 3545 8.4.1. Success Case 3547 A client requests a server-generated resource identifier by sending 3548 an IQ stanza of type "set" (see Section 9.2.3) containing an empty 3549 element qualified by the 'urn:ietf:params:xml:ns:xmpp-bind' 3550 namespace. 3552 C: 3553 3554 3556 Once the server has generated an XMPP resource identifier for the 3557 client, it MUST return an IQ stanza of type "result" to the client, 3558 which MUST include a child element that specifies the full JID 3559 for the connected resource as determined by the server. 3561 S: 3562 3563 3564 juliet@im.example.com/4db06f06-1ea4-11dc-aca3-000bcd821bfb 3565 3566 3567 3569 8.4.2. Error Cases 3571 When a client asks the server to generate a resource identifer during 3572 resource binding, the following stanza error conditions are possible: 3574 o The account has reached a limit on the number of simultaneous 3575 connected resources allowed. 3576 o The client is otherwise not allowed to bind a resource to the 3577 stream. 3579 8.4.2.1. Resource Constraint 3581 If the account has reached a limit on the number of simultaneous 3582 connected resources allowed, the server MUST return a error. 3585 S: 3586 3587 3589 3590 3592 8.4.2.2. Not Allowed 3594 If the client is otherwise not allowed to bind a resource to the 3595 stream, the server MUST return a error. 3597 S: 3598 3599 3601 3602 3604 8.5. Client-Submitted Resource Identifier 3606 Instead of asking the server to generate a resource identifier on its 3607 behalf, a client MAY attempt to submit a resource identifier that it 3608 has generated or that the controlling user has provided. 3610 8.5.1. Success Case 3612 A client asks its server to accept a client-submitted resource 3613 identifier by sending an IQ stanza of type "set" containing a 3614 element with a child element containing non-zero-length 3615 XML character data. 3617 C: 3618 3619 balcony 3620 3621 3623 The server SHOULD accept the client-submitted resource identifier. 3624 It does so by returning an IQ stanza of type "result" to the client, 3625 including a child element that specifies the full JID for the 3626 connected resource and contains without modification the client- 3627 submitted text. 3629 S: 3630 3631 juliet@im.example.com/balcony 3632 3633 3635 8.5.2. Error Cases 3637 When a client attempts to submit its own XMPP resource identifier 3638 during resource binding, the following stanza error conditions are 3639 possible in addition to those described under Section 8.4.2: 3641 o The provided resource identifier cannot be processed by the 3642 server, e.g. because it is not in accordance with the Resourceprep 3643 (Appendix B) profile of [STRINGPREP]). 3644 o The provided resource identifier is already in use. 3646 8.5.2.1. Bad Request 3648 If the provided resource identifier cannot be processed by the 3649 server, the server MAY return a error (but SHOULD 3650 instead apply the Resourceprep (Appendix B) profile of [STRINGPREP] 3651 or otherwise process the resource identifier so that it is in 3652 conformance). 3654 S: 3655 3656 3657 3658 3660 8.5.2.2. Conflict 3662 If there is already a connected resource of the same name, the server 3663 MUST do one of the following: 3665 1. Not accept the resource identifier provided by the client but 3666 instead override it with an XMPP resource identifier that the 3667 server generates. 3668 2. Terminate the current resource and allow the newly-requested 3669 resource. 3670 3. Disallow the newly-requested resource and maintain the current 3671 resource. 3673 Which of these the server does is up to the implementation, although 3674 it is RECOMMENDED to implement case #1. 3676 S: 3677 3678 3679 juliet@im.example.com/balcony 4db06f06-1ea4-11dc-aca3-000bcd821bfb 3680 3681 3682 3684 In case #2, the server MUST send a stream error to the 3685 current resource and return an IQ stanza of type "result" (indicating 3686 success) to the newly-requested resource. 3688 S: 3690 In case #3, the server MUST send a stanza error to the 3691 newly-requested resource but maintain the XML stream for that 3692 connection so that the newly-requested resource has an opportunity to 3693 negotiate a non-conflicting resource identifier before sending 3694 another request for resource binding. 3696 S: 3697 3698 3699 3700 3702 8.5.3. Retries 3704 If an error occurs when a client submits a resource identifier, the 3705 server SHOULD allow a configurable but reasonable number of retries 3706 (at least 2 and no more than 5); this enables the client to tolerate 3707 incorrectly-provided resource identifiers (e.g., bad data formats or 3708 duplicate text strings) without being forced to reconnect. 3710 After the client has reached the retry limit, the server MUST return 3711 a stream error to the client. 3713 9. XML Stanzas 3715 After a client has connected to a server or two servers have 3716 connected to each other, either party can send XML stanzas over the 3717 negotiated stream. Three kinds of XML stanza are defined for the 3718 'jabber:client' and 'jabber:server' namespaces: , 3719 , and . In addition, there are five common 3720 attributes for these stanza types. These common attributes, as well 3721 as the basic semantics of the three stanza types, are defined herein; 3722 more detailed information regarding the syntax of XML stanzas for 3723 instant messaging and presence applications is provided in [XMPP-IM], 3724 and for other applications in the relevant XMPP extension 3725 specifications. 3727 A server MUST NOT process a partial stanza and MUST NOT attach 3728 meaning to the transmission timing of any part of a stanza (before 3729 receipt of the close tag). 3731 Support for the XML stanza syntax and semantics defined herein is 3732 REQUIRED in XMPP client and server implementations. 3734 9.1. Common Attributes 3736 The following five attributes are common to message, presence, and IQ 3737 stanzas. 3739 9.1.1. to 3741 The 'to' attribute specifies the JID of the intended recipient for 3742 the stanza. 3744 3745 Art thou not Romeo, and a Montague? 3746 3748 For information about server processing of inbound and outbound XML 3749 stanzas based on the nature of the 'to' address, refer to Section 11. 3751 9.1.1.1. Client-to-Server Streams 3753 The following rules apply to inclusion of the 'to' attribute in the 3754 context of XML streams qualified by the 'jabber:client' namespace 3755 (i.e., client-to-server streams). 3757 1. A stanza with a specific intended recipient MUST possess a 'to' 3758 attribute whose value is an XMPP address. 3760 2. A stanza sent from a client to a server for direct processing by 3761 the server on behalf of the client (e.g., presence sent to the 3762 server for broadcasting to other entities) MUST NOT possess a 3763 'to' attribute. 3765 9.1.1.2. Server-to-Server Streams 3767 The following rules apply to inclusion of the 'to' attribute in the 3768 context of XML streams qualified by the 'jabber:server' namespace 3769 (i.e., server-to-server streams). 3771 1. A stanza MUST possess a 'to' attribute whose value is an XMPP 3772 address; if a server receives a stanza that does not meet this 3773 restriction, it MUST generate an stream 3774 error. 3775 2. The domain identifier portion of the JID in the 'to' atttribute 3776 MUST match a hostname serviced by the receiving server; if a 3777 server receives a stanza that does not meet this restriction, it 3778 MUST generate a or stream error. 3780 9.1.2. from 3782 The 'from' attribute specifies the JID of the sender. 3784 3786 Art thou not Romeo, and a Montague? 3787 3789 9.1.2.1. Client-to-Server Streams 3791 The following rules apply to the 'from' attribute in the context of 3792 XML streams qualified by the 'jabber:client' namespace (i.e., client- 3793 to-server streams). 3795 1. When the server receives an XML stanza from a client and the 3796 stanza does not include a 'from' attribute, the server MUST add a 3797 'from' attribute to the stanza, where the value of the 'from' 3798 attribute is the full JID () 3799 determined by the server for the connected resource that 3800 generated the stanza (see Section 3.5), or the bare JID 3801 () in the case of subscription-related presence 3802 stanzas (see [XMPP-IM]). 3803 2. When the server receives an XML stanza from a client and the 3804 stanza includes a 'from' attribute, the server MUST either (a) 3805 validate that the value of the 'from' attribute provided by the 3806 client is that of a connected resource for the associated entity 3807 or (b) override the provided 'from' attribute by adding a 'from' 3808 attribute as specified under Rule #1. 3809 3. When the server generates a stanza from the server for delivery 3810 to the client on behalf of the account of the connected client 3811 (e.g., in the context of data storage services provided by the 3812 server on behalf of the client), the stanza MUST either (a) not 3813 include a 'from' attribute or (b) include a 'from' attribute 3814 whose value is the account's bare JID (). 3815 4. When the server generates a stanza from the server itself for 3816 delivery to the client, the stanza MUST include a 'from' 3817 attribute whose value is the bare JID (i.e., ) of the 3818 server. 3819 5. A server MUST NOT send to the client a stanza without a 'from' 3820 attribute if the stanza was not generated by the server (e.g., if 3821 it was generated by another client or another server); therefore, 3822 when a client receives a stanza that does not include a 'from' 3823 attribute, it MUST assume that the stanza is from the server to 3824 which the client is connected. 3826 9.1.2.2. Server-to-Server Streams 3828 The following rules apply to the 'from' attribute in the context of 3829 XML streams qualified by the 'jabber:server' namespace (i.e., server- 3830 to-server streams). 3832 1. A stanza MUST possess a 'from' attribute whose value is an XMPP 3833 address; if a server receives a stanza that does not meet this 3834 restriction, it MUST generate an stream 3835 error. 3836 2. The domain identifier portion of the JID contained in the 'from' 3837 attribute MUST match the hostname of the sending server (or any 3838 validated domain thereof) as communicated in the SASL negotiation 3839 (see Section 7), server dialback (see [XEP-0220], or similar 3840 means; if a server receives a stanza that does not meet this 3841 restriction, it MUST generate an stream error. 3843 Enforcement of these rules helps to prevent certain denial of service 3844 attacks as described under Section 15.14. 3846 9.1.3. id 3848 The 'id' attribute is used by the entity that generates a stanza 3849 ("the originating entity") to track any response or error stanza that 3850 it might receive in relation to the generated stanza from another 3851 entity (such as an intermediate server or the intended recipient). 3853 It is up to the originating entity whether the value of the 'id' 3854 attribute will be unique only within its current stream (session) or 3855 unique globally. 3857 For and stanzas, it is RECOMMENDED for the 3858 originating entity to include an 'id' attribute; for stanzas, 3859 it is REQUIRED. 3861 If the generated stanza includes an 'id' attribute then it is 3862 REQUIRED for the response or error stanza to also include an 'id' 3863 attribute, where the value of the 'id' attribute MUST match that of 3864 the generated stanza. 3866 Note: The semantics of IQ stanzas impose additional restrictions; see 3867 Section 9.2.3. 3869 9.1.4. type 3871 The 'type' attribute specifies the purpose or context of the message, 3872 presence, or IQ stanza. The particular allowable values for the 3873 'type' attribute vary depending on whether the stanza is a message, 3874 presence, or IQ stanza. The defined values for message and presence 3875 stanzas are specific to instant messaging and presence applications 3876 and therefore are specified in [XMPP-IM], whereas the values for IQ 3877 stanzas specify the role of an IQ stanza in a structured request- 3878 response exchange and therefore are specified under Section 9.2.3. 3879 The only 'type' value common to all three stanzas is "error"; see 3880 Section 9.3. 3882 9.1.5. xml:lang 3884 A stanza SHOULD possess an 'xml:lang' attribute (as defined in 3885 Section 2.12 of [XML]) if the stanza contains XML character data that 3886 is intended to be presented to a human user (as explained in 3887 [CHARSET], "internationalization is for humans"). The value of the 3888 'xml:lang' attribute specifies the default language of any such 3889 human-readable XML character data. 3891 3892 dnd 3893 Wooing Juliet 3894 3896 The value of the 'xml:lang' attribute MAY be overridden by the 'xml: 3897 lang' attribute of a specific child element. 3899 3900 dnd 3901 Wooing Juliet 3902 Dvořím se Julii 3903 3910 dnd 3911 Wooing Juliet 3912 3914 S: 3917 dnd 3918 Wooing Juliet 3919 3921 If an inbound stanza received received by a client or server does not 3922 possess an 'xml:lang' attribute, an implementation MUST assume that 3923 the default language is that specified for the stream as defined 3924 under Section 5.3.4. 3926 The value of the 'xml:lang' attribute MUST conform to the NMTOKEN 3927 datatype (as defined in Section 2.3 of [XML]) and MUST conform to the 3928 format defined in [LANGTAGS]. 3930 A server MUST NOT modify or delete 'xml:lang' attributes on stanzas 3931 it receives from other entities. 3933 9.2. Basic Semantics 3935 9.2.1. Message Semantics 3937 The stanza can be seen as a "push" mechanism whereby one 3938 entity pushes information to another entity, similar to the 3939 communications that occur in a system such as email. All message 3940 stanzas SHOULD possess a 'to' attribute that specifies the intended 3941 recipient of the message; upon receiving such a stanza, a server 3942 SHOULD route or deliver it to the intended recipient (see Section 11 3943 for general routing and delivery rules related to XML stanzas). 3945 9.2.2. Presence Semantics 3947 The stanza can be seen as a specialized broadcast or 3948 "publish-subscribe" mechanism, whereby multiple entities receive 3949 information (in this case, network availability information) about an 3950 entity to which they have subscribed. In general, a publishing 3951 entity (client) SHOULD send a presence stanza with no 'to' attribute, 3952 in which case the server to which the entity is connected SHOULD 3953 broadcast that stanza to all subscribed entities. However, a 3954 publishing entity MAY also send a presence stanza with a 'to' 3955 attribute, in which case the server SHOULD route or deliver that 3956 stanza to the intended recipient. See Section 11 for general routing 3957 and delivery rules related to XML stanzas, and [XMPP-IM] for rules 3958 specific to presence applications. 3960 9.2.3. IQ Semantics 3962 Info/Query, or IQ, is a request-response mechanism, similar in some 3963 ways to the Hypertext Transfer Protocol [HTTP]. The semantics of IQ 3964 enable an entity to make a request of, and receive a response from, 3965 another entity. The data content of the request and response is 3966 defined by the schema or other structural definition associated with 3967 the XML namespace that qualifies the direct child element of the IQ 3968 element (see Section 9.4), and the interaction is tracked by the 3969 requesting entity through use of the 'id' attribute. Thus, IQ 3970 interactions follow a common pattern of structured data exchange such 3971 as get/result or set/result (although an error can be returned in 3972 reply to a request if appropriate): 3974 Requesting Responding 3975 Entity Entity 3976 ---------- ---------- 3977 | | 3978 | | 3979 | [ ... payload ... ] | 3980 | | 3981 | -------------------------> | 3982 | | 3983 | | 3984 | [ ... payload ... ] | 3985 | | 3986 | <------------------------- | 3987 | | 3988 | | 3989 | [ ... payload ... ] | 3990 | | 3991 | -------------------------> | 3992 | | 3993 | | 3994 | [ ... condition ... ] | 3995 | | 3996 | <------------------------- | 3997 | | 3999 To enforce these semantics, the following rules apply: 4001 1. The 'id' attribute is REQUIRED for IQ stanzas. 4002 2. The 'type' attribute is REQUIRED for IQ stanzas. The value MUST 4003 be one of the following (if the value is other than one of the 4004 following strings, the recipient or an intermediate router MUST 4005 return a stanza error of ): 4006 * get -- The stanza requests information, inquires about what 4007 data is needed in order to complete further operations, etc. 4008 * set -- The stanza provides data that is needed for an 4009 operation to be completed, sets new values, replaces existing 4010 values, etc. 4011 * result -- The stanza is a response to a successful get or set 4012 request. 4013 * error -- The stanza reports an error that has occurred 4014 regarding processing or delivery of a previously-sent get or 4015 set request (see Section 9.3). 4016 3. An entity that receives an IQ request of type "get" or "set" MUST 4017 reply with an IQ response of type "result" or "error". The 4018 response MUST preserve the 'id' attribute of the request. 4019 4. An entity that receives a stanza of type "result" or "error" MUST 4020 NOT respond to the stanza by sending a further IQ response of 4021 type "result" or "error"; however, the requesting entity MAY send 4022 another request (e.g., an IQ of type "set" to provide required 4023 information discovered through a get/result pair). 4024 5. An IQ stanza of type "get" or "set" MUST contain exactly one 4025 child element, which specifies the semantics of the particular 4026 request. 4027 6. An IQ stanza of type "result" MUST include zero or one child 4028 elements. 4029 7. An IQ stanza of type "error" MAY include the child element 4030 contained in the associated "get" or "set" and MUST include an 4031 child; for details, see Section 9.3. 4033 9.3. Stanza Errors 4035 Stanza-related errors are handled in a manner similar to stream 4036 errors (Section 5.8). Unlike stream errors, stanza errors are 4037 recoverable; therefore they do not result in termination of the XML 4038 stream and underlying TCP connection. Instead, the entity that 4039 discovers the error condition returns an ERROR STANZA to the sender, 4040 i.e., a stanza of the same kind (message, presence, or IQ) whose 4041 'type' attribute is set to a value of "error" and which contains an 4042 child element that specifies the error condition. The 4043 specified error condition provides a hint regarding actions that the 4044 sender can take to remedy the error if possible. 4046 9.3.1. Rules 4048 The following rules apply to stanza errors: 4050 1. The receiving or processing entity that detects an error 4051 condition in relation to a stanza SHOULD return an error stanza 4052 (and MUST do so for IQ stanzas). 4053 2. The entity that generates an error stanza MAY include the 4054 original XML sent so that the sender can inspect and, if 4055 necessary, correct the XML before attempting to resend. 4056 3. An error stanza MUST contain an child element. 4057 4. An child MUST NOT be included if the 'type' attribute 4058 has a value other than "error" (or if there is no 'type' 4059 attribute). 4060 5. An entity that receives an error stanza MUST NOT respond to the 4061 stanza with a further error stanza; this helps to prevent 4062 looping. 4064 9.3.2. Syntax 4066 The syntax for stanza-related errors is: 4068 4069 [OPTIONAL to include sender XML here] 4070 4071 4072 [ 4074 OPTIONAL descriptive text 4075 ] 4076 [OPTIONAL application-specific condition element] 4077 4078 4080 The "stanza-kind" MUST be one of message, presence, or iq. 4082 The "error-type MUST be one of the following: 4084 o auth -- retry after providing credentials 4085 o cancel -- do not retry (the error cannot be remedied) 4086 o continue -- proceed (the condition was only a warning) 4087 o modify -- retry after changing the data sent 4088 o wait -- retry after waiting (the error is temporary) 4090 The element: 4092 o MUST contain a child element corresponding to one of the stanza 4093 error conditions defined under Section 9.3.3; this element MUST be 4094 qualified by the 'urn:ietf:params:xml:ns:xmpp-stanzas' namespace. 4095 o MAY contain a child element containing XML character data 4096 that describes the error in more detail; this element MUST be 4097 qualified by the 'urn:ietf:params:xml:ns:xmpp-stanzas' namespace 4098 and SHOULD possess an 'xml:lang' attribute specifying the natural 4099 language of the XML character data. 4100 o MAY contain a child element for an application-specific error 4101 condition; this element MUST be qualified by an application- 4102 specific namespace that defines the syntax and semantics of the 4103 element. 4105 The element is OPTIONAL. If included, it MUST be used only 4106 to provide descriptive or diagnostic information that supplements the 4107 meaning of a defined condition or application-specific condition. It 4108 MUST NOT be interpreted programmatically by an application. It MUST 4109 NOT be used as the error message presented to a human user, but MAY 4110 be shown in addition to the error message associated with the defined 4111 condition element (and, optionally, the application-specific 4112 condition element). 4114 9.3.3. Defined Conditions 4116 The following conditions are defined for use in stanza errors. 4118 9.3.3.1. bad-request 4120 The sender has sent a stanza containing XML that does not conform to 4121 the appropriate schema or that cannot be processed (e.g., an IQ 4122 stanza that includes an unrecognized value of the 'type' attribute, 4123 or an element that is qualified by a recognized namespace but that 4124 violates the defined syntax for the element); the associated error 4125 type SHOULD be "modify". 4127 C: 4131 4132 4134 S: 4138 4139 4140 4141 4143 9.3.3.2. conflict 4145 Access cannot be granted because an existing resource exists with the 4146 same name or address; the associated error type SHOULD be "cancel". 4148 C: 4149 4150 balcony 4151 4152 4154 S: 4155 4156 4157 4158 4160 9.3.3.3. feature-not-implemented 4162 The feature represented in the XML stanza is not implemented by the 4163 intended recipient or an intermediate server and therefore the stanza 4164 cannot be processed (e.g., the entity understands the namespace but 4165 does not recognize the element name); the associated error type 4166 SHOULD be "cancel" or "modify". 4168 C: 4172 4173 4174 4175 4177 E: 4181 4182 4184 4187 4188 4190 9.3.3.4. forbidden 4192 The requesting entity does not possess the required permissions to 4193 perform the action; the associated error type SHOULD be "auth". 4195 C: 4198 4199 4201 E: 4205 4206 4207 4208 4210 9.3.3.5. gone 4212 The recipient or server can no longer be contacted at this address, 4213 typically on a permanent basis; the associated error type SHOULD be 4214 "cancel" or "modify" and the error stanza SHOULD include a new 4215 address as the XML character data of the element (which MUST 4216 be a URI or IRI at which the entity can be contacted, typically an 4217 XMPP IRI as specified in [XMPP-URI]). 4219 C: 4222 4223 4225 E: 4229 4230 4231 xmpp:conference.example.com 4232 4233 4234 4236 9.3.3.6. internal-server-error 4238 The server could not process the stanza because of a misconfiguration 4239 or an otherwise-undefined internal server error; the associated error 4240 type SHOULD be "wait" or "cancel". 4242 C: 4245 4246 4248 E: 4252 4253 4255 4256 4258 9.3.3.7. item-not-found 4260 The addressed JID or item requested cannot be found; the associated 4261 error type SHOULD be "cancel" or "modify". 4263 C: 4266 S: 4269 4270 4271 4272 4274 Note: An application MUST NOT return this error if doing so would 4275 provide information about the intended recipient's network 4276 availability to an entity that is not authorized to know such 4277 information; instead it MUST return a 4278 error. 4280 9.3.3.8. jid-malformed 4282 The sending entity has provided or communicated an XMPP address 4283 (e.g., a value of the 'to' attribute) or aspect thereof (e.g., an 4284 XMPP resource identifier) that does not adhere to the syntax defined 4285 under Section 3; the associated error type SHOULD be "modify". 4287 C: 4290 4291 4293 E: 4297 4298 4300 4301 4303 9.3.3.9. not-acceptable 4305 The recipient or server understands the request but is refusing to 4306 process it because it does not meet criteria defined by the recipient 4307 or server (e.g., a local policy regarding stanza size limits or 4308 acceptable words in messages); the associated error type SHOULD be 4309 "modify". 4311 C: 4312 [ ... the-emacs-manual ... ] 4313 4315 S: 4316 4317 4319 4320 4322 9.3.3.10. not-allowed 4324 The recipient or server does not allow any entity to perform the 4325 action (e.g., sending to entities at a blacklisted domain); the 4326 associated error type SHOULD be "cancel". 4328 C: 4331 4332 4334 E: 4338 4339 4340 4341 4343 9.3.3.11. not-authorized 4345 The sender needs to provide proper credentials before being allowed 4346 to perform the action, or has provided improper credentials; the 4347 associated error type SHOULD be "auth". 4349 C: 4352 4353 4355 E: 4358 4359 4360 4361 4363 9.3.3.12. not-modified 4365 The item requested has not changed since it was last requested; the 4366 associated error type SHOULD be "continue". 4368 C: 4371 4372 4373
4374 some-long-opaque-string 4375
4376 4377 4378 4380 S: 4383 4384 4385
4386 some-long-opaque-string 4387
4388 4389 4390 4391 4392 4393 4395 9.3.3.13. payment-required 4397 The requesting entity is not authorized to access the requested 4398 service because payment is required; the associated error type SHOULD 4399 be "auth". 4401 C: 4405 4406 4407 4408 4410 E: 4414 4415 4417 4418 4420 9.3.3.14. policy-violation 4422 The entity has violated some local service policy (e.g., the stanza 4423 exceeds a configured size limit); the server MAY choose to specify 4424 the policy in the element or in an application-specific 4425 condition element; the associated error type SHOULD be "modify" or 4426 "wait" depending on the policy being violated. 4428 (In the following example, the client sends an XMPP message that is 4429 too large according to the server's local service policy.) 4431 C: 4432 [ ... the-emacs-manual ... ] 4433 4435 S: 4436 4437 4439 4440 4442 9.3.3.15. recipient-unavailable 4444 The intended recipient is temporarily unavailable; the associated 4445 error type SHOULD be "wait". 4447 C: 4450 4451 4453 E: 4456 4457 4459 4460 4462 Note: An application MUST NOT return this error if doing so would 4463 provide information about the intended recipient's network 4464 availability to an entity that is not authorized to know such 4465 information; instead it MUST return a 4466 error. 4468 9.3.3.16. redirect 4470 The recipient or server is redirecting requests for this information 4471 to another entity, typically in a temporary fashion (the 4472 condition is used for permanent addressing failures); the associated 4473 error type SHOULD be "modify" and the error stanza SHOULD contain the 4474 alternate address in the XML character data of the 4475 element (which MUST be a URI or IRI at which the entity can be 4476 contacted, typically an XMPP IRI as specified in [XMPP-URI]). 4478 C: 4481 4482 4484 E: 4488 4489 4490 xmpp:characters@conference.example.org 4491 4492 4493 4495 9.3.3.17. registration-required 4497 The requesting entity is not authorized to access the requested 4498 service because prior registration is required; the associated error 4499 type SHOULD be "auth". 4501 C: 4504 4505 4507 E: 4510 4511 4513 4514 4516 9.3.3.18. remote-server-not-found 4518 A remote server or service specified as part or all of the JID of the 4519 intended recipient does not exist; the associated error type SHOULD 4520 be "cancel". 4522 C: 4525 4526 4528 E: 4531 4532 4534 4535 4537 9.3.3.19. remote-server-timeout 4539 A remote server or service specified as part or all of the JID of the 4540 intended recipient (or required to fulfill a request) could not be 4541 contacted within a reasonable amount of time; the associated error 4542 type SHOULD be "wait". 4544 C: 4547 4548 4550 E: 4553 4554 4556 4557 4559 9.3.3.20. resource-constraint 4561 The server or recipient lacks the system resources necessary to 4562 service the request; the associated error type SHOULD be "wait" or 4563 "modify". 4565 C: 4569 4570 4571 4572 4574 E: 4578 4579 4581 4582 4584 9.3.3.21. service-unavailable 4586 The server or recipient does not currently provide the requested 4587 service; the associated error type SHOULD be "cancel". 4589 C: 4591 Hello? 4592 4594 S: 4596 4597 4599 4600 4602 An application MUST return a error instead of 4603 or if sending one of the 4604 latter errors would provide information about the intended 4605 recipient's network availability to an entity that is not authorized 4606 to know such information. 4608 9.3.3.22. subscription-required 4610 The requesting entity is not authorized to access the requested 4611 service because a prior subscription is required; the associated 4612 error type SHOULD be "auth". 4614 C: help 4618 4620 E: 4624 4625 4627 4628 4630 9.3.3.23. undefined-condition 4632 The error condition is not one of those defined by the other 4633 conditions in this list; any error type can be associated with this 4634 condition, and it SHOULD be used only in conjunction with an 4635 application-specific condition. 4637 C: 4641 My lord, dispatch; read o'er these articles. 4642 4643 4646 4648 S: 4652 4656 4659 4660 4661 4663 4664 4667 4668 4669 4671 9.3.3.24. unexpected-request 4673 The recipient or server understood the request but was not expecting 4674 it at this time (e.g., the request was out of order); the associated 4675 error type SHOULD be "wait" or "modify". 4677 C: 4681 4682 4685 4686 4688 E: 4692 4693 4695 4697 4698 4700 9.3.4. Application-Specific Conditions 4702 As noted, an application MAY provide application-specific stanza 4703 error information by including a properly-namespaced child in the 4704 error element. The application-specific element SHOULD supplement or 4705 further qualify a defined element. Thus, the element will 4706 contain two or three child elements. 4708 4709 4710 4711 4712 4713 4714 4715 4716 4718 4720 [ ... application-specific information ... ] 4721 4722 4723 4724 4726 An entity that receives an application-specific error condition it 4727 does not understand MUST ignore the condition. 4729 9.4. Extended Content 4731 While the message, presence, and IQ stanzas provide basic semantics 4732 for messaging, availability, and request-response interactions, XMPP 4733 uses XML namespaces (see [XML-NAMES] to extend the basic stanza 4734 syntax for the purpose of providing additional functionality. 4736 A message or presence stanza MAY contain one or more optional child 4737 elements specifying content that extends the meaning of the message 4738 (e.g., an XHTML-formatted version of the message body as described in 4739 [XEP-0071]), and an IQ stanza of type "get" or "set" MUST contain one 4740 such child element. Such a child element MAY have any name and MUST 4741 possess a namespace declaration (other than "jabber:client", "jabber: 4742 server", or "http://etherx.jabber.org/streams") that defines all data 4743 contained within the child element. Such a child element is called 4744 an "extension element". 4746 Similarly, "extension attributes" are allowed. That is: a stanza 4747 itself (i.e., the , , and elements 4748 qualified by the "jabber:client" or "jabber:server" namespace 4749 declared as the default namespace for the stream) and any child 4750 element of such a stanza (whether a child element qualifed by the 4751 default namespace or an extension element) MAY also include one or 4752 more attributes that are qualified by XML namespaces other than the 4753 default namespace or the reserved "xml" prefix (including the "empty 4754 namespace" if the attribute is not prefixed). For the sake of 4755 backward compatibility and maximum interoperability, an entity that 4756 generates a stanza SHOULD NOT include such attributes in the stanza 4757 itself or in child elements of the stanza that are qualified by the 4758 default namespace (e.g., the message element). 4760 An extension element or extension attribute is said to be EXTENDED 4761 CONTENT and the namespace name for such an element or attribute is 4762 said to be an EXTENDED NAMESPACE. 4764 Because an XML stanza is the primary unit of meaning in XMPP, any 4765 prefixed element or attribute included in a stanza MUST use a prefix 4766 that is declared in the stanza itself or a child element of the 4767 stanza, not outside the context of the stanza (e.g., not on the 4768 stream header). 4770 Routing entities (typically servers) SHOULD try to maintain prefixes 4771 when serializing XML stanzas for processing, but receiving entities 4772 MUST NOT rely on the prefix strings having any particular value. 4774 Support for any given extended namespace is OPTIONAL on the part of 4775 any implementation. If an entity does not understand such a 4776 namespace, the entity's expected behavior depends on whether the 4777 entity is (1) the recipient or (2) an entity that is routing the 4778 stanza to the recipient. 4780 Recipient: If a recipient receives a stanza that contains a child 4781 element it does not understand, it MUST silently ignore that 4782 particular XML data, i.e., it MUST NOT process it or present it to 4783 a user or associated application (if any). In particular: 4784 * If an entity receives a message or presence stanza that 4785 contains XML data qualified by a namespace it does not 4786 understand, the portion of the stanza that qualified by the 4787 unknown namespace MUST be ignored. 4788 * If an entity receives a message stanza whose only child element 4789 is qualified by a namespace it does not understand, it MUST 4790 ignore the entire stanza. 4791 * If an entity receives an IQ stanza of type "get" or "set" 4792 containing a child element qualified by a namespace it does not 4793 understand, the entity MUST return an IQ stanza of type "error" 4794 with an error condition of . 4795 Router: If a routing entity (typically a server) handles a stanza 4796 that contains a child element it does not understand, it MUST 4797 ignore the associated XML data by routing or delivering it 4798 untouched to the recipient. 4800 9.5. Stanza Size 4802 XMPP is optimized for the exchange of relatively large numbers of 4803 relatively small stanzas. A client or server MAY enforce a maximum 4804 stanza size. The maximum stanza size MUST NOT be smaller than 10000 4805 bytes, from the opening "<" character to the closing ">" character. 4806 If an entity receives a stanza that exceeds its maximum stanza size, 4807 it MUST return a stanza error or a stream error. 4810 10. Examples 4812 10.1. Client-to-Server 4814 The following examples show the XMPP data flow for a client 4815 negotiating an XML stream with a server, exchanging XML stanzas, and 4816 closing the negotiated stream. The server is "im.example.com", the 4817 server requires use of TLS, the client authenticates via the SASL 4818 PLAIN mechanism as "juliet@im.example.com", and the client binds a 4819 client-submitted resource to the stream. It is assumed that before 4820 sending the initial stream header, the client has already resolved an 4821 SRV record of _xmpp-client._tcp.im.example.com and has opened a TCP 4822 connection to the advertised port at the resolved IP address. 4824 Note: The alternate steps shown are provided only to illustrate 4825 the protocol for failure cases; they are not exhaustive and would 4826 not necessarily be triggered by the data sent in the examples. 4828 10.1.1. TLS 4830 Step 1: Client initiates stream to server: 4832 C: 4840 Step 2: Server responds by sending a response stream header to 4841 client: 4843 S: 4856 4857 4858 4859 4861 Step 4: Client sends STARTTLS command to server: 4863 C: 4865 Step 5: Server informs client that it is allowed to proceed: 4867 S: 4869 Step 5 (alt): Server informs client that STARTTLS negotiation has 4870 failed and closes both XML stream and TCP connection: 4872 S: 4874 S: 4876 Step 6: Client and server attempt to complete TLS negotiation over 4877 the existing TCP connection (see [TLS] for details). 4879 Step 7: If TLS negotiation is successful, client initiates a new 4880 stream to server: 4882 C: 4890 Step 7 (alt): If TLS negotiation is unsuccessful, server closes TCP 4891 connection. 4893 10.1.2. SASL 4895 Step 8: Server responds by sending a stream header to client along 4896 with any available stream features: 4898 S: 4908 4909 DIGEST-MD5 4910 PLAIN 4911 4912 4913 4915 Step 9: Client selects an authentication mechanism, in this case 4916 [PLAIN]: 4918 C: UjBtMzBSMGNrcw== 4921 Step 10: Server informs client of success: 4923 S: 4925 Step 10 (alt): Server returns error to client: 4927 S: 4928 4929 4931 Step 11: Client initiates a new stream to server: 4933 C: 4955 S: 4956 4957 4958 4959 4961 Upon being so informed that resource binding is mandatory, the client 4962 needs to bind a resource to the stream; here we assume that the 4963 client submits a human-readable text string. 4965 Step 13: Client binds a resource: 4967 C: 4968 4969 balcony 4970 4971 4973 Step 14: Server accepts submitted resource identifier and informs 4974 client of successful resource binding: 4976 S: 4977 4978 4979 juliet@im.example.com/balcony 4980 4981 4982 4984 10.1.4. Stanza Exchange 4986 Now the client is allowed to send XML stanzas over the negotiated 4987 stream. 4989 C: 4992 Art thou not Romeo, and a Montague? 4993 4995 If necessary, sender's server negotiates XML streams with intended 4996 recipient's server (see Section 10.2). 4998 The intended recipient replies and the message is delivered to the 4999 client. 5001 E: 5004 Neither, fair saint, if either thee dislike. 5005 5007 The client can subsequently send and receive an unbounded number of 5008 subsequent XML stanzas over the stream. 5010 10.1.5. Close 5012 Desiring to send no further messages, the client closes the stream. 5014 C: 5016 Consistent with the recommended stream closing handshake, the server 5017 closes the stream as well: 5019 S: 5021 Client now terminates the underlying TCP connection. 5023 10.2. Server-to-Server Examples 5025 The following examples show the data flow for a server negotiating an 5026 XML stream with another server, exchanging XML stanzas, and closing 5027 the negotiated stream. The initiating server ("Server1") is 5028 im.example.com; the receiving server ("Server2") is example.net and 5029 it requires use of TLS; im.example.com presents a certificate and 5030 authenticates via the SASL EXTERNAL mechanism. It is assumed that 5031 before sending the initial stream header, Server1 has already 5032 resolved an SRV record of _xmpp-server._tcp.example.net and has 5033 opened a TCP connection to the advertised port at the resolved IP 5034 address. 5036 Note: The alternate steps shown are provided only to illustrate 5037 the protocol for failure cases; they are not exhaustive and would 5038 not necessarily be triggered by the data sent in the examples. 5040 10.2.1. TLS 5042 Step 1: Server1 initiates stream to Server2: 5044 S1: 5051 Step 2: Server2 responds by sending a response stream header to 5052 Server1: 5054 S2: 5062 Step 3: Server2 sends stream features to Server1: 5064 S2: 5065 5066 5067 5068 5070 Step 4: Server1 sends the STARTTLS command to Server2: 5072 S1: 5074 Step 5: Server2 informs Server1 that it is allowed to proceed: 5076 S2: 5078 Step 5 (alt): Server2 informs Server1 that STARTTLS negotiation has 5079 failed and closes stream: 5081 S2: 5083 S2: 5084 Step 6: Server1 and Server2 attempt to complete TLS negotiation via 5085 TCP (see [TLS] for details). 5087 Step 7: If TLS negotiation is successful, Server1 initiates a new 5088 stream to Server2: 5090 S1: 5097 Step 7 (alt): If TLS negotiation is unsuccessful, Server2 closes TCP 5098 connection. 5100 10.2.2. SASL 5102 Step 8: Server2 sends a response stream header to Server1 along with 5103 available stream features (including a preference for the SASL 5104 EXTERNAL mechanism): 5106 S2: 5114 S2: 5115 5116 EXTERNAL 5117 5118 5119 5121 Step 9: Server1 selects the EXTERNAL mechanism, in this case with an 5122 authorization identity encoded according to [BASE64]: 5124 S1: eG1wcC5leGFtcGxlLmNvbQ 5127 The decoded authorization identity is "im.example.com". 5129 Step 10: Server2 determines that the authorization identity provided 5130 by Server1 matches the information in the presented certificate and 5131 therefore returns success: 5133 S2: 5135 Step 10 (alt): Server2 informs Server1 of failed authentication: 5137 S2: 5138 5139 5141 S2: 5143 Step 11: Server1 initiates a new stream to Server2: 5145 S1: 5152 Step 12: Server2 responds by sending a stream header to Server1 along 5153 with any additional features (or, in this case, an empty features 5154 element): 5156 S2: 5164 S2: 5166 10.2.3. Stanza Exchange 5168 Now Server1 is allowed to send XML stanzas to Server2 over the 5169 negotiated stream; here we assume that the transferred stanzas are 5170 those shown earlier for client-to-server communication, albeit over a 5171 server-to-server stream qualified by the 'jabber:server' namespace. 5173 Server1 sends XML stanza to Server2: 5175 S1: 5178 Art thou not Romeo, and a Montague? 5179 5181 The intended recipient replies and the message is delivered from 5182 Server2 to Server1. 5184 Server2 sends XML stanza to Server1: 5186 S2: 5189 Neither, fair saint, if either thee dislike. 5190 5192 10.2.4. Close 5194 Desiring to send no further messages, Server1 closes the stream. (In 5195 practice, the stream would most likely remain open for some time, 5196 since Server1 and Server2 do not immediately know if the stream will 5197 be needed for further communication.) 5199 S1: 5201 Consistent with the recommended stream closing handshake, Server2 5202 closes the stream as well: 5204 S2: 5206 Server1 now terminates the underlying TCP connection. 5208 11. Server Rules for Processing XML Stanzas 5210 An XMPP server MUST ensure in-order processing of XML stanzas between 5211 any two entities. This includes stanzas sent by a client to its 5212 server for direct processing by the server (e.g., in-order processing 5213 of a roster get and initial presence as described in [XMPP-IM]). 5215 Beyond the requirement for in-order processing, each server 5216 implementation will contain its own logic for processing stanzas it 5217 receives. Such logic determines whether the server needs to ROUTE a 5218 given stanza to another domain, DELIVER it to a local entity 5219 (typically a connected client associated with a local account), or 5220 HANDLE it directly within the server itself. The following rules 5221 apply. 5223 Note: Particular XMPP applications MAY specify delivery rules that 5224 modify or supplement the following rules; for example, a set of 5225 delivery rules for instant messaging and presence applications is 5226 defined in [XMPP-IM]. 5228 11.1. No 'to' Address 5230 11.1.1. Overview 5232 If the stanza possesses no 'to' attribute, the server MUST handle it 5233 directly on behalf of the entity that sent it, where the meaning of 5234 "handle it directly" depends on whether the stanza is message, 5235 presence, or IQ. Because all stanzas received from other servers 5236 MUST possess a 'to' attribute, this rule applies only to stanzas 5237 received from a local entity (such as a client) that is connected to 5238 the server. 5240 11.1.2. Message 5242 If the server receives a message stanza with no 'to' attribute, it 5243 MUST treat the message as if the 'to' address were the bare JID 5244 of the sending entity. 5246 11.1.3. Presence 5248 If the server receives a presence stanza with no 'to' attribute, it 5249 MUST broadcast it to the entities that are subscribed to the sending 5250 entity's presence, if applicable ([XMPP-IM] defines the semantics of 5251 such broadcasting for presence applications). 5253 11.1.4. IQ 5255 If the server receives an IQ stanza with no 'to' attribute, it MUST 5256 process the stanza on behalf of the account from which received the 5257 stanza, as follows: 5259 1. If the IQ stanza is of type "get" or "set" and the server 5260 understands the namespace that qualifies the payload, the server 5261 MUST handle the stanza on behalf of the sending entity or return 5262 an appropriate error to the sending entity. While the meaning of 5263 "handle" is determined by the semantics of the qualifying 5264 namespace, in general the server shall respond to the IQ stanza 5265 of type "get" or "set" by returning an appropriate IQ stanza of 5266 type "result" or "error", responding as if the server were the 5267 bare JID of the sending entity. As an example, if the sending 5268 entity sends an IQ stanza of type "get" where the payload is 5269 qualified by the 'jabber:iq:roster' namespace (as described in 5270 [XMPP-IM]), then the server shall return the roster associated 5271 with the sending entity's bare JID to the particular resource of 5272 the sending entity that requested the roster. 5273 2. If the IQ stanza is of type "get" or "set" and the server does 5274 not understand the namespace that qualifies the payload, the 5275 server MUST return an error to the sending entity, which MUST be 5276 . 5277 3. If the IQ stanza is of type "error" or "result", the server MUST 5278 handle the error or result as appropriate for the request- 5279 response interaction, responding as if the server were the bare 5280 JID of the sending entity. 5282 11.2. Local Domain 5284 If the hostname of the domain identifier portion of the JID contained 5285 in the 'to' attribute matches one of the configured hostnames of the 5286 server itself, the server MUST first determine if the hostname is 5287 serviced by the server or by a specialized local service. If the 5288 latter, the server MUST route the stanza to that service. If the 5289 former, the server MUST proceed as follows. 5291 11.2.1. Mere Domain 5293 If the JID contained in the 'to' attribute is of the form , 5294 then the server MUST either handle the stanza as appropriate for the 5295 stanza kind or return an error stanza to the sender. 5297 11.2.2. Domain with Resource 5299 If the JID contained in the 'to' attribute is of the form , then the server MUST either handle the stanza as 5301 appropriate for the stanza kind or return an error stanza to the 5302 sender. 5304 11.2.3. Localpart at Domain 5306 Note: For addresses of this type, more detailed rules in the 5307 context of instant messaging and presence applications are 5308 provided in [XMPP-IM]. 5310 11.2.3.1. No Such User 5312 If there is no local account associated with the , 5313 how the stanza shall be processed depends on the stanza type. 5315 o For a message stanza, the server MUST return a stanza error to the sender. 5317 o For a presence stanza, the server SHOULD silently discard the 5318 stanza. 5319 o For an IQ stanza, the server MUST return a 5320 stanza error to the sender. 5322 11.2.3.2. Bare JID 5324 If the JID contained in the 'to' attribute is of the form 5325 , how the stanza shall be processed depends on the 5326 stanza type. 5328 o For a message stanza, if there exists at least one connected 5329 resource for the account the server SHOULD deliver it to at least 5330 one of the connected resources. If there exists no connected 5331 resource, the server MUST either return an error or store the 5332 message offline for delivery when the account next has a connected 5333 resource. 5334 o For a presence stanza, if there exists at least one connected 5335 resource for the account the server SHOULD deliver it to at least 5336 one of the connected resources. If there exists no connected 5337 resource, the server MUST silently discard the stanza. 5338 o For an IQ stanza, the server MUST handle it directly on behalf of 5339 the intended recipient. 5341 11.2.3.3. Full JID 5343 If the JID contained in the 'to' attribute is of the form 5344 and there is no connected resource that 5345 exactly matches the full JID, the stanza shall be processed as if the 5346 JID were of the form . 5348 If the JID contained in the 'to' attribute is of the form 5349 and there is a connected resource that 5350 exactly matches the full JID, the server SHOULD deliver the stanza to 5351 that connected resource. 5353 11.3. Remote Domain 5355 If the hostname of the domain identifier portion of the JID contained 5356 in the 'to' attribute does not match one of the configured hostnames 5357 of the server itself, the server SHOULD attempt to route the stanza 5358 to the remote domain (subject to local service provisioning and 5359 security policies regarding inter-domain communication, since such 5360 communication is optional for any given deployment). There are two 5361 possible cases. 5363 11.3.1. Existing Stream 5365 If a server-to-server stream already exists between the two domains, 5366 the sender's server shall attempt to route the stanza to the 5367 authoritative server for the remote domain over the existing stream. 5369 11.3.2. No Existing Stream 5371 If there exists no server-to-server stream between the two domains, 5372 the sender's server shall proceed as follows: 5374 1. Resolve the hostname of the remote domain (as defined under 5375 Section 15.4). 5376 2. Negotiate a server-to-server stream between the two domains (as 5377 defined under Section 6 and Section 7). 5378 3. Route the stanza to the authoritative server for the remote 5379 domain over the newly-established stream. 5381 11.3.3. Error Handling 5383 If routing of a stanza to the intended recipient's server is 5384 unsuccessful, the sender's server MUST return an error to the sender. 5385 If resolution of the remote domain is unsuccessful, the stanza error 5386 MUST be . If resolution succeeds but 5387 streams cannot be negotiated, the stanza error MUST be . 5390 If stream negotiation with the intended recipient's server is 5391 successful but the remote server cannot deliver the stanza to the 5392 recipient, the remote server shall return an appropriate error to the 5393 sender by way of the sender's server. 5395 12. XML Usage 5397 12.1. Restrictions 5399 The Extensible Messaging and Presence Protocol (XMPP) defines a class 5400 of data objects called XML streams as well as the behavior of 5401 computer programs that process XML streams. XMPP is an application 5402 profile or restricted form of the Extensible Markup Language [XML], 5403 and a complete XML stream (including start and end stream tags) is a 5404 conforming XML document. 5406 However, XMPP does not deal with XML documents but with XML streams. 5407 Because XMPP does not require the parsing of arbitrary and complete 5408 XML documents, there is no requirement that XMPP needs to support the 5409 full feature set of [XML]. In particular, the following features of 5410 XML are prohibited in XMPP: 5412 o comments (as defined in Section 2.5 of [XML]) 5413 o processing instructions (Section 2.6 therein) 5414 o internal or external DTD subsets (Section 2.8 therein) 5415 o internal or external entity references (Section 4.2 therein) with 5416 the exception of predefined entities (Section 4.6 therein) 5418 An XMPP implementation MUST behave as follows with regard to these 5419 features: 5421 1. An XMPP implementation MUST NOT inject characters matching such 5422 features into an XML stream. 5423 2. If an XMPP implementation receives characters matching such 5424 features over an XML stream, it MUST return a stream error, which 5425 SHOULD be but MAY be . 5427 12.2. XML Namespace Names and Prefixes 5429 XML namespaces (see [XML-NAMES]) are used within XMPP streams to 5430 create strict boundaries of data ownership. The basic function of 5431 namespaces is to separate different vocabularies of XML elements that 5432 are structurally mixed together. Ensuring that XMPP streams are 5433 namespace-aware enables any allowable XML to be structurally mixed 5434 with any data element within XMPP. XMPP-specific rules for XML 5435 namespace names and prefixes are defined in the following 5436 subsections. 5438 12.2.1. Streams Namespace 5440 A streams namespace declaration is REQUIRED in all XML stream headers 5441 and the name of the streams namespace MUST be 5442 'http://etherx.jabber.org/streams'. If this rule is violated, the 5443 entity that receives the offending stream header MUST return a stream 5444 error to the sending entity, which SHOULD be but 5445 MAY be . 5447 The element names of the element and its and 5448 children MUST be qualified by the streams namespace prefix 5449 in all instances. If this rule is violated, the entity that receives 5450 the offending element MUST return a stream error to the sending 5451 entity, which SHOULD be . 5453 An implementation SHOULD generate only the 'stream:' prefix for these 5454 elements, and for historical reasons MAY accept only the 'stream:' 5455 prefix. If an entity receives a stream header with a streams 5456 namespace prefix it does not accept, it MUST return a stream error to 5457 the sending entity, which SHOULD be but MAY 5458 be . 5460 12.2.2. Default Namespace 5462 A default namespace declaration is REQUIRED and defines the allowable 5463 first-level children of the root stream element. This namespace 5464 declaration MUST be the same for the initial stream and the response 5465 stream so that both streams are qualified consistently. The default 5466 namespace declaration applies to the stream and all first-level child 5467 element sent within a stream unless explicitly qualified by the 5468 streams namespace or another namespace. 5470 A server implementation MUST support the following two default 5471 namespaces: 5473 o jabber:client -- this default namespace is declared when the 5474 stream is used for communication between a client and a server 5475 o jabber:server -- this default namespace is declared when the 5476 stream is used for communication between two servers 5478 A client implementation MUST support the 'jabber:client' default 5479 namespace. 5481 If an implementation accepts a stream that is qualified by the 5482 'jabber:client' or 'jabber:server' namespace, it MUST support the 5483 common attributes (Section 9.1) and basic semantics (Section 9.2) of 5484 all three core stanza types (message, presence, and IQ). 5486 For historical reasons, an implementation MAY refuse to support any 5487 other default namespaces. If an entity receives a stream header with 5488 a default namespace it does not support, it MUST return an stream error. 5491 An implementation MUST NOT generate namespace prefixes for elements 5492 qualified by the default namespace if the default namespace is 5493 'jabber:client' or 'jabber:server'. 5495 Note: The 'jabber:client' and 'jabber:server' namespaces are 5496 nearly identical but are used in different contexts (client-to- 5497 server communication for 'jabber:client' and server-to-server 5498 communication for 'jabber:server'). The only difference between 5499 the two is that the 'to' and 'from' attributes are OPTIONAL on 5500 stanzas sent over XML streams qualified by the 'jabber:client' 5501 namespace, whereas they are REQUIRED on stanzas sent over XML 5502 streams qualified by the 'jabber:server' namespace. 5504 An implementation MAY support a default namespace other than "jabber: 5505 client" or "jabber:server". However, because such namespaces would 5506 define applications other than XMPP, they are to be defined in 5507 separate specifications. 5509 12.2.3. Extended Namespaces 5511 An EXTENDED NAMESPACE is an XML namespace that qualifies extended 5512 content as defined under Section 9.4. For example, in the following 5513 stanza, the extended namespace is 'jabber:iq:roster': 5515 5518 5519 5521 An XML stanza MAY contain XML data qualified by more than one 5522 extended namespace, either at the direct child level of the stanza 5523 (for presence and message stanzas) or in any mix of levels (for all 5524 stanzas). 5526 5527 5530 5531 sha1-hash-of-image 5532 5533 5535 5536 Hello? 5537 5538 5539

Hello? 5540 5541 5542 5544 5547 5548 5549

some-long-opaque-string
5550 5551 5552 5554 An implementation SHOULD NOT generate namespace prefixes for elements 5555 qualified by content (as opposed to stream) namespaces other than the 5556 default namespace. However, if included, the namespace declarations 5557 for those prefixes MUST be included on the stanza root or a child 5558 thereof, not at the level of the stream element (this helps to ensure 5559 that any such namespace declaration is routed and delivered with the 5560 stanza, instead of assumed from the stream). 5562 12.3. Well-Formedness 5564 There are two varieties of well-formedness: 5566 o "XML-well-formedness" in accordance with the definition of "well- 5567 formed" in Section 2.1 of [XML]. 5568 o "Namespace-well-formedness" in accordance with the definition of 5569 "namespace-well-formed" in Section 7 of [XML-NAMES]. 5571 The following rules apply. 5573 An XMPP entity MUST NOT generate data that is not XML-well-formed. 5574 An XMPP entity MUST NOT accept data that is not XML-well-formed; 5575 instead it MUST return an stream error and 5576 close the stream over which the data was received. 5578 An XMPP entity MUST NOT generate data that is not namespace-well- 5579 formed. An XMPP server SHOULD NOT route or deliver data that is not 5580 namespace-well-formed, and SHOULD return a stanza error of or a stream error of in response 5582 to the receipt of such data. 5584 Note: Because these restrictions were underspecified in an earlier 5585 revision of this specification, it is possible that 5586 implementations based on that revision will send data that does 5587 not comply with the restrictions; an entity SHOULD be liberal in 5588 accepting such data. 5590 12.4. Validation 5592 A server is not responsible for ensuring that XML data delivered to a 5593 client or routed to another server is valid, in accordance with the 5594 definition of "valid" provided in Section 2.8 of [XML]. An 5595 implementation MAY choose to accept or provide only validated data, 5596 but such behavior is OPTIONAL. A client SHOULD NOT rely on the 5597 ability to send data that does not conform to the schemas, and SHOULD 5598 ignore any non-conformant elements or attributes on the incoming XML 5599 stream. 5601 Note: The terms "valid" and "well-formed" are distinct in XML. 5603 12.5. Inclusion of XML Declaration 5605 Before sending a stream header, an implementation SHOULD send an XML 5606 declaration (matching production [23] content of [XML]). 5607 Applications MUST follow the rules provided in [XML] regarding the 5608 format of the XML declaration and the circumstances under which the 5609 XML declaration is included. 5611 12.6. Character Encoding 5613 Implementations MUST support the UTF-8 transformation of Universal 5614 Character Set [UCS2] characters, as required by [CHARSET] and defined 5615 in [UTF-8]. Implementations MUST NOT attempt to use any other 5616 encoding. If one party to an XML stream detects that the other party 5617 has attempted to send XML data with an encoding other than UTF-8, it 5618 MUST return a stream error, which SHOULD be 5619 but MAY be . 5621 Note: Because it is mandatory for an XMPP implementation to support 5622 all and only the UTF-8 encoding and because UTF-8 always has the same 5623 byte order, an implementation MUST NOT send a byte order mark ("BOM") 5624 at the beginning of the data stream. If an entity receives the 5625 Unicode character U+FEFF anywhere in an XML stream (including as the 5626 first character of the stream), it MUST interpret that character as a 5627 zero width no-break space, not as a byte order mark. 5629 12.7. Whitespace 5631 Except where explicitly disallowed (e.g., during TLS negotiation 5632 (Section 6) and SASL negotiation (Section 7)), either entity MAY send 5633 whitespace within the root stream element as separators between XML 5634 stanzas or between any other first-level elements sent over the 5635 stream. One common use for sending such whitespace is explained 5636 under Section 5.7.3. 5638 12.8. XML Versions 5640 XMPP is an application profile of XML 1.0. A future version of XMPP 5641 might be defined in terms of higher versions of XML, but this 5642 specification addresses XML 1.0 only. 5644 13. Compliance Requirements 5646 This section summarizes the specific aspects of the Extensible 5647 Messaging and Presence Protocol that MUST be supported by servers and 5648 clients in order to be considered compliant implementations, as well 5649 as additional protocol aspects that SHOULD be supported. For 5650 compliance purposes, we draw a distinction between core protocols 5651 (which MUST be supported by any server or client, regardless of the 5652 specific application) and instant messaging and presence protocols 5653 (which MUST be supported only by instant messaging and presence 5654 applications built on top of the core protocols). Compliance 5655 requirements that apply to all servers and clients are specified in 5656 this section; compliance requirements for instant messaging and 5657 presence applications are specified in the corresponding section of 5658 [XMPP-IM]. 5660 13.1. Servers 5662 A server MUST support the following core protocols in order to be 5663 considered compliant: 5665 o Conformance with [IDNA] for domain identifiers, the Nodeprep 5666 (Appendix A) profile of [STRINGPREP] for localparts, and the 5667 Resourceprep (Appendix B) profile of [STRINGPREP] for resource 5668 identifiers, as well as enforcement thereof for clients that 5669 authenticate with the server 5670 o XML streams (Section 5), including TLS negotiation (Section 6), 5671 SASL negotiation (Section 7), stream features (Section 5.5), and 5672 Resource Binding (Section 8) 5673 o The basic semantics of the three defined stanza types (i.e., 5674 , , and ) 5675 o Generation (and, where appropriate, handling) of error syntax and 5676 semantics related to streams, TLS, SASL, and XML stanzas 5678 For backward compatibility with the large deployed base of XMPP 5679 servers, server developers are advised to implement the server 5680 dialback protocol first specified in [RFC3920] and now documented in 5681 [XEP-0220], since that protocol is widely used for weak identity 5682 verification of peer servers in the absence of domain certificates. 5684 13.2. Clients 5686 A client MUST support the following core protocols in order to be 5687 considered compliant: 5689 o XML streams (Section 5), including TLS negotiation (Section 6), 5690 SASL negotiation (Section 7), stream features (Section 5.5), and 5691 Resource Binding (Section 8) 5692 o The basic semantics of the three defined stanza types (i.e., 5693 , , and ) 5695 o Handling (and, where appropriate, generation) of error syntax and 5696 semantics related to streams, TLS, SASL, and XML stanzas 5698 In addition, a client SHOULD support the following core protocols: 5700 o Conformance with [IDNA] for domain identifiers, the Nodeprep 5701 (Appendix A) profile of [STRINGPREP] for localparts, and the 5702 Resourceprep (Appendix B) profile of [STRINGPREP] for resource 5703 identifiers. 5705 14. Internationalization Considerations 5707 As specified under Section 12.6, XML streams MUST be encoded in 5708 UTF-8. 5710 As specified under Section 5.3, an XML stream SHOULD include an 'xml: 5711 lang' attribute specifying the default language for any XML character 5712 data that is intended to be presented to a human user. As specified 5713 under Section 9.1.5, an XML stanza SHOULD include an 'xml:lang' 5714 attribute if the stanza contains XML character data that is intended 5715 to be presented to a human user. A server SHOULD apply the default 5716 'xml:lang' attribute to stanzas it routes or delivers on behalf of 5717 connected entities, and MUST NOT modify or delete 'xml:lang' 5718 attributes on stanzas it receives from other entities. 5720 As specified under Section 3, a server MUST support and enforce 5721 [IDNA] for domain identifiers, the Nodeprep (Appendix A) profile of 5722 [STRINGPREP] for localparts, and the Resourceprep (Appendix B) 5723 profile of [STRINGPREP] for resource identifiers; this enables XMPP 5724 addresses to include a wide variety of Unicode characters outside the 5725 US-ASCII range. 5727 15. Security Considerations 5729 15.1. High Security 5731 For the purposes of XMPP communication (client-to-server and server- 5732 to-server), the term "high security" refers to the use of security 5733 technologies that provide both mutual authentication and integrity 5734 checking; in particular, when using certificate-based authentication 5735 to provide high security, a trust chain SHOULD be established out-of- 5736 band, although a shared certification authority signing certificates 5737 could allow a previously unknown certificate to establish trust in- 5738 band. See Section 15.2 regarding certificate validation procedures. 5740 Implementations MUST support high security. Service provisioning 5741 SHOULD use high security, subject to local security policies. 5743 15.2. Certificates 5745 Channel encryption of an XML stream using Transport Layer Security as 5746 described under Section 6, and in some cases also authentication as 5747 described under Section 7, is commonly based on a digital certificate 5748 presented by the receiving entity (or, in the case of mutual 5749 authentication, both the receiving entity and the initiating entity). 5750 This section describes best practices regarding the generation of 5751 digital certificates to be presented by XMPP entities and the 5752 verification of digital certificates presented by XMPP entities. 5754 For both client and server certificates, a certificate MUST conform 5755 to the format defined in [X509]. Considerations specific to client 5756 certificates or server certificates are described in the following 5757 sections. 5759 15.2.1. Certificate Generation 5761 15.2.1.1. Server Certificates 5763 In a digital certificate to be presented by an XMPP server (i.e., a 5764 SERVER CERTIFICATE), it is RECOMMENDED for the certificate to include 5765 one or more JIDs (i.e., domain identifiers) associated with domains 5766 serviced at the server. The representations described in the 5767 following sections are RECOMMENDED. These representations are 5768 provided in preference order. 5770 15.2.1.1.1. SRVName 5772 A server's domain identifier SHOULD be represented as an SRVName, 5773 i.e., as an otherName field of type "id-on-dnsSRV" as specified in 5774 [X509-SRV]. 5776 15.2.1.1.2. dNSName 5778 A server's domain identifier SHOULD be represented as a dNSName, 5779 i.e., as a subjectAltName extension of type dNSName. 5781 The dNSName MAY contain the wildcard character '*'. The wildcard 5782 character applies only to the left-most domain name component and 5783 matches any single component (thus a dNSName of *.example.com matches 5784 foo.example.com but not bar.foo.example.com or example.com itself). 5785 The wildcard character is not allowed in component fragments (thus a 5786 dNSName of im*.example.net is not allowed and shall not be taken to 5787 match im1.example.net and im2.example.net). 5789 15.2.1.1.3. XmppAddr 5791 A server's domain identifier MAY be represented as an XmppAddr, i.e., 5792 as a UTF8String within an otherName entity inside the subjectAltName, 5793 using the [ASN.1] Object Identifier "id-on-xmppAddr" specified under 5794 Section 15.2.1.3. In server certificates, this representation is 5795 included only for the sake of backward-compatibility. 5797 15.2.1.1.4. Common Name 5799 A server's domain identifier SHOULD NOT be represented as a Common 5800 Name; instead, the Common Name field SHOULD be reserved for 5801 representation of a human-friendly name. 5803 15.2.1.1.5. Examples 5805 For our first (relatively simple) example, consider a company called 5806 "Example Products, Inc." It hosts an XMPP service at 5807 "im.example.com" (i.e., user addresses at the service are of the form 5808 "user@im.example.com"), and SRV lookups for the xmpp-client and xmpp- 5809 server services at "im.example.com" yield one machine, called 5810 "x.example.com", as follows: 5812 _xmpp-client._tcp.im.example.com. 400 IN SRV 20 0 5222 x.example.com 5813 _xmpp-server._tcp.im.example.com. 400 IN SRV 20 0 5269 x.example.com 5815 The certificate presented by x.example.com contains the following 5816 representations: 5818 o An otherName type of SRVName (id-on-dnsSRV) containing an 5819 IA5String (ASCII) string of: "_xmpp-client.im.example.com" 5820 o An otherName type of SRVName (id-on-dnsSRV) containing an 5821 IA5String (ASCII) string of: "_xmpp-server.im.example.com" 5822 o A dNSName containing an ASCII string of "im.example.com" 5823 o An otherName type of XmppAddr (id-on-xmppAddr) containing a UTF-8 5824 string of: "im.example.com" 5825 o A CN containing an ASCII string of "Example Products, Inc." 5827 For our second (more complex) example, consider an ISP called 5828 "Example Internet Services". It hosts an XMPP service at 5829 "example.net" (i.e., user addresses at the service are of the form 5830 "user@example.net"), but SRV lookups for the xmpp-client and xmpp- 5831 server services at "example.net" yield two machines ("x1.example.net" 5832 and "x2.example.net"), as follows: 5834 _xmpp-client._tcp.example.net. 68400 IN SRV 20 0 5222 x1.example.net. 5835 _xmpp-client._tcp.example.net. 68400 IN SRV 20 0 5222 x2.example.net. 5836 _xmpp-server._tcp.example.net. 68400 IN SRV 20 0 5269 x1.example.net. 5838 _xmpp-server._tcp.example.net. 68400 IN SRV 20 0 5269 x2.example.net. 5840 Example Internet Services also hosts chatrooms at chat.example.net, 5841 and provides an xmpp-server SRV record for that service as well (thus 5842 enabling entity from remote domains to access that service). It also 5843 might provide other such services in the future, so it wishes to 5844 represent a wildcard in its certificate to handle such growth. 5846 The certificate presented by either x1.example.net or x2.example.net 5847 contains the following representations: 5849 o An otherName type of SRVName (id-on-dnsSRV) containing an 5850 IA5String (ASCII) string of: "_xmpp-client.example.net" 5851 o An otherName type of SRVName (id-on-dnsSRV) containing an 5852 IA5String (ASCII) string of: "_xmpp-server.example.net" 5853 o An otherName type of SRVName (id-on-dnsSRV) containing an 5854 IA5String (ASCII) string of: "_xmpp-server.chat.example.net" 5855 o A dNSName containing an ASCII string of "example.net" 5856 o A dNSName containing an ASCII string of "*.example.net" 5857 o An otherName type of XmppAddr (id-on-xmppAddr) containing a UTF-8 5858 string of: "example.net" 5859 o An otherName type of XmppAddr (id-on-xmppAddr) containing a UTF-8 5860 string of: "chat.example.net" 5861 o A CN containing an ASCII string of "Example Internet Services" 5863 15.2.1.2. Client Certificates 5865 In a digital certificate to be presented by an XMPP client controlled 5866 by a human user (i.e., a CLIENT CERTIFICATE), it is RECOMMENDED for 5867 the certificate to include one or more JIDs associated with an XMPP 5868 user. If included, a JID MUST be represented as an XmppAddr, i.e., 5869 as a UTF8String within an otherName entity inside the subjectAltName, 5870 using the [ASN.1] Object Identifier "id-on-xmppAddr" specified under 5871 Section 15.2.1.3. 5873 15.2.1.3. ASN.1 Object Identifier 5875 The [ASN.1] Object Identifier "id-on-xmppAddr" (also called an 5876 XmppAddr) is defined as follows. 5878 id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 5879 dod(6) internet(1) security(5) mechanisms(5) pkix(7) } 5881 id-on OBJECT IDENTIFIER ::= { id-pkix 8 } -- other name forms 5883 id-on-xmppAddr OBJECT IDENTIFIER ::= { id-on 5 } 5885 XmppAddr ::= UTF8String 5886 As an alternative to the "id-on-xmppAddr" notation, this Object 5887 Identifier MAY be represented in dotted display format (i.e., 5888 "1.3.6.1.5.5.7.8.5") or in the Uniform Resource Name notation 5889 specified in [URN-OID] (i.e., "urn:oid:1.3.6.1.5.5.7.8.5"). 5891 Thus for example the JID "juliet@im.example.com" as included in a 5892 certificate could be formatted in any of the following three ways: 5894 id-on-xmppAddr: 5895 subjectAltName=otherName:id-on-xmppAddr;UTF8:juliet@im.example.com 5896 dotted display format: subjectAltName=otherName: 5897 1.3.6.1.5.5.7.8.5;UTF8:juliet@im.example.com 5898 URN notation: subjectAltName=otherName:urn:oid: 5899 1.3.6.1.5.5.7.8.5;UTF8:juliet@im.example.com 5901 Use of the "id-on-xmppAddr" format is RECOMMENDED in the generation 5902 of certificates, but all three formats MUST be supported for the 5903 purpose of certificate validation. 5905 The "id-on-xmppAddr" object identifier MAY be used on conjuction with 5906 the extended key usage extension specified in Section 4.2.1.12 of 5907 [X509] in order to explicitly define and limit the intended use of a 5908 certificate to the XMPP network. 5910 15.2.2. Certificate Validation 5912 When an XMPP entity is presented with a server certificate or client 5913 certificate by a peer for the purpose of encryption or authentication 5914 of XML streams as described under Section 6 and Section 7, the entity 5915 MUST validate the certificate to determine if the certificate shall 5916 be considered a TRUSTED CERTIFICATE, i.e., a certificate that is 5917 acceptable for encryption and/or authentication in accordance with 5918 the XMPP entity's local service policies or configured settings. 5920 For both server certificates and client certificates, the validating 5921 entity MUST verify the integrity of the certificate, MUST verify that 5922 the certificate has been properly signed by the issuing Certificate 5923 Authority, and MUST support certificate revocation messages. An 5924 implementation MUST enable a human user to view information about the 5925 full chain of certificates. 5927 The following sections describe certificate validation rules for 5928 server-to-server and client-to-server streams. 5930 15.2.2.1. Server Certificates 5932 When an entity (client or server) validates a certificate presented 5933 by an XMPP server, there are three possible cases, as discussed in 5934 the following sections. 5936 15.2.2.1.1. Case #1 5938 If the server certificate appears to be certified by a chain of 5939 certificates terminating in a trust anchor (as described in Section 5940 6.1 of [X509]), the entity MUST check the certificate for any 5941 instances of the SRVName, dNSName, and XmppAddr (in that order of 5942 preference) as described under Section 15.2.1.1.1, 5943 Section 15.2.1.1.2, and Section 15.2.1.1.3. There are three possible 5944 sub-cases: 5946 Sub-Case #1: The entity finds at least one SRVName, dNSName, or 5947 XmppAddr that matches the hostname to which it attempted to 5948 connect; the entity MUST use this represented domain identifier as 5949 the validated identity of the XMPP server. The server certificate 5950 MUST be checked against the hostname as provided by the entity 5951 (client or server), not the hostname as resolved via the Domain 5952 Name System; e.g., if a user specifies a hostname of "example.net" 5953 but a [DNS-SRV] lookup returns "x1.example.net", the certificate 5954 MUST be checked as "example.net". A user-oriented client MAY 5955 provide a configuration setting that enables a human user to 5956 explicitly specify a hostname to be checked for connection 5957 purposes. 5958 Sub-Case #2: The entity finds no SRVName, dNSName, or XmppAddr that 5959 matches the hostname to which it attempted to connect and a human 5960 user has not permanently accepted the certificate during a 5961 previous connection attempt; the entity MUST NOT use the 5962 represented domain identifier (if any) as the validated identity 5963 of the XMPP server. Instead, if the connecting entity is a user- 5964 oriented client then it MUST either (1) automatically terminate 5965 the connection with a bad certificate error or (2) show the 5966 certificate (including the entire certificate chain) to the user 5967 and give the user the choice of terminating the connecting or 5968 accepting the certificate temporarily (i.e., for this connection 5969 attempt only) or permanently (i.e., for all future connection 5970 attempts) and then continuing with the connection; if a user 5971 permanently accepts a certificate in this way, the client MUST 5972 cache the certificate (or some non-forgeable representation such 5973 as a hash value) and in future connection attempts behave as in 5974 Sub-Case #3. (It is the resposibility of the human user to verify 5975 the hash value or fingerprint of the certificate with the peer 5976 over a trusted communication layer.) If the connecting entity is 5977 an XMPP server or an automated client, the application SHOULD 5978 terminate the connection (with a bad certificate error) and log 5979 the error to an appropriate audit log; an XMPP server or automated 5980 client MAY provide a configuration setting that disables this 5981 check, but MUST provide a setting that enables the check. 5983 Sub-Case #3: The entity finds no SRVName, dNSName, or XmppAddr that 5984 matches the hostname to which it attempted to connect but a human 5985 user has permanently accepted the certificate during a previous 5986 connection attempt; the entity MUST verify that the cached 5987 certificate was presented and MUST notify the user if the 5988 certificate has changed. 5990 15.2.2.1.2. Case #2 5992 If the server certificate is certified by a Certificate Authority not 5993 known to the entity, the entity MUST proceed as under Case #1, Sub- 5994 Case #2 or Case #1, Sub-Case #3 as appropriate. 5996 15.2.2.1.3. Case #3 5998 If the server certificate is self-signed, the entity MUST proceed as 5999 under Case #1, Sub-Case #2 or Case #1, Sub-Case #3 as appropriate. 6001 15.2.2.2. Client Certificates 6003 When an XMPP server validates a certificate presented by a client, 6004 there are three possible cases, as discussed in the following 6005 sections. 6007 15.2.2.2.1. Case #1 6009 If the client certificate appears to be certified by a chain of 6010 certificates terminating in a trust anchor (as described in Section 6011 6.1 of [X509]), the server MUST check the certificate for any 6012 instances of the XmppAddr as described under Section 15.2.1.3. There 6013 are three possible sub-cases: 6015 Sub-Case #1: The server finds one XmppAddr for which the domain 6016 identifier portion of the represented JID matches one of the 6017 configured hostnames of the server itself; the server SHOULD use 6018 this represented JID as the validated identity of the client. 6019 Sub-Case #2: The server finds more than one XmppAddr for which the 6020 domain identifier portion of the represented JID matches one of 6021 the configured hostnames of the server itself; the server SHOULD 6022 use one of these represented JIDs as the validated identity of the 6023 client, choosing among them according to local service policies or 6024 based on the 'to' address of the initial stream header. 6025 Sub-Case #3: The server finds no XmppAddrs, or finds at least one 6026 XmppAddr but the domain identifier portion of the represented JID 6027 does not match one of the configured hostnames of the server 6028 itself; the server MUST NOT use the represented JID (if any) as 6029 the validated identity of the client but instead MUST either 6030 validate the identity of the client using other means. 6032 15.2.2.2.2. Case #2 6034 If the client certificate is certified by a Certificate Authority not 6035 known to the server, the server MUST proceed as under Case #1, Sub- 6036 Case #3. 6038 15.2.2.2.3. Case #3 6040 If the client certificate is self-signed, the server MUST proceed as 6041 under Case #1, Sub-Case #3. 6043 15.2.2.3. Use of Certificates in XMPP Extensions 6045 Certificates MAY be used in extensions to XMPP for the purpose of 6046 application-layer encryption or authentication above the level of XML 6047 streams (e.g., for end-to-end encryption). Such extensions shall 6048 define their own certificate handling rules, which at a minimum 6049 SHOULD be consistent with the rules specified herein but MAY specify 6050 additional rules. 6052 15.3. Client-to-Server Communication 6054 A compliant client implementation MUST support both TLS and SASL for 6055 connections to a server. 6057 The TLS protocol for encrypting XML streams (defined under Section 6) 6058 provides a reliable mechanism for helping to ensure the 6059 confidentiality and integrity of data exchanged between two entities. 6061 The SASL protocol for authenticating XML streams (defined under 6062 Section 7) provides a reliable mechanism for validating that a client 6063 connecting to a server is who it claims to be. 6065 Client-to-server communication MUST NOT proceed until the DNS 6066 hostname asserted by the server has been resolved as specified under 6067 Section 4. If there is a mismatch between the hostname to which a 6068 client attempted to connect (e.g., "example.net") and the hostname to 6069 which the client actually connects (e.g., "x1.example.net"), the 6070 client MUST warn a human user about the mismatch and the human user 6071 MUST approve the connection before the client proceeds; however, the 6072 client MAY also allow the user to add the presented hostname to a 6073 configured set of accepted hostnames to expedite future connections. 6075 A client's IP address and method of access MUST NOT be made public by 6076 a server, nor are any connections other than the original server 6077 connection required. This helps to protect the client's server from 6078 direct attack or identification by third parties. 6080 15.4. Server-to-Server Communication 6082 A compliant server implementation MUST support both TLS and SASL for 6083 inter-domain communication. 6085 Because service provisioning is a matter of policy, it is optional 6086 for any given domain to communicate with other domains, and server- 6087 to-server communication can be disabled by the administrator of any 6088 given deployment. If a particular domain enables inter-domain 6089 communication, it SHOULD enable high security. 6091 Administrators might want to require use of SASL for server-to-server 6092 communication to ensure both authentication and confidentiality 6093 (e.g., on an organization's private network). Compliant 6094 implementations SHOULD support SASL for this purpose. 6096 Server-to-server communication MUST NOT proceed until the DNS 6097 hostnames asserted by both servers have been resolved as specified 6098 under Section 4. 6100 15.5. Order of Layers 6102 The order of layers in which protocols MUST be stacked is: 6104 1. TCP 6105 2. TLS 6106 3. SASL 6107 4. XMPP 6109 The rationale for this order is that [TCP] is the base connection 6110 layer used by all of the protocols stacked on top of TCP, [TLS] is 6111 often provided at the operating system layer, [SASL] is often 6112 provided at the application layer, and XMPP is the application 6113 itself. 6115 15.6. Mandatory-to-Implement Technologies 6117 At a minimum, all implementations MUST support the following 6118 mechanisms: 6120 for confidentiality only: TLS (using the 6121 TLS_RSA_WITH_AES_128_CBC_SHA cipher) 6122 for both confidentiality and authentication: TLS plus the SASL PLAIN 6123 mechanism (See [PLAIN]) for password-based authentication and TLS 6124 plus the SASL EXTERNAL mechanism (see Appendix A of [SASL]) for 6125 non-password-based authentication (using the 6126 TLS_RSA_WITH_AES_128_CBC_SHA cipher supporting peer certificates) 6128 Naturally, implementations MAY support other ciphers with TLS and MAY 6129 support other SASL mechanisms. 6131 Note: The use of TLS plus SASL PLAIN replaces the SASL DIGEST-MD5 6132 mechanism as XMPP's mandatory-to-implement password-based method 6133 for authentication. For backward-compatibility, implementations 6134 are encouraged to continue supporting the SASL DIGEST-MD5 6135 mechanism as specified in [DIGEST-MD5]. Refer to [PLAIN] for 6136 important security considerations related to the SASL PLAIN 6137 mechanism. 6139 15.7. Hash Function Agility 6141 XMPP itself does not directly mandate the use of any particular hash 6142 function. However, technologies on which XMPP depends (e.g., TLS and 6143 particular SASL mechanisms), as well as various XMPP extensions, 6144 might make use of hash functions. Those who implement XMPP 6145 technologies or who develop XMPP extensions are advised to closely 6146 monitor the state of the art regarding attacks against cryptographic 6147 hashes in Internet protocols as they relate to XMPP. For helpful 6148 guidance, refer to [HASHES]. 6150 15.8. SASL Downgrade Attacks 6152 Because the initiating entity chooses an acceptable SASL mechanism 6153 from the list presented by the receiving entity, the initiating 6154 entity depends on the receiving entity's list for authentication. 6155 This dependency introduces the possibility of a downgrade attack if 6156 an attacker can gain control of the channel and therefore present a 6157 weak list of mechanisms. To prevent this attack, the parties SHOULD 6158 protect the channel using TLS before attempting SASL negotiation. 6160 15.9. Lack of SASL Channel Binding to TLS 6162 The SASL framework itself does not provide a method for binding SASL 6163 authentication to a security layer providing confidentiality and 6164 integrity protection that was negotiated at a lower layer. Such a 6165 binding is known as a "channel binding" (see [CHANNEL]). Some SASL 6166 mechanisms provide channel bindings. However, if a SASL mechanism 6167 does not provide a channel binding, then the mechanism cannot provide 6168 a way to verify that the source and destination end points to which 6169 the lower layer's security is bound are equivalent to the end points 6170 that SASL is authenticating; furthermore, if the end points are not 6171 identical, then the lower layer's security cannot be trusted to 6172 protect data transmitted between the SASL-authenticated entities. In 6173 such a situation, a SASL security layer SHOULD be negotiated that 6174 effectively ignores the presence of the lower-layer security. 6176 15.10. Use of base64 in SASL 6178 Both the client and the server MUST verify any base64 data received 6179 during SASL negotiation (Section 7). An implementation MUST reject 6180 (not ignore) any characters that are not explicitly allowed by the 6181 base64 alphabet; this helps to guard against creation of a covert 6182 channel that could be used to "leak" information. 6184 An implementation MUST NOT break on invalid input and MUST reject any 6185 sequence of base64 characters containing the pad ('=') character if 6186 that character is included as something other than the last character 6187 of the data (e.g., "=AAA" or "BBBB=CCC"); this helps to guard against 6188 buffer overflow attacks and other attacks on the implementation. 6190 While base 64 encoding visually hides otherwise easily recognized 6191 information (such as passwords), it does not provide any 6192 computational confidentiality. 6194 All uses of base 64 encoding MUST follow the definition in Section 4 6195 of [BASE64] and padding bits MUST be set to zero. 6197 15.11. Stringprep Profiles 6199 XMPP makes use of the [NAMEPREP] profile of [STRINGPREP] for 6200 processing of domain identifiers; for security considerations related 6201 to Nameprep, refer to the appropriate section of [NAMEPREP]. 6203 In addition, XMPP defines two profiles of [STRINGPREP]: Nodeprep 6204 (Appendix A) for localparts and Resourceprep (Appendix B) for 6205 resource identifiers. 6207 The Unicode and ISO/IEC 10646 repertoires have many characters that 6208 look similar. In many cases, users of security protocols might 6209 perform visual matching, such as when comparing the names of trusted 6210 third parties. Because it is impossible to map similar-looking 6211 characters without a great deal of context (such as knowing the fonts 6212 used), stringprep does nothing to map similar-looking characters 6213 together, nor to prohibit some characters because they look like 6214 others. 6216 A localpart can be employed as one part of an entity's address in 6217 XMPP. One common usage is as the username of an instant messaging 6218 user; another is as the name of a multi-user conference room; and 6219 many other kinds of entities could use localparts as part of their 6220 addresses. The security of such services could be compromised based 6221 on different interpretations of the internationalized localpart; for 6222 example, a user entering a single internationalized localpart could 6223 access another user's account information, or a user could gain 6224 access to a hidden or otherwise restricted chat room or service. 6226 A resource identifier can be employed as one part of an entity's 6227 address in XMPP. One common usage is as the name for an instant 6228 messaging user's connected resource; another is as the nickname of a 6229 user in a multi-user conference room; and many other kinds of 6230 entities could use resource identifiers as part of their addresses. 6231 The security of such services could be compromised based on different 6232 interpretations of the internationalized resource identifier; for 6233 example, a user could attempt to initiate multiple connections with 6234 the same name, or a user could send a message to someone other than 6235 the intended recipient in a multi-user conference room. 6237 15.12. Address Spoofing 6239 As discussed in [XEP-0165], there are two forms of address spoofing: 6240 forging and mimicking. 6242 15.12.1. Address Forging 6244 In the context of XMPP technologies, address forging occurs when an 6245 entity is able to generate an XML stanza whose 'from' address does 6246 not correspond to the account credentials with which the entity 6247 authenticated onto the network (or an authorization identity provided 6248 during SASL negotiation (Section 7)). For example, address forging 6249 occurs if an entity that authenticated as "juliet@im.example.com" is 6250 able to send XML stanzas from "nurse@im.example.com" or 6251 "romeo@example.net". 6253 Address forging is difficult in XMPP systems, given the requirement 6254 for sending servers to stamp 'from' addresses and for receiving 6255 servers to verify sending domains via server-to-server 6256 authentication. However, address forging is not impossible, since a 6257 rogue server could forge JIDs at the sending domain by ignoring the 6258 stamping requirement. A rogue server could even forge JIDs at other 6259 domains by means of a DNS poisoning attack if [DNSSEC] is not used. 6260 This specification does not define methods for discovering or 6261 counteracting such rogue servers. 6263 Note: An entity outside the security perimeter of a particular server 6264 cannot reliably distinguish between bare JIDs of the form 6265 at that server, since the server could forge any 6266 such JID; therefore only the domain identifier can be authenticated 6267 or authorized with any level of assurance. 6269 15.12.2. Address Mimicking 6271 Address mimicking occus when an entity provides legitimate 6272 authentication credentials for and sends XML stanzas from an account 6273 whose JID appears to a human user to be the same as another JID. For 6274 example, in some XMPP clients the address "paypa1@example.org" 6275 (spelled with the number one as the final character of the localpart) 6276 might appear to be the same as "paypal@example.org (spelled with the 6277 lower-case version of the letter "L"), especially on casual visual 6278 inspection; this phenomenon is sometimes called "typejacking". A 6279 more sophisticated example of address mimicking might involve the use 6280 of characters from outside the US-ASCII range, such as the Cherokee 6281 characters U+13DA U+13A2 U+13B5 U+13AC U+13A2 U+13AC U+13D2 instead 6282 of the US-ASCII characters "STPETER". 6284 In some examples of address mimicking, it is unlikely that the 6285 average user could tell the difference between the real JID and the 6286 fake JID. (Naturally, there is no way to distinguish with full 6287 certainty which is the fake JID and which is the real JID; in some 6288 communication contexts, the JID with Cherokee characters might be the 6289 real JID and the JID with US-ASCII characters might thus appear to be 6290 the fake JID.) Because JIDs can contain almost any Unicode 6291 character, it can be relatively easy to mimic some JIDs in XMPP 6292 systems. The possibility of address mimicking introduces security 6293 vulnerabilities of the kind that have also plagued the World Wide 6294 Web, specifically the phenomenon known as phishing. 6296 Mimicked addresses that involve characters from only one character 6297 set or from the character set typically employed by a particular user 6298 are not easy to combat (e.g., the simple typejacking attack 6299 previously described, which relies on a surface similarity between 6300 the characters "1" and "l" in some presentations). However, mimicked 6301 addresses that involve characters from more than one character set, 6302 or from a character set not typically employed by a particular user, 6303 can be mitigated somewhat through intelligent presentation. In 6304 particular, every human user of an XMPP technology presumably has a 6305 preferred language (or, in some cases, a small set of preferred 6306 languages), which an XMPP application SHOULD gather either explicitly 6307 from the user or implicitly via the operating system of the user's 6308 device. Furthermore, every language has a range (or a small set of 6309 ranges) of characters normally used to represent that language in 6310 textual form. Therefore, an XMPP application SHOULD warn the user 6311 when presenting a JID that uses characters outside the normal range 6312 of the user's preferred language(s). This recommendation is not 6313 intended to discourage communication across language communities; 6314 instead, it recognizes the existence of such language communities and 6315 encourages due caution when presenting unfamiliar character sets to 6316 human users. 6318 For more detailed recommendations regarding prevention of address 6319 mimicking in XMPP systems, refer to [XEP-0165]. 6321 15.13. Firewalls 6323 Communication using XMPP normally occurs over TCP connections on port 6324 5222 (client-to-server) or port 5269 (server-to-server), as 6325 registered with the IANA (see Section 16). Use of these well-known 6326 ports allows administrators to easily enable or disable XMPP activity 6327 through existing and commonly-deployed firewalls. 6329 15.14. Denial of Service 6331 [DOS] defines denial of service as follows: 6333 A Denial-of-Service (DoS) attack is an attack in which one or more 6334 machines target a victim and attempt to prevent the victim from 6335 doing useful work. The victim can be a network server, client or 6336 router, a network link or an entire network, an individual 6337 Internet user or a company doing business using the Internet, an 6338 Internet Service Provider (ISP), country, or any combination of or 6339 variant on these. 6341 [XEP-0205] provides a detailed discussion of potential denial of 6342 service attacks against XMPP systems and best practices for 6343 preventing such attacks. The recommendations include: 6345 1. A server implementation SHOULD enable a server administrator to 6346 limit the number of TCP connections that it will accept from a 6347 given IP address at any one time. If an entity attempts to 6348 connect but the maximum number of TCP connections has been 6349 reached, the receiving server MUST NOT allow the new connection 6350 to proceed. 6351 2. A server implementation SHOULD enable a server administrator to 6352 limit the number of TCP connection attempts that it will accept 6353 from a given IP address in a given time period. (While it is 6354 possible to limit the number of connections at the TCP layer 6355 rather than at the XMPP application layer, this is not advisable 6356 because limits at the TCP layer might result in an inability to 6357 access non-XMPP services.) If an entity attempts to connect but 6358 the maximum number of connections has been reached, the receiving 6359 server MUST NOT allow the new connection to proceed. 6360 3. A server MUST NOT process XML stanzas from clients that have not 6361 yet provided appropriate authentication credentials and MUST NOT 6362 process XML stanzas from peer servers whose identity it has not 6363 either authenticated via SASL or weakly verified via server 6364 dialback (see [XEP-0220]). 6366 4. A server implementation SHOULD enable a server administrator to 6367 limit the number of connected resources it will allow an account 6368 to bind at any one time. If a client attempts to bind a resource 6369 but it has already reached the configured number of allowable 6370 resources, the receiving server MUST return a stanza error. 6372 5. A server implementation SHOULD enable a server administrator to 6373 limit the size of stanzas it will accept from a connected client 6374 or peer server. If a connected resource or peer server sends a 6375 stanza that violates the upper limit, the receiving server SHOULD 6376 NOT process the stanza and instead SHOULD return a 6377 stanza error. Alternatively (e.g., if the sender has sent an 6378 egregiously large stanza), the server MAY instead return a 6379 stream error. 6380 6. A server implementation SHOULD enable a server administrator to 6381 limit the number of XML stanzas that a connected client is 6382 allowed to send to distinct recipients within a given time 6383 period. If a connected client sends too many stanzas to distinct 6384 recipients in a given time period, the receiving server SHOULD 6385 NOT process the stanza and instead SHOULD return an stanza error. 6387 7. A server implementation SHOULD enable a server administrator to 6388 limit the amount of bandwidth it will allow a connected client or 6389 peer server to use in a given time period. 6390 8. A server implementation MAY enable a server administrator to 6391 limit the types of stanzas (based on the extended content 6392 "payload") that it will allow a connected resource or peer server 6393 send over an active connection. Such limits and restrictions are 6394 a matter of deployment policy. 6395 9. A server implementation MAY refuse to route or deliver any stanza 6396 that it considers to be abusive, with or without returning an 6397 error to the sender. 6399 For more detailed recommendations regarding denial of service attacks 6400 in XMPP systems, refer to [XEP-0205]. 6402 15.15. Presence Leaks 6404 One of the core aspects of XMPP is presence: information about the 6405 network availability of an XMPP entity (i.e., whether the entity is 6406 currently online or offline). A PRESENCE LEAK occurs when an 6407 entity's network availability is inadvertently and involuntarily 6408 revealed to a second entity that is not authorized to know the first 6409 entity's network availability. 6411 Although presence is discussed more fully in [XMPP-IM], it is 6412 important to note that an XMPP server MUST NOT leak presence. In 6413 particular at the core XMPP level, real-time addressing and network 6414 availability is associated with a specific connected resource; 6415 therefore, any disclosure of a connected resource's full JID 6416 comprises a presence leak. To help prevent such a presence leak, a 6417 server MUST NOT return different stanza errors if a potential 6418 attacker sends XML stanzas to the entity's bare JID 6419 () or full JID (). 6421 15.16. Directory Harvesting 6423 When a server generates an error stanza in response to receiving a 6424 stanza for a user account that does not exist, the use of the 6425 stanza error condition can help protect 6426 against dictionary attacks, since this is the same error condition 6427 that is returned if, for instance, the namespace of an IQ child 6428 element is not understood, or if offline message storage or message 6429 forwarding is not enabled for a domain. However, subtle differences 6430 in the exact XML of error stanzas, as well as in the timing with 6431 which such errors are returned, can enable an attacker to determine 6432 the network presence of a user when more advanced blocking 6433 technologies are not used (see for instance [XEP-0016] and 6434 [XEP-0191]). 6436 16. IANA Considerations 6438 The following sections update the registrations provided in 6439 [RFC3920]. 6441 16.1. XML Namespace Name for TLS Data 6443 A URN sub-namespace for STARTTLS negotiation data in the Extensible 6444 Messaging and Presence Protocol (XMPP) is defined as follows. (This 6445 namespace name adheres to the format defined in [XML-REG].) 6447 URI: urn:ietf:params:xml:ns:xmpp-tls 6448 Specification: XXXX 6449 Description: This is the XML namespace name for STARTTLS negotiation 6450 data in the Extensible Messaging and Presence Protocol (XMPP) as 6451 defined by XXXX. 6452 Registrant Contact: IETF, XMPP Working Group, 6454 16.2. XML Namespace Name for SASL Data 6456 A URN sub-namespace for SASL negotiation data in the Extensible 6457 Messaging and Presence Protocol (XMPP) is defined as follows. (This 6458 namespace name adheres to the format defined in [XML-REG].) 6459 URI: urn:ietf:params:xml:ns:xmpp-sasl 6460 Specification: XXXX 6461 Description: This is the XML namespace name for SASL negotiation 6462 data in the Extensible Messaging and Presence Protocol (XMPP) as 6463 defined by XXXX. 6464 Registrant Contact: IETF, XMPP Working Group, 6466 16.3. XML Namespace Name for Stream Errors 6468 A URN sub-namespace for stream error data in the Extensible Messaging 6469 and Presence Protocol (XMPP) is defined as follows. (This namespace 6470 name adheres to the format defined in [XML-REG].) 6472 URI: urn:ietf:params:xml:ns:xmpp-streams 6473 Specification: XXXX 6474 Description: This is the XML namespace name for stream error data in 6475 the Extensible Messaging and Presence Protocol (XMPP) as defined 6476 by XXXX. 6477 Registrant Contact: IETF, XMPP Working Group, 6479 16.4. XML Namespace Name for Resource Binding 6481 A URN sub-namespace for resource binding in the Extensible Messaging 6482 and Presence Protocol (XMPP) is defined as follows. (This namespace 6483 name adheres to the format defined in [XML-REG].) 6485 URI: urn:ietf:params:xml:ns:xmpp-bind 6486 Specification: XXXX 6487 Description: This is the XML namespace name for resource binding in 6488 the Extensible Messaging and Presence Protocol (XMPP) as defined 6489 by XXXX. 6490 Registrant Contact: IETF, XMPP Working Group, 6492 16.5. XML Namespace Name for Stanza Errors 6494 A URN sub-namespace for stanza error data in the Extensible Messaging 6495 and Presence Protocol (XMPP) is defined as follows. (This namespace 6496 name adheres to the format defined in [XML-REG].) 6498 URI: urn:ietf:params:xml:ns:xmpp-stanzas 6499 Specification: XXXX 6500 Description: This is the XML namespace name for stanza error data in 6501 the Extensible Messaging and Presence Protocol (XMPP) as defined 6502 by XXXX. 6504 Registrant Contact: IETF, XMPP Working Group, 6506 16.6. Nodeprep Profile of Stringprep 6508 The Nodeprep profile of stringprep is defined under Nodeprep 6509 (Appendix A). The IANA has registered Nodeprep in the stringprep 6510 profile registry. 6512 Name of this profile: 6514 Nodeprep 6516 RFC in which the profile is defined: 6518 XXXX 6520 Indicator whether or not this is the newest version of the profile: 6522 This is the first version of Nodeprep 6524 16.7. Resourceprep Profile of Stringprep 6526 The Resourceprep profile of stringprep is defined under Resourceprep 6527 (Appendix B). The IANA has registered Resourceprep in the stringprep 6528 profile registry. 6530 Name of this profile: 6532 Resourceprep 6534 RFC in which the profile is defined: 6536 XXXX 6538 Indicator whether or not this is the newest version of the profile: 6540 This is the first version of Resourceprep 6542 16.8. GSSAPI Service Name 6544 The IANA has registered "xmpp" as a GSSAPI [GSS-API] service name, as 6545 defined under Section 7.5. 6547 16.9. Port Numbers 6549 The IANA has registered "xmpp-client" and "xmpp-server" as keywords 6550 for [TCP] ports 5222 and 5269 respectively. 6552 These ports SHOULD be used for client-to-server and server-to-server 6553 communications respectively, but other ports MAY be used. 6555 17. References 6557 17.1. Normative References 6559 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 6560 Specifications: ABNF", STD 68, RFC 5234, January 2008. 6562 [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data 6563 Encodings", RFC 4648, October 2006. 6565 [CHARSET] Alvestrand, H., "IETF Policy on Character Sets and 6566 Languages", BCP 18, RFC 2277, January 1998. 6568 [DNS] Mockapetris, P., "Domain names - implementation and 6569 specification", STD 13, RFC 1035, November 1987. 6571 [DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 6572 specifying the location of services (DNS SRV)", RFC 2782, 6573 February 2000. 6575 [IDNA] Faltstrom, P., Hoffman, P., and A. Costello, 6576 "Internationalizing Domain Names in Applications (IDNA)", 6577 RFC 3490, March 2003. 6579 [LANGTAGS] 6580 Phillips, A. and M. Davis, "Tags for Identifying 6581 Languages", BCP 47, RFC 4646, September 2006. 6583 [NAMEPREP] 6584 Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep 6585 Profile for Internationalized Domain Names (IDN)", 6586 RFC 3491, March 2003. 6588 [PLAIN] Zeilenga, K., "The PLAIN Simple Authentication and 6589 Security Layer (SASL) Mechanism", RFC 4616, August 2006. 6591 [RANDOM] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 6592 Requirements for Security", BCP 106, RFC 4086, June 2005. 6594 [SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and 6595 Security Layer (SASL)", RFC 4422, June 2006. 6597 [STRINGPREP] 6598 Hoffman, P. and M. Blanchet, "Preparation of 6599 Internationalized Strings ("stringprep")", RFC 3454, 6600 December 2002. 6602 [TCP] Postel, J., "Transmission Control Protocol", STD 7, 6603 RFC 793, September 1981. 6605 [TERMS] Bradner, S., "Key words for use in RFCs to Indicate 6606 Requirement Levels", BCP 14, RFC 2119, March 1997. 6608 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 6609 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 6611 [UCS2] International Organization for Standardization, 6612 "Information Technology - Universal Multiple-octet coded 6613 Character Set (UCS) - Amendment 2: UCS Transformation 6614 Format 8 (UTF-8)", ISO Standard 10646-1 Addendum 2, 6615 October 1996. 6617 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 6618 3.2.0", 2000. 6620 The Unicode Standard, Version 3.2.0 is defined by The 6621 Unicode Standard, Version 3.0 (Reading, MA, Addison- 6622 Wesley, 2000. ISBN 0-201-61633-5), as amended by the 6623 Unicode Standard Annex #27: Unicode 3.1 6624 (http://www.unicode.org/reports/tr27/) and by the Unicode 6625 Standard Annex #28: Unicode 3.2 6626 (http://www.unicode.org/reports/tr28/). 6628 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 6629 10646", STD 63, RFC 3629, November 2003. 6631 [UUID] Leach, P., Mealling, M., and R. Salz, "A Universally 6632 Unique IDentifier (UUID) URN Namespace", RFC 4122, 6633 July 2005. 6635 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 6636 Resource Identifier (URI): Generic Syntax", STD 66, 6637 RFC 3986, January 2005. 6639 [X509] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 6640 Housley, R., and W. Polk, "Internet X.509 Public Key 6641 Infrastructure Certificate and Certificate Revocation List 6642 (CRL) Profile", RFC 5280, May 2008. 6644 [X509-SRV] 6645 Santesson, S., "Internet X.509 Public Key Infrastructure 6646 Subject Alternative Name for Expression of Service Name", 6647 RFC 4985, August 2007. 6649 [XML] Paoli, J., Maler, E., Sperberg-McQueen, C., Yergeau, F., 6650 and T. Bray, "Extensible Markup Language (XML) 1.0 (Fourth 6651 Edition)", World Wide Web Consortium Recommendation REC- 6652 xml-20060816, August 2006, 6653 . 6655 [XML-NAMES] 6656 Layman, A., Hollander, D., Tobin, R., and T. Bray, 6657 "Namespaces in XML 1.1 (Second Edition)", World Wide Web 6658 Consortium Recommendation REC-xml-names11-20060816, 6659 August 2006, . 6661 17.2. Informative References 6663 [ACAP] Newman, C. and J. Myers, "ACAP -- Application 6664 Configuration Access Protocol", RFC 2244, November 1997. 6666 [ANONYMOUS] 6667 Zeilenga, K., "Anonymous Simple Authentication and 6668 Security Layer (SASL) Mechanism", RFC 4505, June 2006. 6670 [ASN.1] CCITT, "Recommendation X.208: Specification of Abstract 6671 Syntax Notation One (ASN.1)", 1988. 6673 [CHANNEL] Williams, N., "On the Use of Channel Bindings to Secure 6674 Channels", RFC 5056, November 2007. 6676 [DIGEST-MD5] 6677 Leach, P. and C. Newman, "Using Digest Authentication as a 6678 SASL Mechanism", RFC 2831, May 2000. 6680 [DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. 6681 Rose, "DNS Security Introduction and Requirements", 6682 RFC 4033, March 2005. 6684 [DNS-TXT] Rosenbaum, R., "Using the Domain Name System To Store 6685 Arbitrary String Attributes", RFC 1464, May 1993. 6687 [DOS] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- 6688 Service Considerations", RFC 4732, December 2006. 6690 [EMAIL-ARCH] 6691 Crocker, D., "Internet Mail Architecture", RFC 5598, 6692 July 2009. 6694 [GSS-API] Linn, J., "Generic Security Service Application Program 6695 Interface Version 2, Update 1", RFC 2743, January 2000. 6697 [HASHES] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 6698 Hashes in Internet Protocols", RFC 4270, November 2005. 6700 [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 6701 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 6702 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 6704 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 6705 4rev1", RFC 3501, March 2003. 6707 [IMP-REQS] 6708 Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging 6709 / Presence Protocol Requirements", RFC 2779, 6710 February 2000. 6712 [IRI] Duerst, M. and M. Suignard, "Internationalized Resource 6713 Identifiers (IRIs)", RFC 3987, January 2005. 6715 [LINKLOCAL] 6716 Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 6717 Configuration of IPv4 Link-Local Addresses", RFC 3927, 6718 May 2005. 6720 [MAILBOXES] 6721 Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND 6722 FUNCTIONS", RFC 2142, May 1997. 6724 [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 6725 STD 53, RFC 1939, May 1996. 6727 [PUNYCODE] 6728 Costello, A., "Punycode: A Bootstring encoding of Unicode 6729 for Internationalized Domain Names in Applications 6730 (IDNA)", RFC 3492, March 2003. 6732 [REST] Fielding, R., "Architectural Styles and the Design of 6733 Network-based Software Architectures", 2000. 6735 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 6736 Protocol (XMPP): Core", RFC 3920, October 2004. 6738 [RFC3921] Saint-Andre, P., Ed., "Extensible Messaging and Presence 6739 Protocol (XMPP): Instant Messaging and Presence", 6740 RFC 3921, October 2004. 6742 [SECTERMS] 6743 Shirey, R., "Internet Security Glossary, Version 2", 6744 RFC 4949, August 2007. 6746 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 6747 October 2008. 6749 [URN-OID] Mealling, M., "A URN Namespace of Object Identifiers", 6750 RFC 3061, February 2001. 6752 [USINGTLS] 6753 Newman, C., "Using TLS with IMAP, POP3 and ACAP", 6754 RFC 2595, June 1999. 6756 [XEP-0001] 6757 Saint-Andre, P., "XMPP Extension Protocols", XSF XEP 0001, 6758 January 2008. 6760 [XEP-0016] 6761 Millard, P. and P. Saint-Andre, "Privacy Lists", XSF 6762 XEP 0016, February 2007. 6764 [XEP-0030] 6765 Hildebrand, J., Millard, P., Eatmon, R., and P. Saint- 6766 Andre, "Service Discovery", XSF XEP 0030, June 2008. 6768 [XEP-0045] 6769 Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, 6770 July 2007. 6772 [XEP-0060] 6773 Millard, P., Saint-Andre, P., and R. Meijer, "Publish- 6774 Subscribe", XSF XEP 0060, September 2008. 6776 [XEP-0071] 6777 Saint-Andre, P., "XHTML-IM", XSF XEP 0071, September 2008. 6779 [XEP-0077] 6780 Saint-Andre, P., "In-Band Registration", XSF XEP 0077, 6781 January 2006. 6783 [XEP-0124] 6784 Paterson, I., Smith, D., and P. Saint-Andre, 6785 "Bidirectional-streams Over Synchronous HTTP (BOSH)", XSF 6786 XEP 0124, April 2009. 6788 [XEP-0156] 6789 Hildebrand, J. and P. Saint-Andre, "Discovering 6790 Alternative XMPP Connection Methods", XSF XEP 0156, 6791 June 2007. 6793 [XEP-0165] 6794 Saint-Andre, P., "Best Practices to Prevent JID 6795 Mimicking", XSF XEP 0165, December 2007. 6797 [XEP-0174] 6798 Saint-Andre, P., "Link-Local Messaging", XSF XEP 0174, 6799 November 2008. 6801 [XEP-0175] 6802 Saint-Andre, P., "Best Practices for Use of SASL 6803 ANONYMOUS", XSF XEP 0175, November 2007. 6805 [XEP-0178] 6806 Saint-Andre, P. and P. Millard, "Best Practices for Use of 6807 SASL EXTERNAL with Certificates", XSF XEP 0178, 6808 February 2007. 6810 [XEP-0191] 6811 Saint-Andre, P., "Simple Communications Blocking", XSF 6812 XEP 0191, February 2007. 6814 [XEP-0198] 6815 Karneges, J., Hildebrand, J., Saint-Andre, P., and F. 6816 Forno, "Stream Management", XSF XEP 0198, June 2009. 6818 [XEP-0199] 6819 Saint-Andre, P., "XMPP Ping", XSF XEP 0199, June 2009. 6821 [XEP-0205] 6822 Saint-Andre, P., "Best Practices to Discourage Denial of 6823 Service Attacks", XSF XEP 0205, January 2009. 6825 [XEP-0206] 6826 Paterson, I., "XMPP Over BOSH", XSF XEP 0206, 6827 October 2008. 6829 [XEP-0220] 6830 Saint-Andre, P. and J. Miller, "Server Dialback", XSF 6831 XEP 0220, October 2008. 6833 [XEP-0271] 6834 Saint-Andre, P., "XMPP Nodes", XSF XEP 0271, June 2009. 6836 [XML-FRAG] 6837 Grosso, P. and D. Veillard, "XML Fragment Interchange", 6838 World Wide Web Consortium CR CR-xml-fragment-20010212, 6839 February 2001, 6840 . 6842 [XML-REG] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 6843 January 2004. 6845 [XML-SCHEMA] 6846 Thompson, H., Maloney, M., Mendelsohn, N., and D. Beech, 6847 "XML Schema Part 1: Structures Second Edition", World Wide 6848 Web Consortium Recommendation REC-xmlschema-1-20041028, 6849 October 2004, 6850 . 6852 [XMPP-IM] Saint-Andre, P., "Extensible Messaging and Presence 6853 Protocol (XMPP): Instant Messaging and Presence", 6854 draft-ietf-xmpp-3921bis-01 (work in progress), 6855 August 2009. 6857 [XMPP-URI] 6858 Saint-Andre, P., "Internationalized Resource Identifiers 6859 (IRIs) and Uniform Resource Identifiers (URIs) for the 6860 Extensible Messaging and Presence Protocol (XMPP)", 6861 RFC 5122, February 2008. 6863 Appendix A. Nodeprep 6865 A.1. Introduction 6867 This appendix defines the "Nodeprep" profile of stringprep. As such, 6868 it specifies processing rules that will enable users to enter 6869 internationalized localparts in the Extensible Messaging and Presence 6870 Protocol (XMPP) and have the highest chance of getting the content of 6871 the strings correct. (An XMPP localpart is the optional portion of 6872 an XMPP address that precedes an XMPP domain identifier and the '@' 6873 separator; it is often but not exclusively associated with an instant 6874 messaging username.) These processing rules are intended only for 6875 XMPP localparts and are not intended for arbitrary text or any other 6876 aspect of an XMPP address. 6878 This profile defines the following, as required by [STRINGPREP]: 6880 o The intended applicability of the profile: internationalized 6881 localparts within XMPP 6882 o The character repertoire that is the input and output to 6883 stringprep: Unicode 3.2, specified in Section 2 of this Appendix 6885 o The mappings used: specified in Section 3 6886 o The Unicode normalization used: specified in Section 4 6887 o The characters that are prohibited as output: specified in Section 6888 5 6889 o Bidirectional character handling: specified in Section 6 6891 A.2. Character Repertoire 6893 This profile uses Unicode 3.2 with the list of unassigned code points 6894 being Table A.1, both defined in Appendix A of [STRINGPREP]. 6896 A.3. Mapping 6898 This profile specifies mapping using the following tables from 6899 [STRINGPREP]: 6901 Table B.1 6902 Table B.2 6904 A.4. Normalization 6906 This profile specifies the use of Unicode normalization form KC, as 6907 described in [STRINGPREP]. 6909 A.5. Prohibited Output 6911 This profile specifies the prohibition of using the following tables 6912 from [STRINGPREP]. 6914 Table C.1.1 6915 Table C.1.2 6916 Table C.2.1 6917 Table C.2.2 6918 Table C.3 6919 Table C.4 6920 Table C.5 6921 Table C.6 6922 Table C.7 6923 Table C.8 6924 Table C.9 6926 In addition, the following additional Unicode characters are also 6927 prohibited: 6929 U+0022 (QUOTATION MARK), i.e., " 6930 U+0026 (AMPERSAND), i.e., & 6931 U+0027 (APOSTROPHE), i.e., ' 6932 U+002F (SOLIDUS), i.e., / 6933 U+003A (COLON), i.e., : 6934 U+003C (LESS-THAN SIGN), i.e., < 6935 U+003E (GREATER-THAN SIGN), i.e., > 6936 U+0040 (COMMERCIAL AT), i.e., @ 6938 A.6. Bidirectional Characters 6940 This profile specifies checking bidirectional strings, as described 6941 in Section 6 of [STRINGPREP]. 6943 A.7. Notes 6945 Because the additional characters prohibited by Nodeprep are 6946 prohibited after normalization, an implementation MUST NOT enable a 6947 human user to input any Unicode code point whose decomposition 6948 includes those characters; such code points include but are not 6949 necessarily limited to the following (refer to [UNICODE] for complete 6950 information). 6952 o U+2100 (ACCOUNT OF) 6953 o U+2101 (ADDRESSED TO THE SUBJECT) 6954 o U+2105 (CARE OF) 6955 o U+2106 (CADA UNA) 6956 o U+226E (NOT LESS-THAN) 6957 o U+226F (NOT GREATER-THAN) 6958 o U+2A74 (DOUBLE COLON EQUAL) 6959 o U+FE13 (SMALL COLON) 6960 o U+FE60 (SMALL AMPERSAND) 6961 o U+FE64 (SMALL LESS-THAN SIGN) 6962 o U+FE65 (SMALL GREATER-THAN SIGN) 6963 o U+FE6B (SMALL COMMERCIAL AT) 6964 o U+FF02 (FULLWIDTH QUOTATION MARK) 6965 o U+FF06 (FULLWIDTH AMPERSAND) 6966 o U+FF07 (FULLWIDTH APOSTROPHE) 6967 o U+FF0F (FULLWIDTH SOLIDUS) 6968 o U+FF1A (FULLWIDTH COLON) 6969 o U+FF1C (FULLWIDTH LESS-THAN SIGN) 6970 o U+FF1E (FULLWIDTH GREATER-THAN SIGN) 6971 o U+FF20 (FULLWIDTH COMMERCIAL AT) 6973 Appendix B. Resourceprep 6974 B.1. Introduction 6976 This appendix defines the "Resourceprep" profile of stringprep. As 6977 such, it specifies processing rules that will enable users to enter 6978 internationalized resource identifiers in the Extensible Messaging 6979 and Presence Protocol (XMPP) and have the highest chance of getting 6980 the content of the strings correct. (An XMPP resource identifier is 6981 the optional portion of an XMPP address that follows an XMPP domain 6982 identifier and the '/' separator.) These processing rules are 6983 intended only for XMPP resource identifiers and are not intended for 6984 arbitrary text or any other aspect of an XMPP address. 6986 This profile defines the following, as required by [STRINGPREP]: 6988 o The intended applicability of the profile: internationalized 6989 resource identifiers within XMPP 6990 o The character repertoire that is the input and output to 6991 stringprep: Unicode 3.2, specified in Section 2 of this Appendix 6992 o The mappings used: specified in Section 3 6993 o The Unicode normalization used: specified in Section 4 6994 o The characters that are prohibited as output: specified in Section 6995 5 6996 o Bidirectional character handling: specified in Section 6 6998 B.2. Character Repertoire 7000 This profile uses Unicode 3.2 with the list of unassigned code points 7001 being Table A.1, both defined in Appendix A of [STRINGPREP]. 7003 B.3. Mapping 7005 This profile specifies mapping using the following tables from 7006 [STRINGPREP]: 7008 Table B.1 7010 B.4. Normalization 7012 This profile specifies the use of Unicode normalization form KC, as 7013 described in [STRINGPREP]. 7015 B.5. Prohibited Output 7017 This profile specifies the prohibition of using the following tables 7018 from [STRINGPREP]. 7020 Table C.1.2 7021 Table C.2.1 7022 Table C.2.2 7023 Table C.3 7024 Table C.4 7025 Table C.5 7026 Table C.6 7027 Table C.7 7028 Table C.8 7029 Table C.9 7031 B.6. Bidirectional Characters 7033 This profile specifies checking bidirectional strings, as described 7034 in Section 6 of [STRINGPREP]. 7036 Appendix C. XML Schemas 7038 Because validation of XML streams and stanzas is optional, the 7039 following XML schemas are provided for descriptive purposes only. 7040 These schemas are not normative. 7042 The following schemas formally define various XML namespaces used in 7043 the core XMPP protocols, in conformance with [XML-SCHEMA]. For 7044 schemas defining the 'jabber:client' and 'jabber:server' namespaces, 7045 refer to [XMPP-IM]. 7047 C.1. Streams Namespace 7049 7051 7057 7058 7059 7060 7061 7063 7064 7065 7068 7069 7072 7075 7076 7077 7078 7079 7080 7081 7082 7083 7084 7085 7086 7087 7088 7089 7090 7091 7092 7093 7094 7095 7096 7097 7099 7100 7101 7102 7103 7105 7106 7107 7108 7109 7112 7115 7117 7118 7120 7122 C.2. Stream Error Namespace 7124 7126 7132 7133 7134 7135 7136 7137 7138 7139 7140 7141 7142 7143 7144 7145 7146 7147 7148 7149 7150 7151 7152 7153 7154 7155 7157 7158 7159 7160 7161 7162 7163 7164 7165 7166 7167 7168 7169 7170 7171 7172 7173 7174 7175 7176 7177 7178 7179 7180 7181 7182 7183 7184 7186 7187 7188 7189 7190 7191 7192 7193 7194 7196 7197 7198 7199 7200 7202 7204 C.3. STARTTLS Namespace 7206 7208 7214 7215 7216 7217 7218 7219 7220 7221 7223 7225 7227 7228 7229 7230 7231 7233 7235 C.4. SASL Namespace 7237 7239 7245 7246 7247 7248 7253 7254 7255 7256 7257 7260 7261 7262 7264 7266 7267 7268 7269 7270 7273 7274 7275 7276 7278 7280 7282 7284 7285 7286 7287 7288 7289 7290 7291 7292 7293 7294 7295 7296 7297 7298 7299 7300 7301 7302 7303 7304 7306 7307 7308 7309 7310 7311 7312 7313 7314 7316 7317 7318 7319 7320 7322 7324 C.5. Resource Binding Namespace 7326 7328 7334 7335 7336 7337 7338 7339 7340 7341 7342 7343 7344 7345 7346 7347 7349 7350 7351 7352 7353 7354 7356 7357 7358 7359 7360 7361 7363 7365 C.6. Stanza Error Namespace 7367 7369 7375 7376 7377 7378 7379 7380 7381 7382 7383 7384 7385 7386 7387 7388 7389 7390 7391 7392 7393 7394 7395 7396 7397 7398 7400 7401 7402 7403 7404 7405 7406 7407 7408 7409 7410 7411 7412 7413 7414 7415 7416 7417 7418 7419 7420 7421 7422 7423 7424 7425 7426 7427 7429 7430 7431 7432 7433 7434 7435 7436 7437 7439 7440 7441 7442 7443 7445 7447 Appendix D. Contact Addresses 7449 Consistent with [MAILBOXES], an organization that offers an XMPP 7450 service SHOULD provide an Internet mailbox of "XMPP" for inquiries 7451 related to that service, where the host portion of the resulting 7452 mailto URI MUST be the organization's domain, not the domain of the 7453 XMPP service itself (e.g., the XMPP service might be offered at 7454 im.example.com but the Internet mailbox would be ). 7456 Appendix E. Account Provisioning 7458 Account provisioning is out of scope for this specification. 7459 Possible methods for account provisioning include account creation by 7460 a server administrator and in-band account registration using the 7461 'jabber:iq:register' namespace as documented in [XEP-0077]. 7463 Appendix F. Differences From RFC 3920 7465 Based on consensus derived from implementation and deployment 7466 experience as well as formal interoperability testing, the following 7467 substantive modifications were made from RFC 3920. 7469 o Corrected the ABNF syntax for JIDs to prevent zero-length 7470 localparts, domain identifiers, and resource identifiers. 7471 o To avoid confusion with the term "node" as used in [XEP-0030] and 7472 [XEP-0060] (see also [XEP-0271]), changed the term "node 7473 identifier" to "localpart" (but retained the name "Nodeprep" for 7474 backward compatibility). 7475 o Corrected the nameprep processing rules to require use of the 7476 UseSTD3ASCIIRules flag. 7477 o Recommended or mandated use of the 'from' and 'to' attributes on 7478 stream headers. 7479 o More fully specified stream closing handshake. 7480 o Specified recommended stream reconnection algorithm. 7481 o Specified return of stream error in response to 7482 receipt of prohibited XML features. 7483 o Specified that TLS plus SASL PLAIN is a mandatory-to-implement 7484 technology for client-to-server connections, since implementation 7485 of SASL EXTERNAL is uncommon in XMPP clients, in part because 7486 underlying security features such as end-user X.509 certificates 7487 are not yet widely deployed. 7488 o Added the , , 7489 , , and SASL error conditions to handle error flows mistakenly 7491 left out of RFC 3920 or discussed in RFC 4422 but not in RFC 2222. 7492 o Added the stanza error condition to enable 7493 potential ETags usage. 7494 o Removed unnecessary requirement for escaping of characters that 7495 map to certain predefined entities, which do not need to be 7496 escaped in XML. 7497 o Clarified process of DNS SRV lookups and fallbacks. 7498 o Clarified handling of SASL security layers. 7499 o Clarified handling of stream features, regularized use of the 7500 child element, and defined use of the 7501 child element. 7502 o Clarified handling of data that violates the well-formedness 7503 definitions for XML 1.0 and XML namespaces. 7504 o Specified security considerations in more detail, especially with 7505 regard to presence leaks and denial of service attacks. 7506 o Moved historical documentation of the server dialback protocol 7507 from this specification to a separate specification maintained by 7508 the XMPP Standards Foundation. 7510 In addition, numerous changes of an editorial nature were made in 7511 order to more fully specify and clearly explain XMPP. 7513 Appendix G. Copying Conditions 7515 Regarding this entire document or any portion of it, the author makes 7516 no guarantees and is not responsible for any damage resulting from 7517 its use. The author grants irrevocable permission to anyone to use, 7518 modify, and distribute it in any way that does not diminish the 7519 rights of anyone else to use, modify, and distribute it, provided 7520 that redistributed derivative works do not contain misleading author 7521 or version information. Derivative works need not be licensed under 7522 similar terms. 7524 Index 7526 B 7527 Bare JID 18 7529 C 7530 Connected Resource 76 7532 D 7533 Domain Identifier 16 7535 E 7536 Entity 15 7537 Error Stanza 88 7538 Extended Content 105 7540 F 7541 Full JID 18 7543 I 7544 Initial Stream 23 7545 IQ Stanza 87 7547 J 7548 Jabber Identifier 15 7550 L 7551 Localpart 18 7553 M 7554 Message Stanza 86 7556 P 7557 Presence Stanza 86 7559 R 7560 Resource Identifier 18 7561 Response Stream 23 7563 S 7564 Stream ID 29 7566 W 7567 Whitespace Keepalive 36 7569 X 7570 XML Stanza 24 7571 XML Stream 23 7573 Author's Address 7575 Peter Saint-Andre 7576 Cisco 7578 Email: Peter.SaintAndre@WebEx.com