idnits 2.17.1 draft-ietf-xmpp-core-12.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 2 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 == 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 (May 04, 2003) is 7661 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 382, but not defined -- Looks like a reference, but probably isn't: 'RFCXXXX' on line 2421 -- 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-02 -- Possible downref: Normative reference to a draft: ref. '10' == Outdated reference: A later version (-03) exists of draft-ietf-xmpp-resourceprep-02 -- 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 2818 (ref. '14') (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 2222 (ref. '15') (Obsoleted by RFC 4422, RFC 4752) ** Obsolete normative reference: RFC 2831 (ref. '16') (Obsoleted by RFC 6331) ** Obsolete normative reference: RFC 3066 (ref. '17') (Obsoleted by RFC 4646, RFC 4647) ** Obsolete normative reference: RFC 2052 (ref. '18') (Obsoleted by RFC 2782) ** Obsolete normative reference: RFC 2279 (ref. '19') (Obsoleted by RFC 3629) ** Downref: Normative reference to an Informational RFC: RFC 2781 (ref. '20') -- Possible downref: Non-RFC (?) normative reference: ref. '21' ** Obsolete normative reference: RFC 2078 (ref. '22') (Obsoleted by RFC 2743) == Outdated reference: A later version (-22) exists of draft-ietf-xmpp-im-11 -- Obsolete informational reference (is this intentional?): RFC 2396 (ref. '24') (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. '26') (Obsoleted by RFC 3501) -- Obsolete informational reference (is this intentional?): RFC 2535 (ref. '30') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. '31') (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-02 Summary: 14 errors (**), 0 flaws (~~), 11 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: November 2, 2003 Jabber Software Foundation 5 May 04, 2003 7 XMPP Core 8 draft-ietf-xmpp-core-12 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 other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on November 2, 2003. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 This document describes the core features of the Extensible Messaging 39 and Presence Protocol (XMPP), a protocol for streaming XML elements 40 in order to exchange messages and presence information in close to 41 real time. XMPP is used mainly for the purpose of building instant 42 messaging (IM) and presence applications, such as the servers and 43 clients that comprise the Jabber network. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 48 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 49 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 50 1.3 Discussion Venue . . . . . . . . . . . . . . . . . . . . . . 5 51 1.4 Intellectual Property Notice . . . . . . . . . . . . . . . . 5 52 2. Generalized Architecture . . . . . . . . . . . . . . . . . . 6 53 2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 54 2.2 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 2.3 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 2.4 Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 2.5 Network . . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 3. Addressing Scheme . . . . . . . . . . . . . . . . . . . . . 8 59 3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 3.2 Domain Identifier . . . . . . . . . . . . . . . . . . . . . 8 61 3.3 Node Identifier . . . . . . . . . . . . . . . . . . . . . . 8 62 3.4 Resource Identifier . . . . . . . . . . . . . . . . . . . . 9 63 4. XML Streams . . . . . . . . . . . . . . . . . . . . . . . . 10 64 4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 4.2 Stream Attributes . . . . . . . . . . . . . . . . . . . . . 11 66 4.3 Namespace Declarations . . . . . . . . . . . . . . . . . . . 12 67 4.3.1 Stream Namespace Declaration . . . . . . . . . . . . . . . . 12 68 4.3.2 Default Namespace Declaration . . . . . . . . . . . . . . . 13 69 4.4 Stream Features . . . . . . . . . . . . . . . . . . . . . . 13 70 4.5 Stream Errors . . . . . . . . . . . . . . . . . . . . . . . 14 71 4.5.1 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 4.5.2 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 4.5.3 Conditions . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 4.5.4 Extensibility . . . . . . . . . . . . . . . . . . . . . . . 16 75 4.6 Simple Streams Example . . . . . . . . . . . . . . . . . . . 16 76 5. Stream Encryption . . . . . . . . . . . . . . . . . . . . . 19 77 5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 19 78 5.2 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . 20 79 5.3 Client-to-Server Example . . . . . . . . . . . . . . . . . . 21 80 5.4 Server-to-Server Example . . . . . . . . . . . . . . . . . . 23 81 6. Stream Authentication . . . . . . . . . . . . . . . . . . . 26 82 6.1 SASL Authentication . . . . . . . . . . . . . . . . . . . . 26 83 6.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 26 84 6.1.2 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . 27 85 6.1.3 SASL Definition . . . . . . . . . . . . . . . . . . . . . . 29 86 6.1.4 Client-to-Server Example . . . . . . . . . . . . . . . . . . 30 87 6.1.5 Server-to-Server Example . . . . . . . . . . . . . . . . . . 32 88 6.2 Dialback Authentication . . . . . . . . . . . . . . . . . . 35 89 6.2.1 Dialback Protocol . . . . . . . . . . . . . . . . . . . . . 37 90 7. XML Stanzas . . . . . . . . . . . . . . . . . . . . . . . . 42 91 7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 42 92 7.2 Common Attributes . . . . . . . . . . . . . . . . . . . . . 42 93 7.2.1 to . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 94 7.2.2 from . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 95 7.2.3 id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 96 7.2.4 type . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 97 7.2.5 xml:lang . . . . . . . . . . . . . . . . . . . . . . . . . . 43 98 7.3 Message Stanzas . . . . . . . . . . . . . . . . . . . . . . 44 99 7.3.1 Types of Message . . . . . . . . . . . . . . . . . . . . . . 44 100 7.3.2 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 44 101 7.4 Presence Stanzas . . . . . . . . . . . . . . . . . . . . . . 46 102 7.4.1 Types of Presence . . . . . . . . . . . . . . . . . . . . . 46 103 7.4.2 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 46 104 7.5 IQ Stanzas . . . . . . . . . . . . . . . . . . . . . . . . . 48 105 7.5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 48 106 7.5.2 Types of IQ . . . . . . . . . . . . . . . . . . . . . . . . 48 107 7.5.3 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 49 108 7.6 Extended Namespaces . . . . . . . . . . . . . . . . . . . . 49 109 7.7 Stanza Errors . . . . . . . . . . . . . . . . . . . . . . . 50 110 7.7.1 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 111 7.7.2 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 112 7.7.3 Conditions . . . . . . . . . . . . . . . . . . . . . . . . . 51 113 7.7.4 Extensibility . . . . . . . . . . . . . . . . . . . . . . . 52 114 8. XML Usage within XMPP . . . . . . . . . . . . . . . . . . . 54 115 8.1 Restrictions . . . . . . . . . . . . . . . . . . . . . . . . 54 116 8.2 Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . 54 117 8.3 Validation . . . . . . . . . . . . . . . . . . . . . . . . . 54 118 8.4 Character Encodings . . . . . . . . . . . . . . . . . . . . 55 119 8.5 Inclusion of Text Declaration . . . . . . . . . . . . . . . 55 120 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 56 121 9.1 XML Namespace Name for TLS Data . . . . . . . . . . . . . . 56 122 9.2 XML Namespace Name for SASL Data . . . . . . . . . . . . . . 56 123 9.3 XML Namespace Name for Stream Errors . . . . . . . . . . . . 56 124 9.4 XML Namespace Name for Stanza Errors . . . . . . . . . . . . 57 125 9.5 Existing Registrations . . . . . . . . . . . . . . . . . . . 57 126 10. Internationalization Considerations . . . . . . . . . . . . 58 127 11. Security Considerations . . . . . . . . . . . . . . . . . . 59 128 11.1 High Security . . . . . . . . . . . . . . . . . . . . . . . 59 129 11.2 Client-to-Server Communications . . . . . . . . . . . . . . 59 130 11.3 Server-to-Server Communications . . . . . . . . . . . . . . 60 131 11.4 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . 60 132 11.5 Mandatory to Implement Technologies . . . . . . . . . . . . 60 133 Normative References . . . . . . . . . . . . . . . . . . . . 61 134 Informative References . . . . . . . . . . . . . . . . . . . 63 135 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 63 136 A. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . 65 137 A.1 Streams namespace . . . . . . . . . . . . . . . . . . . . . 65 138 A.2 TLS namespace . . . . . . . . . . . . . . . . . . . . . . . 66 139 A.3 SASL namespace . . . . . . . . . . . . . . . . . . . . . . . 66 140 A.4 Dialback namespace . . . . . . . . . . . . . . . . . . . . . 67 141 A.5 Client namespace . . . . . . . . . . . . . . . . . . . . . . 68 142 A.6 Server namespace . . . . . . . . . . . . . . . . . . . . . . 72 143 A.7 Stream error namespace . . . . . . . . . . . . . . . . . . . 76 144 A.8 Stanza error namespace . . . . . . . . . . . . . . . . . . . 77 145 B. Revision History . . . . . . . . . . . . . . . . . . . . . . 79 146 B.1 Changes from draft-ietf-xmpp-core-09 . . . . . . . . . . . . 79 147 B.2 Changes from draft-ietf-xmpp-core-09 . . . . . . . . . . . . 79 148 B.3 Changes from draft-ietf-xmpp-core-08 . . . . . . . . . . . . 79 149 B.4 Changes from draft-ietf-xmpp-core-07 . . . . . . . . . . . . 80 150 B.5 Changes from draft-ietf-xmpp-core-06 . . . . . . . . . . . . 80 151 B.6 Changes from draft-ietf-xmpp-core-05 . . . . . . . . . . . . 80 152 B.7 Changes from draft-ietf-xmpp-core-04 . . . . . . . . . . . . 80 153 B.8 Changes from draft-ietf-xmpp-core-03 . . . . . . . . . . . . 80 154 B.9 Changes from draft-ietf-xmpp-core-02 . . . . . . . . . . . . 81 155 B.10 Changes from draft-ietf-xmpp-core-01 . . . . . . . . . . . . 81 156 B.11 Changes from draft-ietf-xmpp-core-00 . . . . . . . . . . . . 81 157 B.12 Changes from draft-miller-xmpp-core-02 . . . . . . . . . . . 81 158 Intellectual Property and Copyright Statements . . . . . . . 83 160 1. Introduction 162 1.1 Overview 164 The Extensible Messaging and Presence Protocol (XMPP) is an open XML 165 [1] protocol for near-real-time messaging, presence, and 166 request-response services. The basic syntax and semantics were 167 developed originally within the Jabber open-source community, mainly 168 in 1999. In 2002, the XMPP WG was chartered with developing an 169 adaptation of the Jabber protocol that would be suitable as an IETF 170 instant messaging and presence technology. As a result of work by the 171 XMPP WG, the current document defines the core features of XMPP; XMPP 172 IM [23] defines the extensions required to provide the instant 173 messaging (IM) and presence functionality defined in RFC 2779 [2]. 175 1.2 Terminology 177 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 178 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 179 "OPTIONAL" in this document are to be interpreted as described in RFC 180 2119 [3]. 182 1.3 Discussion Venue 184 The authors welcome discussion and comments related to the topics 185 presented in this document. The preferred forum is the 186 mailing list, for which archives and subscription 187 information are available at . 190 1.4 Intellectual Property Notice 192 This document is in full compliance with all provisions of Section 10 193 of RFC 2026. Parts of this specification use the term "jabber" for 194 identifying namespaces and other protocol syntax. Jabber[tm] is a 195 registered trademark of Jabber, Inc. Jabber, Inc. grants permission 196 to the IETF for use of the Jabber trademark in association with this 197 specification and its successors, if any. 199 2. Generalized Architecture 201 2.1 Overview 203 Although XMPP is not wedded to any specific network architecture, to 204 this point it usually has been implemented via a typical 205 client-server architecture, wherein a client utilizing XMPP accesses 206 a server over a TCP [4] socket. 208 The following diagram provides a high-level overview of this 209 architecture (where "-" represents communications that use XMPP and 210 "=" represents communications that use any other protocol). 212 C1 - S1 - S2 - C3 213 / \ 214 C2 - G1 = FN1 = FC1 216 The symbols are as follows: 218 o C1, C2, C3 -- XMPP clients 220 o S1, S2 -- XMPP servers 222 o G1 -- A gateway that translates between XMPP and the protocol(s) 223 used on a foreign (non-XMPP) messaging network 225 o FN1 -- A foreign messaging network 227 o FC1 -- A client on a foreign messaging network 229 2.2 Server 231 A server acts as an intelligent abstraction layer for XMPP 232 communications. Its primary responsibilities are to manage 233 connections from or sessions for other entities (in the form of XML 234 streams to and from authorized clients, servers, and other entities) 235 and to route appropriately-addressed XML data "stanzas" among such 236 entities over XML streams. Most XMPP-compliant servers also assume 237 responsibility for the storage of data that is used by clients (e.g., 238 contact lists for users of XMPP-based IM applications); in this case, 239 the XML data is processed directly by the server itself on behalf of 240 the client and is not routed to another entity. Compliant server 241 implementations MUST ensure in-order processing of XML stanzas 242 between any two entities. 244 2.3 Client 245 Most clients connect directly to a server over a TCP socket and use 246 XMPP to take full advantage of the functionality provided by a server 247 and any associated services. Although there is no necessary coupling 248 of an XML stream to a TCP socket (e.g., a client COULD connect via 249 HTTP polling or some other mechanism), this specification defines a 250 binding for XMPP to TCP only. Multiple resources (e.g., devices or 251 locations) MAY connect simultaneously to a server on behalf of each 252 authorized client, with each resource connecting over a discrete TCP 253 socket and differentiated by the resource identifier of a Jabber 254 Identifier (e.g., user@domain/home vs. user@domain/work) as defined 255 under Section 3. The port registered with the IANA [5] for 256 connections between a Jabber client and a Jabber server is 5222. 258 2.4 Gateway 260 A gateway is a special-purpose server-side service whose primary 261 function is to translate XMPP into the protocol used by a foreign 262 (non-XMPP) messaging system, as well as to translate the return data 263 back into XMPP. Examples are gateways to Internet Relay Chat (IRC), 264 Short Message Service (SMS), SMTP, and legacy instant messaging 265 networks such as AIM, ICQ, MSN Messenger, and Yahoo! Instant 266 Messenger. Communications between gateways and servers, and between 267 gateways and the foreign messaging system, are not defined in this 268 document. 270 2.5 Network 272 Because each server is identified by a network address and because 273 server-to-server communications are a straightforward extension of 274 the client-to-server protocol, in practice the system consists of a 275 network of servers that inter-communicate. Thus user-a@domain1 is 276 able to exchange messages, presence, and other information with 277 user-b@domain2. This pattern is familiar from messaging protocols 278 (such as SMTP) that make use of network addressing standards. There 279 are two methods for negotiating a connection between any two servers: 280 primarily SASL authentication (Section 6.1) and secondarily server 281 dialback (Section 6.2). 283 3. Addressing Scheme 285 3.1 Overview 287 An entity is anything that can be considered a network endpoint 288 (i.e., an ID on the network) and that can communicate using XMPP. All 289 such entities are uniquely addressable in a form that is consistent 290 with RFC 2396 [24]. In particular, a valid Jabber Identifier (JID) 291 contains a set of ordered elements formed of a domain identifier, 292 node identifier, and resource identifier in the following format: 293 [node@]domain[/resource]. 295 All JIDs are based on the foregoing structure. The most common use of 296 this structure is to identify an IM user, the server to which the 297 user connects, and the user's active session or connection (e.g., a 298 specific client) in the form of . However, node 299 types other than clients are possible; for example, a specific chat 300 room offered by a multi-user chat service could be addressed as 301 (where "room" is the name of the chat room and 302 "service" is the hostname of the multi-user chat service) and a 303 specific occupant of such a room could be addressed as (where "nick" is the occupant's room nickname). Many other JID 305 types are possible (e.g., could be a server-side 306 script or service). 308 3.2 Domain Identifier 310 The domain identifier is the primary identifier and is the only 311 REQUIRED element of a JID (a mere domain identifier is a valid JID). 312 It usually represents the network gateway or "primary" server to 313 which other entities connect for XML routing and data management 314 capabilities. However, the entity referenced by a domain identifier 315 is not always a server, and may be a service that is addressed as a 316 subdomain of a server and that provides functionality above and 317 beyond the capabilities of a server (a multi-user chat service, a 318 user directory, a gateway to a foreign messaging system, etc.). 320 The domain identifier for every server or service that will 321 communicate over a network SHOULD resolve to a Fully Qualified Domain 322 Name. A domain identifier MUST conform to RFC 952 [6] and RFC 1123 323 [7]. A domain identifier MUST be no more than 1023 bytes in length 324 and MUST conform to the nameprep [8] profile of stringprep [9]. 326 3.3 Node Identifier 328 The node identifier is an optional secondary identifier. It usually 329 represents the entity requesting and using network access provided by 330 the server or gateway (i.e., a client), although it can also 331 represent other kinds of entities (e.g., a multi-user chat room 332 associated with a multi-user chat service). The entity represented by 333 a node identifier is addressed within the context of a specific 334 domain; within IM applications of XMPP this address is called a "bare 335 JID" and is of the form . 337 A node identifier MUST be no more than 1023 bytes in length and MUST 338 conform to the nodeprep [10] profile of stringprep [9]. 340 3.4 Resource Identifier 342 The resource identifier is an optional tertiary identifier, which may 343 modify either a or mere address. It usually 344 represents a specific session, connection (e.g., a device or 345 location), or object (e.g., a participant in a multi-user chat room) 346 belonging to the entity associated with a node identifier. A resource 347 identifier is opaque to both servers and other clients, and is 348 typically defined by a client implementation as the authzid value 349 provided during stream authentication. An entity may maintain 350 multiple resources simultaneously. 352 A resource identifier MUST be no more than 1023 bytes in length and 353 MUST conform to the resourceprep [11] profile of stringprep [9]. 355 4. XML Streams 357 4.1 Overview 359 Two fundamental concepts make possible the rapid, asynchronous 360 exchange of relatively small payloads of structured information 361 between presence-aware entities: XML streams and XML stanzas. These 362 terms may be defined as follows: 364 Definition of XML Stream: An XML stream is a container for the 365 exchange of XML elements between any two entities over a network. 366 An XML stream is negotiated from an initiating entity (usually a 367 client or server) to a receiving entity (usually a server), 368 normally over a TCP socket, and corresponds to the initiating 369 entity's "session" with the receiving entity. The start of the XML 370 stream is denoted unambiguously by an opening XML tag 371 with appropriate attributes and namespace declarations, and the 372 end of the XML stream is denoted unambiguously by a closing XML tag. An XML stream is unidirectional; in order to enable 374 bidirectional information exchange, the initiating entity and 375 receiving entity must negotiate one stream in each direction, 376 normally over the same TCP connection. 378 Definition of XML Stanza: An XML stanza is a discrete semantic unit 379 of structured information that is sent from one entity to another 380 over an XML stream. An XML stanza exists at the direct child level 381 of the root element and is said to be well-balanced if 382 it matches production [43] content of the XML specification [1]). 383 The start of any XML stanza is denoted unambiguously by the 384 element start tag at depth=1 of the XML stream (e.g., ), 385 and the end of any XML stanza is denoted unambiguously by the 386 corresponding close tag at depth=1 (e.g., ). An XML 387 stanza MAY contain child elements (with accompanying attributes, 388 elements, and CDATA) as necessary in order to convey the desired 389 information. 391 Consider the example of a client's session with a server. In order to 392 connect to a server, a client must initiate an XML stream by sending 393 an opening tag to the server, optionally preceded by a text 394 declaration specifying the XML version supported and the character 395 encoding (see also Section 8.4). The server SHOULD then reply with a 396 second XML stream back to the client, again optionally preceded by a 397 text declaration. Once the client has authenticated with the server 398 (see Section 6), the client MAY send an unlimited number of XML 399 stanzas over the stream to any recipient on the network. When the 400 client desires to close the stream, it simply sends a closing tag to the server (alternatively, the stream may be closed by 402 the server), after which both the client and server SHOULD close the 403 underlying TCP connection as well. 405 Those who are accustomed to thinking of XML in a document-centric 406 manner may wish to view a client's session with a server as 407 consisting of two open-ended XML documents: one from the client to 408 the server and one from the server to the client. From this 409 perspective, the root element can be considered the 410 document entity for each "document", and the two "documents" are 411 built up through the accumulation of XML stanzas sent over the two 412 XML streams. However, this perspective is a convenience only, and 413 XMPP does not deal in documents but in XML streams and XML stanzas. 415 In essence, then, an XML stream acts as an envelope for all the XML 416 stanzas sent during a session. We can represent this graphically as 417 follows: 419 |--------------------| 420 | | 421 |--------------------| 422 | | 423 | | 424 | | 425 |--------------------| 426 | | 427 | | 428 | | 429 |--------------------| 430 | | 431 | | 432 | | 433 |--------------------| 434 | ... | 435 |--------------------| 436 | | 437 |--------------------| 439 4.2 Stream Attributes 441 The attributes of the stream element are as follows: 443 o to -- The 'to' attribute SHOULD be used only in the XML stream 444 header from the initiating entity to the receiving entity, and 445 MUST be set to the XMPP address of the receiving entity. There 446 SHOULD be no 'to' attribute set in the XML stream header by which 447 the receiving entity replies to the initiating entity; however, if 448 a 'to' attribute is included, it SHOULD be silently ignored by the 449 initiating entity. 451 o from -- The 'from' attribute SHOULD be used only in the XML stream 452 header from the receiving entity to the initiating entity, and 453 MUST be set to the XMPP address of the receiving entity granting 454 access to the initiating entity. There SHOULD be no 'from' 455 attribute on the XML stream header sent from the initiating entity 456 to the receiving entity; however, if a 'from' attribute is 457 included, it SHOULD be silently ignored by the receiving entity. 459 o id -- The 'id' attribute SHOULD be used only in the XML stream 460 header from the receiving entity to the initiating entity. This 461 attribute is a unique identifier created by the receiving entity 462 to function as a session key for the initiating entity's streams 463 with the receiving entity. There SHOULD be no 'id' attribute on 464 the XML stream header sent from the initiating entity to the 465 receiving entity; however, if an 'id' attribute is included, it 466 SHOULD be silently ignored by the receiving entity. 468 o version -- If the initiating entity complies with the protocol 469 defined herein, it MUST include a 'version' attribute in the XML 470 stream header it sends to the receiving entity, and it MUST set 471 the value of the 'version' attribute to "1.0". If the initiating 472 entity includes the version attribute and the receiving entity 473 supports XMPP 1.0, the receiving entity MUST reciprocate by 474 including the attribute in its response. 476 We can summarize these values as follows: 478 | initiating to receiving | receiving to initiating 479 ------------------------------------------------------------ 480 to | hostname of receiver | silently ignored 481 from | silently ignored | hostname of receiver 482 id | silently ignored | session key 483 version | signals XMPP 1.0 support | signals XMPP 1.0 support 485 4.3 Namespace Declarations 487 The stream element MUST possess both a stream namespace declaration 488 and a default namespace declaration (as "namespace declaration" is 489 defined in the XML namespaces specification [12]). 491 4.3.1 Stream Namespace Declaration 493 A stream namespace declaration (e.g., 'xmlns:stream') is REQUIRED in 494 both XML streams. A compliant entity SHOULD accept any namespace 495 prefix on the element; however, for historical reasons some 496 entities MAY accept only a 'stream' prefix, resulting in the use of a 497 element as the stream root. The name of the stream 498 namespace MUST be "http://etherx.jabber.org/streams". 500 4.3.2 Default Namespace Declaration 502 A default namespace declaration ('xmlns') is REQUIRED and is used in 503 both XML streams in order to define the allowable first-level 504 children of the root stream element for both streams. This namespace 505 declaration MUST be the same for the initiating stream and the 506 responding stream so that both streams are scoped consistently. The 507 default namespace declaration applies to the stream and all stanzas 508 sent within a stream (unless explicitly scoped by another namespace). 510 Since XML streams function as containers for any XML stanzas sent 511 asynchronously between network endpoints, it should be possible to 512 scope an XML stream with any default namespace declaration. At a 513 minimum, a compliant implementation MUST support the following two 514 namespaces (for historical reasons, some implementations MAY support 515 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 524 identical but are used in different contexts (client-to-server 525 communications for 'jabber:client' and server-to-server 526 communications for 'jabber:server'). The only difference between the 527 two is that the 'to' and 'from' attributes are OPTIONAL on stanzas 528 sent within 'jabber:client', whereas they are REQUIRED on stanzas 529 sent within 'jabber:server'. If a compliant implementation accepts a 530 stream that is scoped by the 'jabber:client' or 'jabber:server' 531 namespace, it MUST support all three core stanza types (message, 532 presence, and IQ) as described herein and defined in the schema. 534 4.4 Stream Features 536 If the initiating entity sends a "version='1.0'" flag in its 537 initiating stream element, the receiving entity MUST send a features 538 child element to the initiating entity in order to announce any 539 stream-level features that can be negotiated (or capabilities that 540 otherwise need to be advertised). Currently this is used for SASL and 541 TLS negotiation only, but it could be used for other negotiable 542 features in the future (usage is defined under Stream Encryption 543 (Section 5) and Stream Authentication (Section 6) below). If an 544 entity does not understand or support some features, it SHOULD 545 silently ignore them. 547 4.5 Stream Errors 549 The root stream element MAY contain an error child element (e.g., 550 if the stream namespace prefix is 'stream'). The 551 error child MUST be sent by a compliant entity (usually a server 552 rather than a client) if it perceives that a stream-level error has 553 occurred. 555 4.5.1 Rules 557 The following rules apply to stream-level errors: 559 o It is assumed that all stream-level errors are unrecoverable; 560 therefore, if an error occurs at the level of the stream, the 561 entity that detects the error MUST send a stream error to the 562 other entity, send a closing tag, and close the 563 underlying TCP connection. 565 o If the error occurs while the stream is being set up, the 566 receiving entity MUST still send the opening and closing stream 567 tags and include the error element as a child of the stream 568 element. In this case, if the initiating entity provides an 569 unknown host in the 'to' attribute (or provides no 'to' attribute 570 at all), the server SHOULD provide the server's authoritative 571 hostname in the 'from' attribute of the stream header sent before 572 termination. 574 4.5.2 Syntax 576 The syntax for stream errors is as follows: 578 579 580 581 582 584 The value of the 'class' attribute must be one of the following: 586 o address -- the condition relates to the JID or domain to which the 587 stream was addressed 589 o format -- the condition relates to XML format or structure 591 o redirect -- the condition relates to a host redirection 593 o server -- the condition relates to the internal state of the 594 server 596 The element MUST contain a child element that specifies 597 a particular stream-level error condition, as defined in the next 598 section. (Note: the XML namespace name 599 'urn:ietf:params:xml:ns:xmpp-streams' that scopes the 600 element adheres to the format defined in The IETF XML Registry [25].) 602 4.5.3 Conditions 604 The following stream-level error conditions are defined: 606 o -- the value of the 'to' attribute provided by the 607 initiating entity in the stream header corresponds to a hostname 608 that is no longer hosted by the server; the associated class is 609 "address". 611 o -- the value of the 'to' attribute provided by the 612 initiating entity in the stream header does not correspond to a 613 hostname that is hosted by the server; the associated class is 614 "address". 616 o -- the server has experienced a 617 misconfiguration or an otherwise-undefined internal error that 618 prevents it from servicing the stream; the associated class is 619 "server". 621 o -- the stream ID or dialback ID is invalid or does 622 not match an ID previously provided; the associated class is 623 "format". 625 o -- the stream namespace name is something 626 other than "http://etherx.jabber.org/streams" or the dialback 627 namespace name is something other than "jabber:server:dialback"; 628 the associated class is "format". 630 o -- the hostname provided in a 'from' address 631 does not match the hostname (or any validated domain) negotiated 632 via SASL or dialback; the associated class is "address". 634 o -- the entity does not possess sufficient 635 privileges to perform the desired action; the associated class is 636 "access". 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 672 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 after similar extensions for the IMAP 739 [26], POP3 [27], and ACAP [28] protocols as described in RFC 2595 740 [29]. The namespace name for the STARTTLS extension is 741 'urn:ietf:params:xml:ns:xmpp-tls', which adheres to the format 742 defined in The IETF XML Registry [25].) 744 TLS SHOULD be used between any initiating entity and any receiving 745 entity (e.g., a stream from a client to a server or from one server 746 to another). An administrator of a given domain MAY require use of 747 TLS for either or both client-to-server communications and 748 server-to-server communications. Servers SHOULD use TLS betweeen two 749 domains for the purpose of securing server-to-server communications. 750 When the remote domain is already known, the server can verify the 751 credentials of the known domain by comparing known keys or 752 certificates. When the remote domain is not recognized, it may still 753 be possible to verify a certificate if it is signed by a common 754 trusted authority. Even if there is no way to verify certificates 755 (e.g., an unknown domain with a self-signed certificate, or a 756 certificate signed by an unrecognized authority), if the servers 757 choose to communicate despite the lack of verified credentials, TLS 758 still SHOULD be used to provide channel encryption. 760 The following business rules apply: 762 1. An initiating entity that complies with this specification MUST 763 include the "version='1.0'" flag in the initiating stream header. 765 2. When a receiving entity that complies with this specification 766 receives an initiating stream header that includes the 767 "version='1.0'" flag, after sending a stream header in reply 768 (including the version flag) it MUST include a 769 element scoped by the 'urn:ietf:params:xml:ns:xmpp-tls' namespace 770 with the list of other stream features it supports. 772 3. If the initiating entity chooses to use TLS for stream 773 encryption, TLS negotiation MUST be completed before proceeding 774 to SASL negotiation. 776 4. The initiating entity MUST validate the certificate presented by 777 the receiving entity: 779 Case 1 -- The initiating entity has been configured with a set of 780 trusted root certificates: Normal certificate validation 781 processing is appropriate, and SHOULD follow the rules defined 782 for HTTP over TLS [14]. The trusted roots may be either a 783 well-known public set or a manually configured Root CA (e.g., 784 an organization's own Certificate Authority or a self-signed 785 Root CA for the service as described under High Security 786 (Section 11.1)). This case is RECOMMENDED. 788 Case 2 -- The initiating entity has been configured with the 789 receiving entity's self-signed service certificate: Simple 790 comparison of public keys is appropriate. This case is NOT 791 RECOMMENDED (see High Security (Section 11.1) for details). 793 If the above methods fail, the certificate SHOULD be presented to 794 a user for approval; if presented, the receiver MUST deliver the 795 entire certificate chain to the user, who SHOULD be given the 796 option to store the Root CA certificate (not the service or End 797 Entity certificate) and to not be queried again regarding 798 acceptance of the certificate for some reasonable period of time. 800 5. If the TLS negotiation is successful, the receiving entity MUST 801 discard any knowledge obtained from the initiating entity before 802 TLS takes effect. 804 6. If the TLS negotiation is successful, the initiating entity MUST 805 discard any knowledge obtained from the receiving entity before 806 TLS takes effect. 808 7. If the TLS negotiation is successful, the receiving entity MUST 809 NOT offer the STARTTLS extension to the initiating entity along 810 with the other stream features that are offered when the stream 811 is restarted. 813 8. If the TLS negotiation results in success, the initiating entity 814 SHOULD continue with SASL negotiation. 816 9. If the TLS negotiation results in failure, the receiving entity 817 MUST terminate both the XML stream and the underlying TCP 818 connection. 820 5.2 Narrative 822 When an initiating entity secures a stream with a receiving entity, 823 the steps involved are as follows: 825 1. The initiating entity opens a TCP connection and initiates the 826 stream by sending the opening XML stream header to the receiving 827 entity, including the "version='1.0'" flag. 829 2. The receiving entity responds by opening a TCP connection and 830 sending an XML stream header to the initiating entity, including 831 the "version='1.0'" flag. 833 3. The receiving entity offers the STARTTLS extension to the 834 initiating entity by including it with the list of other 835 supported stream features (if TLS is required for interaction 836 with the receiving entity, it SHOULD signal that fact by 837 including a element as a child of the 838 element). 840 4. The initiating entity issues the STARTTLS command to instruct the 841 receiving entity that it wishes to begin a TLS negotiation to 842 secure the stream. 844 5. The receiving entity MUST reply with either a element 845 or a element scoped by the 846 'urn:ietf:params:xml:ns:xmpp-tls' namespace. If the failure case 847 occurs, the receiving entity MUST terminate both the XML stream 848 and the underlying TCP connection. If the proceed case occurs, 849 the receiving entity MUST ignore any further XML data sent over 850 the XML stream but keep the underlying TCP connection open for 851 the purpose of completing the TLS negotiation. 853 6. The initiating entity and receiving entity attempt to complete a 854 TLS negotiation in accordance with RFC 2246 [13]. 856 7. If the TLS negotiation is successful, the initiating entity 857 SHOULD initiate a new stream by sending an opening XML stream 858 header to the receiving entity. If the TLS negotiation is 859 unsuccessful, the receiving entity MUST terminate the TCP 860 connection. 862 8. Upon receiving the new stream header from the initiating entity, 863 the receiving entity SHOULD respond by sending a new XML stream 864 header to the initiating entity along with the remaining 865 available features (but NOT including the STARTTLS element). 867 5.3 Client-to-Server Example 869 The following example shows the data flow for a client securing a 870 stream using STARTTLS (the IANA registers port 5222 for 871 client-to-server communications using XMPP/Jabber, but another port 872 MAY be used). 874 Step 1: Client initiates stream to server: 876 882 Step 2: Server responds by sending a stream tag to the client: 884 890 Step 3: Server sends the STARTTLS extension to the client along with 891 authentication mechanisms and any other stream features: 893 894 895 896 897 898 DIGEST-MD5 899 PLAIN 900 901 903 Step 4: Client sends the STARTTLS command to the server: 905 907 Step 5: Server informs client to proceed: 909 911 Step 5 (alt): Server informs client that TLS negotiation has failed 912 and closes both stream and TCP connection: 914 915 917 Step 6: Client and server attempt to complete TLS negotiation over 918 the existing TCP connection. 920 Step 7: If TLS negotiation is successful, client initiates a new 921 stream to the server: 923 929 Step 7 (alt): If TLS negotiation is unsuccessful, server MUST close 930 TCP connection. 932 Step 8: Server responds by sending a stream header to the client 933 along with any remaining negotiable stream features: 935 940 941 942 DIGEST-MD5 943 PLAIN 944 EXTERNAL 945 946 948 Step 9: Client SHOULD continue with stream authentication (Section 949 6). 951 5.4 Server-to-Server Example 953 The following example shows the data flow for two servers securing a 954 stream using STARTTLS (the IANA registers port 5269 for 955 server-to-server communications using XMPP/Jabber, but another port 956 MAY be used). 958 Step 1: Server1 initiates stream to Server2: 960 965 Step 2: Server2 responds by sending a stream tag to Server1: 967 973 Step 3: Server2 sends the STARTTLS extension to Server1 along with 974 authentication mechanisms and any other stream features: 976 977 978 979 980 981 DIGEST-MD5 982 KERBEROS_V4 983 984 986 Step 4: Server1 sends the STARTTLS command to Server2: 988 990 Step 5: Server2 informs Server1 to proceed: 992 994 Step 5 (alt): Server2 informs Server1 that TLS negotiation has failed 995 and closes stream: 997 998 1000 Step 6: Server1 and Server2 attempt to complete TLS negotiation via 1001 TCP. 1003 Step 7: If TLS negotiation is successful, Server1 initiates a new 1004 stream to Server2: 1006 1011 Step 7 (alt): If TLS negotiation is unsuccessful, server MUST close 1012 TCP connection. 1014 Step 8: Server2 responds by sending a stream header to Server1 along 1015 with any remaining negotiable stream features: 1017 1022 1023 1024 DIGEST-MD5 1025 KERBEROS_V4 1026 EXTERNAL 1027 1028 1030 Step 9: Server1 SHOULD continue with stream authentication (Section 1031 6). 1033 6. Stream Authentication 1035 XMPP includes two methods for enforcing authentication at the level 1036 of XML streams. The secure and preferred method for authenticating 1037 streams between two entities uses an XMPP adaptation of the Simple 1038 Authentication and Security Layer (SASL) [15]. If SASL negotiation is 1039 not possible, some level of trust MAY be established between servers 1040 based on existing trust in DNS; the authentication method used in 1041 this case is the server dialback protocol that is native to XMPP (no 1042 such ad-hoc method is defined between a client and a server). If SASL 1043 is used for server-to-server authentication, the servers MUST NOT use 1044 dialback. For further information about the relative merits of these 1045 two methods, consult Security Considerations (Section 11). 1047 Stream authentication is REQUIRED for all direct communications 1048 between two entities; if an entity sends a stanza to an 1049 unauthenticated stream, the receiving entity SHOULD silently drop the 1050 stanza, MUST NOT process it, and MAY terminate both the XML stream 1051 and the underlying TCP connection. 1053 6.1 SASL Authentication 1055 6.1.1 Overview 1057 The Simple Authentication and Security Layer (SASL) provides a 1058 generalized method for adding authentication support to 1059 connection-based protocols. XMPP uses a generic XML namespace profile 1060 for SASL that conforms to section 4 ("Profiling Requirements") of RFC 1061 2222 [15] (the XMPP-specific namespace name is 1062 'urn:ietf:params:xml:ns:xmpp-sasl'), which adheres to the format 1063 defined in The IETF XML Registry [25].) 1065 The following business rules apply: 1067 1. If TLS is used for stream encryption, SASL SHOULD NOT be used for 1068 anything except stream authentication (i.e., a security layer 1069 SHOULD NOT be negotiated using SASL). Conversely, if a security 1070 layer is to be negotiated via SASL, TLS SHOULD NOT be used. 1072 2. If the initiating entity is capable of authenticating via SASL, 1073 it MUST include the "version='1.0'" flag in the initiating stream 1074 header. 1076 3. If the receiving entity is capable of accepting authentications 1077 via SASL, it MUST send one or more authentication mechanisms 1078 within a element scoped by the 1079 'urn:ietf:params:xml:ns:xmpp-sasl' namespace in response to the 1080 opening stream tag received from the initiating entity. 1082 4. If the SASL negotiation involves negotiation of a security layer, 1083 the receiving entity MUST discard any knowledge obtained from the 1084 initiating entity which was not obtained from the SASL 1085 negotiation itself. 1087 5. If the SASL negotiation involves negotiation of a security layer, 1088 the initiating entity MUST discard any knowledge obtained from 1089 the receiving entity which was not obtained from the SASL 1090 negotiation itself. 1092 The following syntax rules apply: 1094 1. The initial challenge MUST include a realm, nonce, qop, charset, 1095 and algorithm. 1097 2. The inital response for client-to-server negotiation MUST include 1098 all and only a username, realm, nonce, cnonce, nc, qop, 1099 digest-uri, response, charset, and authzid. 1101 3. The inital response for server-to-server negotiation MUST include 1102 all and only a realm, nonce, cnonce, nc, qop, digest-uri, 1103 response, and charset. 1105 4. The realm-value MUST be no more than 1023 bytes in length and 1106 MUST conform to the nameprep [8] profile of stringprep [9]. 1108 5. The username-value MUST be no more than 1023 bytes in length and 1109 MUST conform to the nodeprep [10] profile of stringprep [9]. 1111 6. The response-value MUST be computed in accordance with the 1112 relevant SASL mechanism as defined by the appropriate RFC (e.g., 1113 RFC 2831 [16] for digest authentication). 1115 7. The authzid-value MUST be a Jabber Identifier of the form 1116 , i.e., it MUST include a node identifier, 1117 domain identifier, and resource identifier. 1119 6.1.2 Narrative 1121 When an initiating entity authenticates with a receiving entity, the 1122 steps involved are as follows: 1124 1. The initiating entity requests SASL authentication by including a 1125 'version' attribute in the opening XML stream header sent to the 1126 receiving entity, with the value set to "1.0". 1128 2. After sending an XML stream header in response, the receiving 1129 entity sends a list of available SASL authentication mechanisms; 1130 each of these is a element included as a child 1131 within a container element scoped by the 1132 'urn:ietf:params:xml:ns:xmpp-sasl' namespace, which in turn is a 1133 child of a element in the streams namespace. If 1134 channel encryption must be established before a particular 1135 authentication mechanism may be used, the receiving entity MUST 1136 NOT provide that mechanism in the list of available SASL 1137 authentication methods prior to channel encryption. If the 1138 initiating entity presents a valid initiating entity certificate 1139 during prior TLS negotiation, the receiving entity MAY offer the 1140 SASL EXTERNAL mechanism to the initiating entity during stream 1141 authentication (see RFC 2222 [15]). 1143 3. The initiating entity selects a mechanism by sending an 1144 element scoped by the 'urn:ietf:params:xml:ns:xmpp-sasl' 1145 namespace to the receiving entity and including the appropriate 1146 value for the 'mechanism' attribute; this element MAY optionally 1147 contain character data (in SASL terminology the "initial 1148 response") if the mechanism supports or requires it. If the 1149 initiating entity selects the EXTERNAL mechanism for 1150 authentication, the authentication credentials shall be taken 1151 from the certificate presented during prior TLS negotiation. 1153 4. If necessary, the receiving entity challenges the initiating 1154 entity by sending a element scoped by the 1155 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating 1156 entity; this element MAY optionally contain character data (which 1157 MUST be computed in accordance with the SASL mechanism chosen by 1158 the initiating entity). 1160 5. The initiating entity responds to the challenge by sending a 1161 element scoped by the 1162 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the receiving 1163 entity; this element MAY optionally contain character data (which 1164 MUST be computed in accordance with the SASL mechanism chosen by 1165 the initiating entity). 1167 6. If necessary, the receiving entity sends more challenges and the 1168 initiating entity sends more responses. 1170 This series of challenge/response pairs continues until one of three 1171 things happens: 1173 1. The initiating entity aborts the handshake by sending an 1174 element to the receiving entity. 1176 2. The receiving entity reports failure of the handshake by sending 1177 a element scoped by the 1178 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating 1179 entity. The particular cause of failure SHOULD be communicated in 1180 an appropriate child element of the element. The 1181 following conditions are defined: 1183 * 1185 * 1187 * 1189 * 1191 * 1193 3. The receiving entity reports success of the handshake by sending 1194 a element scoped by the 1195 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating 1196 entity; this element MAY optionally contain character data (in 1197 SASL terminology "additional data with success"). 1199 Any character data contained within these elements MUST be encoded 1200 using base64. 1202 6.1.3 SASL Definition 1204 Section 4 of the SASL specification [15] requires that the following 1205 information be supplied by a protocol definition: 1207 service name: "xmpp" 1209 initiation sequence: After the initiating entity provides an opening 1210 XML stream header and the receiving entity replies in kind, the 1211 receiving entity provides a list of acceptable authentication 1212 methods. The initiating entity chooses one method from the list 1213 and sends it to the receiving entity as the value of the 1214 'mechanism' attribute possessed by an element, optionally 1215 including an initial response to avoid a round trip. 1217 exchange sequence: Challenges and responses are carried through the 1218 exchange of elements from receiving entity to 1219 initiating entity and elements from initiating entity 1220 to receiving entity. The receiving entity reports failure by 1221 sending a element and success by sending a 1222 element; the initiating entity aborts the exchange by sending an 1223 element. (All of these elements are scoped by the 1224 'urn:ietf:params:xml:ns:xmpp-sasl' namespace.) 1226 security layer negotiation: If a security layer is negotiated, both 1227 sides consider the original stream closed and new headers 1228 are sent by both entities. The security layer takes effect 1229 immediately following the ">" character of the element 1230 for the client and immediately following the closing ">" character 1231 of the element for the server. (Both of these elements 1232 are scoped by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace.) 1234 use of the authorization identity: The authorization identity is used 1235 by xmpp only in negotiation between a client and a server, and 1236 denotes the "full JID" (user@domain/resource) requested by the 1237 user or application associated with the client. 1239 6.1.4 Client-to-Server Example 1241 The following example shows the data flow for a client authenticating 1242 with a server using SASL (the IANA registers port 5222 for 1243 client-to-server communications using XMPP/Jabber, but another port 1244 MAY be used). 1246 Step 1: Client initiates stream to server: 1248 1254 Step 2: Server responds with a stream tag sent to the client: 1256 1263 Step 3: Server informs client of available authentication mechanisms: 1265 1266 1267 DIGEST-MD5 1268 PLAIN 1269 1270 1271 Step 4: Client selects an authentication mechanism: 1273 1277 Step 5: Server sends a base64-encoded challenge to the client: 1279 1280 cmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIi 1281 xxb3A9ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNz 1282 1284 The decoded challenge is: 1286 realm="cataclysm.cx",nonce="OA6MG9tEQGm2hh",\ 1287 qop="auth",charset=utf-8,algorithm=md5-sess 1289 Step 6: Client responds to the challenge: 1291 1292 dXNlcm5hbWU9InJvYiIscmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik 1293 9BNk1HOXRFUUdtMmhoIixjbm9uY2U9Ik9BNk1IWGg2VnFUclJrIixuYz0w 1294 MDAwMDAwMSxxb3A9YXV0aCxkaWdlc3QtdXJpPSJ4bXBwL2NhdGFjbHlzbS 1295 5jeCIscmVzcG9uc2U9ZDM4OGRhZDkwZDRiYmQ3NjBhMTUyMzIxZjIxNDNh 1296 ZjcsY2hhcnNldD11dGYtOCxhdXRoemlkPSJyb2JAY2F0YWNseXNtLmN4L2 1297 15UmVzb3VyY2Ui 1298 1300 The decoded response is: 1302 username="rob",realm="cataclysm.cx",\ 1303 nonce="OA6MG9tEQGm2hh",cnonce="OA6MHXh6VqTrRk",\ 1304 nc=00000001,qop=auth,digest-uri="xmpp/cataclysm.cx",\ 1305 response=d388dad90d4bbd760a152321f2143af7,charset=utf-8,\ 1306 authzid="rob@cataclysm.cx/myResource" 1308 Step 7: Server sends another challenge to the client: 1310 1311 cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA== 1312 1314 The decoded challenge is: 1316 rspauth=ea40f60335c427b5527b84dbabcdfffd 1317 Step 8: Client responds to the challenge: 1319 1321 Step 9: Server informs client of successful authentication: 1323 1325 Step 9 (alt): Server informs client of failed authentication: 1327 1328 1329 1331 Step 10: Client initiates a new stream to the server: 1333 1339 Step 11: Server responds by sending a stream header to the client, 1340 with the stream already authenticated (not followed by further stream 1341 features): 1343 1350 6.1.5 Server-to-Server Example 1352 The following example shows the data flow for a server authenticating 1353 with another server using SASL (the IANA registers port 5269 for 1354 server-to-server communications using XMPP/Jabber, but another port 1355 MAY be used). 1357 Step 1: Server1 initiates stream to Server2: 1359 1364 Step 2: Server2 responds with a stream tag sent to Server1: 1366 1372 Step 3: Server2 informs Server1 of available authentication 1373 mechanisms: 1375 1376 1377 DIGEST-MD5 1378 KERBEROS_V4 1379 1380 1382 Step 4: Server1 selects an authentication mechanism: 1384 1388 Step 5: Server2 sends a base64-encoded challenge to Server1: 1390 1391 cmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIi 1392 xxb3A9ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNz 1393 1395 The decoded challenge is: 1397 realm="cataclysm.cx",nonce="OA6MG9tEQGm2hh",\ 1398 qop="auth",charset=utf-8,algorithm=md5-sess 1400 Step 6: Server1 responds to the challenge: 1402 1403 cmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIi 1404 xjbm9uY2U9Ik9BNk1IWGg2VnFUclJrIixuYz0wMDAwMDAwMSxxb3A9YXV0 1405 aCxkaWdlc3QtdXJpPSJ4bXBwL2NhdGFjbHlzbS5jeCIscmVzcG9uc2U9ZD 1406 M4OGRhZDkwZDRiYmQ3NjBhMTUyMzIxZjIxNDNhZjcsY2hhcnNldD11dGYt 1407 OAo= 1408 1410 The decoded response is: 1412 realm="cataclysm.cx",nonce="OA6MG9tEQGm2hh",cnonce="OA6MHXh6VqTrRk",\ 1413 nc=00000001,qop=auth,digest-uri="xmpp/cataclysm.cx",\ 1414 response=d388dad90d4bbd760a152321f2143af7,charset=utf-8 1416 Step 7: Server2 sends another challenge to Server1: 1418 1419 cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA== 1420 1422 The decoded challenge is: 1424 rspauth=ea40f60335c427b5527b84dbabcdfffd 1426 Step 8: Server1 responds to the challenge: 1428 1430 Step 9: Server2 informs Server1 of successful authentication: 1432 1434 Step 9 (alt): Server2 informs Server1 of failed authentication: 1436 1437 1438 1440 Step 10: Server1 initiates a new stream to Server2: 1442 1447 Step 11: Server2 responds by sending a stream header to Server1, with 1448 the stream already authenticated (not followed by further stream 1449 features): 1451 1457 6.2 Dialback Authentication 1459 XMPP includes a protocol-level method for verifying that a connection 1460 between two servers can be trusted as much as the DNS can be trusted. 1461 The method is called dialback and is used only within XML streams 1462 that are declared under the "jabber:server" namespace. 1464 The purpose of the dialback protocol is to make server spoofing more 1465 difficult, and thus to make it more difficult to forge XML stanzas. 1466 Dialback is decidedly not intended as a mechanism for securing or 1467 encrypting the streams between servers as is done via SASL and TLS, 1468 only for helping to prevent the spoofing of a server and the sending 1469 of false data from it. In particular, dialback authentication is 1470 susceptible to DNS poisoning attacks unless DNSSec [30] is used. 1471 Furthermore, even if the DNS information is accurate, dialback 1472 authentication cannot protect from attacks where the attacker is 1473 capable of hijacking the IP address of the remote domain. Domains 1474 requiring more robust security SHOULD use TLS and SASL as defined 1475 above. 1477 Server dialback is made possible by the existence of DNS, since one 1478 server can verify that another server which is connecting to it is 1479 authorized to represent a given hostname. All DNS hostname 1480 resolutions MUST first resolve the hostname using an SRV [18] record 1481 of _jabber._tcp.server. If the SRV lookup fails, the fallback is a 1482 normal A lookup to determine the IP address, using the jabber-server 1483 port of 5269 assigned by the Internet Assigned Numbers Authority [5]. 1485 The method for generating and verifying the keys used in the dialback 1486 protocol MUST take into account the hostnames being used, the random 1487 ID generated for the stream, and a secret known by the authoritative 1488 server's network. Generating unique but verifiable keys is important 1489 to prevent common man-in-the-middle attacks and server spoofing. 1491 Any error that occurs during dialback negotiation MUST be considered 1492 a stream error, resulting in termination of the stream and of the 1493 underlying TCP connection. The possible error conditions are 1494 specified in the protocol description below. 1496 The following terminology applies: 1498 o Originating Server -- the server that is attempting to establish a 1499 connection between two domains. 1501 o Receiving Server -- the server that is trying to authenticate that 1502 Originating Server represents the domain which it claims to be. 1504 o Authoritative Server -- the server that answers to the DNS 1505 hostname asserted by Originating Server; for basic environments 1506 this will be Originating Server, but it could be a separate 1507 machine in Originating Server's network. 1509 The following is a brief summary of the order of events in dialback: 1511 1. Originating Server establishes a connection to Receiving Server. 1513 2. Originating Server sends a 'key' value over the connection to 1514 Receiving Server. 1516 3. Receiving Server establishes a connection to Authoritative 1517 Server. 1519 4. Receiving Server sends the same 'key' value to Authoritative 1520 Server. 1522 5. Authoritative Server replies that key is valid or invalid. 1524 6. Receiving Server informs Originating Server whether it is 1525 authenticated or not. 1527 We can represent this flow of events graphically as follows: 1529 Originating Receiving 1530 Server Server 1531 ----------- --------- 1532 | | 1533 | establish connection | 1534 | ----------------------> | 1535 | | 1536 | send stream header | 1537 | ----------------------> | 1538 | | 1539 | establish connection | 1540 | <---------------------- | 1541 | | 1542 | send stream header | 1543 | <---------------------- | 1544 | | Authoritative 1545 | send dialback key | Server 1546 | ----------------------> | ------------- 1547 | | | 1548 | establish connection | 1549 | ----------------------> | 1550 | | 1551 | send stream header | 1552 | ----------------------> | 1553 | | 1554 | establish connection | 1555 | <---------------------- | 1556 | | 1557 | send stream header | 1558 | <---------------------- | 1559 | | 1560 | send dialback key | 1561 | ----------------------> | 1562 | | 1563 | validate dialback key | 1564 | <---------------------- | 1565 | 1566 | report dialback result | 1567 | <---------------------- | 1568 | | 1570 6.2.1 Dialback Protocol 1572 The interaction between the servers is as follows: 1574 1. Originating Server establishes TCP connection to Receiving 1575 Server. 1577 2. Originating Server sends a stream header to Receiving Server: 1579 1584 Note: the 'to' and 'from' attributes are NOT REQUIRED on the 1585 root stream element. The inclusion of the xmlns:db namespace 1586 declaration with the name shown indicates to Receiving Server 1587 that Originating Server supports dialback. If the namespace name 1588 is incorrect, then Receiving Server MUST generate an 1589 stream error condition and terminate both 1590 the XML stream and the underlying TCP connection. 1592 3. Receiving Server SHOULD send a stream header back to Originating 1593 Server, including a unique ID for this interaction: 1595 1601 Note: The 'to' and 'from' attributes are NOT REQUIRED on the 1602 root stream element. If the namespace name is incorrect, then 1603 Originating Server MUST generate an stream 1604 error condition and terminate both the XML stream and the 1605 underlying TCP connection. Note well that Receiving Server is 1606 NOT REQUIRED to reply and MAY silently terminate the XML stream 1607 and underlying TCP connection depending on security policies in 1608 place. 1610 4. Originating Server sends a dialback key to Receiving Server: 1612 1615 98AF014EDC0... 1616 1618 Note: this key is not examined by Receiving Server, since 1619 Receiving Server does not keep information about Originating 1620 Server between sessions. The key generated by Originating Server 1621 must be based in part on the value of the ID provided by 1622 Receiving Server in the previous step, and in part on a secret 1623 shared by Originating Server and Authoritative Server. If the 1624 value of the 'to' address does not match a hostname recognized 1625 by Receiving Server, then Receiving Server MUST generate a 1626 stream error condition and terminate both the 1627 XML stream and the underlying TCP connection. If the value of 1628 the 'from' address matches a domain with which Receiving Server 1629 already has an established connection, then Receiving Server 1630 SHOULD generate a stream error condition and 1631 terminate both the XML stream and the underlying TCP connection. 1633 5. Receiving Server establishes a TCP connection back to the domain 1634 name asserted by Originating Server, as a result of which it 1635 connects to Authoritative Server. (Note: as an optimization, an 1636 implementation MAY reuse an existing trusted connection here 1637 rather than opening a new TCP connection.) 1639 6. Receiving Server sends Authoritative Server a stream header: 1641 1646 Note: the 'to' and 'from' attributes are NOT REQUIRED on the 1647 root stream element. If the namespace name is incorrect, then 1648 Authoritative Server MUST generate an 1649 stream error condition and terminate both the XML stream and the 1650 underlying TCP connection. 1652 7. Authoritative Server sends Receiving Server a stream header: 1654 1660 Note: if the namespace name is incorrect, then Receiving Server 1661 MUST generate an stream error condition and 1662 terminate both the XML stream and the underlying TCP connection 1663 between it and Authoritative Server. If the ID does not match 1664 that provided by Receiving Server in Step 3, then Receiving 1665 Server MUST generate an stream error condition and 1666 terminate both the XML stream and the underlying TCP connection 1667 between it and Authoritative Server. If either of the foregoing 1668 stream errors occurs between Receiving Server and Authoritative 1669 Server, then Receiving Server MUST generate a 1670 stream error condition and terminate 1671 both the XML stream and the underlying TCP connection between it 1672 and Originating Server. 1674 8. Receiving Server sends Authoritative Server a stanza requesting 1675 that Authoritative Server verify a key: 1677 1681 98AF014EDC0... 1682 1684 Note: passed here are the hostnames, the original identifier 1685 from Receiving Server's stream header to Originating Server in 1686 Step 3, and the key that Originating Server sent to Receiving 1687 Server in Step 4. Based on this information as well as shared 1688 secret information within the Authoritative Server's network, 1689 the key is verified. Any verifiable method MAY be used to 1690 generate the key. If the value of the 'to' address does not 1691 match a hostname recognized by Authoritative Server, then 1692 Authoritative Server MUST generate a stream 1693 error condition and terminate both the XML stream and the 1694 underlying TCP connection. If the value of the 'from' address 1695 does not match the hostname represented by Receiving Server when 1696 opening the TCP connection (or any validated domain), then 1697 Authoritative Server MUST generate a stream 1698 error condition and terminate both the XML stream and the 1699 underlying TCP connection. 1701 9. Authoritative Server sends a stanza back to Receiving Server 1702 verifying whether the key was valid or invalid: 1704 1710 or 1712 1718 Note: if the ID does not match that provided by Receiving Server 1719 in Step 3, then Receiving Server MUST generate an 1720 stream error condition and terminate both the XML stream and the 1721 underlying TCP connection. If the value of the 'to' address does 1722 not match a hostname recognized by Receiving Server, then 1723 Receiving Server MUST generate a stream error 1724 condition and terminate both the XML stream and the underlying 1725 TCP connection. If the value of the 'from' address does not 1726 match the hostname represented by Originating Server when 1727 opening the TCP connection (or any validated domain), then 1728 Receiving Server MUST generate a stream 1729 error condition and terminate both the XML stream and the 1730 underlying TCP connection. 1732 10. Receiving Server informs Originating Server of the result: 1734 1739 Note: At this point the connection has either been validated via 1740 a type='valid', or reported as invalid. If the connection is 1741 invalid, then Receiving Server MUST terminate both the XML 1742 stream and the underlying TCP connection. If the connection is 1743 validated, data can be sent by Originating Server and read by 1744 Receiving Server; before that, all data stanzas sent to 1745 Receiving Server SHOULD be silently dropped. 1747 Even if dialback negotiation is successful, a server MUST verify that 1748 all XML stanzas received from the other server include a 'from' 1749 attribute and a 'to' attribute; if a stanza does not meet this 1750 restriction, the server that receives the stanza MUST generate an 1751 stream error condition and terminate both the XML 1752 stream and the underlying TCP connection. Furthermore, a server MUST 1753 verify that the 'from' attribute of stanzas received from the other 1754 server includes a validated domain for the stream; if a stanza does 1755 not meet this restriction, the server that receives the stanza MUST 1756 generate a stream error condition and terminate 1757 both the XML stream and the underlying TCP connection. Both of these 1758 checks help to prevent spoofing related to particular stanzas. 1760 7. XML Stanzas 1762 7.1 Overview 1764 Once the XML streams in each direction have been authenticated and 1765 (if desired) encrypted, XML stanzas can be sent over the streams. 1766 Three XML stanza types are defined for the 'jabber:client' and 1767 'jabber:server' namespaces: , , and . 1769 In essence, the stanza type can be seen as a "push" 1770 mechanism whereby one entity pushes information to another entity, 1771 similar to the communications that occur in a system such as email. 1772 The element can be seen as a basic broadcast or 1773 "publish-subscribe" mechanism, whereby multiple entities receive 1774 information (in this case, presence information) about an entity to 1775 which they have subscribed. The element can be seen as a 1776 "request-response" mechanism similar to HTTP, whereby two entities 1777 can engage in a structured conversation using 'get' or 'set' requests 1778 and 'result' or 'error' responses. 1780 7.2 Common Attributes 1782 The following five attributes are common to message, presence, and IQ 1783 stanzas: 1785 7.2.1 to 1787 The 'to' attribute specifies the JID of the intended recipient for 1788 the stanza. 1790 In the 'jabber:client' namespace, a stanza SHOULD possess a 'to' 1791 attribute, although a stanza sent from a client to a server for 1792 handling by that server (e.g., presence sent to the server for 1793 broadcasting to other entities) MAY legitimately lack a 'to' 1794 attribute. 1796 In the 'jabber:server' namespace, a stanza MUST possess a 'to' 1797 attribute; if a server receives a stanza that does not meet this 1798 restriction, it MUST generate an stream error 1799 condition and terminate both the XML stream and the underlying TCP 1800 connection. 1802 If the value of the 'to' attribute is invalid or cannot be contacted, 1803 the entity discovering that fact (usually the sender's or recipient's 1804 server) MUST return an appropriate error to the sender. 1806 7.2.2 from 1807 The 'from' attribute specifies the JID of the sender. 1809 In the 'jabber:client' namespace, a client MUST NOT include a 'from' 1810 attribute on the stanzas it sends to a server; if a server receives a 1811 stanza from a client and the stanza possesses a 'from' attribute, it 1812 MUST ignore the value of the 'from' attribute and MAY return an error 1813 to the sender. In addition, a server MUST stamp stanzas received from 1814 a client with the user@domain/resource (full JID) of the connected 1815 resource that generated the stanza as defined by the authzid provided 1816 in the SASL negotiation. 1818 In the 'jabber:server' namespace, a stanza MUST possess a 'from' 1819 attribute; if a server receives a stanza that does not meet this 1820 restriction, it MUST generate an stream error 1821 condition. Furthermore, the domain identifier portion of the JID 1822 contained in the 'from' attribute MUST match the hostname of the 1823 sending server (or any validated domain) as communicated in the SASL 1824 negotiation or dialback negotiation; if a server receives a stanza 1825 that does not meet this restriction, it MUST generate a 1826 stream error condition. Both of these conditions 1827 MUST result in closing of the stream and termination of the 1828 underlying TCP connection. 1830 7.2.3 id 1832 The optional 'id' attribute MAY be used by a sending entity for 1833 internal tracking of stanzas that it sends and receives (especially 1834 for tracking the request-response interaction inherent in the use of 1835 IQ stanzas). If the stanza sent by the sending entity is an IQ stanza 1836 of type "get" or "set", the receiving entity MUST include an 'id' 1837 attribute with the same value in any replies of type "result" or 1838 "error". The value of the 'id' attribute is NOT REQUIRED to be unique 1839 either globally, within a domain, or within a stream. 1841 7.2.4 type 1843 The 'type' attribute specifies detailed information about the purpose 1844 or context of the message, presence, or IQ stanza. The particular 1845 allowable values for the 'type' attribute vary depending on whether 1846 the stanza is a message, presence, or IQ, and thus are defined in the 1847 following sections. 1849 7.2.5 xml:lang 1851 A stanza SHOULD possess an 'xml:lang' attribute (as defined in 1852 Section 2.12 of the XML specification [1]) specifying the default 1853 language of any XML character data contained in the stanza or its 1854 child elements. The value of the 'xml:lang' attribute MUST be an 1855 NMTOKEN and MUST conform to the format defined in RFC 3066 [17]. 1857 7.3 Message Stanzas 1859 Message stanzas in the 'jabber:client' or 'jabber:server' namespace 1860 are used to "push" information to another entity. Common uses in the 1861 context of instant messaging include single messages, messages sent 1862 in the context of a chat conversation, messages sent in the context 1863 of a multi-user chat room, headlines, and errors. These messages 1864 types are identified more fully below. 1866 7.3.1 Types of Message 1868 The 'type' attribute of a message stanza is OPTIONAL; if included, it 1869 specifies the conversational context of the message. The sending of a 1870 message stanza without a 'type' attribute signals that the message 1871 stanza is a single message. However, the 'type' attribute MAY also 1872 have one of the following values: 1874 o chat 1876 o error 1878 o groupchat 1880 o headline 1882 For information about the meaning of these message types, refer to 1883 XMPP IM [23]. 1885 7.3.2 Children 1887 As described under extended namespaces (Section 7.6), a message 1888 stanza MAY contain any properly-namespaced child element. 1890 In accordance with the default namespace declaration, by default a 1891 message stanza is in the 'jabber:client' or 'jabber:server' 1892 namespace, which defines certain allowable children of message 1893 stanzas. If the message stanza is of type "error", it MUST include an 1894 child; for details, see Section 7.7. If the message stanza 1895 has no 'type' attribute or has a 'type' attribute with a value of 1896 "chat", "groupchat", or "headline", it MAY contain any of the 1897 following child elements without an explicit namespace declaration: 1899 7.3.2.1 Subject 1901 The element specifies the topic of the message. The 1902 element SHOULD NOT possess any attributes, with the 1903 exception of the 'xml:lang' attribute. Multiple instances of the 1904 element MAY be included for the purpose of providing 1905 alternate versions of the same subject, but only if each instance 1906 possesses an 'xml:lang' attribute with a distinct language value. The 1907 element MUST NOT contain mixed content. 1909 7.3.2.2 Body 1911 The element contains the textual contents of the message; 1912 this child element is normally included but NOT REQUIRED. The 1913 element SHOULD NOT possess any attributes, with the exception of the 1914 'xml:lang' attribute. Multiple instances of the element MAY 1915 be included but only if each instance possesses an 'xml:lang' 1916 attribute with a distinct language value. The element MUST NOT 1917 contain mixed content. 1919 7.3.2.3 Thread 1921 The element contains a random string that is generated by 1922 the sender and that SHOULD be copied back in replies; it is used for 1923 tracking a conversation thread (sometimes referred to as an "IM 1924 session") between two entities. If used, it MUST be unique to that 1925 conversation thread within the stream and MUST be consistent 1926 throughout that conversation. The use of the element is 1927 optional and is not used to identify individual messages, only 1928 conversations. Only one element MAY be included in a 1929 message stanza, and it MUST NOT possess any attributes. The 1930 element MUST be treated as an opaque string by entities; no semantic 1931 meaning may be derived from it, and only exact, case-insensitve 1932 comparisons may be made against it. The element MUST NOT 1933 contain mixed content. 1935 The method for generating thread IDs SHOULD be as follows: 1937 1. concatenate the sender's full JID (user@domain/resource) with the 1938 recipient's full JID 1940 2. concatenate these JID strings with a full ISO-8601 timestamp 1941 including year, month, day, hours, minutes, seconds, and UTC 1942 offset in the following format: YYYY-MM-DD-Thh:mm:ssTZD (where 1943 TZD is either "Z" for UTC or "[+|-]hh:mm" for an offset from UTC) 1945 3. hash the resulting string according to the SHA1 algorithm 1947 4. convert the hexidecimal SHA1 output to all lowercase 1949 7.4 Presence Stanzas 1951 Presence stanzas are used in the 'jabber:client' or 'jabber:server' 1952 namespace to express an entity's current availability status (offline 1953 or online, along with various sub-states of the latter and optional 1954 user-defined descriptive text) and to communicate that status to 1955 other entities. Presence stanzas are also used to negotiate and 1956 manage subscriptions to the presence of other entities. 1958 7.4.1 Types of Presence 1960 The 'type' attribute of a presence stanza is optional. A presence 1961 stanza that does not possess a 'type' attribute is used to signal to 1962 the server that the sender is online and available for communication. 1963 If included, the 'type' attribute specifies a lack of availability, a 1964 request to manage a subscription to another entity's presence, a 1965 request for another entity's current presence, or an error related to 1966 a previously-sent presence stanza. The 'type' attribute MAY have one 1967 of the following values: 1969 o unavailable -- Signals that the entity is no longer available for 1970 communication. 1972 o subscribe -- The sender wishes to subscribe to the recipient's 1973 presence. 1975 o subscribed -- The sender has allowed the recipient to receive 1976 their presence. 1978 o unsubscribe -- A notification that an entity is unsubscribing from 1979 another entity's presence. 1981 o unsubscribed -- The subscription request has been denied or a 1982 previously-granted subscription has been cancelled. 1984 o probe -- A request for an entity's current presence. In general 1985 SHOULD NOT be sent by a client. 1987 o error -- An error has occurred regarding processing or delivery of 1988 a previously-sent presence stanza. 1990 Detailed information about presence semantics and about the 1991 subscription model used within XMPP can be found in XMPP IM [23]. 1993 7.4.2 Children 1995 As described under extended namespaces (Section 7.6), a presence 1996 stanza MAY contain any properly-namespaced child element. 1998 In accordance with the default namespace declaration, by default a 1999 presence stanza is in the 'jabber:client' or 'jabber:server' 2000 namespace, which defines certain allowable children of presence 2001 stanzas. If the presence stanza is of type "error", it MUST include 2002 an child; for details, see Section 7.7. If the presence 2003 stanza possesses no 'type' attribute, it MAY contain any of the 2004 following child elements (note that the child MAY be sent 2005 in a presence stanza of type "unavailable" or, for historical 2006 reasons, "subscribe"): 2008 7.4.2.1 Show 2010 The optional element specifies a particular availability 2011 status of an entity or specific resource (if a element is not 2012 provided, default availability is assumed). Only one element 2013 MAY be included in a presence stanza, and it SHOULD NOT possess any 2014 attributes. The CDATA value SHOULD be one of the following (values 2015 other than these four SHOULD be ignored; additional availability 2016 types could be defined through a properly-namespaced child element of 2017 the presence stanza): 2019 o away 2021 o chat 2023 o xa 2025 o dnd 2027 For information about the meaning of these values, refer to XMPP IM 2028 [23]. 2030 7.4.2.2 Status 2032 The optional element contains a natural-language 2033 description of availability status. It is normally used in 2034 conjunction with the show element to provide a detailed description 2035 of an availability state (e.g., "In a meeting"). The 2036 element SHOULD NOT possess any attributes, with the exception of the 2037 'xml:lang' attribute. Multiple instances of the element MAY 2038 be included but only if each instance possesses an 'xml:lang' 2039 attribute with a distinct language value. 2041 7.4.2.3 Priority 2043 The optional element specifies the priority level of the 2044 connected resource. The value may be any integer between -128 and 2045 127. Only one element MAY be included in a presence 2046 stanza, and it MUST NOT possess any attributes. For information 2047 regarding the semantics of priority values in stanza routing within 2048 IM applications, see XMPP IM [23]. 2050 7.5 IQ Stanzas 2052 7.5.1 Overview 2054 Info/Query, or IQ, is a request-response mechanism, similar in some 2055 ways to HTTP [31]. IQ stanzas in the 'jabber:client' or 2056 'jabber:server' namespace enable an entity to make a request of, and 2057 receive a response from, another entity. The data content of the 2058 request and response is defined by the namespace declaration of a 2059 direct child element of the IQ element, and the interaction is 2060 tracked by the requesting entity through use of the 'id' attribute. 2062 Most IQ interactions follow a common pattern of structured data 2063 exchange such as get/result or set/result (although an error may be 2064 returned in response to a request if appropriate): 2066 Requesting Responding 2067 Entity Entity 2068 ---------- ---------- 2069 | | 2070 | | 2071 | ------------------------> | 2072 | | 2073 | | 2074 | <------------------------ | 2075 | | 2076 | | 2077 | ------------------------> | 2078 | | 2079 | | 2080 | <------------------------ | 2081 | | 2083 An entity that receives an IQ request of type "get" or "set" MUST 2084 reply with an IQ response of type "result" or "error" (which response 2085 MUST preserve the 'id' attribute of the request). An entity that 2086 receives a stanza of type "result" or "error" MUST NOT respond to the 2087 stanza by sending a further IQ response of type "result" or "error"; 2088 however, as shown above, the requesting entity MAY send another 2089 request (e.g., an IQ of type "set" in order to provide required 2090 information discovered through a get/result pair). 2092 7.5.2 Types of IQ 2093 The 'type' attribute of an IQ stanza is REQUIRED. The 'type' 2094 attribute specifies a distinct step within a request-response 2095 interaction. The value SHOULD be one of the following (all other 2096 values SHOULD be ignored): 2098 o get -- The stanza is a request for information or requirements. 2100 o set -- The stanza provides required data, sets new values, or 2101 replaces existing values. 2103 o result -- The stanza is a response to a successful get or set 2104 request. 2106 o error -- An error has occurred regarding processing or delivery of 2107 a previously-sent get or set. 2109 7.5.3 Children 2111 As described under extended namespaces (Section 7.6), an IQ stanza 2112 MAY contain any properly-namespaced child element. Note that an IQ 2113 stanza contains no children in the 'jabber:client' or 'jabber:server' 2114 namespace since it is a vessel for XML in another namespace. 2116 An IQ stanza of type "get" or "set" MUST include one and only one 2117 child element. An IQ stanza of type "error" SHOULD include the child 2118 element contained in the associated "set" or "get" and MUST include 2119 an child; for details, see Section 7.7. 2121 7.6 Extended Namespaces 2123 While the core data elements in the "jabber:client" or 2124 "jabber:server" namespace (along with their attributes and child 2125 elements) provide a basic level of functionality for messaging and 2126 presence, XMPP uses XML namespaces to extend the core data elements 2127 for the purpose of providing additional functionality. Thus a 2128 message, presence, or IQ stanza MAY house one or more optional child 2129 elements containing content that extends the meaning of the message 2130 (e.g., an encrypted form of the message body). This child element MAY 2131 have any name and MUST possess an 'xmlns' namespace declaration 2132 (other than "jabber:client", "jabber:server", or "http:// 2133 etherx.jabber.org/streams") that defines all data contained within 2134 the child element. 2136 Support for any given extended namespace is OPTIONAL on the part of 2137 any implementation. If an entity does not understand such a 2138 namespace, the entity's expected behavior depends on whether the 2139 entity is (1) the recipient or (2) an entity that is routing the 2140 stanza to the recipient. In particular: 2142 Recipient: If a recipient receives a stanza that contains a child 2143 element it does not understand, it SHOULD ignore that specific XML 2144 data, i.e., it SHOULD not process it or present it to a user or 2145 associated application (if any). In particular: 2147 * If an entity receives a message or presence stanza that 2148 contains XML data in an extended namespace it does not 2149 understand, the portion of the stanza that is in the unknown 2150 namespace SHOULD be ignored. 2152 * If an entity receives a message stanza without a 2153 element but containing only a child element bound by a 2154 namespace it does not understand, it MUST ignore the entire 2155 stanza. 2157 * If an entity receives an IQ stanza in a namespace it does not 2158 understand, the entity SHOULD return an IQ stanza of type 2159 "error" with an error condition of . 2161 Router: If a routing entity (usually a server) handles a stanza that 2162 contains a child element it does not understand, it SHOULD ignore 2163 the associated XML data by passing it on untouched to the 2164 recipient. 2166 7.7 Stanza Errors 2168 As defined herein, stanza-related errors are handled in a manner 2169 similar to stream errors (Section 4.5). 2171 7.7.1 Rules 2173 The following rules apply to stanza-related errors: 2175 o A stanza whose 'type' attribute has a value of "error" MUST 2176 contain an child element. 2178 o The receiving or processing entity that returns an error to the 2179 sending entity SHOULD include the original XML sent along with the 2180 element and its children so that the sender can inspect 2181 and if necessary correct the XML before re-sending. 2183 o An entity that receives a stanza whose 'type' attribute has a 2184 value of "error" MUST NOT respond to the stanza with a further 2185 stanza of type "error"; this helps to prevent looping. 2187 o An child MUST NOT be included if the 'type' attribute has 2188 a value other than "error". 2190 7.7.2 Syntax 2192 The syntax for stanza-related errors is as follows: 2194 2195 [include sender XML here] 2196 2197 2198 2199 2200 2201 2203 The stanza-name is one of message, presence, or iq. 2205 The value of the 'class' attribute MUST be one of the following: 2207 o access -- the condition relates to access rights, permissions, or 2208 authorization 2210 o address -- the condition relates to the JID or domain to which the 2211 stanza was addressed 2213 o format -- the condition relates to XML format or structure 2215 o recipient -- the condition relates to the state or capabilities of 2216 the recipient (which may be the server) 2218 o server -- the condition relates to the internal state of the 2219 server 2221 The element MUST contain a child element that specifies 2222 a particular stanza-related error condition, and its namespace name 2223 MUST be 'urn:ietf:params:xml:ns:xmpp-stanzas', which adheres to the 2224 format defined in The IETF XML Registry [25]. 2226 7.7.3 Conditions 2228 The following stanza-related error conditions are defined: 2230 o -- the sender has sent XML that is malformed or 2231 cannot be processed (e.g., a client-generated stanza includes a 2232 'from' address, or an IQ stanza includes an unrecognized value of 2233 the 'type' attribute); the associated class is "format". 2235 o -- access cannot be granted because an existing 2236 resource or session exists with the same name or address; the 2237 associated class is "access". 2239 o -- the feature requested is not 2240 implemented by the recipient or server and therefore cannot be 2241 processed; the associated class is "recipient". 2243 o -- the stanza is understood but the action is 2244 forbidden; the associated class is "access". 2246 o -- the server could not process the 2247 stanza because of a misconfiguration or an otherwise-undefined 2248 internal server error; the associated class is "server". 2250 o -- the addressed JID or item requested cannot be 2251 found; the associated class is "address". 2253 o -- the value of the 'to' attribute in the 2254 sender's stanza does not adhere to the syntax defined in 2255 Addressing (Section 3); the associated class is "address". 2257 o -- the action is not permitted when attempted by 2258 the sender; the associated class is "access". 2260 o -- the specific recipient requested is 2261 currently unavailable; the associated class is "recipient". 2263 o -- the user is not authorized to access 2264 the requested service because registration is required; the 2265 associated class is "access". 2267 o -- a remote server or service specified 2268 as part or all of the JID of the intended recipient does not 2269 exist; the associated class is "address". 2271 o -- a remote server or service specified 2272 as part or all of the JID of the intended recipient could not be 2273 contacted within a reasonable amount of time; the associated class 2274 is "server". 2276 o -- the service requested is currently 2277 unavailable on the server; the associated class is "server". 2279 7.7.4 Extensibility 2281 If desired, an XMPP application MAY provide custom error information 2282 by including a properly-namespaced child of the appropriate 2283 descriptive element name, for example: 2285 2286 2287 2288 2289 2290 2291 2292 2293 2295 8. XML Usage within XMPP 2297 8.1 Restrictions 2299 XMPP is a simplified and specialized protocol for streaming XML 2300 elements in order to exchange messages and presence information in 2301 close to real time. Because XMPP does not require the parsing of 2302 arbitrary and complete XML documents, there is no requirement that 2303 XMPP must support the full XML specification [1]. In particular, the 2304 following restrictions apply: 2306 With regard to XML generation, an XMPP implementation MUST NOT inject 2307 into an XML stream any of the following: 2309 o comments (as defined in Section 2.5 of the XML specification [1]) 2311 o processing instructions (Section 2.6) 2313 o internal or external DTD subsets (Section 2.8) 2315 o internal or external entity references (Section 4.2) with the 2316 exception of predefined entities (Section 4.6) 2318 With regard to XML processing, if an XMPP implementation receives 2319 such restricted XML data, it MUST ignore the data. 2321 8.2 Namespaces 2323 XML Namespaces [12] are used within all XMPP-compliant XML to create 2324 strict boundaries of data ownership. The basic function of namespaces 2325 is to separate different vocabularies of XML elements that are 2326 structurally mixed together. Ensuring that XMPP-compliant XML is 2327 namespace-aware enables any XML to be structurally mixed with any 2328 data element within XMPP. 2330 Additionally, an XMPP implementation MAY be more strict about 2331 namespace prefixes than the XML namespace specification requires. 2333 8.3 Validation 2335 Except as noted with regard to 'to' and 'from' addresses for stanzas 2336 within the 'jabber:server' namespace, a server is not responsible for 2337 validating the XML elements forwarded to a client or another server; 2338 an implementation MAY choose to provide only validated data elements 2339 but is NOT REQUIRED to do so. Clients SHOULD NOT rely on the ability 2340 to send data which does not conform to the schemas, and SHOULD ignore 2341 any non-conformant elements or attributes on the incoming XML stream. 2342 Validation of XML streams and stanzas is NOT REQUIRED or recommended, 2343 and schemas are included herein for descriptive purposes only. 2345 8.4 Character Encodings 2347 Software implementing XML streams MUST support the UTF-8 (RFC 2279 2348 [19]) and UTF-16 (RFC 2781 [20]) transformations of Universal 2349 Character Set (ISO/IEC 10646-1 [21]) characters. Software MUST NOT 2350 attempt to use any other encoding for transmitted data. The encodings 2351 of the transmitted and received streams are independent. Software MAY 2352 select either UTF-8 or UTF-16 for the transmitted stream, and SHOULD 2353 deduce the encoding of the received stream as described in the XML 2354 specification [1]. For historical reasons, existing implementations 2355 MAY support UTF-8 only. 2357 8.5 Inclusion of Text Declaration 2359 An application MAY send a text declaration. Applications MUST follow 2360 the rules in the XML specification [1] regarding the circumstances 2361 under which a text declaration is included. 2363 9. IANA Considerations 2365 9.1 XML Namespace Name for TLS Data 2367 A URN sub-namespace for TLS-related data in the Extensible Messaging 2368 and Presence Protocol (XMPP) is defined as follows. 2370 URI: urn:ietf:params:xml:ns:xmpp-tls 2372 Specification: [RFCXXXX] 2374 Description: This is the XML namespace name for TLS-related data in 2375 the Extensible Messaging and Presence Protocol (XMPP) as defined 2376 by [RFCXXXX]. 2378 Registrant Contact: IETF, XMPP Working Group, 2380 9.2 XML Namespace Name for SASL Data 2382 A URN sub-namespace for SASL-related data in the Extensible Messaging 2383 and Presence Protocol (XMPP) is defined as follows. 2385 URI: urn:ietf:params:xml:ns:xmpp-sasl 2387 Specification: [RFCXXXX] 2389 Description: This is the XML namespace name for SASL-related data in 2390 the Extensible Messaging and Presence Protocol (XMPP) as defined 2391 by [RFCXXXX]. 2393 Registrant Contact: IETF, XMPP Working Group, 2395 9.3 XML Namespace Name for Stream Errors 2397 A URN sub-namespace for stream-related error data in the Extensible 2398 Messaging and Presence Protocol (XMPP) is defined as follows. 2400 URI: urn:ietf:params:xml:ns:xmpp-streams 2402 Specification: [RFCXXXX] 2404 Description: This is the XML namespace name for stream-related error 2405 data in the Extensible Messaging and Presence Protocol (XMPP) as 2406 defined by [RFCXXXX]. 2408 Registrant Contact: IETF, XMPP Working Group, 2410 9.4 XML Namespace Name for Stanza Errors 2412 A URN sub-namespace for stanza-related error data in the Extensible 2413 Messaging and Presence Protocol (XMPP) is defined as follows. 2415 URI: urn:ietf:params:xml:ns:xmpp-stanzas 2417 Specification: [RFCXXXX] 2419 Description: This is the XML namespace name for stanza-related error 2420 data in the Extensible Messaging and Presence Protocol (XMPP) as 2421 defined by [RFCXXXX]. 2423 Registrant Contact: IETF, XMPP Working Group, 2425 9.5 Existing Registrations 2427 The IANA registers "xmpp" as a GSSAPI [22] service name, as specified 2428 in Section 6.1.3. 2430 Additionally, the IANA registers "jabber-client" and "jabber-server" 2431 as keywords for TCP ports 5222 and 5269 respectively. 2433 10. Internationalization Considerations 2435 Each XML stanza SHOULD include the 'xml:lang' attribute as described 2436 above. Servers MUST NOT modify or delete 'xml:lang' attributes from 2437 stanzas they receive from other entities. 2439 11. Security Considerations 2441 11.1 High Security 2443 For the purposes of XMPP communications (client-to-server and 2444 server-to-server), the term "high security" refers to the use of 2445 security technologies that provide both mutual authentication and 2446 integrity-checking; in particular, when using certificate-based 2447 authentication to provide high security, a chain-of-trust SHOULD be 2448 established out-of-band, although a shared certificate authority 2449 signing certificates could allow a previously unknown certificate to 2450 establish trust in-band. 2452 Standalone, self-signed service certificates SHOULD NOT be used; 2453 rather, an entity that wishes to generate a self-signed service 2454 certificate SHOULD first generate a self-signed Root CA certificate 2455 and then generate a signed service certificate. Entities that 2456 communicate with the service SHOULD be configured with the Root CA 2457 certificate rather than the service certificate; this avoids problems 2458 associated with simple comparison of service certificates. If a 2459 self-signed service certificate is used, an entity SHOULD NOT trust 2460 it if it is changed to another self-signed certificate or a 2461 certificate signed by an unrecognized authority. 2463 Implementations MUST support high security. Service provisioning 2464 SHOULD use high security, subject to local security policies. 2466 11.2 Client-to-Server Communications 2468 The TLS protocol for encrypting XML streams (defined under Section 5) 2469 provides a reliable mechanism for helping to ensure the 2470 confidentiality and data integrity of data exchanged between two 2471 entities. 2473 The SASL protocol for authenticating XML streams (defined under 2474 Section 6.1) provides a reliable mechanism for validating that a 2475 client connecting to a server is who it claims to be. 2477 The IP address and method of access of clients MUST NOT be made 2478 available by a server, nor are any connections other than the 2479 original server connection required. This helps to protect the 2480 client's server from direct attack or identification by third 2481 parties. 2483 End-to-end encryption of message bodies and presence status 2484 information MAY be effected through use of the methods defined in 2485 End-to-End Object Encryption in XMPP [32]. 2487 11.3 Server-to-Server Communications 2489 A compliant implementation MUST support both TLS and SASL for 2490 inter-domain communications. For historical reasons, a compliant 2491 implementation SHOULD also support the lower-security Dialback 2492 Protocol (Section 6.2) as a fallback mechanism that helps to prevent 2493 the spoofing of domains. 2495 Because service provisioning is a matter of policy, it is OPTIONAL 2496 for any given domain to communicate with other domains, and 2497 server-to-server communications MAY be disabled by the administrator 2498 of any given deployment. If a particular domain enables inter-domain 2499 communications, it SHOULD enable high security. In the absence of 2500 high security, a domain MAY use server dialback for inter-domain 2501 communications. 2503 Administrators may want to require use of SASL for server-to-server 2504 communications in order to ensure authentication and confidentiality 2505 (e.g., on an organization's private network). Compliant 2506 implementations SHOULD support SASL for this purpose. 2508 11.4 Firewalls 2510 Communications using XMPP normally occur over TCP sockets on port 2511 5222 (client-to-server) or port 5269 (server-to-server), as 2512 registered with the IANA [5]. Use of these well-known ports allows 2513 administrators to easily enable or disable XMPP activity through 2514 existing and commonly-deployed firewalls. 2516 11.5 Mandatory to Implement Technologies 2518 At a minimum, all implementations MUST support the following 2519 mechanisms: 2521 for authentication: the SASL DIGEST-MD5 mechanism 2523 for confidentiality: TLS (using the TLS_RSA_WITH_3DES_EDE_CBC_SHA 2524 cipher) 2526 for both: TLS (using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher 2527 supporting client-side certificates) 2529 Normative References 2531 [1] World Wide Web Consortium, "Extensible Markup Language (XML) 2532 1.0 (Second Edition)", W3C xml, October 2000, . 2535 [2] Day, M., Aggarwal, S., Mohr, G. and J. Vincent, "A Model for 2536 Presence and Instant Messaging", RFC 2779, February 2000, 2537 . 2539 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2540 Levels", BCP 14, RFC 2119, March 1997. 2542 [4] University of Southern California, "Transmission Control 2543 Protocol", RFC 793, September 1981, . 2546 [5] Internet Assigned Numbers Authority, "Internet Assigned Numbers 2547 Authority", January 1998, . 2549 [6] Harrenstien, K., Stahl, M. and E. Feinler, "DoD Internet host 2550 table specification", RFC 952, October 1985. 2552 [7] Braden, R., "Requirements for Internet Hosts - Application and 2553 Support", STD 3, RFC 1123, October 1989. 2555 [8] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile 2556 for Internationalized Domain Names (draft-ietf-idn-nameprep-11, 2557 work in progress)", June 2002. 2559 [9] Hoffman, P. and M. Blanchet, "Preparation of Internationalized 2560 Strings ("stringprep")", RFC 3454, December 2002. 2562 [10] Saint-Andre, P. and J. Hildebrand, "Nodeprep: A Stringprep 2563 Profile for Node Identifiers in XMPP 2564 (draft-ietf-xmpp-nodeprep-02, work in progress)", April 2003. 2566 [11] Saint-Andre, P. and J. Hildebrand, "Resourceprep: A Stringprep 2567 Profile for Resource Identifiers in XMPP 2568 (draft-ietf-xmpp-resourceprep-02, work in progress)", April 2569 2003. 2571 [12] World Wide Web Consortium, "Namespaces in XML", W3C xml-names, 2572 January 1999, . 2575 [13] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and 2576 P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 2577 1999. 2579 [14] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 2581 [15] Myers, J., "Simple Authentication and Security Layer (SASL)", 2582 RFC 2222, October 1997. 2584 [16] Leach, P. and C. Newman, "Using Digest Authentication as a SASL 2585 Mechanism", RFC 2831, May 2000. 2587 [17] Alvestrand, H., "Tags for the Identification of Languages", BCP 2588 47, RFC 3066, January 2001. 2590 [18] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the 2591 location of services (DNS SRV)", RFC 2052, October 1996. 2593 [19] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2594 2279, January 1998. 2596 [20] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", 2597 RFC 2781, February 2000. 2599 [21] International Organization for Standardization, "Information 2600 Technology - Universal Multiple-octet coded Character Set (UCS) 2601 - Amendment 2: UCS Transformation Format 8 (UTF-8)", ISO 2602 Standard 10646-1 Addendum 2, October 1996. 2604 [22] Linn, J., "Generic Security Service Application Program 2605 Interface, Version 2", RFC 2078, January 1997. 2607 Informative References 2609 [23] Saint-Andre, P. and J. Miller, "XMPP Instant Messaging 2610 (draft-ietf-xmpp-im-11, work in progress)", May 2003. 2612 [24] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 2613 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 2614 1998, . 2616 [25] Mealling, M., "The IANA XML Registry", 2617 draft-mealling-iana-xmlns-registry-04 (work in progress), June 2618 2002. 2620 [26] Crispin, M., "Internet Message Access Protocol - Version 2621 4rev1", RFC 2060, December 1996. 2623 [27] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 2624 53, RFC 1939, May 1996. 2626 [28] Newman, C. and J. Myers, "ACAP -- Application Configuration 2627 Access Protocol", RFC 2244, November 1997. 2629 [29] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, 2630 June 1999. 2632 [30] Eastlake, D., "Domain Name System Security Extensions", RFC 2633 2535, March 1999. 2635 [31] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., 2636 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 2637 HTTP/1.1", RFC 2616, June 1999. 2639 [32] Saint-Andre, P. and J. Hildebrand, "End-to-End Object 2640 Encryption in XMPP (draft-ietf-xmpp-e2e-02, work in progress)", 2641 April 2003. 2643 Authors' Addresses 2645 Peter Saint-Andre 2646 Jabber Software Foundation 2648 EMail: stpeter@jabber.org 2649 URI: http://www.jabber.org/people/stpeter.php 2650 Jeremie Miller 2651 Jabber Software Foundation 2653 EMail: jeremie@jabber.org 2654 URI: http://www.jabber.org/people/jer.php 2656 Appendix A. XML Schemas 2658 The following XML schemas are descriptive, not normative. 2660 A.1 Streams namespace 2662 2664 2670 2671 2672 2673 2674 2675 2676 2677 2678 2679 2680 2681 2682 2683 2685 2686 2687 2691 2692 2694 2695 2696 2698 2699 2700 2701 2702 2703 2704 2705 2706 2707 2708 2709 2711 2713 A.2 TLS namespace 2715 2717 2723 2724 2725 2729 2730 2732 2733 2734 2736 2738 A.3 SASL namespace 2740 2742 2748 2749 2750 2751 2752 2754 2756 2757 2758 2760 2761 2763 2764 2765 2766 2767 2768 2769 2770 2771 2772 2773 2774 2775 2776 2777 2779 2780 2781 2782 2783 2785 2787 A.4 Dialback namespace 2789 2791 2797 2798 2799 2800 2801 2802 2803 2804 2805 2806 2807 2808 2809 2810 2811 2812 2813 2814 2816 2817 2818 2819 2820 2821 2822 2823 2824 2825 2826 2827 2828 2829 2830 2831 2832 2833 2834 2836 2838 A.5 Client namespace 2840 2842 2848 2849 2850 2851 2853 2855 2856 2860 2861 2862 2863 2864 2865 2868 2869 2870 2871 2872 2873 2874 2875 2876 2877 2878 2879 2881 2882 2883 2884 2885 2886 2887 2888 2889 2891 2892 2893 2894 2895 2896 2897 2898 2899 2901 2903 2904 2905 2906 2907 2909 2910 2914 2915 2916 2917 2918 2919 2922 2923 2924 2925 2926 2927 2928 2929 2930 2931 2932 2933 2934 2935 2937 2938 2939 2940 2941 2942 2943 2944 2945 2946 2948 2949 2950 2951 2952 2953 2954 2955 2956 2958 2960 2961 2962 2963 2967 2968 2969 2970 2971 2972 2973 2974 2975 2976 2977 2978 2979 2980 2981 2982 2985 2986 2987 2988 2989 2991 2992 2993 2994 2995 2996 2997 2998 2999 3000 3001 3002 3003 3005 3007 A.6 Server namespace 3009 3011 3017 3018 3019 3020 3022 3024 3025 3029 3030 3031 3032 3033 3034 3037 3038 3039 3040 3041 3042 3043 3044 3045 3046 3047 3048 3050 3051 3052 3053 3054 3055 3056 3057 3058 3060 3061 3062 3063 3064 3065 3066 3067 3068 3070 3072 3073 3074 3075 3076 3078 3079 3083 3084 3085 3086 3087 3088 3091 3092 3093 3094 3095 3096 3097 3098 3099 3100 3101 3102 3103 3104 3106 3107 3108 3109 3110 3111 3112 3113 3114 3115 3117 3118 3119 3120 3121 3122 3123 3124 3125 3127 3129 3130 3131 3132 3136 3137 3138 3139 3140 3141 3142 3143 3144 3145 3146 3147 3148 3149 3150 3151 3154 3155 3157 3158 3159 3161 3162 3163 3164 3165 3166 3167 3168 3169 3170 3171 3172 3173 3175 3177 A.7 Stream error namespace 3179 3181 3187 3188 3189 3193 3194 3195 3196 3197 3198 3199 3200 3201 3202 3203 3204 3205 3206 3207 3208 3209 3211 3212 3213 3214 3215 3216 3217 3218 3219 3220 3221 3222 3223 3224 3226 3228 A.8 Stanza error namespace 3230 3232 3238 3239 3240 3241 3242 3243 3244 3245 3246 3247 3248 3249 3250 3251 3252 3253 3254 3256 3257 3258 3259 3260 3261 3262 3263 3264 3265 3266 3267 3269 3270 3271 3273 3275 Appendix B. Revision History 3277 Note to RFC Editor: please remove this entire appendix, and the 3278 corresponding entries in the table of contents, prior to publication. 3280 B.1 Changes from draft-ietf-xmpp-core-09 3282 o Adjusted TLS content regarding certificate validation process. 3284 o Specified that stanza error extensions for specific applications 3285 are to be properly namespaced children of the relevant descriptive 3286 element. 3288 o Clarified rules for inclusion of the 'id' attribute. 3290 o Specified that the 'xml:lang' attribute SHOULD be included (per 3291 list discussion). 3293 o Made small editorial changes and fixed several schema errors. 3295 B.2 Changes from draft-ietf-xmpp-core-09 3297 o Fixed several dialback error conditions. 3299 o Cleaned up business rules regarding TLS and certificate processing 3300 based on off-list feedback. 3302 o Changed and elements to 3303 . 3305 o Added or modified several stream and stanza error conditions. 3307 o Specified only one child allowed for IQ, or two if type="error". 3309 o Fixed several errors in the schemas. 3311 B.3 Changes from draft-ietf-xmpp-core-08 3313 o Incorporated list discussion regarding addressing, SASL, TLS, TCP, 3314 dialback, namespaces, extensibility, and the meaning of 'ignore' 3315 for routers and recipients. 3317 o Specified dialback error conditions. 3319 o Made small editorial changes to address RFC Editor requirements. 3321 B.4 Changes from draft-ietf-xmpp-core-07 3323 o Made several small editorial changes. 3325 B.5 Changes from draft-ietf-xmpp-core-06 3327 o Added text regarding certificate validation in TLS negotiation per 3328 list discussion. 3330 o Clarified nature of XML restrictions per discussion with W3C, and 3331 moved XML Restrictions subsection under "XML Usage within XMPP". 3333 o Further clarified that XML streams are unidirectional. 3335 o Changed stream error and stanza error namespace names to conform 3336 to the format defined in The IETF XML Registry [25]. 3338 o Removed note to RFC Editor regarding provisional namespace names. 3340 B.6 Changes from draft-ietf-xmpp-core-05 3342 o Added as a stream error condition. 3344 o Adjusted security considerations per discussion at IETF 56 and on 3345 list. 3347 B.7 Changes from draft-ietf-xmpp-core-04 3349 o Added server-to-server examples for TLS and SASL. 3351 o Changed error syntax, rules, and examples based on list 3352 discussion. 3354 o Added schemas for the TLS, stream error, and stanza error 3355 namespaces. 3357 o Added note to RFC Editor regarding provisional namespace names. 3359 o Made numerous small editorial changes and clarified text 3360 throughout. 3362 B.8 Changes from draft-ietf-xmpp-core-03 3364 o Clarified rules and procedures for TLS and SASL. 3366 o Amplified stream error code syntax per list discussion. 3368 o Made numerous small editorial changes. 3370 B.9 Changes from draft-ietf-xmpp-core-02 3372 o Added dialback schema. 3374 o Removed all DTDs since schemas provide more complete definitions. 3376 o Added stream error codes. 3378 o Clarified error code "philosophy". 3380 B.10 Changes from draft-ietf-xmpp-core-01 3382 o Updated the addressing restrictions per list discussion and added 3383 references to the new nodeprep and resourceprep profiles. 3385 o Corrected error in Stream Authentication regarding "version='1.0'" 3386 flag. 3388 o Made numerous small editorial changes. 3390 B.11 Changes from draft-ietf-xmpp-core-00 3392 o Added information about TLS from list discussion. 3394 o Clarified meaning of "ignore" based on list discussion. 3396 o Clarified information about Universal Character Set data and 3397 character encodings. 3399 o Provided base64-decoded information for examples. 3401 o Fixed several errors in the schemas. 3403 o Made numerous small editorial fixes. 3405 B.12 Changes from draft-miller-xmpp-core-02 3407 o Brought Streams Authentication section into line with discussion 3408 on list and at IETF 55 meeting. 3410 o Added information about the optional 'xml:lang' attribute per 3411 discussion on list and at IETF 55 meeting. 3413 o Specified that validation is neither required nor recommended, and 3414 that the formal definitions (DTDs and schemas) are included for 3415 descriptive purposes only. 3417 o Specified that the response to an IQ stanza of type "get" or "set" 3418 must be an IQ stanza of type "result" or "error". 3420 o Specified that compliant server implementations must process 3421 stanzas in order. 3423 o Specified that for historical reasons some server implementations 3424 may accept 'stream:' as the only valid namespace prefix on the 3425 root stream element. 3427 o Clarified the difference between 'jabber:client' and 3428 'jabber:server' namespaces, namely, that 'to' and 'from' 3429 attributes are required on all stanzas in the latter but not the 3430 former. 3432 o Fixed typo in Step 9 of the dialback protocol (changed db:result 3433 to db:verify). 3435 o Removed references to TLS pending list discussion. 3437 o Removed the non-normative appendix on OpenPGP usage pending its 3438 inclusion in a separate I-D. 3440 o Simplified the architecture diagram, removed most references to 3441 services, and removed references to the 'jabber:component:*' 3442 namespaces. 3444 o Noted that XMPP activity respects firewall administration 3445 policies. 3447 o Further specified the scope and uniqueness of the 'id' attribute 3448 in all stanza types and the element in message stanzas. 3450 o Nomenclature changes: (1) from "chunks" to "stanzas"; (2) from 3451 "host" to "server" and from "node" to "client" (except with regard 3452 to definition of the addressing scheme). 3454 Intellectual Property Statement 3456 The IETF takes no position regarding the validity or scope of any 3457 intellectual property or other rights that might be claimed to 3458 pertain to the implementation or use of the technology described in 3459 this document or the extent to which any license under such rights 3460 might or might not be available; neither does it represent that it 3461 has made any effort to identify any such rights. Information on the 3462 IETF's procedures with respect to rights in standards-track and 3463 standards-related documentation can be found in BCP-11. Copies of 3464 claims of rights made available for publication and any assurances of 3465 licenses to be made available, or the result of an attempt made to 3466 obtain a general license or permission for the use of such 3467 proprietary rights by implementors or users of this specification can 3468 be obtained from the IETF Secretariat. 3470 The IETF invites any interested party to bring to its attention any 3471 copyrights, patents or patent applications, or other proprietary 3472 rights which may cover technology that may be required to practice 3473 this standard. Please address the information to the IETF Executive 3474 Director. 3476 Full Copyright Statement 3478 Copyright (C) The Internet Society (2003). All Rights Reserved. 3480 This document and translations of it may be copied and furnished to 3481 others, and derivative works that comment on or otherwise explain it 3482 or assist in its implementation may be prepared, copied, published 3483 and distributed, in whole or in part, without restriction of any 3484 kind, provided that the above copyright notice and this paragraph are 3485 included on all such copies and derivative works. However, this 3486 document itself may not be modified in any way, such as by removing 3487 the copyright notice or references to the Internet Society or other 3488 Internet organizations, except as needed for the purpose of 3489 developing Internet standards in which case the procedures for 3490 copyrights defined in the Internet Standards process must be 3491 followed, or as required to translate it into languages other than 3492 English. 3494 The limited permissions granted above are perpetual and will not be 3495 revoked by the Internet Society or its successors or assignees. 3497 This document and the information contained herein is provided on an 3498 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3499 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 3500 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 3501 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3502 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3504 Acknowledgement 3506 Funding for the RFC Editor function is currently provided by the 3507 Internet Society.