idnits 2.17.1 draft-miller-xmpp-core-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == 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. -- 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 (November 03, 2002) is 7844 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 393, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Normative reference to a draft: ref. '2' ** Downref: Normative reference to an Informational RFC: RFC 2779 (ref. '3') ** Obsolete normative reference: RFC 793 (ref. '5') (Obsoleted by RFC 9293) -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 2396 (ref. '7') (Obsoleted by RFC 3986) ** Downref: Normative reference to an Unknown state RFC: RFC 952 (ref. '8') ** Obsolete normative reference: RFC 2222 (ref. '10') (Obsoleted by RFC 4422, RFC 4752) -- Possible downref: Non-RFC (?) normative reference: ref. '11' ** Obsolete normative reference: RFC 2052 (ref. '12') (Obsoleted by RFC 2782) ** Obsolete normative reference: RFC 2078 (ref. '14') (Obsoleted by RFC 2743) Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Miller 3 Internet-Draft P. Saint-Andre 4 Expires: May 4, 2003 Jabber Software Foundation 5 November 03, 2002 7 XMPP Core 8 draft-miller-xmpp-core-02 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on May 4, 2003. 33 Copyright Notice 35 Copyright (C) The Internet Society (2002). All Rights Reserved. 37 Abstract 39 This document describes the core features of the eXtensible Messaging 40 and Presence Protocol (XMPP), which is used by the servers, clients, 41 and other applications that comprise the Jabber network. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 46 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 47 1.2 Conventions Used in this Document . . . . . . . . . . . . . 4 48 1.3 Discussion Venue . . . . . . . . . . . . . . . . . . . . . . 4 49 1.4 Intellectual Property Notice . . . . . . . . . . . . . . . . 4 50 2. Generalized Architecture . . . . . . . . . . . . . . . . . . 5 51 2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 52 2.2 Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 2.3 Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 54 2.4 Service . . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 2.4.1 Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 2.5 Network . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 3. Addressing Scheme . . . . . . . . . . . . . . . . . . . . . 8 58 3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 8 59 3.2 Domain Identifier . . . . . . . . . . . . . . . . . . . . . 8 60 3.3 Node Identifier . . . . . . . . . . . . . . . . . . . . . . 8 61 3.4 Resource Identifier . . . . . . . . . . . . . . . . . . . . 9 62 3.5 URIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 4. XML Streams . . . . . . . . . . . . . . . . . . . . . . . . 11 64 4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 4.2 Restrictions . . . . . . . . . . . . . . . . . . . . . . . . 12 66 4.3 Stream Attributes . . . . . . . . . . . . . . . . . . . . . 12 67 4.4 Namespace Declarations . . . . . . . . . . . . . . . . . . . 13 68 4.5 Stream Errors . . . . . . . . . . . . . . . . . . . . . . . 14 69 4.6 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 5. Stream Authentication . . . . . . . . . . . . . . . . . . . 17 71 5.1 SASL Authentication . . . . . . . . . . . . . . . . . . . . 17 72 5.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 17 73 5.1.2 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 18 74 5.2 Dialback Authentication . . . . . . . . . . . . . . . . . . 20 75 5.2.1 Dialback Protocol . . . . . . . . . . . . . . . . . . . . . 22 76 6. Core Data Elements . . . . . . . . . . . . . . . . . . . . . 26 77 6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 26 78 6.2 Common Attributes . . . . . . . . . . . . . . . . . . . . . 26 79 6.2.1 to . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 80 6.2.2 from . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 81 6.2.3 id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 82 6.2.4 type . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 83 6.3 Message Chunks . . . . . . . . . . . . . . . . . . . . . . . 27 84 6.3.1 Types of Message . . . . . . . . . . . . . . . . . . . . . . 27 85 6.3.2 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 27 86 6.4 Presence Chunks . . . . . . . . . . . . . . . . . . . . . . 28 87 6.4.1 Types of Presence . . . . . . . . . . . . . . . . . . . . . 28 88 6.4.2 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 29 89 6.5 IQ Chunks . . . . . . . . . . . . . . . . . . . . . . . . . 30 90 6.5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 30 91 6.5.2 Types of IQ . . . . . . . . . . . . . . . . . . . . . . . . 30 92 6.5.3 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 31 93 6.6 Extended Namespaces . . . . . . . . . . . . . . . . . . . . 31 94 7. XML Usage within XMPP . . . . . . . . . . . . . . . . . . . 33 95 7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 33 96 7.2 Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . 33 97 7.3 Validation . . . . . . . . . . . . . . . . . . . . . . . . . 33 98 7.4 Character Encodings . . . . . . . . . . . . . . . . . . . . 34 99 7.5 Inclusion of Text Declaration . . . . . . . . . . . . . . . 34 100 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 35 101 9. Internationalization Considerations . . . . . . . . . . . . 36 102 10. Security Considerations . . . . . . . . . . . . . . . . . . 37 103 10.1 Node-to-Host Communications . . . . . . . . . . . . . . . . 37 104 10.2 Host-to-Host Communications . . . . . . . . . . . . . . . . 37 105 10.3 Use of SASL . . . . . . . . . . . . . . . . . . . . . . . . 37 106 References . . . . . . . . . . . . . . . . . . . . . . . . . 38 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 39 108 A. Standard Error Codes . . . . . . . . . . . . . . . . . . . . 40 109 B. Formal Definitions . . . . . . . . . . . . . . . . . . . . . 42 110 B.1 streams namespace . . . . . . . . . . . . . . . . . . . . . 42 111 B.1.1 DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 112 B.1.2 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 113 B.2 sasl namespace . . . . . . . . . . . . . . . . . . . . . . . 43 114 B.2.1 DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 115 B.2.2 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 116 B.3 jabber:client namespace . . . . . . . . . . . . . . . . . . 45 117 B.3.1 DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 118 B.3.2 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 119 C. OpenPGP Usage . . . . . . . . . . . . . . . . . . . . . . . 50 120 C.1 Signing Presence . . . . . . . . . . . . . . . . . . . . . . 50 121 C.2 Encrypting Messages . . . . . . . . . . . . . . . . . . . . 51 122 Full Copyright Statement . . . . . . . . . . . . . . . . . . 53 124 1. Introduction 126 1.1 Overview 128 The eXtensible Messaging and Presence Protocol (XMPP) is an open, XML 129 [1] protocol for near-real-time messaging and presence. Currently, 130 there exist multiple implementations of the protocol, mostly offered 131 under the name of Jabber. In addition, there are countless 132 deployments of these implementations, which provide instant messaging 133 (IM) and presence services at and among thousands of domains to a 134 user base that is estimated at over one million end users. The 135 current document defines the core constituents of XMPP; XMPP IM [2] 136 defines the extensions necessary to provide basic instant messaging 137 and presence functionality that addresses the requirements defined in 138 RFC 2779 [3]. 140 1.2 Conventions Used in this Document 142 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 143 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 144 "OPTIONAL" in this document are to be interpreted as described in RFC 145 2119 [4]. 147 1.3 Discussion Venue 149 The authors welcome discussion and comments related to the topics 150 presented in this document, preferably on the "xmppwg@jabber.org" 151 mailing list (archives and subscription information are available at 152 http://www.jabber.org/cgi-bin/mailman/listinfo/xmppwg/). 154 1.4 Intellectual Property Notice 156 This document is in full compliance with all provisions of Section 10 157 of RFC 2026. Parts of this specification use the term "jabber" for 158 identifying namespaces and other protocol syntax. Jabber[tm] is a 159 registered trademark of Jabber, Inc. Jabber, Inc. grants permission 160 to the IETF for use of the Jabber trademark in association with this 161 specification and its successors, if any. 163 2. Generalized Architecture 165 2.1 Overview 167 Although XMPP is not wedded to any specific network architecture, to 168 this point it has usually been implemented via a typical client- 169 server architecture, wherein a client utilizing XMPP accesses a 170 server over a TCP [5] socket. While it can be helpful to keep that 171 specific architecture in mind when seeking to understand XMPP, we 172 have herein abstracted from any specific architecture and have 173 described the architecture in a more generalized fashion. 175 The following diagram provides a high-level overview of this 176 generalized architecture (where "-" represents communications that 177 use XMPP and "=" represents communications that use any other 178 protocol). 180 Connection Map 182 S1 S2 183 \ / 184 N1 - H1 - H2 - N3 185 / \ 186 N2 - G1 = F1 = C1 188 The symbols are as follows: 190 o N1, N2, N3 -- Nodes on the Jabber network 192 o H1, H2 -- Hosts on the Jabber network 194 o S1, S2 -- Services that add functionality to a primary host 196 o G1 -- A gateway that translates between XMPP and the protocol(s) 197 used on a foreign messaging network 199 o F1 -- A foreign messaging network 201 o C1 -- A client on a foreign messaging network 203 2.2 Host 205 A host acts as an intelligent abstraction layer for XMPP 206 communications. Its primary responsibilities are to manage 207 connections from or sessions for other entities (in the form of XML 208 streams to and from authorized nodes, trusted services, and other 209 hosts) and to route appropriately-addressed XML data "chunks" among 210 such entities over XML streams. Most XMPP-compliant hosts also 211 assume responsibility for the storage of data that is used by nodes 212 or services (e.g., the contact list for each IM user); in this case, 213 the XML data is processed directly by the host itself on behalf of 214 the node or service and is not routed to another entity. 216 2.3 Node 218 Most nodes connect directly to a host over a TCP socket and use XMPP 219 to take full advantage of the functionality provided by a host and 220 its associated services. (Clients on foreign messaging networks may 221 also be part of the architecture, made accessable via a gateway to 222 that network.) Multiple resources (e.g., devices or locations) MAY 223 connect simultaneously to a host on behalf of each authorized node, 224 with each resource connecting over a discrete TCP socket and 225 differentiated by the resource identifier of a JID (Section 3) (e.g., 226 node@host/home vs. node@host/work). The port assigned by the IANA 227 [6] for connections between a Jabber node and a Jabber host is 5222. 228 For further details about node-to-host communications for the purpose 229 of instant messaging and presence, refer to XMPP IM [2]. 231 2.4 Service 233 In addition to the basic functionality provided by a host, additional 234 functionality is made possible by connecting trusted services to a 235 host. Examples include multi-user chat (a.k.a. conferencing), real- 236 time alert systems, custom authentication modules, database 237 connectivity, and translation to foreign messaging protocols. There 238 is no set port on which services communicate with hosts; this is left 239 up to the administrator of the service or host. Communications 240 between services and hosts are not defined in this document. 242 2.4.1 Gateway 244 A gateway is a special-purpose service whose primary function is to 245 translate XMPP into the protocol(s) of another messaging system, as 246 well as to translate the return data back into XMPP. Examples are 247 gateways to Internet Relay Chat (IRC), Short Message Service (SMS), 248 SMTP, and foreign instant messaging networks such as Yahoo!, MSN, 249 ICQ, and AIM. Communications between gateways and hosts, and between 250 gateways and the foreign messaging system, are not defined in this 251 document. 253 2.5 Network 255 Because each host is identified by a network address (typically a DNS 256 hostname) and because host-to-host communications are a simple 257 extension of the node-to-host protocol, in practice the system 258 consists of a network of hosts that inter-communicate. Thus node- 259 a@host1 is able to exchange messages, presence, and other information 260 with node-b@host2. This pattern is familiar from messaging protocols 261 (such as SMTP) that make use of network addressing standards. The 262 usual method for providing a connection between two hosts is to open 263 a TCP socket on the IANA-assigned port 5269 and to negotiate a 264 connection using the Dialback Protocol (Section 5.2) as defined in 265 this document. 267 3. Addressing Scheme 269 3.1 Overview 271 Any entity that can be considered a network endpoint (i.e., an ID on 272 the network) and that can communicate using XMPP is considered a 273 Jabber Entity. All such entities are uniquely addressable in a form 274 that is consistent with RFC 2396 [7]. In particular, a valid Jabber 275 Identifier (JID) contains a set of ordered elements formed of a 276 domain identifier, node identifier, and resource identifier in the 277 following format: [node@]domain[/resource]. 279 All JIDs are based on the foregoing structure. The most common use 280 of this structure is to identify an IM user, the host to which the 281 user connects, and the user's active session or connection in the 282 form of user@host/resource. However, other nodes are possible; for 283 example, a specific conference room is offered by a multi-user chat 284 service is addressed as room@service, where "room" is the name of the 285 room and "service" is the hostname of the chat service. 287 3.2 Domain Identifier 289 The domain identifier is the primary identifier and is the only 290 required element of a JID (a simple domain identifier is a valid 291 JID). It usually represents the network gateway or "primary" host to 292 which other entities connect for XML routing and data management 293 capabilities. However, the entity referenced by a domain identifier 294 is not always a host, and may be a service that is addressed as a 295 subdomain of a host and that provides functionality above and beyond 296 the capabilities of a host (a multi-user chat service, a user 297 directory, a gateway to a foreign messaging system, etc.). 299 The domain identifier for every host or service that will communicate 300 over a network SHOULD resolve to a Fully Qualified Domain Name, and a 301 domain identifier SHOULD conform to RRC 952 [8] and REF 1123 [9]. 302 Specifically, a domain identifier is case-insensitive 7-bit ASCII and 303 is limited to 255 bytes. 305 3.3 Node Identifier 307 The node identifier is an optional secondary identifier. It usually 308 represents the entity requesting and using network access provided by 309 the host (e.g., a client), although it can also represent other kinds 310 of entities (e.g., a multi-user chat room associated with a 311 conference service). The entity represented by a node identifier is 312 addressed within the context of a specific domain (e.g., user@host). 313 Node identifiers are restricted to 256 bytes. A node identifier may 314 contain any Unicode character higher than #x20 with the exception of 315 the following: 317 o #x22 (") 319 o #x26 (&) 321 o #x27 (') 323 o #x3A (:) 325 o #x3C (<) 327 o #x3E (>) 329 o #x40 (@) 331 o #x7F (del) 333 o #xFFFE (BOM) 335 o #xFFFF (BOM) 337 Case is preserved, but comparisons are made in case-normalized 338 canonical form. 340 3.4 Resource Identifier 342 The resource identifer is an optional third identifier. It 343 represents a specific session, connection (e.g., a device or 344 location), or object (e.g., a participant in a multi-user chat room) 345 belonging to a node. A node may maintain multiple resources 346 simultaneously. A resource identifier is restricted to 256 bytes in 347 length. A resource identifier MAY include any Unicode character 348 greater than #x20, except #xFFFE and #xFFFF; if the Unicode character 349 is a valid XML character as defined in Section 2.2 of [1], it MUST be 350 suitably escaped for inclusion within an XML stream. Resource 351 identifiers are case sensitive. 353 3.5 URIs 355 Full conformance with [7] would be valuable. This would most likely 356 be effected through use of an 'xmpp:' URI scheme of the following 357 form: 359 :[@][?] 361 At a minimum, the 'message' and 'presence' query types would be 362 defined, with the likely addition of query types for 'subscribe' (to 363 manage a subscription to teh presence of another entity) and 'roster' 364 (to manage the representation of another entity in one's contact 365 list). However, the use of such URIs has not yet been standardized. 367 4. XML Streams 369 4.1 Overview 371 Two fundamental concepts make possible the rapid, asynchronous 372 exchange of relatively small payloads of structured information 373 between presence-aware entities: XML streams and, as a result, 374 discrete units of structured information that are referred to as "XML 375 chunks". (Note: in this overview we use the example of 376 communications between a node and host; however XML streams are more 377 generalized and may be used for communications among hosts and 378 services as well.) 380 In order to connect to a host, a node must initiate an XML stream by 381 sending a tag to the host, optionally preceded by a text 382 declaration specifying the XML version supported and the character 383 encoding. A compliant entity must accept any namespace prefix on the 384 element; however, for historical reasons some entities may 385 accept only a 'stream' prefix, resulting in use of a 386 element. The host should then reply with a second XML stream back to 387 the node, again optionally preceded by a text declaration. 389 Within the context of an XML stream, a sender may send a discrete 390 semantic unit of structured information to any recipient. This unit 391 of structured information is a well-balanced XML chunk, such as a 392 message, presence, or IQ chunk (a chunk of an XML document is said to 393 be well-balanced if it matches production [43] content of [1]). 394 These chunks exist at the direct child level (depth=1) of the root 395 element. The start of any XML chunk is unambiguously 396 denoted by the element start tag at depth=1 (e.g., ), and 397 the end of any XML chunk is unambiguously denoted by the 398 corresponding close tag at depth=1 (e.g., ). Each XML 399 chunk may contain child elements or CDATA sections as necessary in 400 order to convey the desired information from the sender to the 401 recipient. The session is closed at the node's request by sending a 402 closing tag to the host. 404 Thus a node's session with a host can be seen as two open-ended XML 405 documents that are built up through the accumulation of the XML 406 chunks that are sent over the course of the session (one from the 407 node to the host and one from the host to the node), and the root 408 element may be considered the document entity for those 409 streams. In essence, then, an XML stream acts as an envelope for all 410 the XML chunks sent during a session. We can represent this 411 graphically as follows: 413 |-------------------| 414 | | 415 |-------------------| 416 | | 417 | | 418 | | 419 |-------------------| 420 | | 421 | | 422 | | 423 |-------------------| 424 | | 425 | | 426 | | 427 |-------------------| 428 | | 429 |-------------------| 431 4.2 Restrictions 433 XML streams are used to transport a subset of XML. Specifically, XML 434 streams SHOULD NOT contain processing instructions, non-predefined 435 entities (as defined in Section 4.6 of [1]), comments, or DTDs. Any 436 such XML data SHOULD be ignored. 438 4.3 Stream Attributes 440 The attributes of the stream element are as follows (we now 441 generalize the endpoints by using the terms "initiating entity" and 442 "receiving entity"): 444 o to -- The 'to' attribute should be used only in the XML stream 445 from the initiating entity to the receiving entity, and must be 446 set to the JID of the receiving entity. There should be no 'to' 447 attribute set in the XML stream by which the receiving entity 448 replies to the initiating entity; however, if a 'to' attribute is 449 included, it SHOULD be ignored by the receiving entity. 451 o from -- The 'from' attribute should be used only in the XML stream 452 from the receiving entity to the initiating entity, and must be 453 set to the JID of the receiving entity granting access to the 454 initiating entity. There should be no 'from' attribute on the XML 455 stream sent from the initiating entity to the receiving entity; 456 however, if a 'from' attribute is included, it SHOULD be ignored 457 by the receiving entity. 459 o id -- The 'id' attribute should be used only in the XML stream 460 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 session 463 with the receiving entity. There should be no 'id' attribute on 464 the XML stream sent from the initiating entity to the receiving 465 entity; however, if an 'id' attribute is included, it SHOULD be 466 ignored by the receiving entity. 468 We can summarize these values as follows: 470 | initiating to receiving | receiving to initiating 471 ------------------------------------------------------------ 472 to | JID of receiver | ignored 473 from | ignored | JID of receiver 474 id | ignored | session key 476 4.4 Namespace Declarations 478 The stream element may also contain namespace declarations as defined 479 in [11]. 481 A stream namespace declaration is REQUIRED in both XML streams. A 482 compliant entity must accept any namespace prefix on the 483 element; however, for historical reasons some entities may accept 484 only a 'stream' prefix, resulting in use of a 485 element as the stream root. The value of the stream namespace MUST 486 be "http://etherx.jabber.org/streams". 488 A default namespace declaration ('xmlns') is REQUIRED and is used in 489 both XML streams in order to scope the allowable first-level children 490 of the root stream element for both streams. This namespace 491 declaration must be the same for the initiating stream and the 492 responding stream so that both streams are scoped consistently. 494 XML streams function as containers for any XML chunks sent 495 asynchronously between network endpoints. It should be possible to 496 scope an XML stream with any default namespace declaration, i.e., it 497 should be possible to send any properly-namespaced XML chunk over an 498 XML stream. However, for historical reasons existing implementations 499 will support only the following default namespaces: 501 o jabber:client -- this default namespace is declared when the 502 stream is used for communications between a node and a host 504 o jabber:server -- this default namespace is declared when the 505 stream is used for communications between two hosts 507 o jabber:component:accept or jabber:component:connect -- one of 508 these default namespaces is declared when the stream is used for 509 communications between a host and a trusted service 511 This document addresses the jabber:client and jabber:server 512 namespaces only (indeed these two namespaces have identical schemas). 513 The jabber:component:* namespaces are outside the scope of this 514 document. 516 4.5 Stream Errors 518 The root stream element MAY contain an error child element (e.g., 519 if the stream namespace prefix is 'stream'). The 520 error child is used to signify that a stream-level error has 521 occurred. Examples include the sending of invalid XML, the shutdown 522 of a host, an internal server error such as the shutdown of a session 523 manager, and an attempt by a node to authenticate as the same 524 resource that is currently connected. If an error occurs at the 525 level of the stream, the entity (initiating entity or receiving 526 entity) that detects the error should send a stream error to the 527 other entity specifying why the streams are being closed and then 528 send a closing tag. XML of the following form is sent 529 within the context of an existing stream: 531 532 ... 533 534 Error message (e.g., "Invalid XML") 535 536 538 4.6 Example 540 The following is a simple stream-based session of a node on a host 541 (where the NODE lines are sent from the node to the host, and the 542 HOST lines are sent from the host to the node): 544 A simple session: 546 NODE: 547 551 HOST: 552 557 NODE: 558 NODE: Watson come here, I need you! 559 NODE: 560 HOST: 561 HOST: I'm on my way! 562 HOST: 563 NODE: 564 HOST: 566 These are in actuality a sending stream and a receiving stream, which 567 can be viewed a-chronologically as two XML documents: 569 NODE: 570 574 NODE: 575 NODE: Watson come here, I need you! 576 NODE: 577 NODE: 579 HOST: 580 585 HOST: 586 HOST: I'm on my way! 587 HOST: 588 HOST: 589 A session gone bad: 591 NODE: 592 596 HOST: 597 602 NODE: Bad XML, no closing body tag! 603 HOST: Invalid XML 604 HOST: 606 5. Stream Authentication 608 XMPP includes two methods for enforcing authentication at the level 609 of XML streams. When one entity is already known to another (i.e., 610 there is an existing trust relationship between the entities such as 611 that established when a node registers with a host or an 612 administrator configures a host to trust a service), the preferred 613 method for authenticating streams between the two entities uses an 614 XMPP adaptation of the Simple Authentication and Security Layer 615 (SASL) [10]. When there is no existing trust relationship between 616 the two entities, such trust MAY be established based on existing 617 trust in DNS; the authentication method used when two such entities 618 are hosts is the server dialback protocol that is native to XMPP. 619 Both of these methods are described in this section. 621 5.1 SASL Authentication 623 5.1.1 Overview 625 The Simple Authentication and Security Layer (SASL) provides a 626 generalized method for adding authentication support to connection- 627 based protocols. XMPP uses a generic XML namespace profile for SASL 628 that conforms to section 4 ("Profiling Requirements") of [10] (the 629 namespace identifier for this protocol is http://www.iana.org/ 630 assignments/sasl-mechanisms). If an entity (node, host, or service) 631 is capable of authenticating by means of SASL, it MUST include the 632 agreed-upon SASL namespace within the opening root stream tag it uses 633 to initiate communications. 635 The following example shows the use of SASL in node authentication 636 with a host, for which the steps involved are as follows: 638 1. The node requests SASL authentication by including the 639 appropriate namespace declaration (xmlns:sasl='http:// 640 www.iana.org/assignments/sasl-mechanisms') in the opening XML 641 stream header sent to the host. 643 2. The host includes the xmlns:sasl namespace declaration in the XML 644 stream header sent in reply to the node. 646 3. The host responds with a list of available SASL authentication 647 mechanisms, each of which is a element included as a 648 child within a container element that is sent as a 649 first-level child of the root element. 651 4. The node selects a mechanism by sending a element to 652 the host; this element MAY optionally contain character data. 654 5. If necessary, the host challenges the node by sending a 655 element to the node; this element MAY 656 optionally contain character data. 658 6. The node responds to challenge by sending a 659 element to the host; this element MAY optionally contain 660 character data. 662 7. If necessary, the host sends more challenges and the node sends 663 more responses. 665 This series of challenge/response pairs continues until one of three 666 things happens: 668 o The node aborts the handshake by sending a element 669 to the host. 671 o The host reports failure by sending a element to 672 the node. 674 o The host reports success by sending a element to 675 the node; this element MAY optionally contain character data. 677 Any character data contained within these elements MUST be encoded 678 using base64. 680 5.1.2 Example 682 The following example shows the data flow for a node authenticating 683 with a host using SASL. 685 Step 1: Node initiates stream to host: 687 694 Step 2: Host responds with a stream tag sent to the node: 696 703 Step 3: Host informs node of available authentication mechanisms: 705 706 707 DIGEST-MD5 708 PLAIN 709 710 711 713 Step 4: Node selects an authentication mechanism: 715 717 Step 5: Host sends a challenge to the node: 719 720 cmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIi 721 xxb3A9ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNz 722 724 Step 6: Node responds to the challenge: 726 727 dXNlcm5hbWU9InJvYiIscmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik 728 9BNk1HOXRFUUdtMmhoIixjbm9uY2U9Ik9BNk1IWGg2VnFUclJrIixuYz0w 729 MDAwMDAwMSxxb3A9YXV0aCxkaWdlc3QtdXJpPSJqYWJiZXIvY2F0YWNseX 730 NtLmN4IixyZXNwb25zZT1kMzg4ZGFkOTBkNGJiZDc2MGExNTIzMjFmMjE0 731 M2FmNyxjaGFyc2V0PXV0Zi04 732 734 Step 7: Host sends another challenge to the node: 736 737 cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA== 738 739 Step 8: Node responds to the challenge: 741 743 Step 9: Host informs node of successful authentication: 745 747 Step 9 (alt): Host informs node of failed authentication: 749 751 5.2 Dialback Authentication 753 XMPP includes a protocol-level method for verifying that a connection 754 between two hosts may be trusted. The method is called dialback and 755 is used only within XML streams that are declared under the 756 "jabber:server" namespace. 758 The purpose of the dialback protocol is to make server spoofing more 759 difficult, and thus to make it more difficult to forge XML chunks. 760 Dialback is not intended as a mechanism for securing or encrypting 761 the streams between servers, only for helping to prevent the spoofing 762 of a hostname and the sending of false data from it. Dialback is 763 made possible by the existence of DNS, since one host can verify that 764 another host which is connecting to it is authorized to represent a 765 given host on the Jabber network. All DNS host resolutions must 766 first resolve the host using an SRV [12] record of _jabber._tcp.host. 767 If the SRV lookup fails, the fallback is a normal A lookup to 768 determine the IP address, using the jabber-server port of 5269 769 assigned by the Internet Assigned Numbers Authority [6]. 771 Note that the method used to generate and verify the keys used in the 772 dialback protocol must take into account the hostnames being used, 773 along with a secret known only by the receiving host and the random 774 id per stream. Generating unique but verifiable keys is important to 775 prevent common man-in-the-middle attacks and host spoofing. 777 In the description that follows we use the following terminology: 779 o Originating Host -- the host that is attempting to establish a 780 connection between the two hosts 782 o Receiving Host -- the host that is trying to authenticate that the 783 Originating Host represents the Jabber host which it claims to be 785 o Authoritative Host -- the host which is given when a DNS lookup is 786 performed on the name that the Originating Host initially gave; 787 for simple environments this will be the Originating Host, but it 788 could be a separate machine in the Originating Host's network 790 The following is a brief summary of the order of events in dialback: 792 1. Originating Host establishes a connection to Receiving Host. 794 2. Originating Host sends a 'key' value over the connection to 795 Receiving Host. 797 3. Receiving Host establishes a connection to Authoritative Host. 799 4. Receiving Host sends the same 'key' value to Authoritative Host. 801 5. Authoritative Host replies that key is valid or invalid. 803 6. Receiving Host tells Originating Host whether it is authenticated 804 or not. 806 We can represent this flow of events graphically as follows: 808 Originating Receiving 809 Host Host 810 ----------- --------- 811 | | 812 | establish connection | 813 | ----------------------> | 814 | | 815 | send stream header | 816 | ----------------------> | 817 | | 818 | establish connection | 819 | <---------------------- | 820 | | 821 | send stream header | 822 | <---------------------- | 823 | | Authoritative 824 | send dialback key | Host 825 | ----------------------> | ------------- 826 | | | 827 | establish connection | 828 | ----------------------> | 829 | | 830 | send stream header | 831 | ----------------------> | 832 | | 833 | send stream header | 834 | <---------------------- | 835 | | 836 | send dialback key | 837 | ----------------------> | 838 | | 839 | validate dialback key | 840 | <---------------------- | 841 | 842 | report dialback result | 843 | <---------------------- | 844 | | 846 5.2.1 Dialback Protocol 848 The traffic sent between the hosts is as follows: 850 1. Originating Host establishes connection to Receiving Host 852 2. Originating Host sends a stream header to Receiving Host (the 853 'to' and 'from' attributes are not required): 855 860 Note: the value of the xmlns:db namespace declaration indicates 861 to Receiving Host that the Originating Host supports dialback. 863 3. Receiving Host sends a stream header back to Originating Host 864 (the 'to' and 'from' attributes are not required): 866 872 4. Originating Host sends a dialback key to Receiving Host: 874 877 98AF014EDC0... 878 880 Note: this key is not examined by Receiving Host, since the 881 Receiving Host does not keep information about Originating Host 882 between sessions. 884 5. Receiving Host now establishes a connection back to Originating 885 Host, getting the Authoritative Host. 887 6. Receiving Host sends Authoritative Host a stream header (the 888 'to' and 'from' attributes are not required): 890 895 7. Authoritative Host sends Receiving Host a stream header: 897 903 8. Receiving Host sends Authoritative Host a chunk indicating it 904 wants Authoritative Host to verify a key: 906 910 98AF014EDC0... 911 913 Note: passed here are the hostnames, the original identifier 914 from Receiving Host's stream header to Originating Host in step 915 2, and the key Originating Host gave Receiving Host in step 3. 916 Based on this information and shared secret information within 917 the 'Originating Host' network, the key is verified. Any 918 verifiable method can be used to generate the key. 920 9. Authoritative Host sends a chunk back to Receiving Host 921 indicating whether the key was valid or invalid: 923 929 or 931 937 10. Receiving Host informs Originating Host of the result: 939 944 Note: At this point the connection has either been validated via 945 a type='valid', or reported as invalid. Once the connection is 946 validated, data can be sent by the Originating Host and read by 947 the Receiving Host; before that, all data chunks sent to 948 Receiving Host SHOULD be dropped. As a final guard against 949 domain spoofing, the Receiving Host MUST verify that all XML 950 chunks received from the Originating Host include a 'from' 951 attribute and that from address of each chunk includes the 952 validated domain. In addition, all XML chunks of type message, 953 presence, and IQ MUST include a 'to' attribute. 955 6. Core Data Elements 957 6.1 Overview 959 The core data elements for XMPP communications are , 960 , and . These data elements are sent as direct 961 (depth=1) children of the root element and are scoped by 962 one of the default namespaces identified in Section 4.4. 964 6.2 Common Attributes 966 Four attributes are common to message, presence, and IQ chunks. 967 These are defined below. 969 6.2.1 to 971 The 'to' attribute specifies the JID of the intended recipient for 972 the chunk. A chunk SHOULD possess a 'to' attribute. A chunk sent 973 from a node to a host for handling by that host (e.g., presence sent 974 to the host for broadcasting to other entities) MAY legitimately lack 975 a 'to' attribute. 977 6.2.2 from 979 The 'from' attribute specifies the JID of the sender. 981 A node MUST NOT include a 'from' attribute on the chunks it sends to 982 a host; if a host receives a chunk from a node and the chunk 983 possesses a 'from' attribute, it must ignore the value of the 'from' 984 attribute. A host MUST stamp chunks received from a node with the 985 user@host/resource (full JID) of the connected resource that 986 generated the chunk. 988 A host MUST include a 'from' attribute on chunks it routes to other 989 hosts. The domain identifier of the JID contained in the 'from' 990 attribute MUST match the hostname of the host as communicated in the 991 dialback negotiation (or a subdomain thereof). 993 6.2.3 id 995 The optional 'id' attribute may be used to track chunks sent and 996 received. The 'id' attribute is generated by the sender. An 'id' 997 attribute included in an IQ request of type "get" or "set" SHOULD be 998 returned to the sender in any IQ response of type "result" or "error" 999 generated by the recipient of the request. A recipient of a message 1000 or presence chunk MAY return that 'id' in any replies, but is not 1001 required to do so. 1003 6.2.4 type 1005 The 'type' attribute specifies detailed information about the purpose 1006 or context of the message, presence, or IQ chunk. The particular 1007 allowable values for the 'type' attribute vary depending on whether 1008 the chunk is a message, presence, or IQ, and thus are specified in 1009 the following sections. 1011 6.3 Message Chunks 1013 Message chunks in the 'jabber:client' or 'jabber:server' namespace 1014 are used to "push" information to another entity. Common uses in the 1015 context of instant messaging include single messages, messages sent 1016 in the context of a chat conversation, messages sent in the context 1017 of a multi-user chat room, headlines, and errors. These messages 1018 types are identified more fully below. 1020 6.3.1 Types of Message 1022 The 'type' attribute of a message chunk is optional and specifies the 1023 conversational context of the message. The sending of a message 1024 chunk without a 'type' attribute signals that the message chunk is a 1025 single message. However, the 'type' attribute may also have one of 1026 the following values: 1028 o chat -- The message is sent in the context of a one-to-one chat 1029 conversation. 1031 o groupchat -- The message is sent in the context of a multi-user 1032 chat environment. 1034 o headline -- The message is generated by an automated service that 1035 delivers content (news, sports, market information, etc.). 1037 o error - A message returned to a sender specifying an error 1038 associated with a previous message sent by the sender (for a full 1039 list of error messages, see error codes (Appendix A)) 1041 For detailed information about these message types, refer to XMPP IM 1042 [2]. 1044 6.3.2 Children 1046 If a message chunk in the 'jabber:client' or 'jabber:server' 1047 namespace has no 'type' attribute or has a 'type' attribute with a 1048 value of "chat", "groupchat", or "headline", it MAY contain zero or 1049 one of each of the following child elements (which MUST NOT contain 1050 mixed content): 1052 o body -- The textual contents of the message; normally included but 1053 not required. The element MUST NOT have any attributes. 1055 o subject -- The subject of the message. The element 1056 MUST NOT have any attributes. 1058 o thread -- A random string that is generated by the sender and that 1059 MAY be copied back in replies; it is used for tracking a 1060 conversation thread. The element MUST NOT have any 1061 attributes. 1063 If the message chunk is of type "error", it MUST include an 1064 child, which in turn MUST possess a 'code' attribute corresponding to 1065 one of the standard error codes (Appendix A) and MAY also contain 1066 PCDATA corresponding to a natural-language description of the error. 1067 An child MUST NOT be included if the chunk type is anything 1068 other than "error". 1070 As described under extended namespaces (Section 6.6), a message chunk 1071 MAY also contain any properly-namespaced child element (other than 1072 the core data elements, stream elements, or defined children 1073 thereof). 1075 6.4 Presence Chunks 1077 Presence chunks are used in the 'jabber:client' or 'jabber:server' 1078 namespace to express an entity's current availability status (offline 1079 or online, along with various sub-states of the latter) and to 1080 communicate that status to other entities. They are also used to 1081 negotiate and manage subscriptions to the presence of other entities. 1083 6.4.1 Types of Presence 1085 The 'type' attribute of a presence chunk is optional. A presence 1086 chunk that does not have a 'type' attribute is used to signal that 1087 the sender is online and available for communication. If included, 1088 the 'type' attribute specifies the availability state of the sender, 1089 a request to manage a subscription to another entity's presence, a 1090 request for another entity's current presence, or an error related to 1091 a previously-sent presence chunk. The 'type' attribute may have one 1092 of the following values: 1094 o unavailable -- Signals that the entity is no longer available for 1095 communication. 1097 o subscribe -- The sender wishes to subscribe to the recipient's 1098 presence. 1100 o subscribed -- The sender has allowed the recipient to receive 1101 their presence. 1103 o unsubscribe -- A notification that an entity is unsubscribing from 1104 another entity's presence. 1106 o unsubscribed -- The subscription request has been denied or a 1107 previously-granted subscription has been cancelled. 1109 o probe -- A request for an entity's current presence. 1111 o error -- An error has occurred regarding processing or delivery of 1112 a previously-sent presence chunk. 1114 Information about the subscription model used within XMPP may be 1115 found in [2]. 1117 6.4.2 Children 1119 If a presence chunk possesses no 'type' attribute, it MAY contain 1120 zero or one of each of the following child elements (for historical 1121 reasons the child MAY be sent in a presence chunk of type 1122 "subscribe"): 1124 o show -- Describes the availability status of an entity or specific 1125 resource. The value SHOULD be one of the following (values other 1126 than these four MAY be ignored; additional availability types 1127 should be defined through a properly-namespaced child element of 1128 the presence chunk): 1130 * away -- The entity or resource is temporarily away. 1132 * chat -- The entity or resource is actively interested in 1133 chatting. 1135 * xa -- The entity or resource is away for an extended period (xa 1136 = "eXtended Away"). 1138 * dnd -- The entity or resource is busy (dnd = "Do Not Disturb"). 1140 o status -- An optional natural-language description of availability 1141 status. Normally used in conjunction with the show element to 1142 provide a detailed description of an availability state (e.g., "In 1143 a meeting"). 1145 o priority -- A non-negative integer representing the priority level 1146 of the connected resource, with zero as the lowest priority. 1148 If the presence chunk is of type "error", it MUST include an 1149 child, which in turn MUST possess a 'code' attribute corresponding to 1150 one of the standard error codes (Appendix A) and MAY also contain 1151 PCDATA corresponding to a natural-language description of the error. 1152 An child MUST NOT be included if the chunk type is anything 1153 other than "error". 1155 As described under extended namespaces (Section 6.6), a presence 1156 chunk MAY also contain any properly-namespaced child element (other 1157 than the core data elements, stream elements, or defined children 1158 thereof). 1160 6.5 IQ Chunks 1162 6.5.1 Overview 1164 Info/Query, or IQ, is a simple request-response mechanism. Just as 1165 HTTP is a request-response medium, IQ chunks in the 'jabber:client' 1166 or 'jabber:server' namespace enable an entity to make a request of, 1167 and receive a response from, another entity. The data content of the 1168 request and response is defined by the namespace declaration of a 1169 direct child element of the iq element. 1171 Most IQ interactions follow a common pattern of structured data 1172 exchange such as get/result or set/result: 1174 Requesting Responding 1175 Entity Entity 1176 ---------- ---------- 1177 | | 1178 | | 1179 | ---------------------> | 1180 | | 1181 | | 1182 | <--------------------- | 1183 | | 1184 | | 1185 | ---------------------> | 1186 | | 1187 | | 1188 | <--------------------- | 1189 | | 1191 6.5.2 Types of IQ 1193 The 'type' attribute of an IQ chunk is REQUIRED. The 'type' 1194 attribute specifies a distinct step within a request-response 1195 interaction. The value SHOULD be one of the following (all other 1196 values MAY be ignored): 1198 o get -- The chunk is a request for information. 1200 o set -- The chunk provides required data, sets new values, or 1201 replaces existing values. 1203 o result -- The chunk is a response to a successful get or set 1204 request. 1206 o error -- An error has occurred regarding processing or delivery of 1207 a previously-sent get or set. 1209 6.5.3 Children 1211 An IQ chunk contains no children in the 'jabber:client' or 1212 'jabber:server' namespace since it is a vessel for XML in another 1213 namespace. As described under extended namespaces (Section 6.6), an 1214 IQ chunk MAY contain any properly-namespaced child element (other 1215 than the core data elements, stream elements, or defined children 1216 thereof). 1218 If the IQ chunk is of type "error", it MUST include an 1219 child, which in turn MUST possess a 'code' attribute corresponding to 1220 one of the standard error codes (Appendix A) and MAY also contain 1221 PCDATA corresponding to a natural-language description of the error. 1222 An child MUST NOT be included if the chunk type is anything 1223 other than "error". 1225 6.6 Extended Namespaces 1227 While the core data elements defined in this document provide a basic 1228 level of functionality for messaging and presence, XMPP uses XML 1229 namespaces to extend the core data elements for the purpose of 1230 providing additional functionality. Thus a message, presence, or IQ 1231 chunk may house one or more optional child elements containing 1232 content that extends the meaning of the message (e.g., an encrypted 1233 form of the message body as described in Appendix C). This child 1234 element MAY be any element (other than the core data elements, stream 1235 elements, or defined children thereof). The child element MUST 1236 possess an 'xmlns' namespace declaration (other than the stream 1237 namespace and the default namespace) that defines all data contained 1238 within the child element. 1240 Support for any given extended namespace is OPTIONAL on the part of 1241 any implementation. If an entity does not understand such a 1242 namespace, it must ignore the associated XML data. If an entity 1243 receives an IQ chunk in a namespace it does not understand, the 1244 entity SHOULD return an IQ chunk of type "error" with an error 1245 element of code 400 (bad request). If an entity receives a message 1246 or presence chunk that contains XML data in an extended namespace it 1247 does not understand, the portion of the chunk that is in the unknown 1248 namespace SHOULD be ignored. If an entity receives a message chunk 1249 without a element but containing only a child element bound 1250 by a namespace it does not understand, it MUST ignore that chunk. 1252 7. XML Usage within XMPP 1254 7.1 Overview 1256 In essence, XMPP core consists of three interrelated parts: 1258 1. XML streams (Section 4), which provide a stateful means for 1259 transporting data in an asynchronous manner from one entity to 1260 another 1262 2. stream authentication using SASL authentication (Section 5.1) or 1263 the dialback protocol (Section 5.2) 1265 3. core data elements (Section 6) (message, presence, and iq), which 1266 provide a framework for communications between entities 1268 XML [1] is used to define each of these protocols, as described in 1269 detail in the following sections. 1271 In addition, XMPP contains protocol extensions (such as extended 1272 namespaces) that address the specific functionality required to 1273 create a basic instant messaging and presence application; these non- 1274 core protocol extensions are defined in XMPP IM [2]. 1276 7.2 Namespaces 1278 XML Namespaces [11] are used within all XMPP-compliant XML to create 1279 strict boundaries of data ownership. The basic function of 1280 namespaces is to separate different vocabularies of XML elements that 1281 are structurally mixed together. Ensuring that XMPP-compliant XML is 1282 namespace-aware enables any XML to be structurally mixed with any 1283 data element within XMPP. This feature is relied upon frequently 1284 within XMPP to separate the XML that is processed by different 1285 services. Mainly for historical reasons, the default namespace for 1286 XMPP data chunks MUST be one of the namespaces identified in Section 1287 4.4. 1289 Additionally, XMPP is more strict about namespace prefixes than the 1290 XML namespace specification requires. 1292 7.3 Validation 1294 A host is not responsible for validating the XML elements forwarded 1295 to a node; an implementation MAY choose to provide only validated 1296 data elements but is NOT REQUIRED to do so. Nodes and services 1297 SHOULD NOT rely on the ability to send data which does not conform to 1298 the schemas, and SHOULD ignore any non-conformant elements or 1299 attributes on the incoming XML stream. 1301 7.4 Character Encodings 1303 Software implementing XML streams MUST support the UTF-8 and UTF-16 1304 encodings for received data. Software MUST NOT attempt to use any 1305 other encoding for transmitted data. The encodings of the transmit 1306 and receive streams are independent. Software may select either UTF- 1307 8 or UTF-16 for the transmitted stream, and should deduce the 1308 encoding of the received stream as described in [1]. 1310 7.5 Inclusion of Text Declaration 1312 An application MAY send a text declaration. Applications MUST follow 1313 the rules in [1] concerning the circumstances in which a text 1314 declaration is included. 1316 8. IANA Considerations 1318 The IANA registers "jabber-client" and "jabber-server" as GSS-API 1319 [14] service names, as specified in Section 6.1.1. 1321 9. Internationalization Considerations 1323 o A node SHOULD include an xml:lang declaration on the stream:stream 1324 it initiates to a host, denoting the node's default (preferred) 1325 language. 1327 o If the host detects an xml:lang declaration on the stream:stream 1328 from a node, it SHOULD remember that value. 1330 o If a host does not receive an xml:lang from a node, it SHOULD have 1331 a configurable default locale that it remembers instead. 1333 o For all chunks, if the node does not send an xml:lang attribute on 1334 the root tag of the packet, the server SHOULD apply its remembered 1335 value. 1337 o If a node does send an xml:lang attribute on a chunk, the server 1338 MUST NOT modify or delete it. 1340 o A host SHOULD include an xml:lang declaration on the stream:stream 1341 with which it replies to a node, denoting the host's default 1342 (preferred) language. 1344 10. Security Considerations 1346 10.1 Node-to-Host Communications 1348 The SASL protocol for authenticating XML streams negotiated between a 1349 node and a host (defined under Section 5.1 above) provides a reliable 1350 mechanism for validating that a node connecting to a host is who it 1351 claims to be. 1353 The IP address and method of access of nodes MUST NOT be made 1354 available by a host, nor are any connections other than the original 1355 host connection required. This helps protect the node's host from 1356 direct attack or identification by third parties. 1358 End-to-end encryption of message bodies and presence status 1359 information MAY be effected through use of OpenPGP [13]; for details, 1360 see Appendix C. 1362 10.2 Host-to-Host Communications 1364 It is OPTIONAL for any given host to communicate with other hosts, 1365 and host-to-host communications MAY be disabled by the administrator 1366 of any given deployment. 1368 If two hosts would like to enable communications between themselves, 1369 they MUST form a relationship of trust at some level, either based on 1370 trust in DNS or based on a pre-existing trust relationship (e.g., 1371 through exchange of certificates). If two hosts have a pre-existing 1372 trust relationship, they MAY use SASL Authentication (Section 5.1) 1373 for the purpose of authenticating each other. If they do not have a 1374 pre-existing relationship, they MUST use the Dialback Protocol 1375 (Section 5.2), which provides a reliable mechanism for preventing the 1376 spoofing of hosts. 1378 10.3 Use of SASL 1380 Although service provisioning is a policy matter, at a minimum, all 1381 implementations MUST provide the SASL DIGEST-MD5 mechanism for 1382 authentication. 1384 References 1386 [1] World Wide Web Consortium, "Extensible Markup Language (XML) 1387 1.0 (Second Edition)", W3C xml, October 2000, . 1390 [2] Miller, J. and P. Saint-Andre, "XMPP Instant Messaging (draft- 1391 miller-xmpp-im-02, work in progress)", November 2002. 1393 [3] Day, M., Aggarwal, S., Mohr, G. and J. Vincent, "A Model for 1394 Presence and Instant Messaging", RFC 2779, February 2000, 1395 . 1397 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1398 Levels", BCP 14, RFC 2119, March 1997. 1400 [5] University of Southern California, "Transmission Control 1401 Protocol", RFC 793, September 1981, . 1404 [6] Internet Assigned Numbers Authority, "Internet Assigned Numbers 1405 Authority", January 1998, . 1407 [7] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 1408 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1409 1998, . 1411 [8] Harrenstien, K., Stahl, M. and E. Feinler, "DoD Internet host 1412 table specification", RFC 952, October 1985. 1414 [9] Braden, R., "Requirements for Internet Hosts - Application and 1415 Support", STD 3, RFC 1123, October 1989. 1417 [10] Myers, J., "Simple Authentication and Security Layer (SASL)", 1418 RFC 2222, October 1997. 1420 [11] World Wide Web Consortium, "Namespaces in XML", W3C xml-names, 1421 January 1999, . 1424 [12] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the 1425 location of services (DNS SRV)", RFC 2052, October 1996. 1427 [13] Elkins, M., Del Torto, D., Levien, R. and T. Roessler, "MIME 1428 Security with OpenPGP", RFC 3156, August 2001. 1430 [14] Linn, J., "Generic Security Service Application Program 1431 Interface, Version 2", RFC 2078, January 1997. 1433 Authors' Addresses 1435 Jeremie Miller 1436 Jabber Software Foundation 1437 1899 Wynkoop Street, Suite 600 1438 Denver, CO 80202 1439 US 1441 EMail: jeremie@jabber.org 1442 URI: http://www.jabber.org/people/jer.php 1444 Peter Saint-Andre 1445 Jabber Software Foundation 1446 1899 Wynkoop Street, Suite 600 1447 Denver, CO 80202 1448 US 1450 EMail: stpeter@jabber.org 1451 URI: http://www.jabber.org/people/stpeter.php 1453 Appendix A. Standard Error Codes 1455 A standard error element is used for failed processing of XML chunks. 1456 This element is a child of the failed chunk and MUST include a 'code' 1457 attribute corresponding to one of the following error codes. 1459 o 302 (Redirect) - Whereas HTTP contains eight different codes for 1460 redirection, XMPP contains only one (which is intended to stand 1461 for any redirection error). However, code 302 is being reserved 1462 for future functionality and is not implemented at this time. 1464 o 400 (Bad Request) - Code 400 is used to inform a sender that a 1465 request could not be understood by the recipient. This might be 1466 generated when, for example, an entity sends a message that does 1467 not have a 'to' attribute. 1469 o 401 (Unauthorized) - Code 401 is used to inform nodes that they 1470 have provided incorrect authorization information, e.g., an 1471 incorrect password or unknown username when attempting to 1472 authenticate with a host. 1474 o 402 (Payment Required) - Code 402 is being reserved for future 1475 use. 1477 o 403 (Forbidden) - Code 403 is used to inform an entity that the 1478 its request was understood but that the recipient is refusing to 1479 fulfill it, e.g., if a node attempts to set information associated 1480 with another node. 1482 o 404 (Not Found) - Code 404 is used to inform a sender that no 1483 recipient was found matching the JID to which an XML chunk was 1484 sent, e.g., if a sender has attempted to send a message to a JID 1485 that does not exist. (Note: if the host of the intended recipient 1486 cannot be reached, an error code from the 500 series must be 1487 sent). 1489 o 405 (Not Allowed) - Code 405 is used when the action requested is 1490 not allowed for the JID identified by the 'from' address, e.g., if 1491 a node attempts to set the time or version of a host. 1493 o 406 (Not Acceptable) - Code 406 is used when an XML chunk is for 1494 some reason not acceptable to a host or other entity. This might 1495 be generated when, for example, a node attempts to register with a 1496 host using an empty password. 1498 o 407 (Registration Required) - Code 407 is used when a message or 1499 request is sent to a service that requires prior registration, 1500 e.g., if a node attempts to send a message through a gateway to a 1501 foreign messaging system without having first registered with that 1502 gateway. 1504 o 408 (Request Timeout) - Code 408 is returned when a recipient does 1505 not produce a response within the time that the sender was 1506 prepared to wait. 1508 o 500 (Internal Server Error) - Code 500 is used when a host or 1509 service encounters an unexpected condition which prevents it from 1510 handling an XML chunk from a sender, e.g., if an authentication 1511 request is not handled by a host because the password could not be 1512 retrieved. 1514 o 501 (Not Implemented) - Code 501 is used when the recipient does 1515 not support the functionality being requested by a sender, e.g., 1516 if a node attempts to register with a host that does not allow 1517 registration. 1519 o 502 (Remote Server Error) - Code 502 is used when delivery of an 1520 XML chunk fails because of an inability to reach the intended 1521 remote host or service, e.g., because a remote host's hostname 1522 could not be resolved. 1524 o 503 (Service Unavailable) - Code 503 is used when a sender 1525 requests a service that a recipient is temporarily unable to 1526 offer. 1528 o 504 (Remote Server Timeout) - Code 504 is used when attempts to 1529 contact a remote host timeout, e.g., if an incorrect hostname is 1530 specified. 1532 Appendix B. Formal Definitions 1534 B.1 streams namespace 1536 B.1.1 DTD 1538 1539 1540 1544 1546 B.1.2 Schema 1547 1548 1554 1555 1556 1557 1558 1561 1564 1567 1570 1573 1574 1575 1576 1577 1578 1580 1582 1584 B.2 sasl namespace 1586 B.2.1 DTD 1588 The DTD for the sasl: namespace is as follows: 1590 1591 1592 1593 1594 1595 1596 1597 1598 1599 1600 1602 B.2.2 Schema 1603 1604 1610 1611 1612 1613 1614 1615 1616 1618 1619 1620 1621 1622 1624 1625 1626 1627 1628 1629 1630 1631 1632 1633 1635 1637 B.3 jabber:client namespace 1639 Note: the formal definition for the 'jabber:server' namespace is 1640 identical to that for the 'jabber:client' namespace. 1642 B.3.1 DTD 1644 1645 1648 1655 1656 1657 1659 1661 1669 1670 1671 1673 1675 1682 1683 1685 B.3.2 Schema 1687 1688 1694 1695 1696 1697 1698 1699 1700 1701 1705 1706 1707 1708 1709 1710 1711 1712 1713 1714 1715 1716 1717 1718 1719 1720 1721 1723 1725 1727 1729 1730 1731 1732 1733 1734 1735 1736 1740 1741 1742 1743 1744 1745 1746 1747 1748 1749 1750 1751 1752 1753 1754 1755 1756 1757 1759 1760 1761 1762 1763 1764 1765 1766 1767 1768 1770 1772 1774 1775 1776 1777 1778 1782 1783 1784 1785 1786 1787 1788 1789 1790 1791 1792 1794 1795 1796 1797 1798 1800 1801 1802 1806 1807 1809 1811 Appendix C. OpenPGP Usage 1813 This section is non-normative. It describes an end-to-end encryption 1814 and signing method currently in use within the Jabber community. It 1815 is not recommended as a complete solution for encrypting streams or 1816 for guaranteeing the privacy of messages or presence. When this 1817 method is used, replay attacks are possible on presence chunks and 1818 also on messages for which the recipient is not mentioned in the 1819 message body. Key exchange may rely on the web of trust model used 1820 on the OpenPGP keys network. There is no method to check a 1821 fingerprint or ownership of a key other than checking the user IDs on 1822 a key. 1824 All operations described herein may be completed using standard 1825 OpenPGP software. All program output is US-ASCII armored output with 1826 the headers removed, which allows for straightforward encapsulation 1827 of the program output directly in XML chunks. It is assumed that all 1828 keys are exchanged using OpenPGP key servers; for example, the key of 1829 another user may be retrieved automatically when a signed presence 1830 chunk is received from that user. 1832 C.1 Signing Presence 1834 Signing enables a sender to verify that they sent a certain block of 1835 text. As applied within the Jabber community, the child of 1836 a presence chunk is signed and sent as extended presence information 1837 in the 'jabber:x:signed' namespace. Because signing requires a block 1838 of text, a signed presence chunk MUST contain a child 1839 element that is non-empty (i.e., contains text. 1841 When signing presence, the sender MUST use the private key which is 1842 the same KeyID as the one they wish to use for encrypted messages. 1843 This is because there is no feature negotiation related to message 1844 encryption; the only indicator that another user encrypts is or her 1845 messages is that one receives signed presence chunks from that user. 1847 As shown in the following example, the only presence information that 1848 is signed is the CDATA of the element. 1850 1853 Online 1854 1855 iQA/AwUBOjU5dnol3d88qZ77EQI2JACfRngLJ045brNnaCX78ykKNUZaTIoAoPHI 1856 2uJxPMGR73EBIvEpcv0LRSy+ 1857 =45f8 1858 1859 1861 C.2 Encrypting Messages 1863 Encryption enables the sender to encrypt a message sent to a specific 1864 recipient. This is accomplished by sending the encrypted form of the 1865 CDATA from the child in second child that is scoped by the 1866 'jabber:x:encrypted' namespace. Because a block of text is 1867 necessary, the message chunk MUST contain a child element 1868 that is non-empty (i.e., that contains some CDATA text). It is 1869 considered polite to include a message informing the 1870 recipient that the message is encrypted. The public key used for 1871 message encryption should match the KeyID used for signing presence. 1872 The actual data that is encrypted is what would be the CDATA of the 1873 element if the message were not encrypted. 1875 1878 This message is encrypted. 1879 1880 qANQR1DBwU4DX7jmYZnncmUQB/9KuKBddzQH+tZ1ZywKK0yHKnq57kWq+RFtQdCJ 1881 WpdWpR0uQsuJe7+vh3NWn59/gTc5MDlX8dS9p0ovStmNcyLhxVgmqS8ZKhsblVeu 1882 IpQ0JgavABqibJolc3BKrVtVV1igKiX/N7Pi8RtY1K18toaMDhdEfhBRzO/XB0+P 1883 AQhYlRjNacGcslkhXqNjK5Va4tuOAPy2n1Q8UUrHbUd0g+xJ9Bm0G0LZXyvCWyKH 1884 kuNEHFQiLuCY6Iv0myq6iX6tjuHehZlFSh80b5BVV9tNLwNR5Eqz1klxMhoghJOA 1885 w7R61cCPt8KSd8Vcl8K+StqOMZ5wkhosVjUqvEu8uJ9RupdpB/4m9E3gOQZCBsmq 1886 OsX4/jJhn2wIsfYYWdqkbNKnuYoKCnwrlmn6I+wX72p0R8tTv8peNCwK9bEtL/XS 1887 mhn4bCxoUkCITv3k8a+Jdvbov9ucduKSFuCBq4/l0fpHmPhHQjkFofxmaWJveFfF 1888 619NXyYyCfoLTmWk2AaTHVCjtKdf1WmwcTa0vFfk8BuFHkdah6kJJiJ7w/yNwa/E 1889 O6CMymuZTr/LpcKKWrWCt+SErxqmq8ekPI8h7oNwMxZBYAa7OJ1rXWKNgL9pDtNI 1890 824Mf0mXj7q5N1eMHvX1QEoKLAda/Ae3TTEevOyeUK1DEgvxfM2KRZ11RzU+XtIE 1891 My/bJk7EycAw8P/QKyeNlO1fxP58VEd6Gb8NCPqKOYn/LKh1O+c20ZNVEPFM4bNV 1892 XA4hB4UtFF7Ao8kpdlrUqdKyw4lEtnmdemYQ6+iIIVPEarWl9PxOMY90KAnZrSAq 1893 bt9uRY/1rPgelRaWblMKvxgpRO8++Y8VjdEyGgMOXxOiE851Ve72ftGzkSxDH8mW 1894 TgY3pf2aATmBp3lagQ1COkGS/xupovT5AQPA3RzbCxDvc6s6eGYKmVVQVj5vmSj1 1895 WULad5MB9KT1DzCm6FOSy063nWGBYYMWiejRvGLpo1j4eAnj0qOt7rTWmgv3RkYF 1896 Oin0vDOhW7aC 1897 =CvnG 1898 1899 1901 Full Copyright Statement 1903 Copyright (C) The Internet Society (2002). All Rights Reserved. 1905 This document and translations of it may be copied and furnished to 1906 others, and derivative works that comment on or otherwise explain it 1907 or assist in its implementation may be prepared, copied, published 1908 and distributed, in whole or in part, without restriction of any 1909 kind, provided that the above copyright notice and this paragraph are 1910 included on all such copies and derivative works. However, this 1911 document itself may not be modified in any way, such as by removing 1912 the copyright notice or references to the Internet Society or other 1913 Internet organizations, except as needed for the purpose of 1914 developing Internet standards in which case the procedures for 1915 copyrights defined in the Internet Standards process must be 1916 followed, or as required to translate it into languages other than 1917 English. 1919 The limited permissions granted above are perpetual and will not be 1920 revoked by the Internet Society or its successors or assigns. 1922 This document and the information contained herein is provided on an 1923 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1924 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1925 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1926 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1927 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1929 Acknowledgement 1931 Funding for the RFC Editor function is currently provided by the 1932 Internet Society.