idnits 2.17.1 draft-ietf-xmpp-core-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1043 has weird spacing: '... it it MU...' == 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 exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Recipient: If a recipient receives a stanza that contains a child element it does not understand, it SHOULD ignore that specific XML data, i.e., it SHOULD not process it or present it to a user or associated application (if any). In particular: -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 17, 2003) is 7679 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) == Missing Reference: '43' is mentioned on line 386, but not defined -- Looks like a reference, but probably isn't: 'RFCXXXX' on line 2384 -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Downref: Normative reference to an Informational RFC: RFC 2779 (ref. '2') ** Obsolete normative reference: RFC 793 (ref. '4') (Obsoleted by RFC 9293) -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Downref: Normative reference to an Unknown state RFC: RFC 952 (ref. '6') -- Unexpected draft version: The latest known version of draft-ietf-idn-nameprep is -10, but you're referring to -11. ** Obsolete normative reference: RFC 3454 (ref. '9') (Obsoleted by RFC 7564) == Outdated reference: A later version (-03) exists of draft-ietf-xmpp-nodeprep-01 -- Possible downref: Normative reference to a draft: ref. '10' == Outdated reference: A later version (-03) exists of draft-ietf-xmpp-resourceprep-01 -- Possible downref: Normative reference to a draft: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' ** Obsolete normative reference: RFC 2246 (ref. '13') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2222 (ref. '14') (Obsoleted by RFC 4422, RFC 4752) ** Obsolete normative reference: RFC 2831 (ref. '15') (Obsoleted by RFC 6331) ** Obsolete normative reference: RFC 3066 (ref. '16') (Obsoleted by RFC 4646, RFC 4647) ** Obsolete normative reference: RFC 2052 (ref. '17') (Obsoleted by RFC 2782) ** Obsolete normative reference: RFC 2279 (ref. '18') (Obsoleted by RFC 3629) ** Downref: Normative reference to an Informational RFC: RFC 2781 (ref. '19') -- Possible downref: Non-RFC (?) normative reference: ref. '20' ** Obsolete normative reference: RFC 2078 (ref. '21') (Obsoleted by RFC 2743) == Outdated reference: A later version (-22) exists of draft-ietf-xmpp-im-08 -- Obsolete informational reference (is this intentional?): RFC 2396 (ref. '23') (Obsoleted by RFC 3986) == Outdated reference: A later version (-05) exists of draft-mealling-iana-xmlns-registry-04 -- Obsolete informational reference (is this intentional?): RFC 2060 (ref. '25') (Obsoleted by RFC 3501) -- Obsolete informational reference (is this intentional?): RFC 2535 (ref. '29') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. '30') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: A later version (-09) exists of draft-ietf-xmpp-e2e-01 Summary: 13 errors (**), 0 flaws (~~), 12 warnings (==), 15 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 J. Miller 4 Expires: October 16, 2003 Jabber Software Foundation 5 April 17, 2003 7 XMPP Core 8 draft-ietf-xmpp-core-09 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on October 16, 2003. 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 This document describes the core features of the Extensible Messaging 40 and Presence Protocol (XMPP), a protocol for streaming XML elements 41 in order to exchange messages and presence information in close to 42 real time. XMPP is used mainly for the purpose of building instant 43 messaging (IM) and presence applications, such as the servers and 44 clients that comprise the Jabber network. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 49 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 50 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 51 1.3 Discussion Venue . . . . . . . . . . . . . . . . . . . . . 5 52 1.4 Intellectual Property Notice . . . . . . . . . . . . . . . 5 53 2. Generalized Architecture . . . . . . . . . . . . . . . . . 6 54 2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 2.2 Server . . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 2.3 Client . . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 2.4 Gateway . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 2.5 Network . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 3. Addressing Scheme . . . . . . . . . . . . . . . . . . . . 8 60 3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 3.2 Domain Identifier . . . . . . . . . . . . . . . . . . . . 8 62 3.3 Node Identifier . . . . . . . . . . . . . . . . . . . . . 8 63 3.4 Resource Identifier . . . . . . . . . . . . . . . . . . . 9 64 4. XML Streams . . . . . . . . . . . . . . . . . . . . . . . 10 65 4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 4.2 Stream Attributes . . . . . . . . . . . . . . . . . . . . 11 67 4.3 Namespace Declarations . . . . . . . . . . . . . . . . . . 12 68 4.4 Stream Features . . . . . . . . . . . . . . . . . . . . . 13 69 4.5 Stream Errors . . . . . . . . . . . . . . . . . . . . . . 14 70 4.5.1 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 4.5.2 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 4.5.3 Conditions . . . . . . . . . . . . . . . . . . . . . . . . 15 73 4.5.4 Extensibility . . . . . . . . . . . . . . . . . . . . . . 16 74 4.6 Simple Streams Example . . . . . . . . . . . . . . . . . . 16 75 5. Stream Encryption . . . . . . . . . . . . . . . . . . . . 19 76 5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 19 77 5.2 Narrative . . . . . . . . . . . . . . . . . . . . . . . . 20 78 5.3 Client-to-Server Example . . . . . . . . . . . . . . . . . 21 79 5.4 Server-to-Server Example . . . . . . . . . . . . . . . . . 23 80 6. Stream Authentication . . . . . . . . . . . . . . . . . . 26 81 6.1 SASL Authentication . . . . . . . . . . . . . . . . . . . 26 82 6.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 26 83 6.1.2 Narrative . . . . . . . . . . . . . . . . . . . . . . . . 27 84 6.1.3 SASL Definition . . . . . . . . . . . . . . . . . . . . . 29 85 6.1.4 Client-to-Server Example . . . . . . . . . . . . . . . . . 30 86 6.1.5 Server-to-Server Example . . . . . . . . . . . . . . . . . 32 87 6.2 Dialback Authentication . . . . . . . . . . . . . . . . . 35 88 6.2.1 Dialback Protocol . . . . . . . . . . . . . . . . . . . . 37 89 7. XML Stanzas . . . . . . . . . . . . . . . . . . . . . . . 42 90 7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 42 91 7.2 Common Attributes . . . . . . . . . . . . . . . . . . . . 42 92 7.2.1 to . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 93 7.2.2 from . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 94 7.2.3 id . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 95 7.2.4 type . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 96 7.2.5 xml:lang . . . . . . . . . . . . . . . . . . . . . . . . . 43 97 7.3 Message Stanzas . . . . . . . . . . . . . . . . . . . . . 44 98 7.3.1 Types of Message . . . . . . . . . . . . . . . . . . . . . 44 99 7.3.2 Children . . . . . . . . . . . . . . . . . . . . . . . . . 44 100 7.3.2.1 Body . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 101 7.3.2.2 Subject . . . . . . . . . . . . . . . . . . . . . . . . . 45 102 7.3.2.3 Thread . . . . . . . . . . . . . . . . . . . . . . . . . . 45 103 7.4 Presence Stanzas . . . . . . . . . . . . . . . . . . . . . 46 104 7.4.1 Types of Presence . . . . . . . . . . . . . . . . . . . . 46 105 7.4.2 Children . . . . . . . . . . . . . . . . . . . . . . . . . 46 106 7.4.2.1 Show . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 107 7.4.2.2 Status . . . . . . . . . . . . . . . . . . . . . . . . . . 47 108 7.4.2.3 Priority . . . . . . . . . . . . . . . . . . . . . . . . . 48 109 7.5 IQ Stanzas . . . . . . . . . . . . . . . . . . . . . . . . 48 110 7.5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 48 111 7.5.2 Types of IQ . . . . . . . . . . . . . . . . . . . . . . . 49 112 7.5.3 Children . . . . . . . . . . . . . . . . . . . . . . . . . 49 113 7.6 Extended Namespaces . . . . . . . . . . . . . . . . . . . 49 114 7.7 Stanza Errors . . . . . . . . . . . . . . . . . . . . . . 50 115 7.7.1 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 50 116 7.7.2 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 51 117 7.7.3 Conditions . . . . . . . . . . . . . . . . . . . . . . . . 52 118 7.7.4 Extensibility . . . . . . . . . . . . . . . . . . . . . . 53 119 8. XML Usage within XMPP . . . . . . . . . . . . . . . . . . 54 120 8.1 Restrictions . . . . . . . . . . . . . . . . . . . . . . . 54 121 8.2 Namespaces . . . . . . . . . . . . . . . . . . . . . . . . 54 122 8.3 Validation . . . . . . . . . . . . . . . . . . . . . . . . 54 123 8.4 Character Encodings . . . . . . . . . . . . . . . . . . . 55 124 8.5 Inclusion of Text Declaration . . . . . . . . . . . . . . 55 125 9. IANA Considerations . . . . . . . . . . . . . . . . . . . 56 126 9.1 XML Namespace Name for TLS Data . . . . . . . . . . . . . 56 127 9.2 XML Namespace Name for SASL Data . . . . . . . . . . . . . 56 128 9.3 XML Namespace Name for Stream Errors . . . . . . . . . . . 56 129 9.4 XML Namespace Name for Stanza Errors . . . . . . . . . . . 57 130 9.5 Existing Registrations . . . . . . . . . . . . . . . . . . 57 131 10. Internationalization Considerations . . . . . . . . . . . 58 132 11. Security Considerations . . . . . . . . . . . . . . . . . 59 133 11.1 High Security . . . . . . . . . . . . . . . . . . . . . . 59 134 11.2 Client-to-Server Communications . . . . . . . . . . . . . 59 135 11.3 Server-to-Server Communications . . . . . . . . . . . . . 60 136 11.4 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . 60 137 11.5 Mandatory to Implement Technologies . . . . . . . . . . . 60 138 Normative References . . . . . . . . . . . . . . . . . . . 61 139 Informative References . . . . . . . . . . . . . . . . . . 63 140 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 63 141 A. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . 65 142 A.1 Streams namespace . . . . . . . . . . . . . . . . . . . . 65 143 A.2 TLS namespace . . . . . . . . . . . . . . . . . . . . . . 66 144 A.3 SASL namespace . . . . . . . . . . . . . . . . . . . . . . 66 145 A.4 Dialback namespace . . . . . . . . . . . . . . . . . . . . 67 146 A.5 Client namespace . . . . . . . . . . . . . . . . . . . . . 68 147 A.6 Server namespace . . . . . . . . . . . . . . . . . . . . . 72 148 A.7 Stream error namespace . . . . . . . . . . . . . . . . . . 75 149 A.8 Stanza error namespace . . . . . . . . . . . . . . . . . . 76 150 B. Revision History . . . . . . . . . . . . . . . . . . . . . 78 151 B.1 Changes from draft-ietf-xmpp-core-08 . . . . . . . . . . . 78 152 B.2 Changes from draft-ietf-xmpp-core-07 . . . . . . . . . . . 78 153 B.3 Changes from draft-ietf-xmpp-core-06 . . . . . . . . . . . 78 154 B.4 Changes from draft-ietf-xmpp-core-05 . . . . . . . . . . . 78 155 B.5 Changes from draft-ietf-xmpp-core-04 . . . . . . . . . . . 79 156 B.6 Changes from draft-ietf-xmpp-core-03 . . . . . . . . . . . 79 157 B.7 Changes from draft-ietf-xmpp-core-02 . . . . . . . . . . . 79 158 B.8 Changes from draft-ietf-xmpp-core-01 . . . . . . . . . . . 79 159 B.9 Changes from draft-ietf-xmpp-core-00 . . . . . . . . . . . 80 160 B.10 Changes from draft-miller-xmpp-core-02 . . . . . . . . . . 80 161 Full Copyright Statement . . . . . . . . . . . . . . . . . 82 163 1. Introduction 165 1.1 Overview 167 The Extensible Messaging and Presence Protocol (XMPP) is an open XML 168 [1] protocol for near-real-time messaging, presence, and request- 169 response services. The basic syntax and semantics were developed 170 originally within the Jabber open-source community, mainly in 1999. 171 In 2002, the XMPP WG was chartered with developing an adaptation of 172 the Jabber protocol that would be suitable as an IETF instant 173 messaging and presence technology. As a result of work by the XMPP 174 WG, the current document defines the core features of XMPP; XMPP IM 175 [22] defines the extensions required to provide the instant messaging 176 (IM) and presence functionality defined in RFC 2779 [2]. 178 1.2 Terminology 180 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 181 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 182 "OPTIONAL" in this document are to be interpreted as described in RFC 183 2119 [3]. 185 1.3 Discussion Venue 187 The authors welcome discussion and comments related to the topics 188 presented in this document. The preferred forum is the 189 mailing list, for which archives and subscription 190 information are available at . 193 1.4 Intellectual Property Notice 195 This document is in full compliance with all provisions of Section 10 196 of RFC 2026. Parts of this specification use the term "jabber" for 197 identifying namespaces and other protocol syntax. Jabber[tm] is a 198 registered trademark of Jabber, Inc. Jabber, Inc. grants permission 199 to the IETF for use of the Jabber trademark in association with this 200 specification and its successors, if any. 202 2. Generalized Architecture 204 2.1 Overview 206 Although XMPP is not wedded to any specific network architecture, to 207 this point it has usually been implemented via a typical client- 208 server architecture, wherein a client utilizing XMPP accesses a 209 server over a TCP [4] socket. 211 The following diagram provides a high-level overview of this 212 architecture (where "-" represents communications that use XMPP and 213 "=" represents communications that use any other protocol). 215 C1 - S1 - S2 - C3 216 / \ 217 C2 - G1 = FN1 = FC1 219 The symbols are as follows: 221 o C1, C2, C3 -- XMPP clients 223 o S1, S2 -- XMPP servers 225 o G1 -- A gateway that translates between XMPP and the protocol(s) 226 used on a foreign (non-XMPP) messaging network 228 o FN1 -- A foreign messaging network 230 o FC1 -- A client on a foreign messaging network 232 2.2 Server 234 A server acts as an intelligent abstraction layer for XMPP 235 communications. Its primary responsibilities are to manage 236 connections from or sessions for other entities (in the form of XML 237 streams to and from authorized clients, servers, and other entities) 238 and to route appropriately-addressed XML data "stanzas" among such 239 entities over XML streams. Most XMPP-compliant servers also assume 240 responsibility for the storage of data that is used by clients (e.g., 241 contact lists for users of XMPP-based IM applications); in this case, 242 the XML data is processed directly by the server itself on behalf of 243 the client and is not routed to another entity. Compliant server 244 implementations MUST ensure in-order processing of XML stanzas 245 between any two entities. 247 2.3 Client 249 Most clients connect directly to a server over a TCP socket and use 250 XMPP to take full advantage of the functionality provided by a server 251 and any associated services. Although there is no necessary coupling 252 of an XML stream to a TCP socket (e.g., a client COULD connect via 253 HTTP polling or some other mechanism), this specification defines a 254 binding for XMPP to TCP only. Multiple resources (e.g., devices or 255 locations) MAY connect simultaneously to a server on behalf of each 256 authorized client, with each resource connecting over a discrete TCP 257 socket and differentiated by the resource identifier of a JID 258 (Section 3) (e.g., user@domain/home vs. user@domain/work). The port 259 registered with the IANA [5] for connections between a Jabber client 260 and a Jabber server is 5222. 262 2.4 Gateway 264 A gateway is a special-purpose server-side service whose primary 265 function is to translate XMPP into the protocol used by a foreign 266 (non-XMPP) messaging system, as well as to translate the return data 267 back into XMPP. Examples are gateways to SIMPLE, Internet Relay Chat 268 (IRC), Short Message Service (SMS), SMTP, and legacy instant 269 messaging networks such as AIM, ICQ, MSN Messenger, and Yahoo! 270 Instant Messenger. Communications between gateways and servers, and 271 between gateways and the foreign messaging system, are not defined in 272 this document. 274 2.5 Network 276 Because each server is identified by a network address (typically a 277 DNS hostname) and because server-to-server communications are a 278 straightforward extension of the client-to-server protocol, in 279 practice the system consists of a network of servers that inter- 280 communicate. Thus user-a@domain1 is able to exchange messages, 281 presence, and other information with user-b@domain2. This pattern is 282 familiar from messaging protocols (such as SMTP) that make use of 283 network addressing standards. Upon opening a TCP socket on the IANA- 284 registered port 5269, there are two methods for negotiating a 285 connection between any two servers: primarily SASL authentication 286 (Section 6.1) and secondarily server dialback (Section 6.2). 288 3. Addressing Scheme 290 3.1 Overview 292 An entity is anything that can be considered a network endpoint 293 (i.e., an ID on the network) and that can communicate using XMPP. 294 All such entities are uniquely addressable in a form that is 295 consistent with RFC 2396 [23]. In particular, a valid Jabber 296 Identifier (JID) contains a set of ordered elements formed of a 297 domain identifier, node identifier, and resource identifier in the 298 following format: [node@]domain[/resource]. 300 All JIDs are based on the foregoing structure. The most common use 301 of this structure is to identify an IM user, the server to which the 302 user connects, and the user's active session or connection (e.g., a 303 specific client) in the form of user@domain/resource. However, node 304 types other than clients are possible; for example, a specific chat 305 room offered by a multi-user chat service could be addressed as 306 (where "room" is the name of the chat room and 307 "service" is the hostname of the multi-user chat service) and a 308 specific occupant of such a room could be addressed as (where "nick" is the occupant's room nickname). Many other JID 310 types are possible (e.g., could be a server-side 311 script or service). 313 3.2 Domain Identifier 315 The domain identifier is the primary identifier and is the only 316 REQUIRED element of a JID (a mere domain identifier is a valid JID). 317 It usually represents the network gateway or "primary" server to 318 which other entities connect for XML routing and data management 319 capabilities. However, the entity referenced by a domain identifier 320 is not always a server, and may be a service that is addressed as a 321 subdomain of a server and that provides functionality above and 322 beyond the capabilities of a server (a multi-user chat service, a 323 user directory, a gateway to a foreign messaging system, etc.). 325 The domain identifier for every server or service that will 326 communicate over a network SHOULD resolve to a Fully Qualified Domain 327 Name. A domain identifier MUST conform to RFC 952 [6] and RFC 1123 328 [7]. A domain identifier MUST be no more than 1023 bytes in length 329 and MUST conform to the nameprep [8] profile of stringprep [9]. 331 3.3 Node Identifier 333 The node identifier is an optional secondary identifier. It usually 334 represents the entity requesting and using network access provided by 335 the server or gateway (i.e., a client), although it can also 336 represent other kinds of entities (e.g., a multi-user chat room 337 associated with a multi-user chat service). The entity represented 338 by a node identifier is addressed within the context of a specific 339 domain; within IM applications of XMPP this address is called a "bare 340 JID" and is of the form . 342 A node identifier MUST be no more than 1023 bytes in length and MUST 343 conform to the nodeprep [10] profile of stringprep [9]. 345 3.4 Resource Identifier 347 The resource identifier is an optional tertiary identifier, which may 348 modify either a "user@domain" or mere "domain" address. It usually 349 represents a specific session, connection (e.g., a device or 350 location), or object (e.g., a participant in a multi-user chat room) 351 belonging to the entity associated with a node identifier. A 352 resource identifier is typically defined by a client implementation 353 and is opaque to both servers and other clients. An entity may 354 maintain multiple resources simultaneously. 356 A resource identifier MUST be no more than 1023 bytes in length and 357 MUST conform to the resourceprep [11] profile of stringprep [9]. 359 4. XML Streams 361 4.1 Overview 363 Two fundamental concepts make possible the rapid, asynchronous 364 exchange of relatively small payloads of structured information 365 between presence-aware entities: XML streams and XML stanzas. The 366 terms may be defined as follows: 368 Definition of XML stream: An XML stream is a container for the 369 exchange of XML elements between any two entities over a network. 370 An XML stream is negotiated from an initiating entity (usually a 371 client or server) to a receiving entity (usually a server), 372 normally over a TCP socket, and corresponds to the initiating 373 entity's "session" with the receiving entity. The start of the 374 XML stream is denoted unambiguously by an opening XML tag 375 with appropriate attributes and namespace declarations, and the 376 end of the XML stream is denoted unambiguously be a closing XML tag. An XML stream is unidirectional; in order to enable 378 bidirectional information exchange, the initiating entity and 379 receiving entity must negotiate one stream in each direction, 380 normally over the same TCP connection. 382 Definition of XML stanza: An XML stanza is a discrete semantic unit 383 of structured information that is sent from one entity to another 384 over an XML stream. An XML stanza exists at the direct child 385 level of the root element and is said to be well- 386 balanced if it matches production [43] content of the XML 387 specification [1]). The start of any XML stanza is denoted 388 unambiguously by the element start tag at depth=1 (e.g., 389 ), and the end of any XML stanza is denoted 390 unambiguously by the corresponding close tag at depth=1 (e.g., ). An XML stanza MAY contain child elements (with 392 accompanying attributes, elements, and CDATA) as necessary in 393 order to convey the desired information. 395 Consider the example of a client's session with a server. In order 396 to connect to a server, a client must initiate an XML stream by 397 sending an opening tag to the server, optionally preceded by 398 a text declaration specifying the XML version supported and the 399 character encoding. The server SHOULD then reply with a second XML 400 stream back to the client, again optionally preceded by a text 401 declaration. Once the client has authenticated with the server (see 402 Section 6), the client MAY send an unlimited number of XML stanzas 403 over the stream to any recipient on the network. When the client 404 desires to close the stream, it simply sends a closing tag 405 to the server (alternatively, the session may be closed by the 406 server), after which both the client and server SHOULD close the 407 underlying TCP connection as well. 409 Those who are accustomed to thinking of XML in a document-centric 410 manner may wish to view a client's session with a server as 411 consisting of two open-ended XML documents: one from the client to 412 the server and one from the server to the client. From this 413 perspective, the root element can be considered the 414 document entity for each "document", and the two "documents" are 415 built up through the accumulation of XML stanzas sent over the two 416 XML streams. However, this perspective is a convenience only, and 417 XMPP does not deal in documents but in XML streams and XML stanzas. 419 In essence, then, an XML stream acts as an envelope for all the XML 420 stanzas sent during a session. We can represent this graphically as 421 follows: 423 |-------------------| 424 | | 425 |-------------------| 426 | | 427 | | 428 | | 429 |-------------------| 430 | | 431 | | 432 | | 433 |-------------------| 434 | | 435 | | 436 | | 437 |-------------------| 438 | ... | 439 |-------------------| 440 | | 441 |-------------------| 443 4.2 Stream Attributes 445 The attributes of the stream element are as follows: 447 o to -- The 'to' attribute SHOULD be used only in the XML stream 448 header from the initiating entity to the receiving entity, and 449 MUST be set to the XMPP address of the receiving entity. There 450 SHOULD be no 'to' attribute set in the XML stream header by which 451 the receiving entity replies to the initiating entity; however, if 452 a 'to' attribute is included, it SHOULD be silently ignored by the 453 initiating entity. 455 o from -- The 'from' attribute SHOULD be used only in the XML stream 456 header from the receiving entity to the initiating entity, and 457 MUST be set to the XMPP address of the receiving entity granting 458 access to the initiating entity. There SHOULD be no 'from' 459 attribute on the XML stream header sent from the initiating entity 460 to the receiving entity; however, if a 'from' attribute is 461 included, it SHOULD be silently ignored by the receiving entity. 463 o id -- The 'id' attribute SHOULD be used only in the XML stream 464 header from the receiving entity to the initiating entity. This 465 attribute is a unique identifier created by the receiving entity 466 to function as a session key for the initiating entity's session 467 with the receiving entity. There SHOULD be no 'id' attribute on 468 the XML stream header sent from the initiating entity to the 469 receiving entity; however, if an 'id' attribute is included, it 470 SHOULD be silently ignored by the receiving entity. 472 o version -- The 'version' attribute MAY be used in the XML stream 473 header from the initiating entity to the receiving entity in order 474 signal compliance with the protocol defined herein; this is done 475 by setting the value of the attribute to "1.0". If the initiating 476 entity includes the version attribute and the receiving entity 477 supports XMPP 1.0, the receiving entity MUST reciprocate by 478 including the attribute in its response. 480 We can summarize these values as follows: 482 | initiating to receiving | receiving to initiating 483 ------------------------------------------------------------ 484 to | hostname of receiver | silently ignored 485 from | silently ignored | hostname of receiver 486 id | silently ignored | session key 487 version | signals XMPP 1.0 support | signals XMPP 1.0 support 489 4.3 Namespace Declarations 491 The stream element MAY contain namespace declarations as defined in 492 the XML namespaces specification [12]. 494 A stream namespace declaration (e.g., 'xmlns:stream') is REQUIRED in 495 both XML streams. A compliant entity SHOULD accept any namespace 496 prefix on the element; however, for historical reasons some 497 entities MAY accept only a 'stream' prefix, resulting in the use of a 498 element as the stream root. The name of the stream 499 namespace MUST be "http://etherx.jabber.org/streams". 501 A default namespace declaration ('xmlns') is REQUIRED and is used in 502 both XML streams in order to define the allowable first-level 503 children of the root stream element for both streams. This namespace 504 declaration MUST be the same for the initiating stream and the 505 responding stream so that both streams are scoped consistently. The 506 default namespace declaration applies to the stream and all stanzas 507 sent within a stream (unless explicitly scoped by another namespace). 509 Since XML streams function as containers for any XML stanzas sent 510 asynchronously between network endpoints, it should be possible to 511 scope an XML stream with any default namespace declaration (i.e., it 512 should be possible to send any properly-namespaced XML stanza over an 513 XML stream). At a minimum, a compliant implementation MUST support 514 the following two namespaces (for historical reasons, some 515 implementations MAY support only these two default namespaces): 517 o jabber:client -- this default namespace is declared when the 518 stream is used for communications between a client and a server 520 o jabber:server -- this default namespace is declared when the 521 stream is used for communications between two servers 523 The jabber:client and jabber:server namespaces are nearly identical 524 but are used in different contexts (client-to-server communications 525 for jabber:client and server-to-server communications for 526 jabber:server). The only difference between the two is that the 'to' 527 and 'from' attributes are OPTIONAL on stanzas sent within 528 jabber:client, whereas they are REQUIRED on stanzas sent within 529 jabber:server. If a compliant implementation accepts a stream that 530 is scoped by the 'jabber:client' or 'jabber:server' namespace, it 531 MUST support all three core stanza types (message, presence, and IQ) 532 as described herein and defined in the schema. 534 4.4 Stream Features 536 The root stream element MAY contain a features child element (e.g., 537 if the stream namespace prefix is 'stream'). This 538 is used to communicate generic stream-level capabilities including 539 stream-level features that can be negotiated as the streams are set 540 up. If the initiating entity sends a "version='1.0'" flag in its 541 initiating stream element, the receiving entity MUST send a features 542 child element to the initiating entity if there are any capabilities 543 that need to be advertised or features that can be negotiated for the 544 stream. Currently this is used for SASL and TLS negotiation only, 545 but it could be used for other negotiable features in the future 546 (usage is defined under Stream Encryption (Section 5) and Stream 547 Authentication (Section 6) below). If an entity does not understand 548 or support some features, it SHOULD silently ignore them. 550 4.5 Stream Errors 552 The root stream element MAY contain an error child element (e.g., 553 if the stream namespace prefix is 'stream'). The 554 error child MUST be sent by a compliant entity (usually a server 555 rather than a client) if it perceives that a stream-level error has 556 occurred. 558 4.5.1 Rules 560 The following rules apply to stream-level errors: 562 o It is assumed that all stream-level errors are unrecoverable; 563 therefore, if an error occurs at the level of the stream, the 564 entity that detects the error MUST send a stream error to the 565 other entity, send a closing tag, and close the 566 underlying TCP connection. 568 o If the error occurs while the stream is being set up, the 569 receiving entity MUST still send the opening and closing stream 570 tags and include the error element as a child of the stream 571 element. In this case, if the initiating entity provides an 572 unknown host in the 'to' attribute (or provides no 'to' attribute 573 at all), the server SHOULD provide the server's authoritative 574 hostname in the 'from' attribute of the stream header sent before 575 termination. 577 4.5.2 Syntax 579 The syntax for stream errors is as follows: 581 582 583 584 585 587 The value of the 'class' attribute must be one of the following: 589 o address -- the condition relates to the JID or domain to which the 590 stream was addressed 592 o format -- the condition relates to XML format or structure 594 o redirect -- the condition relates to a host redirection 596 o server -- the condition relates to the internal state of the 597 server 599 The element MUST contain a child element that 600 specifies a particular stream-level error condition, as defined in 601 the next section. (Note: the XML namespace name 602 'urn:ietf:params:xml:ns:xmpp-streams' that scopes the element adheres to the format defined in The IETF XML 604 Registry [24].) 606 4.5.3 Conditions 608 The following stream-level error conditions are defined: 610 o -- the value of the 'to' attribute provided by the 611 initiating entity in the stream header corresponds to a hostname 612 that is no longer hosted by the server; the associated class is 613 "address". 615 o -- the value of the 'to' attribute provided by the 616 initiating entity in the stream header does not correspond to a 617 hostname that is hosted by the server; the associated class is 618 "address". 620 o -- the server has experienced a 621 misconfiguration or an otherwise-undefined internal server error 622 that prevents it from servicing the stream; the associated class 623 is "server". 625 o -- the stream ID or dialback ID is invalid or does 626 not match an ID previously provided; the associated class is 627 "format". 629 o -- the stream namespace name is something 630 other than "http://etherx.jabber.org/streams" or the dialback 631 namespace name is something other than "jabber:server:dialback"; 632 the associated class is "format". 634 o -- the hostname provided in a 'from' address 635 does not match the hostname (or any validated domain) negotiated 636 via SASL or dialback; the associated class is "address". 638 o -- the server is unable to properly 639 connect to a remote resource that is required for authentication 640 or authorization; the associated class is "server". 642 o -- the server is resource-contrained and is 643 unable to service the stream; the associated class is "server". 645 o -- the server will not provide service to the 646 initiating entity but is redirecting traffic to another host; this 647 element SHOULD contain CDATA specifying the alternate hostname or 648 IP address to which the initiating entity MAY attempt to connect; 649 the associated class is "redirect". 651 o -- the server is being shut down and all active 652 streams are being closed; the associated class is "server". 654 o -- the initiating entity has sent a 655 first-level child of the stream that is not supported by the 656 server; the associated class is "format". 658 o -- the value of the 'version' attribute 659 provided by the initiating entity in the stream header specifies a 660 version of XMPP that is not supported by the server; this element 661 MAY contain CDATA specifying the XMPP version(s) supported by the 662 server; the associated class is "format". 664 o -- the initiating entity has sent XML that 665 is not well-formed as defined by the XML specification [1]; the 666 associated class is "format". 668 4.5.4 Extensibility 670 If desired, an XMPP application MAY provide custom error information; 671 this MUST be contained in a properly-namespaced child of the element (i.e., the namespace name MUST NOT be one of the 673 namespace names defined herein). 675 4.6 Simple Streams Example 677 The following is a stream-based session of a client on a server 678 (where the "C" lines are sent from the client to the server, and the 679 "S" lines are sent from the server to the client): 681 A basic session: 683 C: 684 689 S: 690 696 ... authentication ... 697 C: 699 C: Art thou not Romeo, and a Montague? 700 C: 701 S: 703 S: Neither, fair saint, if either thee dislike. 704 S: 705 C: 706 S: 707 A session gone bad: 709 C: 710 715 S: 716 722 ... authentication ... 723 C: Bad XML, no closing body tag! 724 S: 725 726 727 728 729 S: 731 5. Stream Encryption 733 5.1 Overview 735 XMPP includes a method for securing the stream from tampering and 736 eavesdropping. This channel encryption method makes use of the 737 Transport Layer Security (TLS) [13] protocol, along with a "STARTTLS" 738 extension that is modelled on similar extensions for the IMAP [25], 739 POP3 [26], and ACAP [27] protocols as described in RFC 2595 [28]. 740 The namespace identifier for the STARTTLS extension is 741 'urn:ietf:params:xml:ns:xmpp-tls'. 743 TLS SHOULD be used between any initiating entity and any receiving 744 entity (e.g., a stream from a client to a server or from one server 745 to another). An administrator of a given domain MAY require use of 746 TLS for either or both client-to-server communications and server-to- 747 server communications. Servers SHOULD use TLS betweeen two domains 748 for the purpose of securing server-to-server communcations. When the 749 remote domain is already known, the server can verify the credentials 750 of the known domain by comparing known keys or certificates. When 751 the remote domain is not recognized, it may still be possible to 752 verify a certificate if it is signed by a common trusted authority. 753 Even if there is no way to verify certificates (e.g., an unknown 754 domain with a self-signed certificate, or a certificate signed by an 755 unrecognized authority), if the servers choose to communicate despite 756 the lack of verified credentials, TLS still SHOULD be used to provide 757 encryption. 759 The following business rules apply: 761 1. An initiating entity that complies with this specification MUST 762 include the "version='1.0'" flag in the initiating stream header. 764 2. When a receiving entity that complies with this specification 765 receives an initiating stream header that includes the 766 "version='1.0'" flag, after sending a stream header in reply it 767 MUST also send a element scoped by the 768 'urn:ietf:params:xml:ns:xmpp-tls' namespace as well as the list 769 of other stream features it supports. 771 3. If the initiating entity chooses to use TLS for stream 772 encryption, TLS negotiation MUST be completed before proceeding 773 to SASL negotiation. 775 4. The initiating entity MUST validate the certificate presented by 776 the receiving entity: 778 1. If the initiating entity has been configured with a set of 779 trusted roots, either a well-known public set or a manually 780 configured Certificate Authority (e.g., an organization's own 781 Certificate Authority), normal certificate validation 782 processing is appropriate. 784 2. If the initiating entity has been configured with the 785 receiving entity's public key or certificate, a simple 786 comparison is appropriate. 788 If the above methods fail, the certificate MAY be presented to a 789 user for approval; the user SHOULD be given the option to store 790 the certificate and not ask again for at least some reasonable 791 period of time. 793 5. If the TLS negotiation is successful, the receiving entity MUST 794 discard any knowledge obtained from the initiating entity before 795 TLS takes effect. 797 6. If the TLS negotiation is successful, the initiating entity MUST 798 discard any knowledge obtained from the receiving entity before 799 TLS takes effect. 801 7. If the TLS negotiation is successful, the receiving entity MUST 802 NOT offer the STARTTLS extension to the initiating entity along 803 with the other stream features that are offered when the stream 804 is restarted. 806 8. If the TLS negotiation results in success, the initiating entity 807 SHOULD continue with SASL negotiation. 809 9. If the TLS negotiation results in failure, the receiving entity 810 MUST terminate both the stream and the underlying TCP connection. 812 5.2 Narrative 814 When an initiating entity secures a stream with a receiving entity, 815 the steps involved are as follows: 817 1. The initiating entity opens a TCP connection and initiates the 818 stream by sending the opening XML stream header to the receiving 819 entity, including the "version='1.0'" flag. 821 2. The receiving entity responds by opening a TCP connection and 822 sending an XML stream header to the initiating entity. 824 3. The receiving entity offers the STARTTLS extension to the 825 initiating entity by sending it along with the list of supported 826 stream features. 828 4. The initiating entity issues the STARTTLS command to instruct the 829 receiving entity that it wishes to begin a TLS negotiation to 830 secure the stream. 832 5. The receiving entity MUST reply with either a element 833 or a element scoped by the 834 'urn:ietf:params:xml:ns:xmpp-tls' namespace, but keep the 835 underlying TCP connection open. 837 6. The initiating entity begins a TLS negotiation in accordance with 838 RFC 2246 [13]. Upon completion of the negotiation, the 839 initiating entity initiates a new stream by sending a new opening 840 XML stream header to the receiving entity. 842 7. The receiving entity responds by sending an XML stream header to 843 the initiating entity along with the remaining available features 844 (but NOT including the STARTTLS element). 846 5.3 Client-to-Server Example 848 The following example shows the data flow for a client securing a 849 stream using STARTTLS. 851 Step 1: Client initiates stream to server: 853 859 Step 2: Server responds by sending a stream tag to the client: 861 867 Step 3: Server sends the STARTTLS extension to the client along with 868 authentication mechanisms and any other stream features (if TLS is 869 required for interaction with this server, the server SHOULD signal 870 that fact by including a element as a child of the 871 element): 873 874 875 876 877 878 DIGEST-MD5 879 PLAIN 880 881 883 Step 4: Client sends the STARTTLS command to the server: 885 887 Step 5: Server informs client to proceed: 889 891 Step 5 (alt): Server informs client that TLS negotiation has failed 892 and closes stream: 894 895 897 Step 6: Client and server complete TLS negotiation over the existing 898 TCP connection. 900 Step 7: Client initiates a new stream to the server: 902 908 Step 8: Server responds by sending a stream header to the client 909 along with any remaining negotiatiable stream features: 911 916 917 918 DIGEST-MD5 919 PLAIN 920 EXTERNAL 921 922 924 Step 9: Client SHOULD continue with stream authentication (Section 925 6). 927 5.4 Server-to-Server Example 929 The following example shows the data flow for two servers securing a 930 stream using STARTTLS. 932 Step 1: Server1 initiates stream to Server2: 934 939 Step 2: Server2 responds by sending a stream tag to Server1: 941 947 Step 3: Server2 sends the STARTTLS extension to Server1 along with 948 authentication mechanisms and any other stream features (if TLS is 949 required for interaction with Server2, it SHOULD signal that fact by 950 including a element as a child of the 951 element): 953 954 955 956 957 958 DIGEST-MD5 959 KERBEROS_V4 960 961 963 Step 4: Server1 sends the STARTTLS command to Server2: 965 967 Step 5: Server2 informs Server1 to proceed: 969 971 Step 5 (alt): Server2 informs Server1 that TLS negotiation has failed 972 and closes stream: 974 975 977 Step 6: Server1 and Server2 complete TLS negotiation via TCP. 979 Step 7: Server1 initiates a new stream to Server2: 981 986 Step 8: Server2 responds by sending a stream header to Server1 along 987 with any remaining negotiatiable stream features: 989 994 995 996 DIGEST-MD5 997 KERBEROS_V4 998 EXTERNAL 999 1000 1002 Step 9: Server1 SHOULD continue with stream authentication (Section 1003 6). 1005 6. Stream Authentication 1007 XMPP includes two methods for enforcing authentication at the level 1008 of XML streams. The secure and preferred method for authenticating 1009 streams between two entities uses an XMPP adaptation of the Simple 1010 Authentication and Security Layer (SASL) [14]. If SASL negotiation 1011 is not possible, some level of trust MAY be established based on 1012 existing trust in DNS; the authentication method used in this case is 1013 the server dialback protocol that is native to XMPP (no such ad-hoc 1014 method is defined between a client and a server). If SASL is used 1015 for server-to-server authentication, the servers MUST NOT use 1016 dialback. For further information about the relative merits of these 1017 two methods, consult Security Considerations (Section 11). 1019 Stream authentication is REQUIRED for all direct communications 1020 between two entities; if an entity sends a stanza to an 1021 unauthenticated stream, the receiving entity SHOULD silently drop the 1022 stanza and MUST NOT process it. 1024 6.1 SASL Authentication 1026 6.1.1 Overview 1028 The Simple Authentication and Security Layer (SASL) provides a 1029 generalized method for adding authentication support to connection- 1030 based protocols. XMPP uses a generic XML namespace profile for SASL 1031 that conforms to section 4 ("Profiling Requirements") of RFC 2222 1032 [14] (the XMPP-specific namespace identifier is 1033 'urn:ietf:params:xml:ns:xmpp-sasl'). 1035 The following business rules apply: 1037 1. If TLS is used for stream encryption, SASL MUST NOT be used for 1038 anything but stream authentication (i.e., a security layer MUST 1039 NOT be negotiated using SASL). Conversely, if a security layer 1040 is to be negotiated via SASL, TLS MUST NOT be used. 1042 2. If the initiating entity is capable of authenticating via SASL, 1043 it it MUST include the "version='1.0'" flag in the initiating 1044 stream header. 1046 3. If the receiving entity is capable of accepting authentications 1047 via SASL, it MUST send one or more authentication mechanisms 1048 within a element scoped by the 1049 'urn:ietf:params:xml:ns:xmpp-sasl' namespace in response to the 1050 opening stream tag received from the initiating entity. 1052 4. If the SASL negotiation involves negotiation of a security layer, 1053 the receiving entity MUST discard any knowledge obtained from the 1054 initiating entity which was not obtained from the SASL 1055 negotiation itself. 1057 5. If the SASL negotiation involves negotiation of a security layer, 1058 the initiating entity MUST discard any knowledge obtained from 1059 the receiving entity which was not obtained from the SASL 1060 negotiation itself. 1062 The following syntax rules apply: 1064 1. The initial challenge MUST include a realm, nonce, qop, charset, 1065 and algorithm. 1067 2. The inital response for client-to-server negotiation MUST include 1068 a username, realm, nonce, cnonce, nc, qop, digest-uri, response, 1069 charset, and authzid. 1071 3. The inital response for server-to-server negotiation MUST include 1072 a realm, nonce, cnonce, nc, qop, digest-uri, response, and 1073 charset. 1075 4. The realm-value MUST be no more than 1023 bytes in length and 1076 MUST conform to the nameprep [8] profile of stringprep [9]. 1078 5. The username-value MUST be no more than 1023 bytes in length and 1079 MUST conform to the nodeprep [10] profile of stringprep [9]. 1081 6. The response-value MUST be computed in accordance with the 1082 relevant SASL mechanism as defined by the appropriate RFC (e.g., 1083 RFC 2831 [15] for digest authentication). 1085 7. The resource identifier portion of the authzid-value MUST be no 1086 more than 1023 bytes in length and MUST conform to the 1087 resourceprep [11] profile of stringprep [9]. 1089 6.1.2 Narrative 1091 When an initiating entity authenticates with a receiving entity, the 1092 steps involved are as follows: 1094 1. The initiating entity requests SASL authentication by including a 1095 'version' attribute in the opening XML stream header sent to the 1096 receiving entity, with the value set to "1.0". 1098 2. After sending an XML stream header in response, the receiving 1099 entity sends a list of available SASL authentication mechanisms, 1100 each of which is a element included as a child 1101 within a container element scoped by the 1102 'urn:ietf:params:xml:ns:xmpp-sasl' namespace that is sent as a 1103 child of a element in the streams namespace. If 1104 channel encryption must be established before a particular 1105 authentication mechanism may be used, the receiving entity MUST 1106 NOT provide that mechanism in the list of available SASL 1107 authentication methods. If the initiating entity presents a 1108 valid initiating entity certificate during TLS negotiation, the 1109 receiving entity MAY offer the SASL EXTERNAL mechanism to the 1110 initiating entity during stream authentication (see RFC 2222 1111 [14]). 1113 3. The initiating entity selects a mechanism by sending an 1114 element scoped by the 'urn:ietf:params:xml:ns:xmpp-sasl' 1115 namespace to the receiving entity; this element MAY optionally 1116 contain character data (in SASL terminology the "initial 1117 response") if the mechanism supports or requires it. If the 1118 initiating entity selects the EXTERNAL mechanism for 1119 authentication, the authentication credentials shall be taken 1120 from the certificate presented during TLS negotiation. 1122 4. If necessary, the receiving entity challenges the initiating 1123 entity by sending a element scoped by the 1124 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating 1125 entity; this element MAY optionally contain character data (which 1126 MUST be computed in accordance with the SASL mechanism chosen by 1127 the initiating entity). 1129 5. The initiating entity responds to the challenge by sending a 1130 element scoped by the 'urn:ietf:params:xml:ns:xmpp- 1131 sasl' namespace to the receiving entity; this element MAY 1132 optionally contain character data (which MUST be computed in 1133 accordance with the SASL mechanism chosen by the initiating 1134 entity). 1136 6. If necessary, the receiving entity sends more challenges and the 1137 initiating entity sends more responses. 1139 This series of challenge/response pairs continues until one of three 1140 things happens: 1142 1. The initiating entity aborts the handshake by sending an 1143 element to the receiving entity. 1145 2. The receiving entity reports failure of the handshake by sending 1146 a element scoped by the 'urn:ietf:params:xml:ns:xmpp- 1147 sasl' namespace to the initiating entity. The particular cause 1148 of failure SHOULD be communicated in an appropriate child element 1149 of the element. The following conditions are defined: 1151 * 1153 * 1155 * 1157 * 1159 * 1161 * 1163 3. The receiving entity reports success of the handshake by sending 1164 a element scoped by the 'urn:ietf:params:xml:ns:xmpp- 1165 sasl' namespace to the initiating entity; this element MAY 1166 optionally contain character data (in SASL terminology 1167 "additional data with success"). 1169 Any character data contained within these elements MUST be encoded 1170 using base64. 1172 6.1.3 SASL Definition 1174 Section 4 of the SASL specification [14] requires that the following 1175 information be supplied by a protocol definition: 1177 service name: "xmpp" 1179 initiation sequence: After the initiating entity provides an opening 1180 XML stream header and the receiving entity replies in kind, the 1181 receiving entity provides a list of acceptable authentication 1182 methods. The initiating entity chooses one method from the list 1183 and sends it to the receiving entity as the value of the 1184 'mechanism' attribute possessed by an element, optionally 1185 including an initial response to avoid a round trip. 1187 exchange sequence: Challenges and responses are carried through the 1188 exchange of elements from receiving entity to 1189 initiating entity and elements from initiating entity 1190 to receiving entity. The receiving entity reports failure by 1191 sending a element and success by sending a 1192 element; the initiating entity aborts the exchange by sending an 1193 element. (All of these elements are scoped by the 1194 'urn:ietf:params:xml:ns:xmpp-sasl' namespace.) 1196 security layer negotiation: If a security layer is negotiated, both 1197 sides consider the original stream closed and new 1198 headers are sent by both entities. The security layer takes 1199 effect immediately following the ">" character of the 1200 element for the client and immediately following the closing ">" 1201 character of the element for the server. (Both of 1202 these elements are scoped by the 'urn:ietf:params:xml:ns:xmpp- 1203 sasl' namespace.) 1205 use of the authorization identity: The authorization identity is used 1206 by xmpp only in negotiation between a client and a server, and 1207 denotes the "full JID" (user@host/resource) requested by the user 1208 or application associated with the client. 1210 6.1.4 Client-to-Server Example 1212 The following example shows the data flow for a client authenticating 1213 with a server using SASL. 1215 Step 1: Client initiates stream to server: 1217 1223 Step 2: Server responds with a stream tag sent to the client: 1225 1232 Step 3: Server informs client of available authentication mechanisms: 1234 1235 1236 DIGEST-MD5 1237 PLAIN 1238 1239 1240 Step 4: Client selects an authentication mechanism: 1242 1246 Step 5: Server sends a base64-encoded challenge to the client: 1248 1249 cmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIi 1250 xxb3A9ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNz 1251 1253 The decoded challenge is: 1255 realm="cataclysm.cx",nonce="OA6MG9tEQGm2hh",\ 1256 qop="auth",charset=utf-8,algorithm=md5-sess 1258 Step 6: Client responds to the challenge: 1260 1261 dXNlcm5hbWU9InJvYiIscmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik 1262 9BNk1HOXRFUUdtMmhoIixcIGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5j 1263 PTAwMDAwMDAxLHFvcD1hdXRoLFwgZGlnZXN0LXVyaT0ieG1wcC9jYXRhY2 1264 x5c20uY3giLFwgcmVzcG9uc2U9ZDM4OGRhZDkwZDRiYmQ3NjBhMTUyMzIxZ 1265 jIxNDNhZjcsY2hhcnNldD11dGYtOA== 1266 1268 The decoded response is: 1270 username="rob",realm="cataclysm.cx",\ 1271 nonce="OA6MG9tEQGm2hh",cnonce="OA6MHXh6VqTrRk",\ 1272 nc=00000001,qop=auth,digest-uri="xmpp/cataclysm.cx",\ 1273 response=d388dad90d4bbd760a152321f2143af7,charset=utf-8,\ 1274 authzid="rob@cataclysm.cx/myResource" 1276 Step 7: Server sends another challenge to the client: 1278 1279 cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA== 1280 1282 The decoded challenge is: 1284 rspauth=ea40f60335c427b5527b84dbabcdfffd 1285 Step 8: Client responds to the challenge: 1287 1289 Step 9: Server informs client of successful authentication: 1291 1293 Step 9 (alt): Server informs client of failed authentication: 1295 1296 1297 1299 Step 10: Client initiates a new stream to the server: 1301 1307 Step 11: Server responds by sending a stream header to the client, 1308 with the stream already authenticated (not followed by further stream 1309 features): 1311 1318 6.1.5 Server-to-Server Example 1320 The following example shows the data flow for a server authenticating 1321 with another server using SASL. 1323 Step 1: Server1 initiates stream to Server2: 1325 1330 Step 2: Server2 responds with a stream tag sent to Server1: 1332 1338 Step 3: Server2 informs Server1 of available authentication 1339 mechanisms: 1341 1342 1343 DIGEST-MD5 1344 KERBEROS_V4 1345 1346 1348 Step 4: Server1 selects an authentication mechanism: 1350 1354 Step 5: Server2 sends a base64-encoded challenge to Server1: 1356 1357 cmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIi 1358 xxb3A9ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNz 1359 1361 The decoded challenge is: 1363 realm="cataclysm.cx",nonce="OA6MG9tEQGm2hh",\ 1364 qop="auth",charset=utf-8,algorithm=md5-sess 1366 Step 6: Server1 responds to the challenge: 1368 1369 cmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIi 1370 xjbm9uY2U9Ik9BNk1IWGg2VnFUclJrIixuYz0wMDAwMDAwMSxxb3A9YXV0 1371 aCxkaWdlc3QtdXJpPSJ4bXBwL2NhdGFjbHlzbS5jeCIscmVzcG9uc2U9ZD 1372 M4OGRhZDkwZDRiYmQ3NjBhMTUyMzIxZjIxNDNhZjcsY2hhcnNldD11dGYt 1373 OAo= 1374 1376 The decoded response is: 1378 realm="cataclysm.cx",nonce="OA6MG9tEQGm2hh",cnonce="OA6MHXh6VqTrRk",\ 1379 nc=00000001,qop=auth,digest-uri="xmpp/cataclysm.cx",\ 1380 response=d388dad90d4bbd760a152321f2143af7,charset=utf-8 1382 Step 7: Server2 sends another challenge to Server1: 1384 1385 cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA== 1386 1388 The decoded challenge is: 1390 rspauth=ea40f60335c427b5527b84dbabcdfffd 1392 Step 8: Server1 responds to the challenge: 1394 1396 Step 9: Server2 informs Server1 of successful authentication: 1398 1400 Step 9 (alt): Server2 informs Server1 of failed authentication: 1402 1403 1404 1406 Step 10: Server1 initiates a new stream to Server2: 1408 1413 Step 11: Server2 responds by sending a stream header to Server1, with 1414 the stream already authenticated (not followed by further stream 1415 features): 1417 1423 6.2 Dialback Authentication 1425 XMPP includes a protocol-level method for verifying that a connection 1426 between two servers can be trusted as much as the DNS can be trusted. 1427 The method is called dialback and is used only within XML streams 1428 that are declared under the "jabber:server" namespace. 1430 The purpose of the dialback protocol is to make server spoofing more 1431 difficult, and thus to make it more difficult to forge XML stanzas. 1432 Dialback is decidedly not intended as a mechanism for securing or 1433 encrypting the streams between servers as is done via SASL and TLS, 1434 only for helping to prevent the spoofing of a server and the sending 1435 of false data from it. In particular, dialback authentication is 1436 susceptible to DNS poisoning attacks unless DNSSec [29] is used. 1437 Furthermore, even if the DNS information is accurate, dialback 1438 authentication cannot protect from attacks where the attacker is 1439 capable of hijacking the IP address of the remote domain. Domains 1440 requiring more robust security SHOULD use TLS and SASL as defined 1441 above. 1443 Server dialback is made possible by the existence of DNS, since one 1444 server can verify that another server which is connecting to it is 1445 authorized to represent a given hostname. All DNS hostname 1446 resolutions MUST first resolve the hostname using an SRV [17] record 1447 of _jabber._tcp.server. If the SRV lookup fails, the fallback is a 1448 normal A lookup to determine the IP address, using the jabber-server 1449 port of 5269 assigned by the Internet Assigned Numbers Authority [5]. 1451 The method for generating and verifying the keys used in the dialback 1452 protocol MUST take into account the hostnames being used, the random 1453 ID generated for the stream, and a secret known by the authoritative 1454 server's network. Generating unique but verifiable keys is important 1455 to prevent common man-in-the-middle attacks and server spoofing. 1457 Any error that occurs during dialback negotiation MUST be considered 1458 a stream error, resulting in termination of the stream and of the 1459 underlying TCP connection. The possible error conditions are 1460 specified in the protocol description below. 1462 The following terminology applies: 1464 o Originating Server -- the server that is attempting to establish a 1465 connection between two domains. 1467 o Receiving Server -- the server that is trying to authenticate that 1468 Originating Server represents the domain which it claims to be. 1470 o Authoritative Server -- the server that answers to the DNS 1471 hostname asserted by Originating Server; for basic environments 1472 this will be Originating Server, but it could be a separate 1473 machine in Originating Server's network. 1475 The following is a brief summary of the order of events in dialback: 1477 1. Originating Server establishes a connection to Receiving Server. 1479 2. Originating Server sends a 'key' value over the connection to 1480 Receiving Server. 1482 3. Receiving Server establishes a connection to Authoritative 1483 Server. 1485 4. Receiving Server sends the same 'key' value to Authoritative 1486 Server. 1488 5. Authoritative Server replies that key is valid or invalid. 1490 6. Receiving Server tells Originating Server whether it is 1491 authenticated or not. 1493 We can represent this flow of events graphically as follows: 1495 Originating Receiving 1496 Server Server 1497 ----------- --------- 1498 | | 1499 | establish connection | 1500 | ----------------------> | 1501 | | 1502 | send stream header | 1503 | ----------------------> | 1504 | | 1505 | establish connection | 1506 | <---------------------- | 1507 | | 1508 | send stream header | 1509 | <---------------------- | 1510 | | Authoritative 1511 | send dialback key | Server 1512 | ----------------------> | ------------- 1513 | | | 1514 | establish connection | 1515 | ----------------------> | 1516 | | 1517 | send stream header | 1518 | ----------------------> | 1519 | | 1520 | establish connection | 1521 | <---------------------- | 1522 | | 1523 | send stream header | 1524 | <---------------------- | 1525 | | 1526 | send dialback key | 1527 | ----------------------> | 1528 | | 1529 | validate dialback key | 1530 | <---------------------- | 1531 | 1532 | report dialback result | 1533 | <---------------------- | 1534 | | 1536 6.2.1 Dialback Protocol 1538 The interaction between the servers is as follows: 1540 1. Originating Server establishes TCP connection to Receiving 1541 Server. 1543 2. Originating Server sends a stream header to Receiving Server: 1545 1550 Note: the 'to' and 'from' attributes are NOT REQUIRED on the 1551 root stream element. The inclusion of the xmlns:db namespace 1552 declaration with the name shown indicates to Receiving Server 1553 that Originating Server supports dialback. If the namespace 1554 name is incorrect, then Receiving Server MUST generate an 1555 stream error condition and terminate both 1556 the stream and the underlying TCP connection. 1558 3. Receiving Server SHOULD send a stream header back to Originating 1559 Server, including a unique ID for this interaction: 1561 1567 Note: Receiving Server is NOT REQUIRED to reply, and SHOULD NOT 1568 reply if there exists an established session between Receiving 1569 Server and the hostname asserted by Originating Server. The 1570 'to' and 'from' attributes are NOT REQUIRED on the root stream 1571 element. If the namespace name is incorrect, then Originating 1572 Server MUST generate an stream error 1573 condition and terminate both the stream and the underlying TCP 1574 connection. 1576 4. Originating Server sends a dialback key to Receiving Server: 1578 1581 98AF014EDC0... 1582 1584 Note: this key is not examined by Receiving Server, since 1585 Receiving Server does not keep information about Originating 1586 Server between sessions. The key generated by Originating 1587 Server must be based in part on the value of the ID provided by 1588 Receiving Server in the previous step, and in part on a secret 1589 shared by Originating Server and Authoritative Server. If the 1590 value of the 'to' address does not match a hostname recognized 1591 by Receiving Server, then Receiving Server MUST generate a 1592 stream error condition and terminate both the 1593 stream and the underlying TCP connection. If the value of the 1594 'from' address does not match the hostname represented by 1595 Originating Server when opening the TCP connection (or any 1596 validated domain), then Receiving Server MUST generate a 1597 stream error condition and terminate both 1598 the stream and the underlying TCP connection. 1600 5. Receiving Server establishes a TCP connection back to the domain 1601 name asserted by Originating Server, as a result of which it 1602 connects to Authoritative Server. (Note: as an optimization, an 1603 implementation MAY reuse an existing trusted connection here 1604 rather than opening a new TCP connection.) 1606 6. Receiving Server sends Authoritative Server a stream header: 1608 1613 Note: the 'to' and 'from' attributes are NOT REQUIRED on the 1614 root stream element. If the namespace name is incorrect, then 1615 Authoritative Server MUST generate an 1616 stream error condition and terminate both the stream and the 1617 underlying TCP connection. 1619 7. Authoritative Server sends Receiving Server a stream header: 1621 1627 Note: if the namespace name is incorrect, then Receiving Server 1628 MUST generate an stream error condition and 1629 terminate both the stream and the underlying TCP connection 1630 between it and Authoritative Server. If the ID does not match 1631 that provided by Receiving Server in Step 3, then Receiving 1632 Server MUST generate an stream error condition and 1633 terminate both the stream and the underlying TCP connection 1634 between it and Authoritative Server. If either of the foregoing 1635 stream errors occurs between Receiving Server and Authoritative 1636 Server, then Receiving Server MUST generate a stream error condition and terminate both 1638 the stream and the underlying TCP connection between it and 1639 Originating Server. 1641 8. Receiving Server sends Authoritative Server a stanza requesting 1642 that Authoritative Server verify a key: 1644 1648 98AF014EDC0... 1649 1651 Note: passed here are the hostnames, the original identifier 1652 from Receiving Server's stream header to Originating Server in 1653 Step 3, and the key that Originating Server sent to Receiving 1654 Server in Step 4. Based on this information and shared secret 1655 information within the Authoritative Server's network, the key 1656 is verified. Any verifiable method MAY be used to generate the 1657 key. If the value of the 'to' address does not match a hostname 1658 recognized by Authoritative Server, then Authoritative Server 1659 MUST generate a stream error condition and 1660 terminate both the stream and the underlying TCP connection. If 1661 the value of the 'from' address does not match the hostname 1662 represented by Receiving Server when opening the TCP connection 1663 (or any validated domain), then Authoritative Server MUST 1664 generate a stream error condition and 1665 terminate both the stream and the underlying TCP connection. 1667 9. Authoritative Server sends a stanza back to Receiving Server 1668 verifying whether the key was valid or invalid: 1670 1676 or 1678 1684 Note: if the ID does not match that provided by Receiving Server 1685 in Step 3, then Receiving Server MUST generate an 1686 stream error condition and terminate both the stream and the 1687 underlying TCP connection. If the value of the 'to' address 1688 does not match a hostname recognized by Receiving Server, then 1689 Receiving Server MUST generate a stream error 1690 condition and terminate both the stream and the underlying TCP 1691 connection. If the value of the 'from' address does not match 1692 the hostname represented by Originating Server when opening the 1693 TCP connection (or any validated domain), then Receiving Server 1694 MUST generate a stream error condition and 1695 terminate both the stream and the underlying TCP connection. 1697 10. Receiving Server informs Originating Server of the result: 1699 1704 Note: At this point the connection has either been validated via 1705 a type='valid', or reported as invalid. If the connection is 1706 invalid, then Receiving Server MUST terminate both the stream 1707 and the underlying TCP connection. If the connection is 1708 validated, data can be sent by Originating Server and read by 1709 Receiving Server; before that, all data stanzas sent to 1710 Receiving Server SHOULD be silently dropped. 1712 Even if dialback negotiation is successful, a server MUST verify that 1713 all XML stanzas received from the other server include a 'from' 1714 attribute and a 'to' attribute; if a stanza does not meet this 1715 restriction, the server that receives the stanza MUST generate an 1716 stream error condition and terminate both the stream 1717 and the underlying TCP connection. Furthermore, a server MUST verify 1718 that the 'from' attribute of stanzas received from the other server 1719 includes the validated domain (or any validated domain); if a stanza 1720 does not meet this restriction, the server that receives the stanza 1721 MUST generate a stream error condition and 1722 terminate both the stream and the underlying TCP connection. Both of 1723 these checks help to prevent spoofing related to particular stanzas. 1725 7. XML Stanzas 1727 7.1 Overview 1729 Once the XML streams in each direction have been authenticated and 1730 (if desired) encrypted, XML stanzas can be sent over the streams. 1731 Three XML stanza types are defined for the 'jabber:client' and 1732 'jabber:server' namespaces: , , and . 1734 In essence, the stanza type can be seen as a "push" 1735 mechanism whereby one entity pushes information to another entity, 1736 similar to the communications that occur in a system such as email. 1737 The element can be seen as a basic broadcast or "publish- 1738 subscribe" mechanism, whereby multiple entities receive information 1739 (in this case, presence information) about an entity to which they 1740 have subscribed. The element can be seen as a "request- 1741 response" mechanism similar to HTTP, whereby two entities can engage 1742 in a structured conversation using 'get' or 'set' requests and 1743 'result' or 'error' responses. 1745 The syntax for these stanza types is defined below. 1747 7.2 Common Attributes 1749 Five attributes are common to message, presence, and IQ stanzas. 1750 These are defined below. 1752 7.2.1 to 1754 The 'to' attribute specifies the JID of the intended recipient for 1755 the stanza. 1757 In the 'jabber:client' namespace, a stanza SHOULD possess a 'to' 1758 attribute, although a stanza sent from a client to a server for 1759 handling by that server (e.g., presence sent to the server for 1760 broadcasting to other entities) MAY legitimately lack a 'to' 1761 attribute. 1763 In the 'jabber:server' namespace, a stanza MUST possess a 'to' 1764 attribute; if a server receives a stanza that does not meet this 1765 restriction, it MUST generate an stream error 1766 condition and terminate both the stream and the underlying TCP 1767 connection. 1769 7.2.2 from 1771 The 'from' attribute specifies the JID of the sender. 1773 In the 'jabber:client' namespace, a client MUST NOT include a 'from' 1774 attribute on the stanzas it sends to a server; if a server receives a 1775 stanza from a client and the stanza possesses a 'from' attribute, it 1776 MUST ignore the value of the 'from' attribute and MAY return an error 1777 to the sender. In addition, a server MUST stamp stanzas received 1778 from a client with the user@domain/resource (full JID) of the 1779 connected resource that generated the stanza. 1781 In the 'jabber:server' namespace, a stanza MUST possess a 'from' 1782 attribute; if a server receives a stanza that does not meet this 1783 restriction, it MUST generate an stream error 1784 condition. Furthermore, the domain identifier portion of the JID 1785 contained in the 'from' attribute MUST match the hostname of the 1786 sending server (or any validated domain) as communicated in the SASL 1787 negotiation or dialback negotiation; if a server receives a stanza 1788 that does not meet this restriction, it MUST generate a stream error condition. Both of these conditions MUST result 1790 in closing of the stream and termination of the underlying TCP 1791 connection. 1793 7.2.3 id 1795 The optional 'id' attribute MAY be used to track stanzas sent and 1796 received. The 'id' attribute is generated by the sender. An 'id' 1797 attribute included in an IQ request of type "get" or "set" SHOULD be 1798 returned to the sender in any IQ response of type "result" or "error" 1799 generated by the recipient of the request. A recipient of a message 1800 or presence stanza MAY return that 'id' in any replies, but is NOT 1801 REQUIRED to do so. 1803 The value of the 'id' attribute is not intended to be unique -- 1804 globally, within a domain, or within a stream. It is generated by a 1805 sender only for internal tracking of information within the sending 1806 application. 1808 7.2.4 type 1810 The 'type' attribute specifies detailed information about the purpose 1811 or context of the message, presence, or IQ stanza. The particular 1812 allowable values for the 'type' attribute vary depending on whether 1813 the stanza is a message, presence, or IQ, and thus are specified in 1814 the following sections. 1816 7.2.5 xml:lang 1818 Any message or presence stanza MAY possess an 'xml:lang' attribute 1819 specifying the default language of any CDATA sections of the stanza 1820 or its child elements. An IQ stanza SHOULD NOT possess an 'xml:lang' 1821 attribute, since it is merely a vessel for data in other namespaces 1822 and does not itself contain children that have CDATA. The value of 1823 the 'xml:lang' attribute MUST be an NMTOKEN and MUST conform to the 1824 format defined in RFC 3066 [16]. 1826 7.3 Message Stanzas 1828 Message stanzas in the 'jabber:client' or 'jabber:server' namespace 1829 are used to "push" information to another entity. Common uses in the 1830 context of instant messaging include single messages, messages sent 1831 in the context of a chat conversation, messages sent in the context 1832 of a multi-user chat room, headlines, and errors. These messages 1833 types are identified more fully below. 1835 7.3.1 Types of Message 1837 The 'type' attribute of a message stanza is OPTIONAL; if included, it 1838 specifies the conversational context of the message. The sending of 1839 a message stanza without a 'type' attribute signals that the message 1840 stanza is a single message. However, the 'type' attribute MAY also 1841 have one of the following values: 1843 o chat 1845 o error 1847 o groupchat 1849 o headline 1851 For information about the meaning of these message types, refer to 1852 XMPP IM [22]. 1854 7.3.2 Children 1856 As described under extended namespaces (Section 7.6), a message 1857 stanza MAY contain any properly-namespaced child element as long as 1858 the namespace name is not "jabber:client", "jabber:server", or 1859 "http://etherx.jabber.org/streams". 1861 In accordance with the default namespace declaration, by default a 1862 message stanza is in the 'jabber:client' or 'jabber:server' 1863 namespace, which defines certain allowable children of message 1864 stanzas. If the message stanza is of type "error", it MUST include 1865 an child; for details, see Section 7.7. If the message 1866 stanza has no 'type' attribute or has a 'type' attribute with a value 1867 of "chat", "groupchat", or "headline", it MAY contain any of the 1868 following child elements without an explicit namespace declaration: 1870 7.3.2.1 Body 1872 The element contains the textual contents of the message; 1873 normally included but NOT REQUIRED. The element SHOULD NOT 1874 possess any attributes, with the exception of the 'xml:lang' 1875 attribute. Multiple instances of the element MAY be included 1876 but only if each instance possesses an 'xml:lang' attribute with a 1877 distinct language value. The element MUST NOT contain mixed 1878 content. 1880 7.3.2.2 Subject 1882 The element specifies the topic of the message. The 1883 element SHOULD NOT possess any attributes, with the 1884 exception of the 'xml:lang' attribute. Multiple instances of the 1885 element MAY be included for the purpose of providing 1886 alternate versions of the same subject, but only if each instance 1887 possesses an 'xml:lang' attribute with a distinct language value. 1888 The element MUST NOT contain mixed content. 1890 7.3.2.3 Thread 1892 The element contains a random string that is generated by 1893 the sender and that SHOULD be copied back in replies; it is used for 1894 tracking a conversation thread (sometimes referred to as an "IM 1895 session") between two entities. If used, it MUST be unique to that 1896 conversation thread within the stream and MUST be consistent 1897 throughout that conversation. The use of the element is 1898 optional and is not used to identify individual messages, only 1899 conversations. Only one element MAY be included in a 1900 message stanza, and it MUST NOT possess any attributes. The element MUST be treated as an opaque string by entities; no 1902 semantic meaning may be derived from it, and only exact, case- 1903 insensitve comparisons be made against it. The element MUST 1904 NOT contain mixed content. 1906 The method for generating thread IDs SHOULD be as follows: 1908 1. concatenate the sender's full JID (user@host/resource) with the 1909 recipient's full JID 1911 2. concatenate these JID strings with a full ISO-8601 timestamp 1912 including year, month, day, hours, minutes, seconds, and UTC 1913 offset in the following format: yyyy-mm-dd-Thh:mm:ss-hh:mm 1915 3. hash the resulting string according to the SHA1 algorithm 1917 4. convert the hexidecimal SHA1 output to all lowercase 1919 7.4 Presence Stanzas 1921 Presence stanzas are used in the 'jabber:client' or 'jabber:server' 1922 namespace to express an entity's current availability status (offline 1923 or online, along with various sub-states of the latter and optional 1924 user-defined descriptive text) and to communicate that status to 1925 other entities. Presence stanzas are also used to negotiate and 1926 manage subscriptions to the presence of other entities. 1928 7.4.1 Types of Presence 1930 The 'type' attribute of a presence stanza is optional. A presence 1931 stanza that does not possess a 'type' attribute is used to signal to 1932 the server that the sender is online and available for communication. 1933 If included, the 'type' attribute specifies a lack of availability, a 1934 request to manage a subscription to another entity's presence, a 1935 request for another entity's current presence, or an error related to 1936 a previously-sent presence stanza. The 'type' attribute MAY have one 1937 of the following values: 1939 o unavailable -- Signals that the entity is no longer available for 1940 communication. 1942 o subscribe -- The sender wishes to subscribe to the recipient's 1943 presence. 1945 o subscribed -- The sender has allowed the recipient to receive 1946 their presence. 1948 o unsubscribe -- A notification that an entity is unsubscribing from 1949 another entity's presence. 1951 o unsubscribed -- The subscription request has been denied or a 1952 previously-granted subscription has been cancelled. 1954 o probe -- A request for an entity's current presence. In general 1955 SHOULD NOT be sent by a client. 1957 o error -- An error has occurred regarding processing or delivery of 1958 a previously-sent presence stanza. 1960 Information about the subscription model used within XMPP can be 1961 found in XMPP IM [22]. 1963 7.4.2 Children 1965 As described under extended namespaces (Section 7.6), a presence 1966 stanza MAY contain any properly-namespaced child element as long as 1967 the namespace name is not "jabber:client", "jabber:server", or 1968 "http://etherx.jabber.org/streams". 1970 In accordance with the default namespace declaration, by default a 1971 presence stanza is in the 'jabber:client' or 'jabber:server' 1972 namespace, which defines certain allowable children of presence 1973 stanzas. If the presence stanza is of type "error", it MUST include 1974 an child; for details, see Section 7.7. If the presence 1975 stanza possesses no 'type' attribute, it MAY contain any of the 1976 following child elements (note that the child MAY be sent 1977 in a presence stanza of type "unavailable" or, for historical 1978 reasons, "subscribe"): 1980 7.4.2.1 Show 1982 The optional element specifies a particular availability 1983 status of an entity or specific resource (if a element is not 1984 provided, default availability is assumed (if a element is 1985 not provided, default availability is assumed)). Only one 1986 element MAY be included in a presence stanza, and it SHOULD NOT 1987 possess any attributes. The CDATA value SHOULD be one of the 1988 following (values other than these four SHOULD be ignored; additional 1989 availability types could be defined through a properly-namespaced 1990 child element of the presence stanza): 1992 o away 1994 o chat 1996 o xa 1998 o dnd 2000 For information about the meaning of these values, refer to XMPP IM 2001 [22]. 2003 7.4.2.2 Status 2005 The optional element contains a natural-language 2006 description of availability status. It is normally used in 2007 conjunction with the show element to provide a detailed description 2008 of an availability state (e.g., "In a meeting"). The 2009 element SHOULD NOT possess any attributes, with the exception of the 2010 'xml:lang' attribute. Multiple instances of the element 2011 MAY be included but only if each instance possesses an 'xml:lang' 2012 attribute with a distinct language value. 2014 7.4.2.3 Priority 2016 The optional element specifies the priority level of the 2017 connected resource. The value may be any integer between -128 to 2018 127. Only one element MAY be included in a presence 2019 stanza, and it MUST NOT possess any attributes. For information 2020 regarding the use of priority values in stanza routing within IM 2021 applications, see XMPP IM [22]. 2023 7.5 IQ Stanzas 2025 7.5.1 Overview 2027 Info/Query, or IQ, is a request-response mechanism, similar in some 2028 ways to HTTP [30]. IQ stanzas in the 'jabber:client' or 2029 'jabber:server' namespace enable an entity to make a request of, and 2030 receive a response from, another entity. The data content of the 2031 request and response is defined by the namespace declaration of a 2032 direct child element of the IQ element, and the interaction is 2033 tracked by the requesting entity through use of the 'id' attribute, 2034 which responding entities SHOULD return in any response. 2036 Most IQ interactions follow a common pattern of structured data 2037 exchange such as get/result or set/result (although an error may be 2038 returned in response to a request if appropriate): 2040 Requesting Responding 2041 Entity Entity 2042 ---------- ---------- 2043 | | 2044 | | 2045 | ------------------------> | 2046 | | 2047 | | 2048 | <------------------------ | 2049 | | 2050 | | 2051 | ------------------------> | 2052 | | 2053 | | 2054 | <------------------------ | 2055 | | 2057 An entity that receives an IQ request of type 'get' or 'set' MUST 2058 reply with an IQ response of type 'result' or 'error' (which response 2059 MUST preserve the 'id' attribute of the request). An entity that 2060 receives a stanza of type 'result' or 'error' MUST NOT respond to the 2061 stanza by sending a further IQ response of type 'result' or 'error'; 2062 however, as shown above, the requesting entity MAY send another 2063 request (e.g., an IQ of type 'set' in order to provide required 2064 information discovered through a get/result pair). 2066 7.5.2 Types of IQ 2068 The 'type' attribute of an IQ stanza is REQUIRED. The 'type' 2069 attribute specifies a distinct step within a request-response 2070 interaction. The value SHOULD be one of the following (all other 2071 values SHOULD be ignored): 2073 o get -- The stanza is a request for information. 2075 o set -- The stanza provides required data, sets new values, or 2076 replaces existing values. 2078 o result -- The stanza is a response to a successful get or set 2079 request. 2081 o error -- An error has occurred regarding processing or delivery of 2082 a previously-sent get or set. 2084 7.5.3 Children 2086 As described under extended namespaces (Section 7.6), an IQ stanza 2087 MAY contain any properly-namespaced child element as long as the 2088 namespace name is not "jabber:client", "jabber"server", or "http:// 2089 etherx.jabber.org/streams". However, an IQ stanza contains no 2090 children in the 'jabber:client' or 'jabber:server' namespace since it 2091 is a vessel for XML in another namespace. 2093 If the IQ stanza is of type "error", it MUST include an 2094 child; for details, see Section 7.7. 2096 7.6 Extended Namespaces 2098 While the core data elements in the "jabber:client" or 2099 "jabber:server" namespace (along with their attributes and child 2100 elements) provide a basic level of functionality for messaging and 2101 presence, XMPP uses XML namespaces to extend the core data elements 2102 for the purpose of providing additional functionality. Thus a 2103 message, presence, or IQ stanza MAY house one or more optional child 2104 elements containing content that extends the meaning of the message 2105 (e.g., an encrypted form of the message body). This child element 2106 MAY be have any name and MUST possess an 'xmlns' namespace 2107 declaration (other than "jabber:client", "jabber:server", or "http:// 2108 etherx.jabber.org/streams") that defines all data contained within 2109 the child element. 2111 Support for any given extended namespace is OPTIONAL on the part of 2112 any implementation. If an entity does not understand such a 2113 namespace, the entity's expected behavior depends on whether the 2114 entity is (1) the recipient or (2) an entity that is routing the 2115 stanza to the recipient. In particular: 2117 Recipient: If a recipient receives a stanza that contains a child 2118 element it does not understand, it SHOULD ignore that specific XML 2119 data, i.e., it SHOULD not process it or present it to a user or 2120 associated application (if any). In particular: 2122 * If an entity receives a message or presence stanza that 2123 contains XML data in an extended namespace it does not 2124 understand, the portion of the stanza that is in the unknown 2125 namespace SHOULD be ignored. 2127 * If an entity receives a message stanza without a 2128 element but containing only a child element bound by a 2129 namespace it does not understand, it MUST ignore the entire 2130 stanza/ 2132 * If an entity receives an IQ stanza in a namespace it does not 2133 understand, the entity SHOULD return an IQ stanza of type 2134 "error" with an error condition of . 2136 Router: If a routing entity (usually a server) handles a stanza that 2137 contains a child element it does not understand, it SHOULD ignore 2138 the associated XML data by passing it on untouched to the 2139 recipient. 2141 7.7 Stanza Errors 2143 As defined below, stanza-related errors are handled in a manner 2144 similar to stream errors (Section 4.5). 2146 7.7.1 Rules 2148 The following rules apply to stanza-related errors: 2150 o A stanza of type "error" MUST contain an child element. 2152 o The receiving or processing entity that returns an error to the 2153 sending entity SHOULD include the original XML sent along with the 2154 element and its children so that the sender can inspect 2155 and if necessary correct the XML before re-sending. 2157 o An entity that receives a message stanza of type 'error' MUST NOT 2158 respond to the stanza by sending a further message stanza of type 2159 'error'; this helps to prevent looping. 2161 o An child MUST NOT be included if the stanza type is 2162 something other than "error". 2164 7.7.2 Syntax 2166 The syntax for stanza-related errors is as follows: 2168 2169 [include sender XML here] 2170 2171 2172 2173 2174 2175 2177 The stanza-name is one of message, presence, or iq. 2179 The value of the 'class' attribute MUST be one of the following: 2181 o access -- the condition relates to access rights, permissions, or 2182 authorization 2184 o address -- the condition relates to the JID or domain to which the 2185 stanza was addressed 2187 o app -- the condition is particular to an application and is 2188 specified in a namespace other than 'urn:ietf:params:xml:ns:xmpp- 2189 stanzas' 2191 o format -- the condition relates to XML format or structure 2193 o recipient -- the condition relates to the state or capabilities of 2194 the recipient (which may be the server) 2196 o server -- the condition relates to the internal state of the 2197 server 2199 The element MUST contain a child element that 2200 specifies a particular stanza-related error condition, as defined in 2201 the next section. (Note: the XML namespace name 2202 'urn:ietf:params:xml:ns:xmpp-stanzas' that scopes the element adheres to the format defined in The IETF XML 2204 Registry [24].) 2206 7.7.3 Conditions 2208 The following stanza-related error conditions are defined: 2210 o -- the sender has sent XML that is malformed or 2211 cannot be processed (e.g., a client-generated stanza includes a 2212 'from' address, or an IQ stanza includes an unrecognized value of 2213 the 'type' attribute); the associated class is "format". 2215 o -- the feature requested is not 2216 implemented by the recipient or server and therefore cannot be 2217 processed; the associated class is "recipient". 2219 o -- the stanza is understood but the action is 2220 forbidden; the associated class is "access". 2222 o -- the server could not process the 2223 stanza because of a misconfiguration or an otherwise-undefined 2224 internal server error; the associated class is "server". 2226 o -- the value of the 'to' attribute in the 2227 sender's stanza does not adhere to the syntax defined in 2228 Addressing (Section 3); the associated class is "address". 2230 o -- the value of the 'to' attribute in the 2231 sender's stanza does not correspond to a Jabber ID on the user's 2232 server or a remote server; the associated class is "address". 2234 o -- the action is not permitted when attempted by 2235 the sender; the associated class is "access". 2237 o -- the specific recipient requested is 2238 currently unavailable; the associated class is "recipient". 2240 o -- the user is not authorized to access 2241 the requested service because registration is required; the 2242 associated class is "access". 2244 o -- a remote server or service specified 2245 as part or all of the JID of the intended recipient does not 2246 exist; the associated class is "address". 2248 o -- a remote server or service specified 2249 as part or all of the JID of the intended recipient could not be 2250 contacted within a reasonable amount of time; the associated class 2251 is "server". 2253 o -- the service requested is currently 2254 unavailable on the server; the associated class is "server". 2256 7.7.4 Extensibility 2258 If desired, an XMPP application MAY provide custom error information; 2259 the error class MUST be "app" and the data MUST be contained in a 2260 properly-namespaced child of the element (i.e., 2261 the namespace name MUST NOT be one of namespace names defined 2262 herein). 2264 8. XML Usage within XMPP 2266 8.1 Restrictions 2268 XMPP is a simplified and specialized protocol for streaming XML 2269 elements in order to exchange messages and presence information in 2270 close to real time. Because XMPP does not require the parsing of 2271 arbitrary and complete XML documents, there is no requirement that 2272 XMPP must support the full XML specification [1]. In particular, the 2273 following restrictions apply: 2275 With regard to XML generation, an XMPP implementation MUST NOT inject 2276 into an XML stream any of the following: 2278 o comments (as defined in Section 2.5 of the XML specification [1]) 2280 o processing instructions (Section 2.6) 2282 o internal or external DTD subsets (Section 2.8) 2284 o internal or external entity references (Section 4.2) with the 2285 exception of predefined entities (Section 4.6) 2287 With regard to XML processing, if an XMPP implementation receives 2288 such restricted XML data, it MUST ignore the data. 2290 8.2 Namespaces 2292 XML Namespaces [12] are used within all XMPP-compliant XML to create 2293 strict boundaries of data ownership. The basic function of 2294 namespaces is to separate different vocabularies of XML elements that 2295 are structurally mixed together. Ensuring that XMPP-compliant XML is 2296 namespace-aware enables any XML to be structurally mixed with any 2297 data element within XMPP. 2299 Additionally, XMPP is more strict about namespace prefixes than the 2300 XML namespace specification requires. 2302 8.3 Validation 2304 Except as noted with regard to 'to' and 'from' addresses for stanzas 2305 within the 'jabber:server' namespace, a server is not responsible for 2306 validating the XML elements forwarded to a client or another server; 2307 an implementation MAY choose to provide only validated data elements 2308 but is NOT REQUIRED to do so. Clients SHOULD NOT rely on the ability 2309 to send data which does not conform to the schemas, and SHOULD ignore 2310 any non-conformant elements or attributes on the incoming XML stream. 2311 Validation of XML streams and stanzas is NOT REQUIRED or recommended, 2312 and schemas are included herein for descriptive purposes only. 2314 8.4 Character Encodings 2316 Software implementing XML streams MUST support the UTF-8 (RFC 2279 2317 [18]) and UTF-16 (RFC 2781 [19]) transformations of Universal 2318 Character Set (ISO/IEC 10646-1 [20]) characters. Software MUST NOT 2319 attempt to use any other encoding for transmitted data. The 2320 encodings of the transmitted and received streams are independent. 2321 Software MAY select either UTF-8 or UTF-16 for the transmitted 2322 stream, and SHOULD deduce the encoding of the received stream as 2323 described in the XML specification [1]. For historical reasons, 2324 existing implementations MAY support UTF-8 only. 2326 8.5 Inclusion of Text Declaration 2328 An application MAY send a text declaration. Applications MUST follow 2329 the rules in the XML specification [1] regarding the circumstances 2330 under which a text declaration is included. 2332 9. IANA Considerations 2334 9.1 XML Namespace Name for TLS Data 2336 A URN sub-namespace for TLS-related data in XMPP is defined as 2337 follows. 2339 URI: urn:ietf:params:xml:ns:xmpp-tls 2341 Specification: [RFCXXXX] 2343 Description: This is the XML namespace name for TLS-related data in 2344 XMPP as defined by [RFCXXXX]. 2346 Registrant Contact: IETF, XMPP Working Group, 2348 9.2 XML Namespace Name for SASL Data 2350 A URN sub-namespace for SASL-related data in XMPP is defined as 2351 follows. 2353 URI: urn:ietf:params:xml:ns:xmpp-sasl 2355 Specification: [RFCXXXX] 2357 Description: This is the XML namespace name for SASL-related data in 2358 XMPP as defined by [RFCXXXX]. 2360 Registrant Contact: IETF, XMPP Working Group, 2362 9.3 XML Namespace Name for Stream Errors 2364 A URN sub-namespace for XMPP stream error tags is defined as follows. 2366 URI: urn:ietf:params:xml:ns:xmpp-streams 2368 Specification: [RFCXXXX] 2370 Description: This is the XML namespace name for XMPP stream errors as 2371 defined by [RFCXXXX]. 2373 Registrant Contact: IETF, XMPP Working Group, 2375 9.4 XML Namespace Name for Stanza Errors 2377 A URN sub-namespace for XMPP stanza error tags is defined as follows. 2379 URI: urn:ietf:params:xml:ns:xmpp-stanzas 2381 Specification: [RFCXXXX] 2383 Description: This is the XML namespace name for XMPP stanza errors as 2384 defined by [RFCXXXX]. 2386 Registrant Contact: IETF, XMPP Working Group, 2388 9.5 Existing Registrations 2390 The IANA registers "xmpp" as a GSSAPI [21] service name, as specified 2391 in Section 6.1.3. 2393 Additionally, the IANA registers "jabber-client" and "jabber-server" 2394 as keywords for TCP ports 5222 and 5269 respectively. 2396 10. Internationalization Considerations 2398 Usage of the 'xml:lang' attribute is described above. If a client 2399 includes an 'xml:lang' attribute in a stanza, a server MUST NOT 2400 modify or delete it. 2402 11. Security Considerations 2404 11.1 High Security 2406 For the purposes of XMPP communications (client-to-server and server- 2407 to-server), the term "high security" refers to the use of security 2408 technologies that provide both mutual authentication and integrity- 2409 checking; in particular, when using certificate-based authentication 2410 to provide high security, a chain-of-trust SHOULD be established out- 2411 of-band, although a shared certificate authority signing certificates 2412 could allow a previously unknown certificate to establish trust in- 2413 band. 2415 Self-signed certificates MAY be used but pose a problem for 2416 administrators the first time such a certificate is seen. A self- 2417 signed certificate, if accepted, MUST be stored by an entity in order 2418 to verify in future communications. A server that changes its self- 2419 signed cert to another self-signed cert (or to a certificate signed 2420 by an unrecognized authority) therefore creates administration 2421 problems for all entities with which it has communicated before and 2422 will again. In particular, those entities have no reason to believe 2423 that the new self-signed cert was not generated by an attacker to 2424 impersonate the previously-trusted server. 2426 Implementations MUST support high security. Service provisioning 2427 SHOULD use high security, subject to local security policies. 2429 11.2 Client-to-Server Communications 2431 The TLS protocol for encrypting XML streams (defined under Section 5) 2432 provides a reliable mechanism for helping to ensure the 2433 confidentiality and data integrity of data exchanged between two 2434 entities. 2436 The SASL protocol for authenticating XML streams (defined under 2437 Section 6.1) provides a reliable mechanism for validating that a 2438 client connecting to a server is who it claims to be. 2440 The IP address and method of access of clients MUST NOT be made 2441 available by a server, nor are any connections other than the 2442 original server connection required. This helps protect the client's 2443 server from direct attack or identification by third parties. 2445 End-to-end encryption of message bodies and presence status 2446 information MAY be effected through use of the methods defined in 2447 End-to-End Object Encryption in XMPP [31]. 2449 11.3 Server-to-Server Communications 2451 A compliant implementation MUST support both TLS and SASL for inter- 2452 domain communications. For historical reasons, a compliant 2453 implementation SHOULD also support the lower-security Dialback 2454 Protocol (Section 6.2), which provides a mechanism for helping to 2455 prevent the spoofing of domains. 2457 Because service provisioning is a matter of policy, it is OPTIONAL 2458 for any given domain to communicate with other domains, and server- 2459 to-server communications MAY be disabled by the administrator of any 2460 given deployment. If a particular domain enables inter-domain 2461 communications, it SHOULD enable high security. In the absence of 2462 high security, a domain MAY use server dialback for inter-domain 2463 communications. 2465 Administrators may want to require use of SASL for server-to-server 2466 communications in order to ensure authentication and confidentiality 2467 (e.g., on an organization's private network). Compliant 2468 implementations SHOULD support SASL for this purpose. 2470 11.4 Firewalls 2472 Communications using XMPP normally occur over TCP sockets on port 2473 5222 (client-to-server) or port 5269 (server-to-server), as 2474 registered with the IANA [5]. Use of these well-known ports allows 2475 administrators to easily enable or disable XMPP activity through 2476 existing and commonly-deployed firewalls. 2478 11.5 Mandatory to Implement Technologies 2480 At a minimum, all implementations MUST support the following 2481 mechanisms: 2483 for authentication: the SASL DIGEST-MD5 mechanism 2485 for confidentiality: TLS (using the TLS_RSA_WITH_3DES_EDE_CBC_SHA 2486 cipher) 2488 for both: TLS (using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher 2489 supporting client-side certificates) 2491 Normative References 2493 [1] World Wide Web Consortium, "Extensible Markup Language (XML) 2494 1.0 (Second Edition)", W3C xml, October 2000, . 2497 [2] Day, M., Aggarwal, S., Mohr, G. and J. Vincent, "A Model for 2498 Presence and Instant Messaging", RFC 2779, February 2000, 2499 . 2501 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2502 Levels", BCP 14, RFC 2119, March 1997. 2504 [4] University of Southern California, "Transmission Control 2505 Protocol", RFC 793, September 1981, . 2508 [5] Internet Assigned Numbers Authority, "Internet Assigned Numbers 2509 Authority", January 1998, . 2511 [6] Harrenstien, K., Stahl, M. and E. Feinler, "DoD Internet host 2512 table specification", RFC 952, October 1985. 2514 [7] Braden, R., "Requirements for Internet Hosts - Application and 2515 Support", STD 3, RFC 1123, October 1989. 2517 [8] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile 2518 for Internationalized Domain Names (draft-ietf-idn-nameprep-11, 2519 work in progress)", June 2002. 2521 [9] Hoffman, P. and M. Blanchet, "Preparation of Internationalized 2522 Strings ("stringprep")", RFC 3454, December 2002. 2524 [10] Saint-Andre, P. and J. Hildebrand, "Nodeprep: A Stringprep 2525 Profile for Node Identifiers in XMPP (draft-ietf-xmpp-nodeprep- 2526 01, work in progress)", February 2003. 2528 [11] Saint-Andre, P. and J. Hildebrand, "Resourceprep: A Stringprep 2529 Profile for Resource Identifiers in XMPP (draft-ietf-xmpp- 2530 resourceprep-01, work in progress)", February 2003. 2532 [12] World Wide Web Consortium, "Namespaces in XML", W3C xml-names, 2533 January 1999, . 2536 [13] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and 2537 P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 2538 1999. 2540 [14] Myers, J., "Simple Authentication and Security Layer (SASL)", 2541 RFC 2222, October 1997. 2543 [15] Leach, P. and C. Newman, "Using Digest Authentication as a SASL 2544 Mechanism", RFC 2831, May 2000. 2546 [16] Alvestrand, H., "Tags for the Identification of Languages", BCP 2547 47, RFC 3066, January 2001. 2549 [17] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the 2550 location of services (DNS SRV)", RFC 2052, October 1996. 2552 [18] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2553 2279, January 1998. 2555 [19] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", 2556 RFC 2781, February 2000. 2558 [20] International Organization for Standardization, "Information 2559 Technology - Universal Multiple-octet coded Character Set (UCS) 2560 - Amendment 2: UCS Transformation Format 8 (UTF-8)", ISO 2561 Standard 10646-1 Addendum 2, October 1996. 2563 [21] Linn, J., "Generic Security Service Application Program 2564 Interface, Version 2", RFC 2078, January 1997. 2566 Informative References 2568 [22] Saint-Andre, P. and J. Miller, "XMPP Instant Messaging (draft- 2569 ietf-xmpp-im-08, work in progress)", April 2003. 2571 [23] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 2572 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 2573 1998, . 2575 [24] Mealling, M., "The IANA XML Registry", draft-mealling-iana- 2576 xmlns-registry-04 (work in progress), June 2002. 2578 [25] Crispin, M., "Internet Message Access Protocol - Version 2579 4rev1", RFC 2060, December 1996. 2581 [26] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 2582 53, RFC 1939, May 1996. 2584 [27] Newman, C. and J. Myers, "ACAP -- Application Configuration 2585 Access Protocol", RFC 2244, November 1997. 2587 [28] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, 2588 June 1999. 2590 [29] Eastlake, D., "Domain Name System Security Extensions", RFC 2591 2535, March 1999. 2593 [30] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., 2594 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 2595 HTTP/1.1", RFC 2616, June 1999. 2597 [31] Saint-Andre, P. and J. Hildebrand, "End-to-End Object 2598 Encryption in XMPP (draft-ietf-xmpp-e2e-01, work in progress)", 2599 April 2003. 2601 Authors' Addresses 2603 Peter Saint-Andre 2604 Jabber Software Foundation 2606 EMail: stpeter@jabber.org 2607 URI: http://www.jabber.org/people/stpeter.php 2608 Jeremie Miller 2609 Jabber Software Foundation 2611 EMail: jeremie@jabber.org 2612 URI: http://www.jabber.org/people/jer.php 2614 Appendix A. XML Schemas 2616 The following XML schemas are descriptive, not normative. 2618 A.1 Streams namespace 2620 2622 2628 2629 2630 2631 2632 2633 2636 2639 2640 2641 2642 2643 2644 2645 2647 2648 2649 2653 2654 2656 2657 2658 2659 2660 2661 2662 2663 2664 2665 2666 2667 2668 2669 2670 2672 2674 A.2 TLS namespace 2676 2678 2684 2685 2686 2687 2688 2689 2690 2691 2693 2695 A.3 SASL namespace 2697 2699 2705 2706 2707 2709 2710 2712 2714 2715 2716 2718 2719 2721 2722 2723 2724 2725 2726 2727 2728 2729 2730 2731 2732 2733 2734 2735 2736 2738 2739 2740 2741 2742 2743 2745 2747 A.4 Dialback namespace 2749 2751 2757 2758 2759 2760 2761 2762 2763 2764 2765 2766 2767 2768 2769 2770 2771 2772 2773 2774 2776 2777 2778 2779 2780 2781 2782 2783 2784 2785 2786 2787 2788 2789 2790 2791 2792 2793 2794 2796 2798 A.5 Client namespace 2800 2802 2808 2809 2810 2811 2813 2815 2816 2817 2821 2822 2823 2824 2825 2827 2828 2829 2830 2831 2832 2833 2834 2835 2836 2837 2838 2840 2841 2842 2844 2845 2847 2848 2849 2851 2853 2855 2857 2858 2859 2860 2861 2863 2864 2865 2869 2870 2871 2872 2873 2875 2876 2877 2878 2879 2880 2881 2882 2883 2884 2885 2886 2887 2888 2890 2891 2892 2893 2894 2895 2896 2897 2898 2899 2900 2901 2902 2904 2905 2907 2909 2910 2911 2912 2913 2917 2918 2919 2920 2921 2922 2923 2924 2925 2926 2927 2928 2929 2930 2931 2932 2934 2935 2936 2937 2938 2939 2940 2941 2942 2943 2944 2945 2946 2947 2949 2950 2952 2953 2954 2955 2956 2958 2960 A.6 Server namespace 2962 2964 2970 2971 2972 2973 2975 2977 2978 2979 2983 2984 2985 2986 2987 2989 2990 2991 2992 2993 2994 2995 2997 2998 2999 3000 3001 3003 3004 3005 3007 3008 3010 3011 3012 3014 3015 3017 3019 3020 3021 3022 3023 3025 3026 3027 3031 3032 3033 3034 3035 3037 3038 3039 3040 3041 3042 3043 3044 3045 3046 3047 3048 3049 3050 3052 3053 3054 3055 3056 3057 3058 3059 3060 3061 3063 3064 3065 3067 3068 3070 3072 3073 3074 3075 3076 3080 3081 3082 3083 3084 3085 3086 3087 3088 3089 3090 3091 3092 3094 3095 3096 3098 3099 3100 3101 3102 3103 3104 3105 3106 3107 3108 3109 3110 3111 3112 3113 3115 3116 3117 3118 3119 3121 3123 A.7 Stream error namespace 3125 3127 3133 3134 3135 3139 3140 3141 3142 3143 3144 3145 3146 3147 3148 3149 3150 3151 3152 3153 3154 3156 3157 3158 3159 3160 3161 3162 3163 3164 3165 3166 3167 3168 3170 3172 A.8 Stanza error namespace 3174 3176 3182 3183 3184 3189 3190 3191 3192 3193 3194 3195 3196 3197 3198 3199 3200 3201 3202 3203 3205 3206 3207 3208 3209 3210 3211 3212 3213 3214 3215 3216 3218 3220 Appendix B. Revision History 3222 Note to RFC editor: please remove this entire appendix, and the 3223 corresponding entries in the table of contents, prior to publication. 3225 B.1 Changes from draft-ietf-xmpp-core-08 3227 o Incorporated list discussion regarding addressing, SASL, TLS, TCP, 3228 dialback, namespaces, extensibility, and the meaning of 'ignore' 3229 for routers and recipients. 3231 o Specified dialback error conditions. 3233 o Made small editorial changes to address RFC Editor requirements. 3235 B.2 Changes from draft-ietf-xmpp-core-07 3237 o Made several small editorial changes. 3239 B.3 Changes from draft-ietf-xmpp-core-06 3241 o Added text regarding certificate validation in TLS negotiation per 3242 list discussion. 3244 o Clarified nature of XML restrictions per discussion with W3C, and 3245 moved XML Restrictions subsection under "XML Usage within XMPP". 3247 o Further clarified that XML streams are unidirectional. 3249 o Changed stream error and stanza error namespace names to conform 3250 to the format defined in The IETF XML Registry [24]. 3252 o Removed note to RFC editor regarding provisional namespace names. 3254 B.4 Changes from draft-ietf-xmpp-core-05 3256 o Added as a stream error condition. 3258 o Adjusted security considerations per discussion at IETF 56 and on 3259 list. 3261 B.5 Changes from draft-ietf-xmpp-core-04 3263 o Added server-to-server examples for TLS and SASL. 3265 o Changed error syntax, rules, and examples based on list 3266 discussion. 3268 o Added schemas for the TLS, stream error, and stanza error 3269 namespaces. 3271 o Added note to RFC editor regarding provisional namespace names. 3273 o Made numerous small editorial changes and clarified text 3274 throughout. 3276 B.6 Changes from draft-ietf-xmpp-core-03 3278 o Clarified rules and procedures for TLS and SASL. 3280 o Amplified stream error code syntax per list discussion. 3282 o Made numerous small editorial changes. 3284 B.7 Changes from draft-ietf-xmpp-core-02 3286 o Added dialback schema. 3288 o Removed all DTDs since schemas provide more complete definitions. 3290 o Added stream error codes. 3292 o Clarified error code "philosophy". 3294 B.8 Changes from draft-ietf-xmpp-core-01 3296 o Updated the addressing restrictions per list discussion and added 3297 references to the new nodeprep and resourceprep profiles. 3299 o Corrected error in Stream Authentication regarding "version='1.0'" 3300 flag. 3302 o Made numerous small editorial changes. 3304 B.9 Changes from draft-ietf-xmpp-core-00 3306 o Added information about TLS from list discussion. 3308 o Clarified meaning of "ignore" based on list discussion. 3310 o Clarified information about Universal Character Set data and 3311 character encodings. 3313 o Provided base64-decoded information for examples. 3315 o Fixed several errors in the schemas. 3317 o Made numerous small editorial fixes. 3319 B.10 Changes from draft-miller-xmpp-core-02 3321 o Brought Streams Authentication section into line with discussion 3322 on list and at IETF 55 meeting. 3324 o Added information about the optional 'xml:lang' attribute per 3325 discussion on list and at IETF 55 meeting. 3327 o Specified that validation is neither required nor recommended, and 3328 that the formal definitions (DTDs and schemas) are included for 3329 descriptive purposes only. 3331 o Specified that the response to an IQ stanza of type 'get' or 'set' 3332 must be an IQ stanza of type 'result' or 'error'. 3334 o Specified that compliant server implementations must process 3335 stanzas in order. 3337 o Specified that for historical reasons some server implementations 3338 may accept 'stream:' as the only valid namespace prefix on the 3339 root stream element. 3341 o Clarified the difference between 'jabber:client' and 3342 'jabber:server' namespaces, namely, that 'to' and 'from' 3343 attributes are required on all stanzas in the latter but not the 3344 former. 3346 o Fixed typo in Step 9 of the dialback protocol (changed db:result 3347 to db:verify). 3349 o Removed references to TLS pending list discussion. 3351 o Removed the non-normative appendix on OpenPGP usage pending its 3352 inclusion in a separate I-D. 3354 o Simplified the architecture diagram, removed most references to 3355 services, and removed references to the 'jabber:component:*' 3356 namespaces. 3358 o Noted that XMPP activity respects firewall administration 3359 policies. 3361 o Further specified the scope and uniqueness of the 'id' attribute 3362 in all stanza types and the element in message stanzas. 3364 o Nomenclature changes: (1) from "chunks" to "stanzas"; (2) from 3365 "host" to "server" and from "node" to "client" (except with regard 3366 to definition of the addressing scheme). 3368 Full Copyright Statement 3370 Copyright (C) The Internet Society (2003). All Rights Reserved. 3372 This document and translations of it may be copied and furnished to 3373 others, and derivative works that comment on or otherwise explain it 3374 or assist in its implementation may be prepared, copied, published 3375 and distributed, in whole or in part, without restriction of any 3376 kind, provided that the above copyright notice and this paragraph are 3377 included on all such copies and derivative works. However, this 3378 document itself may not be modified in any way, such as by removing 3379 the copyright notice or references to the Internet Society or other 3380 Internet organizations, except as needed for the purpose of 3381 developing Internet standards in which case the procedures for 3382 copyrights defined in the Internet Standards process must be 3383 followed, or as required to translate it into languages other than 3384 English. 3386 The limited permissions granted above are perpetual and will not be 3387 revoked by the Internet Society or its successors or assigns. 3389 This document and the information contained herein is provided on an 3390 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3391 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 3392 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 3393 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3394 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3396 Acknowledgement 3398 Funding for the RFC Editor function is currently provided by the 3399 Internet Society.