idnits 2.17.1 draft-miller-jabber-00.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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 1 instance 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (February 21, 2002) is 8100 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 539, but not defined ** Obsolete normative reference: RFC 821 (ref. '1') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 2068 (ref. '2') (Obsoleted by RFC 2616) -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 2396 (ref. '7') (Obsoleted by RFC 3986) -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Obsolete normative reference: RFC 793 (ref. '11') (Obsoleted by RFC 9293) -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' ** Obsolete normative reference: RFC 2052 (ref. '16') (Obsoleted by RFC 2782) -- Possible downref: Non-RFC (?) normative reference: ref. '17' ** Downref: Normative reference to an Informational RFC: RFC 2778 (ref. '18') ** Downref: Normative reference to an Informational RFC: RFC 2779 (ref. '19') -- Possible downref: Non-RFC (?) normative reference: ref. '20' Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 13 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: August 22, 2002 Jabber Software Foundation 5 J. Barry 6 Jabber, Inc. 7 February 21, 2002 9 Jabber 10 draft-miller-jabber-00 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at http:// 28 www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 22, 2002. 35 Copyright Notice 37 Copyright (C) The Internet Society (2002). All Rights Reserved. 39 Abstract 41 This informational document describes the Jabber protocols, a set of 42 open, XML-based protocols developed over a number of years mainly to 43 provide instant messaging and presence services. In addition, this 44 document describes the known deficiencies of the Jabber protocols. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 6 49 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6 50 1.2 Historical Context . . . . . . . . . . . . . . . . . . . . 6 51 1.3 Evolution of Jabber . . . . . . . . . . . . . . . . . . . 7 52 1.4 Requirement Levels . . . . . . . . . . . . . . . . . . . . 8 53 2. Generalized Architecture . . . . . . . . . . . . . . . . . 9 54 2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 9 55 2.2 Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 56 2.3 Node . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 57 2.4 Service . . . . . . . . . . . . . . . . . . . . . . . . . 10 58 2.4.1 Gateway . . . . . . . . . . . . . . . . . . . . . . . . . 10 59 2.5 Network . . . . . . . . . . . . . . . . . . . . . . . . . 10 60 3. Jabber Entities . . . . . . . . . . . . . . . . . . . . . 12 61 3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 12 62 3.2 Domain Identifier . . . . . . . . . . . . . . . . . . . . 12 63 3.3 Node Identifier . . . . . . . . . . . . . . . . . . . . . 12 64 3.4 Resource Identifier . . . . . . . . . . . . . . . . . . . 13 65 4. XML Usage within the Jabber Protocols . . . . . . . . . . 14 66 4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 14 67 4.2 Namespaces . . . . . . . . . . . . . . . . . . . . . . . . 14 68 4.3 Validation . . . . . . . . . . . . . . . . . . . . . . . . 14 69 5. XML Streams . . . . . . . . . . . . . . . . . . . . . . . 15 70 5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 15 71 5.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 16 72 5.3 Restrictions . . . . . . . . . . . . . . . . . . . . . . . 17 73 5.4 Formal Definition . . . . . . . . . . . . . . . . . . . . 17 74 5.5 DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 75 5.6 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 19 76 5.7 Stream Errors . . . . . . . . . . . . . . . . . . . . . . 19 77 5.8 Example . . . . . . . . . . . . . . . . . . . . . . . . . 20 78 6. Common Data Types . . . . . . . . . . . . . . . . . . . . 22 79 6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 22 80 6.2 The Message Element . . . . . . . . . . . . . . . . . . . 22 81 6.2.1 Attributes . . . . . . . . . . . . . . . . . . . . . . . . 22 82 6.2.2 Children . . . . . . . . . . . . . . . . . . . . . . . . . 23 83 6.2.3 DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 84 6.2.4 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 24 85 6.2.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 25 86 6.3 The Presence Element . . . . . . . . . . . . . . . . . . . 26 87 6.3.1 Attributes . . . . . . . . . . . . . . . . . . . . . . . . 26 88 6.3.2 Children . . . . . . . . . . . . . . . . . . . . . . . . . 27 89 6.3.3 DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 90 6.3.4 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 28 91 6.3.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 30 92 6.4 The IQ Element . . . . . . . . . . . . . . . . . . . . . . 31 93 6.4.1 Attributes . . . . . . . . . . . . . . . . . . . . . . . . 31 94 6.4.2 Children . . . . . . . . . . . . . . . . . . . . . . . . . 32 95 6.4.3 DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 96 6.4.4 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 32 97 6.4.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 33 98 7. Standard Extended Namespaces . . . . . . . . . . . . . . . 35 99 7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 35 100 7.2 jabber:iq:agent - Agent Properties . . . . . . . . . . . . 35 101 7.2.1 Children . . . . . . . . . . . . . . . . . . . . . . . . . 36 102 7.2.2 DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 103 7.2.3 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 37 104 7.2.4 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 38 105 7.3 jabber:iq:agents - Available Agents . . . . . . . . . . . 38 106 7.3.1 Children . . . . . . . . . . . . . . . . . . . . . . . . . 38 107 7.3.2 DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 108 7.3.3 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 39 109 7.3.4 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 41 110 7.4 jabber:iq:auth - Node Authentication . . . . . . . . . . . 41 111 7.4.1 Children . . . . . . . . . . . . . . . . . . . . . . . . . 41 112 7.4.2 DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 113 7.4.3 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 42 114 7.4.4 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 42 115 7.5 jabber:iq:oob - Out-of-Band Data . . . . . . . . . . . . . 43 116 7.5.1 Children . . . . . . . . . . . . . . . . . . . . . . . . . 44 117 7.5.2 DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 118 7.5.3 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 44 119 7.5.4 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 45 120 7.6 jabber:iq:register - Registration . . . . . . . . . . . . 45 121 7.6.1 Children . . . . . . . . . . . . . . . . . . . . . . . . . 45 122 7.6.2 DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 123 7.6.3 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 46 124 7.6.4 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 47 125 7.7 jabber:iq:roster - Roster Management . . . . . . . . . . . 49 126 7.7.1 Children . . . . . . . . . . . . . . . . . . . . . . . . . 50 127 7.7.2 DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 128 7.7.3 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 51 129 7.7.4 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 52 130 7.8 jabber:iq:time - Entity Time . . . . . . . . . . . . . . . 54 131 7.8.1 Children . . . . . . . . . . . . . . . . . . . . . . . . . 54 132 7.8.2 DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 133 7.8.3 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 55 134 7.8.4 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 55 135 7.9 jabber:iq:version - Entity Version . . . . . . . . . . . . 56 136 7.9.1 Children . . . . . . . . . . . . . . . . . . . . . . . . . 56 137 7.9.2 DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 138 7.9.3 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 57 139 7.9.4 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 57 140 7.10 jabber:x:delay - Delayed Delivery . . . . . . . . . . . . 58 141 7.10.1 Attributes . . . . . . . . . . . . . . . . . . . . . . . . 58 142 7.10.2 DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 143 7.10.3 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 59 144 7.10.4 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 60 145 7.11 jabber:x:oob - Out-of-Band Data . . . . . . . . . . . . . 61 146 7.11.1 Children . . . . . . . . . . . . . . . . . . . . . . . . . 61 147 7.11.2 DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 148 7.11.3 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 62 149 7.11.4 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 62 150 7.12 jabber:x:roster - Embedded Roster Items . . . . . . . . . 62 151 7.12.1 Children . . . . . . . . . . . . . . . . . . . . . . . . . 62 152 7.12.2 DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 153 7.12.3 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 64 154 7.12.4 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 65 155 8. Authentication Mechanisms . . . . . . . . . . . . . . . . 66 156 8.1 Authentication of a Node by a Host . . . . . . . . . . . . 66 157 8.2 Authentication of a Host by Another Host . . . . . . . . . 66 158 8.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 66 159 8.2.2 Dialback Protocol . . . . . . . . . . . . . . . . . . . . 68 160 8.3 Authentication of Services . . . . . . . . . . . . . . . . 70 161 8.3.1 Authentication of a Service by a Host . . . . . . . . . . 71 162 8.3.2 Authentication of a Host by a Service . . . . . . . . . . 72 163 9. Routing, Delivery, and Presence Guidelines . . . . . . . . 74 164 9.1 Routing and Delivery of XML Chunks . . . . . . . . . . . . 74 165 9.2 Availability Tracking . . . . . . . . . . . . . . . . . . 74 166 9.3 Presence Probe . . . . . . . . . . . . . . . . . . . . . . 74 167 9.4 Presence Broadcast . . . . . . . . . . . . . . . . . . . . 75 168 9.5 Supported Namespaces . . . . . . . . . . . . . . . . . . . 75 169 10. Security Considerations . . . . . . . . . . . . . . . . . 76 170 10.1 SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 171 10.2 Secure Identity and Encryption . . . . . . . . . . . . . . 76 172 10.3 Node Connections . . . . . . . . . . . . . . . . . . . . . 76 173 10.4 Presence Information . . . . . . . . . . . . . . . . . . . 76 174 10.5 Host-to-Host Communications . . . . . . . . . . . . . . . 76 175 11. Multi-User Chat . . . . . . . . . . . . . . . . . . . . . 77 176 11.1 Entering a Room . . . . . . . . . . . . . . . . . . . . . 77 177 11.2 Sending a Message to All Participants . . . . . . . . . . 77 178 11.3 Sending a Message to A Selected Participant . . . . . . . 78 179 11.4 Changing Nickname . . . . . . . . . . . . . . . . . . . . 78 180 11.5 Exiting a Room . . . . . . . . . . . . . . . . . . . . . . 79 181 12. IMPP and Interoperability Notes . . . . . . . . . . . . . 80 182 12.1 Requirements Conformance . . . . . . . . . . . . . . . . . 80 183 12.2 Interoperability . . . . . . . . . . . . . . . . . . . . . 80 184 13. Known Deficiencies . . . . . . . . . . . . . . . . . . . . 81 185 13.1 Further Definition of Transport Layer . . . . . . . . . . 81 186 13.2 More Complete Namespace Support . . . . . . . . . . . . . 81 187 13.3 More Flexible Routing . . . . . . . . . . . . . . . . . . 81 188 13.4 More Robust Security . . . . . . . . . . . . . . . . . . . 82 189 13.5 Improved Subscriptions Model . . . . . . . . . . . . . . . 82 190 14. Future Specifications and Submissions . . . . . . . . . . 83 191 References . . . . . . . . . . . . . . . . . . . . . . . . 84 192 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 85 193 A. The element . . . . . . . . . . . . . . . . . . . 87 194 A.1 Attributes . . . . . . . . . . . . . . . . . . . . . . . . 87 195 A.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 89 196 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 90 197 Full Copyright Statement . . . . . . . . . . . . . . . . . 91 199 1. Introduction 201 1.1 Overview 203 Jabber is a set of open, XML-based protocols for which there exist 204 multiple implementations. These implementations have been used 205 mainly to provide instant messaging and presence services that are 206 currently deployed on thousands of domains worldwide and are accessed 207 by millions of IM users daily. Because a standard description of the 208 Jabber protocols is needed to describe this new traffic growing over 209 the Internet, the current document defines the Jabber protocols as 210 they exist today. In addition, this document describes the known 211 deficiencies of the Jabber protocols; however, this document does not 212 address those deficiencies, since they are being addressed through a 213 variety of standards efforts. 215 1.2 Historical Context 217 Broad adoption of the Internet occurred only after clear, simple 218 protocols had been developed and accepted by the technical community. 219 These include SMTP [1] for electronic mail and the tandem of HTTP [2] 220 and HTML [3] for document publishing and interactive services offered 221 over the World Wide Web. The authors of this document see two major 222 additional emerging uses of the Internet: 224 o the near-real-time exchange of text messages (as well as more 225 advanced content) among individuals and applications, enabled by 226 the concepts of presence and availability 228 o the flexible exchange of structured data between applications, 229 enabled by XML [4] along with related technologies such as XML-RPC 230 [5] and SOAP [6] 232 The standard transport mechanisms for XML-RPC, SOAP, and other forms 233 of XML data interchange are HTTP and, to a lesser extent, SMTP; yet 234 neither of these mechanisms provides knowledge about the availability 235 of network endpoints, nor are they particularly optimized for the 236 often asynchronous nature of data interchange, especially when such 237 data comes in the form of relatively small payloads as opposed to the 238 larger documents originally envisioned to be the main beneficiaries 239 of XML. By contrast, the existing instant messaging (IM) services 240 have developed fairly robust methods for routing small information 241 payloads to presence-aware endpoints (having built text messaging 242 systems that scale up to millions of concurrent users), but their 243 data formats are unstructured and they have for the most part shunned 244 the standard addressing schemes afforded by URIs [7] and the DNS [8] 245 infrastructure. 247 Given these considerations, the developers of the Jabber system saw 248 the need for open protocols that would enable the exchange of 249 structured information in an asynchronous, near-real-time manner 250 between any two or more network endpoints, where each endpoint is 251 addressable as a URI and is able to know about the presence and 252 availability of other endpoints on the network. Such protocols, 253 along with associated implementations, would not only provide an 254 alternative (and in many cases more appropriate) transport mechanism 255 for XML data interchange, but also would encourage the development of 256 instant messaging systems that are consistent with Internet standards 257 related to network addressing (URIs, DNS) and structured information 258 (XML). 260 The Jabber protocols provide just such functionality, since they 261 support asynchronous XML-based messaging and the presence or 262 availability of network endpoints. 264 1.3 Evolution of Jabber 266 Definition of the Jabber protocols began in early 1998 with the open- 267 source Jabber server project (jabberd [9]) and associated IM clients. 268 The purpose of the Jabber project was to create an open IM system 269 that would be capable of functioning over diverse networks (e.g., 270 through firewalls) and provide a level of interoperability between 271 other messaging systems. One of the design goals was that a client 272 would need to understand only simple XML data types for messages and 273 presence, with most of the complexity residing on the server. The 274 protocols co-evolved with the server and clients, and the core 275 protocols reached steady-state with release 1.0 in May 2000. Several 276 critical protocol enhancements (most importantly the Dialback 277 Protocol (Section 8.2)) were added with the 1.2 version released in 278 October 2000. It is the protocols as of that date which are 279 documented herein. 281 Since that time, interest in the Jabber protocols has continued to 282 grow. For example, there now exist at least four server 283 implementations of the protocols as well as countless clients for a 284 wide variety of platforms. In addition, Jabber services have been 285 deployed at thousands of domains on the public Internet and on 286 private intranets, and it is estimated that there are well over a 287 million IM users of Jabber instant messaging services worldwide. 289 Given the level of interest in Jabber, the authors have decided to 290 document the Jabber protocols and offer the resulting document to the 291 IETF for historical purposes. 293 1.4 Requirement Levels 295 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 296 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 297 document are to be interpreted as described in RFC 2119 [10]. 299 2. Generalized Architecture 301 2.1 Overview 303 Although the Jabber protocols are not wedded to any specific network 304 architecture, to this point they have usually been implemented via a 305 typical client-server architecture, wherein a client utilizing the 306 Jabber protocols accesses a server over a TCP [11] socket. While it 307 is helpful to keep that specific architecture in mind when seeking to 308 understand the Jabber protocols, we have herein abstracted from any 309 specific architecture and have described the architecture in a more 310 generalized fashion. 312 The following diagram provides a high-level overview of this 313 generalized architecture (where "-" represents communications that 314 use the Jabber XML protocols and "=" represents communications that 315 use any other protocol). 317 Connection Map 319 S1 S2 320 \ / 321 N1 - H1 - H2 - N3 322 / \ 323 N2 - G1 = I1 = F1 325 The symbols are as follows: 327 o N1, N2, N3 - Nodes on the Jabber network 329 o H1, H2 - Hosts on the Jabber network 331 o S1, S2 - Services that add functionality to a primary host 333 o G1 - A gateway that translates between the Jabber XML protocols 334 and the protocol(s) used on a non-Jabber instant messaging network 336 o I1 - A non-Jabber instant messaging network 338 o F1 - A foreign node on a non-Jabber instant messaging network 340 2.2 Host 342 A host acts as an intelligent abstraction layer for core Jabber 343 communications. Its primary responsibility is to manage connections 344 from or sessions for other entities (authorized nodes, services, and 345 other hosts) and to route appropriately-addressed XML data among such 346 entities. Most Jabber hosts also assume responsibility for the 347 storage of data that is used by nodes or services (e.g., the contact 348 list for each IM user, called in Jabber a "roster"); in this case, 349 the XML data is processed directly by the host itself on behalf of 350 the node or service and is not routed to another entity. 352 2.3 Node 354 Most nodes connect directly to a host over a TCP socket and use the 355 Jabber XML protocols to take full advantage of the functionality 356 provided by a host and its associated services. (Nodes on non-Jabber 357 instant messaging networks are also part of the architecture, made 358 accessable via a gateway to that network.) Multiple resources (e.g., 359 devices or locations) may connect to a host on behalf of each 360 authorized node, with each resource connecting over a discrete TCP 361 socket and differentiated by the resource identifier of a Jabber 362 Identifier (Section 3) (e.g., node@host/home vs. node@host/work). 363 The port assigned by the IANA [12] for connections between a Jabber 364 node and a Jabber host is 5222. 366 2.4 Service 368 In addition to the core functionality provided by a host, additional 369 functionality is made possible by connecting trusted services to a 370 host. Examples include multi-user chat (a.k.a. conferencing), real- 371 time alert systems, custom authentication modules, database 372 connectivity, and translation to non-Jabber messaging protocols. 373 There is no set port on which services communicate with hosts; this 374 is left up to the administrator of the service or host. 376 2.4.1 Gateway 378 A gateway is a special-purpose service whose primary function is to 379 translate the Jabber XML protocols into the protocol(s) of another 380 messaging system, as well as translate the return data back into 381 Jabber XML. Examples are gateways to Internet Relay Chat (IRC), 382 Short Message Service (SMS), SMTP, and non-Jabber instant messaging 383 networks such as Yahoo!, MSN, ICQ, and AIM. 385 2.5 Network 387 Because each Jabber host is identified by a network address 388 (typically a DNS hostname) and because host-to-host communications 389 are a simple extension of the Jabber node-to-host protocol, in 390 practice the Jabber system consists of a network of Jabber hosts that 391 inter-communicate. Thus node-a@host1 is able to exchange messages, 392 presence, and other information with node-b@host2. This pattern is 393 familiar from other standards-based messaging protocols, such as 394 SMTP. The usual method for providing a connection between two Jabber 395 hosts is to open a TCP socket on the IANA-assigned port 5269 and 396 negotiate a connection using the Dialback Protocol (Section 8.2). 398 3. Jabber Entities 400 3.1 Overview 402 Any entity that can be considered a network endpoint (i.e., an ID on 403 the network) and that can communicate using the Jabber protocols is 404 considered a Jabber Entity. All Jabber Entities are uniquely 405 addressable in a form that is nearly consistent with the URI 406 specification (see Section 13.3 for details). In particular, a valid 407 Jabber Identifier (JID) contains a set of ordered elements formed of 408 a domain identifier, node identifier, and resource identifier in the 409 following format: [node@]domain[/resource]. 411 All Jabber Identifiers are based on the foregoing structure. The 412 most common use of this structure is to identify an IM user, the host 413 to which the user connects, and the user's active sessions in the 414 form of user@host/resource. However, other nodes are possible; for 415 example, room-name@conference-service is a specific conference room 416 that is offered by a multi-user chat service. 418 3.2 Domain Identifier 420 The domain identifier is the primary identifier and is the only 421 required element of a Jabber Identifier (a simple domain identifier 422 is a valid Jabber Identifier). It usually represents the network 423 gateway or "primary" host to which other entities connect for core 424 XML routing and data management capabilities. However, the entity 425 referenced by a domain identifier is not always a host, and may be a 426 service that is addressed as a subdomain of a host and that provides 427 functionality above and beyond the capabilities of a host (e.g., a 428 multi-user chat service or a gateway to a non-Jabber messaging 429 system). The domain identifier for every host or service that will 430 communicate over a network should resolve to a Fully Qualified Domain 431 Name, and a domain identifier should conform to the specification for 432 DNS names. Comparison of domain identifiers occurs without regard to 433 case for Basic Latin (U+0041 to U+007A) characters. 435 3.3 Node Identifier 437 The node identifier is an optional secondary identifier. It usually 438 represents the entity requesting and using network access provided by 439 the host (e.g., a client), although it can also represent other kinds 440 of entities (e.g., a multi-user chat room associated with a 441 conference service). The entity represented by a node identifier is 442 addressed within the context of a specific domain. Node identifiers 443 are restricted to 255 characters. Any Unicode character higher than 444 U+0020 may be included in a node identifier, with the exception of 445 the following: 447 o U+0022 (") 449 o U+0026 (&) 451 o U+0027 (') 453 o U+003a (:) 455 o U+003C (<) 457 o U+003E (>) 459 o U+0040 (@) 461 Comparison of node identifiers occurs directly without regard to case 462 or other syntatic differences. 464 3.4 Resource Identifier 466 The resource identifer is an optional third identifier. It 467 represents a specific session, connection (e.g., a device or 468 location), or object (e.g., a participant in a multi-user chat room) 469 belonging to a node. A node may maintain multiple resources 470 simultaneously. There are no restrictions on the length of a 471 resource identifier and any valid XML character is allowed in a 472 resource identifer (as defined in Section 2.2 of the XML 1.0 473 specification [4], and as suitably escaped if necessary for inclusion 474 within an XML stream). Comparison of resource identifiers is case 475 sensitive for Basic Latin (U+0041 to U+007A) characters. 477 4. XML Usage within the Jabber Protocols 479 4.1 Overview 481 In essence, Jabber consists of three interrelated protocols: 483 1. XML streams (Section 5), which provide a means for transporting 484 data in an asynchronous manner from one Jabber Entity to another 486 2. common data types (Section 6) (message, presence, and iq), which 487 provide a framework for communications between Jabber Entities 489 3. standard extended namespaces (Section 7), which address more 490 specific areas of functionality such as registration, 491 authentication, and the handling of information related to nodes 492 and services 494 XML [4] is used to define each of these protocols, as described in 495 detail in the following sections. 497 4.2 Namespaces 499 XML Namespaces [13] are used within all Jabber XML to create strict 500 boundaries of data ownership. The basic function of namespaces is to 501 separate different vocabularies of XML elements that are structurally 502 mixed together. Ensuring that Jabber's XML is namespace-aware 503 enables any XML to be structurally mixed with any data element within 504 the protocols. This feature is relied upon frequently within the 505 protocols to separate the XML that is processed by different 506 services. There are two main uses of XML namespaces within Jabber: 507 to define XML Streams (Section 5) and to define Standard Extended 508 Namespaces (Section 7). 510 4.3 Validation 512 A Jabber host is not responsible for validating the XML elements 513 forwarded to a node; an implementation may choose to provide only 514 validated data elements but is not required to do so. Nodes and 515 services should not rely on the ability to send data which does not 516 conform to the schemas, and should handle any non-conformant elements 517 or attributes on the incoming XML stream by ignoring them. 519 5. XML Streams 521 5.1 Overview 523 Two fundamental concepts make possible the rapid, asynchronous 524 exchange of relatively small payloads of structured information 525 between presence-aware entities: XML streams and, as a result, 526 discrete units of structured information that are referred to as "XML 527 chunks". (Note: in this overview we use the example of 528 communications between a node and host, however XML streams are more 529 generalized and are used in Jabber for communications between a wide 530 range of entities [see Section 5.2].) 532 On connecting to a Jabber host, a node initiates an XML stream by 533 sending a properly namespaced tag, and the host 534 replies with a second XML stream back to the node. Within the 535 context of an XML stream, a sender can route a discrete semantic unit 536 of structured information to any recipient. This unit of structured 537 information is a well-balanced XML chunk, such as a message, 538 presence, or iq chunk (a chunk of an XML document is said to be well- 539 balanced if it matches production [43] content of XML 1.0 540 specification [4]). These chunks exist at the direct child level 541 (depth=1) of the root stream element. The start of any XML chunk is 542 unambiguously denoted by the element start tag at depth=1 (e.g., 543 ) and the end of any XML chunk is unambiguously denoted by 544 the corresponding close tag at depth=1 (e.g., ). Each XML 545 chunk may contain child elements or CDATA sections as necessary in 546 order to convey the desired information from the sender to the 547 recipient. The session is closed at the node's request by sending a 548 closing tag to the host. 550 Thus a node's session with a host can be seen as two open-ended XML 551 documents that are built up through the accumulation of the XML 552 chunks that are sent over the course of the session (one from the 553 node to the host and one from the host to the node). In essence, an 554 XML stream acts as an envelope for all the XML chunks sent during a 555 session. We can represent this graphically as follows: 557 |-------------------| 558 | open stream | 559 |-------------------| 560 | | 561 | | 562 | | 563 |-------------------| 564 | | 565 | | 566 | | 567 |-------------------| 568 | | 569 | | 570 | | 571 |-------------------| 572 | close stream | 573 |-------------------| 575 5.2 Scope 577 XML streams function as containers for any XML chunks sent 578 asynchronously between network endpoints. (We now generalize those 579 endpoints by using the terms "initiating entity" and "receiving 580 entity".) XML streams are used within Jabber for the following types 581 of communication: 583 o Node to Host 585 o Host to Host 587 o Service to Host 589 These usages are differentiated through the inclusion of a namespace 590 declaration in the stream from the initiating entity, which is 591 mirrored in the reply from the receiving entity: 593 o For node-to-host (and by extension host-to-node communications), 594 the namespace declaration is "jabber:client". 596 o For host-to-host commmunications, the namespace declaration is 597 "jabber:server". 599 o Communications between a host and a trusted service are slightly 600 more complex, since there are two ways that a service and a host 601 can communicate (for detailed information, see Section 8.3): 603 * The service initiates communications to the host. In this case 604 the namespace declaration is "jabber:component:accept" (since 605 the host "accepts" communications from the service). 607 * The host initiates communications to the service. In this case 608 the namespace declaration is "jabber:component:connect" (since 609 the host "connects" to the service). 611 The common data types (Section 6) are consistent across all three of 612 these namespaces, as are many of the standard extended namespaces 613 (Section 7) (though not all of the latter are relevant to each type 614 of communication; use of the standard extended namespaces is optional 615 for any given implementation). 617 5.3 Restrictions 619 XML streams are used to transport a subset of XML. Specifically, XML 620 streams should not contain processing instructions, non-predefined 621 entities (as defined in Section 4.6 of the XML 1.0 specification 622 [4]), comments, or DTDs. Any such XML data should be ignored. 624 5.4 Formal Definition 626 The attributes of the stream element are as follows: 628 o to - The 'to' attribute is normally used only in the XML stream 629 from the initiating entity to the receiving entity, and is set to 630 the Jabber Identifier of the receiving entity. Normally there is 631 no 'to' attribute set in the XML stream by which the receiving 632 entity replies to the initiating entity, however there is no 633 prohibition on such attributes and the should be ignored. 635 o from - The 'from' attribute is normally used only in the XML 636 stream from the receiving entity to the initiating entity, and is 637 set to the Jabber Identifier of the receiving entity granting 638 access to the initiating entity. Normally there is no 'from' 639 attribute on the XML stream sent from the initiating entity to the 640 receiving entity; however, if a 'from' attribute is included it 641 should be ignored. 643 o id - The 'id' attribute is normally used only in the XML stream 644 from the receiving entity to the initiating entity. It is a 645 unique identifier created by the receiving entity to function as a 646 session key for the initiating entity's session with the receiving 647 entity. Normally there is no 'id' attribute on the XML stream 648 sent from the initiating entity to the receiving entity; however, 649 if an 'id' attribute is included it should be ignored. 651 We can summarize these values as follows: 653 | initiating to receiving | receiving to initiating 654 ------------------------------------------------------------ 655 to | JID of receiver | ignored 656 from | ignored | JID of receiver 657 id | ignored | session key 659 The stream element also contains the following namespace 660 declarations: 662 o xmlns - The 'xmlns' namespace declaration is required and is used 663 in both XML streams in order to scope the allowable first-level 664 children of the stream element for both streams. This namespace 665 declaration must be the same for the initiating stream and the 666 responding stream so that both streams are scoped consistently. 667 For allowable values of this namespace declaration, see Section 668 5.2. 670 o xmlns:stream - The 'xmlns:stream' namespace declaration is 671 required in both XML streams. The only allowable value is "http:/ 672 /etherx.jabber.org/streams". 674 The stream element may also contain the following child element: 676 o error - signifies that a stream-level error has occurred (see 677 Section 5.7) 679 5.5 DTD 681 682 688 5.6 Schema 690 691 697 698 699 700 701 702 703 704 705 706 707 708 709 710 712 714 716 5.7 Stream Errors 718 Errors may occur at the level of the stream. Examples are the 719 sending of invalid XML, the shutdown of a host, an internal server 720 error such as the shutdown of a session manager, and an attempt by a 721 node to authenticate as the same resource that is currently 722 connected. If an error occurs at the level of the stream, the Jabber 723 Entity (initiating entity or receiving entity) that detects the error 724 should send a stream error to the other entity specifying why the 725 streams are being closed and then send a closing 726 tag. XML of the following form is sent within the context of an 727 existing stream: 729 730 ... 731 732 Error message (e.g., "Invalid XML") 733 734 736 5.8 Example 738 The following is a simple stream-based session of a node on a host 739 (where the NODE lines are sent from the node to the host, and the 740 HOST lines are sent from the host to the node): 742 A simple session: 744 NODE: 748 HOST: 753 [authentication] 754 NODE: 755 NODE: Watson come here, I need you! 756 NODE: 757 HOST: 758 HOST: I'm on my way! 759 HOST: 760 NODE: 761 HOST: 763 These are in actuality a sending stream and a receiving stream, which 764 could be viewed as two XML documents (i.e., a-chronologically) in the 765 following way: 767 NODE: 771 NODE: 772 NODE: Watson come here, I need you! 773 NODE: 774 NODE: 776 HOST: 781 HOST: 782 HOST: I'm on my way! 783 HOST: 784 HOST: 786 A session gone bad: 788 NODE: 792 HOST: 797 [authentication] 798 NODE: Bad XML, no closing body tag! 799 HOST: Invalid XML 800 HOST: 802 6. Common Data Types 804 6.1 Overview 806 The common data types (Section 6) for Jabber communications are 807 message, presence, and iq. These data types are sent as XML chunks 808 (i.e., direct children) of the root stream element. 810 6.2 The Message Element 812 This section describes the valid attributes and child elements of the 813 message element. 815 6.2.1 Attributes 817 A message chunk may possess the following attributes: 819 o to - Specifies the intended recipient of the message chunk. 820 Within the context of communications between a node and host, the 821 absence of a 'to' attribute implies that the XML chunk is 822 addressed to the node@host sending the chunk. Chunks lacking a 823 'to' attribute or addressed to node@host are processed by the host 824 on behalf of the node@host. Chunks addressed to node@host/ 825 resource are sent to a specific connected resource associated with 826 the node. 828 o from - Specifies the sender of the message chunk. Within the 829 context of communications between a node and host, the absence of 830 a 'from' attribute implies that the XML chunk is addressed from 831 the node@host/resource sending the chunk. A node may specify any 832 resource, but the host must verify that the node@host matches that 833 of the connected node (this is to prevent spoofing). 835 o id - An optional unique identifier for the purpose of tracking 836 messages. The sender of the message chunk sets this attribute, 837 which may be returned in any replies. 839 o type - Used to capture the conversational context of the message, 840 thus providing a hint regarding presentation (e.g., in a GUI). If 841 no type is set or if the type is set to a value other than those 842 specified here, the value should be defaulted by the host to 843 "normal". The type should be one of the following: 845 * normal - Single message 847 * chat - Traditional two-way chat between two entities 849 * groupchat - Chat among multiple entities (for details, see 850 Multi-User Chat (Section 11)) 852 * headline - Ticker or active list of items (e.g., news, sports 853 scores, stock market quotes) 855 * error - See the error element (Appendix A) 857 6.2.2 Children 859 A message chunk may contain zero or one of each of the following 860 child elements (which may not contain mixed content): 862 o body - The textual contents of the message (must have no 863 attributes); normally included but not required 865 o subject - The (optional) subject of the message (must have no 866 attributes) 868 o thread - An optional random string that is generated by the 869 originating node and that may be copied back in replies; it is 870 used for tracking a conversation thread (must have no attributes) 872 o error - See the error element (Appendix A). 874 Note: a message element may house an optional element containing 875 content that extends the meaning of the core message (e.g., an 876 encrypted form of the message body). In Jabber usage this child 877 element is often the element but can be any element. The child 878 element must possess an 'xmlns' namespace declaration (other than 879 those defined for XML streams) that defines all elements contained 880 within the child element. The XML data contained within this element 881 is outside the scope of this document, except for the specific uses 882 of the element defined in standard extended namespaces (Section 883 7). If an entity does not understand such a child element or its 884 namespace, it must ignore the associated XML data. 886 6.2.3 DTD 888 891 898 899 900 901 902 904 6.2.4 Schema 906 907 913 914 915 916 917 918 919 920 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 942 943 944 945 946 947 951 952 954 956 6.2.5 Examples 958 The following examples have been processed by each sender's host and 959 contain the 'from' attribute (node@host/resource) of the sender. 960 (For examples of messages of type "groupchat", see Section 11.) 962 A simple message: 964 965 Imploring 966 Wherefore art thou, Romeo? 967 968 A simple threaded conversation: 970 974 Art thou not Romeo, and a Montague? 975 283461923759234 976 978 982 Neither, fair saint, if either thee dislike. 983 283461923759234 984 986 990 How cam'st thou hither, tell me, and wherefore? 991 283461923759234 992 994 6.3 The Presence Element 996 Presence is used to express a Jabber Entity's current availability 997 status and communicate that status to other entities. 999 6.3.1 Attributes 1001 A presence chunk may possess the following attributes: 1003 o to - Specifies the intended recipient of the presence chunk. 1004 Within the context of communications between a node and host, the 1005 absence of a 'to' attribute implies that the XML chunk is 1006 addressed to the node@host sending the chunk. Chunks lacking a 1007 'to' attribute or addressed to node@host are processed by the host 1008 on behalf of the node@host. Chunks addressed to node@host/ 1009 resource are sent to a specific connected resource associated with 1010 the node. 1012 o from - Specifies the sender of the presence chunk. Within the 1013 context of communications between a node and host, the absence of 1014 a 'from' attribute implies that the XML chunk is addressed from 1015 the node@host/resource sending the chunk. A node may specify any 1016 resource, but the host must verify that the node@host matches that 1017 of the connected node (this is to prevent spoofing). 1019 o id - An optional unique identifier for the purpose of tracking 1020 presence. The sender of the presence chunk sets this attribute, 1021 which may be returned in any replies. 1023 o type - Describes the type of presence. No 'type' attribute, or 1024 inclusion of a type not specified here, implies that the sender is 1025 available. The type should be one of the following: 1027 * unavailable - Signals that the node is no longer available for 1028 communications. 1030 * subscribe - The sender wishes to subscribe to the recipient's 1031 presence. 1033 * subscribed - The sender has allowed the recipient to receive 1034 their presence. 1036 * unsubscribe - A notification that an entity is unsubscribing 1037 from another entity's presence. The host handles the actual 1038 unsubscription, but nodes receive a presence element for 1039 notification reasons. 1041 * unsubscribed - The subscription has been cancelled. 1043 * probe - A host-to-host query to request an entity's current 1044 presence. 1046 * error - See the error element (Appendix A). 1048 Note: a presence element may house an optional element containing 1049 content that extends the meaning of the core presence (e.g., a signed 1050 form of the availability status). In Jabber usage this child element 1051 is often the element but can be any element. The child element 1052 must possess an 'xmlns' namespace declaration (other than those 1053 defined for XML streams) that defines all elements contained within 1054 the child element. The XML data contained within this element is 1055 outside the scope of this document, except for the specific uses of 1056 the element defined in standard extended namespaces (Section 7). 1057 If an entity does not understand such a child element or its 1058 namespace, it must ignore the associated XML data. 1060 6.3.2 Children 1062 A presence chunk may contain zero or one of each of the following 1063 child elements: 1065 o show - Describes the availability status of a node or specific 1066 resource. The values should be one of the following (values other 1067 than these four are typically ignored): 1069 * away - Node or resource is temporarily away. 1071 * chat - Node or resource is free to chat. 1073 * xa - Node or resource is away for an extended period ("eXtended 1074 Away"). 1076 * dnd - Node or resource is busy ("Do Not Disturb"). 1078 o status - An optional natural-language description of availability 1079 status. Normally used in conjunction with the show element to 1080 provide a detailed description of an availability state (e.g., "In 1081 a meeting"). 1083 o priority - A positive integer representing the priority level of 1084 the connected resource, with zero as the lowest priority. 1086 o error - See the error element (Appendix A). 1088 6.3.3 DTD 1090 1092 1099 1100 1101 1102 1103 1105 6.3.4 Schema 1107 1108 1114 1115 1116 1117 1118 1119 1120 1121 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1162 1163 1165 1167 6.3.5 Examples 1169 Initial presence sent to host upon login to express default 1170 availability: 1172 1174 Receiving detailed presence from another node: 1176 1177 xa 1178 sleeping 1179 1 1180 1182 Presence sent to host upon logging off to express unavailable state: 1184 1186 A request to subscribe to a node's presence: 1188 1193 Acceptance of a presence subscription request: 1195 1200 Denial of a presence subscription request, or cancellation of a 1201 previously granted subscription request: 1203 1208 Notification of unsubscribing from a node's presence: 1210 1215 6.4 The IQ Element 1217 Info/Query, or IQ, is a simple request-response mechanism. Just as 1218 HTTP is a request-response medium, the iq element enables an entity 1219 to make a request and receive a response from another entity. 1221 The actual content of the request and response is defined by the 1222 namespace declaration of a direct child element of the iq element. 1223 Any direct child element of the iq element must possess an 'xmlns' 1224 namespace declaration (other than those defined for XML streams) that 1225 defines all elements and attributes contained within that child 1226 element. For details, see Section 7. 1228 6.4.1 Attributes 1230 An iq chunk may possess the following attributes: 1232 o to - Specifies the intended recipient of the iq chunk. Within the 1233 context of communications between a node and host, the absence of 1234 a 'to' attribute implies that the XML chunk is addressed to the 1235 node@host sending the chunk. Chunks lacking a 'to' attribute or 1236 addressed to node@host are processed by the host on behalf of the 1237 node@host. Chunks addressed to node@host/resource are sent to a 1238 specific connected resource associated with the node. 1240 o from - Specifies the sender of the iq chunk. Within the context 1241 of communications between a node and host, the absence of a 'from' 1242 attribute implies that the XML chunk is addressed from the 1243 node@host/resource sending the chunk. A node may specify any 1244 resource, but the host must verify that the node@host matches that 1245 of the connected node (this is to prevent spoofing). 1247 o id - An optional unique identifier for the purpose of tracking the 1248 information exchange. The sender of the IQ chunk sets this 1249 attribute, which may be returned in any replies. 1251 o type - The required 'type' attribute specifies a distinct step 1252 within a request-response conversation. Should be one of the 1253 following (all other values are ignored): 1255 * get - Indicates that the current request is a question or 1256 search for information. 1258 * set - This request contains data intended to set values or 1259 replace existing values. 1261 * result - This is a successful response to a get/set request. 1262 If the request was successful, the iq element of type "result" 1263 is normally empty. 1265 * error - The request failed. See the error element (Appendix 1266 A). 1268 6.4.2 Children 1270 In the strictest terms, the iq element contains no children since it 1271 is a vessel for XML in another namespace. In operation, a query 1272 element is usually contained within the iq element as defined by its 1273 own separate namespace. See Standard Extended Namespaces (Section 1274 7). 1276 6.4.3 DTD 1278 1280 1287 1288 1290 6.4.4 Schema 1292 1293 1299 1300 1301 1302 1303 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1324 1325 1326 1330 1331 1333 1335 6.4.5 Examples 1337 Most IQ examples follow a common pattern of structured data exchange 1338 such as get/result or set/result: 1340 Requesting Responding 1341 Entity Entity 1342 ---------- ---------- 1343 | | 1344 | | 1345 | ---------------------> | 1346 | | 1347 | | 1348 | <--------------------- | 1349 | | 1350 | | 1351 | ---------------------> | 1352 | | 1353 | | 1354 | <--------------------- | 1355 | | 1357 For specific examples, see Standard Extended Namespaces (Section 7). 1359 7. Standard Extended Namespaces 1361 7.1 Overview 1363 While the common data types provide a basic level of functionality 1364 for instant messaging and presence, Jabber uses XML namespaces to 1365 extend the common data types for the purpose of providing additional 1366 functionality. The extended namespaces accepted by the Jabber 1367 Software Foundation all begin with 'jabber:'. (In addition, any of 1368 the core data types can be the target of a custom extension using a 1369 namespace determined by the creator of that custom extension; 1370 however, custom extended namespaces are beyond the scope of this 1371 document.) The XML contained in the extension must be defined in the 1372 namespace specified in the element that is included as a direct child 1373 element of the relevant common data type. This information is often 1374 sent within an appropriately-namespaced element that is a 1375 direct child of the iq element, but it can be sent in any element. 1377 There are two types of standard extended namespaces. Namespaces of 1378 the first type, which begin with the string 'jabber:iq:', are used 1379 within the iq element to facilitate requests and responses between 1380 Jabber Entities. These requests usually embody both the action being 1381 requested and the data needed for that request, if any. 1383 Namespaces of the second type, which begin with the string 1384 'jabber:x:', are used within the message element (and less frequently 1385 the presence element) to send structured information that is 1386 specifically related to messages and presence. Jabber Entities can 1387 use this type of namespace to effect registration or authentication, 1388 send URLs, roster items, offline options, encrypted data, and other 1389 information. This information is sent within an appropriately- 1390 namespaced element that is a direct child of the message or 1391 presence element. 1393 Many (but not all) of the Standard Extended Namespaces are relevant 1394 to communications from node to host, host to host, and service to 1395 host. It is up to the implementation to determine which namespaces 1396 to support for each type of communication. 1398 The standard iq and x namespaces are described in detail in this 1399 section. 1401 7.2 jabber:iq:agent - Agent Properties 1403 The jabber:iq:agent namespace is used to obtain the properties of a 1404 specific service associated with a host. 1406 7.2.1 Children 1408 Information about agent properties is contained within a 1409 element that is scoped by the jabber:iq:agent namespace. That query 1410 element may contain the following children: 1412 o agent - the reply to a request of type "get" in the 1413 jabber:iq:agent namespace contains zero or one elements. 1414 The element has a required 'jid' attribute that contains 1415 the Jabber Identifier of the agent. The element in turn 1416 may contain the following children: 1418 * name - a natural-language name for the service 1420 * description - a short phrase describing the service 1422 * transport - inclusion of this element indicates that the 1423 service is a gateway to a non-Jabber instant messaging system 1425 * groupchat - inclusion of this element indicates that the 1426 service is multi-user chat service 1428 * service - what type of service this is -- values normally 1429 included specify the type of gateway (aim, icq, msn, yahoo), 1430 the type of conferencing service (public or private), or user 1431 directory (jud) 1433 * register - the service supports registration 1435 * search - the service supports searching 1437 7.2.2 DTD 1439 1441 1443 1446 1447 1448 1449 1450 1451 1452 1454 7.2.3 Schema 1456 1457 1463 1464 1465 1466 1467 1468 1469 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1485 1487 1488 1489 1490 1491 1492 1493 1495 1497 7.2.4 Examples 1499 Request for agent information: 1501 1502 1503 1505 Reply from host describing a conferencing component: 1507 1508 1509 1510 Conferencing Service 1511 1512 This service provides multi-user chatrooms. 1513 1514 public 1515 1516 1517 1518 1520 7.3 jabber:iq:agents - Available Agents 1522 The jabber:iq:agents namespace is used to obtain a list of entities 1523 associated with a Jabber Entity. Most commonly this is the list of 1524 trusted services associated with a specific host. 1526 7.3.1 Children 1528 Information about available agents properties is contained within a 1529 element that is scoped by the jabber:iq:agents namespace. 1530 That query element may contain the following children: 1532 o agent - the reply to a request of type "get" in the 1533 jabber:iq:agents namespace contains zero or more 1534 elements. The element has a required 'jid' attribute 1535 that contains the Jabber Identifier of each agent. The 1536 element in turn may contain the following children: 1538 * name - a natural-language name for the service 1540 * description - a short phrase describing the service 1542 * transport - inclusion of this element indicates that the 1543 service is a gateway to a non-Jabber instant messaging system 1545 * groupchat - inclusion of this element indicates that the 1546 service is multi-user chat service 1548 * service - what type of service this is -- values normally 1549 included specify the type of gateway (aim, icq, msn, yahoo), 1550 the type of conferencing service (public or private), or user 1551 directory (jud) 1553 * register - the service supports registration 1555 * search - the service supports searching 1557 7.3.2 DTD 1559 1561 1563 1566 1567 1568 1569 1570 1571 1572 1574 7.3.3 Schema 1576 1577 1583 1584 1585 1586 1587 1588 1589 1591 1592 1593 1594 1595 1596 1597 1598 1599 1600 1601 1602 1603 1604 1606 1607 1608 1609 1610 1611 1612 1614 1616 7.3.4 Examples 1618 Request for agents list: 1620 1621 1622 1624 Reply from host: 1626 1631 1632 1633 Jabber User Directory 1634 jud 1635 1636 1637 1638 1639 Conferencing Service 1640 public 1641 1642 1643 1644 1646 7.4 jabber:iq:auth - Node Authentication 1648 The jabber:iq:auth namespace provides a simple mechanism for nodes to 1649 authenticate and create a resource representing their connection to 1650 the host. 1652 7.4.1 Children 1654 o username - the unique username for this node (usually an IM user). 1656 o password - the secret key or passphrase for the node's access to 1657 the host. 1659 o digest - the concatenation of the stream id and the password, 1660 encrypted according to the SHA1 Secure Hash Algorithm [14] and 1661 represented as all lowercase hex. 1663 o resource - unique value to represent current connection. 1665 7.4.2 DTD 1667 1669 1670 1671 1672 1674 7.4.3 Schema 1676 1677 1683 1684 1685 1686 1687 1688 1689 1690 1691 1692 1693 1694 1696 1697 1698 1699 1701 1703 7.4.4 Examples 1705 The following is a complete example of how a node authenticates with 1706 a host. 1708 Node queries host as to what information is required: 1710 1711 1712 juliet 1713 1714 1716 Host replies: 1718 1719 1720 juliet 1721 1722 1723 1724 1725 1727 Node sends authentication information (plaintext password): 1729 1730 1731 juliet 1732 r0m30 1733 balcony 1734 1735 1737 Node sends authentication information (hashed password): 1739 1740 1741 juliet 1742 64d60e40febe09264c52bc9cbddd5dd1147fae97 1743 balcony 1744 1745 1747 Host confirms login: 1749 1751 7.5 jabber:iq:oob - Out-of-Band Data 1753 The jabber:iq:oob namespace provides a standard way to perform node- 1754 to-node transmission of information outside the context of the host 1755 (e.g., for the purpose of file transfers). Note that information can 1756 be transferred out of band within an iq element using the 1757 jabber:iq:oob namespace or within a message element using the 1758 jabber:x:oob namespace. It is expected that a Jabber Entity will 1759 perform an HTTP HEAD request to determine the MIME type and size of 1760 any file before retrieving it from a URL. 1762 7.5.1 Children 1764 o url - a Uniform Resource Locator for the file 1766 o desc - a natural-language description of the file 1768 7.5.2 DTD 1770 1772 1773 1775 7.5.3 Schema 1777 1778 1784 1785 1786 1787 1788 1789 1790 1791 1793 1794 1796 1798 7.5.4 Examples 1800 Node transmits information to another node: 1802 1803 1804 http://denmark/act4/letter-1.html 1805 There's a letter for you sir. 1806 1807 1809 7.6 jabber:iq:register - Registration 1811 Through the jabber:iq:register namespace, nodes can register with a 1812 Jabber host itself or with trusted services of that host. 1814 7.6.1 Children 1816 Note that while numerous fields are available, only the ones returned 1817 by a host or service (other than "instructions") are required in 1818 order to register with that host or service. 1820 o instructions 1822 o username 1824 o password 1826 o name 1828 o email 1830 o address 1832 o city 1834 o state 1836 o zip 1838 o phone 1840 o url 1842 o date 1844 o misc 1845 o text 1847 o remove - request to unregister 1849 7.6.2 DTD 1851 1856 1857 1858 1859 1860 1861 1862 1863 1864 1865 1866 1867 1868 1869 1870 1872 7.6.3 Schema 1874 1875 1881 1882 1883 1884 1885 1886 1887 1888 1889 1890 1891 1892 1893 1894 1895 1896 1897 1898 1899 1900 1901 1903 1904 1905 1906 1907 1908 1909 1910 1911 1912 1913 1914 1915 1916 1917 1919 1921 7.6.4 Examples 1923 Node request for information required to register with a service: 1925 1926 1927 1928 Host response with registration fields required: 1930 1934 1935 1936 Choose a username and password to register with this service. 1937 1938 1939 1940 1941 1942 1944 Node request to register for an account: 1946 1950 1951 hamlet 1952 hamlet@denmark 1953 gertrude 1954 1955 1957 Successful registration: 1959 1965 Failed registration: 1967 1972 Not Acceptable 1973 1975 Node request to unregister: 1977 1981 1982 1983 1984 1986 Successful unregistration: 1988 1994 7.7 jabber:iq:roster - Roster Management 1996 The jabber:iq:roster namespace provides a mechanism for managing a 1997 node's roster (also known as a "contact list"). Upon connecting to 1998 the host, a node should request the roster using jabber:iq:roster. 1999 Since the roster may not be desirable for all resources (e.g., 2000 cellular phone client), the node's request for the roster is 2001 optional. 2003 When a specific connected resource for a node updates the node's 2004 roster on the host, the host is responsible for pushing that change 2005 out to all connected resources for that node using an iq element of 2006 type "set" as seen in the final example within this section. This 2007 enables all connected resources to remain in sync with the host-based 2008 roster information. 2010 7.7.1 Children 2012 A element scoped by the jabber:iq:roster namespace may 2013 contain zero or more elements. An item element may contain 2014 the following attributes: 2016 o jid - a required attribute that contains the complete Jabber 2017 Identifier of the contact that this item represents 2019 o name - an optional attribute that contains a natural-language name 2020 for the contact 2022 o subscription - the current status of the subscription related to 2023 this item. Should be one of the following (all other values are 2024 ignored): 2026 * none - no subscription. 2028 * from - this entity has a subscription to the contact. 2030 * to - the contact has a subscription to this entity. 2032 * both - subscription is both to and from. 2034 * remove - item is to be removed. 2036 o ask - An optional attribute specifying the current status of a 2037 request to this contact. Should be one of the following (all 2038 other values are ignored): 2040 * subscribe - this entity is asking to subscribe to that 2041 contact's presence. 2043 * unsubscribe - this entity is asking unsubscribe from that 2044 contact's presence. 2046 An element may contain zero or more instances of the 2047 following element: 2049 o group - Natural-language name of a user-specified group for the 2050 purpose of categorizing contacts into groups. 2052 7.7.2 DTD 2054 2056 2057 2063 2065 7.7.3 Schema 2067 2068 2074 2075 2076 2077 2078 2079 2080 2082 2083 2084 2085 2086 2087 2088 2089 2090 2091 2092 2093 2094 2095 2096 2097 2098 2100 2101 2102 2103 2104 2105 2106 2107 2108 2109 2110 2112 2114 2116 7.7.4 Examples 2118 Node requests current roster from host: 2120 2121 2122 2123 Node receives the roster from the host: 2125 2126 2131 2135 Friends 2136 2137 2141 Friends 2142 2143 2144 2146 Node adds a new item: 2148 2149 2150 2153 Servants 2154 2155 2157 Host replies with the updated roster information, plus an IQ result: 2159 2160 2161 2164 Servants 2165 2166 2167 2169 7.8 jabber:iq:time - Entity Time 2171 The jabber:iq:time namespace provides a standard way for Jabber 2172 Entities to exchange local time (e.g., to "ping" another entity or 2173 check network latency). 2175 7.8.1 Children 2177 o utc - the time at the responding entity in UTC (the format should 2178 be consistent with that defined in ISO 8601 [15]) 2180 o tz - the time zone in which the entity is located 2182 o display - human-readable time format 2184 7.8.2 DTD 2186 2188 2189 2190 2192 7.8.3 Schema 2194 2195 2201 2202 2203 2204 2205 2206 2207 2208 2209 2211 2212 2213 2215 2217 7.8.4 Examples 2219 Node requests time from another node: 2221 2226 2227 2228 Node replies to request: 2230 2235 2236 20020214T23:55:06 2237 WET 2238 14 Feb 2002 11:55:06 PM 2239 2240 2242 7.9 jabber:iq:version - Entity Version 2244 The jabber:iq:version namespace provides a standard way for Jabber 2245 Entities to discover version information about other entities. 2247 7.9.1 Children 2249 o name - a natural-language name for the entity, resource, or 2250 application 2252 o version - the specific version 2254 o os - the operating system on which the entity is running 2256 7.9.2 DTD 2258 2260 2261 2262 2264 7.9.3 Schema 2266 2267 2273 2274 2275 2276 2277 2278 2279 2280 2281 2283 2284 2285 2287 2289 7.9.4 Examples 2291 Node requests version information from another node: 2293 2298 2299 2300 Node replies to request: 2302 2307 2308 Gabber 2309 0.8.6 2310 Linux i686 2311 2312 2314 7.10 jabber:x:delay - Delayed Delivery 2316 The jabber:x:delay namespace is used to provide timestamp information 2317 about data stored for later delivery. The most common uses of this 2318 namespace are to stamp: 2320 o a message sent to an offline entity and that is stored for later 2321 delivery 2323 o the last presence update sent by a connected node to a host 2325 o messages cached by a multi-user chat room for delivery to new 2326 entrants to the room 2328 7.10.1 Attributes 2330 o from - the Jabber Identifier of the location where the XML chunk 2331 has been delayed or held for later delivery (for example, the 2332 address of a multi-user chat room) 2334 o stamp - a required attribute that contains information about the 2335 time when the chunk was originally sent (the format should be 2336 consistent with that defined in ISO 8601 [15]) 2338 7.10.2 DTD 2340 2342 2347 7.10.3 Schema 2349 2350 2356 2357 2358 2359 2360 2361 2362 2364 7.10.4 Examples 2366 Message sent to an offline node: 2368 2373 Message me when you log in again. 2374 2378 Offline Storage 2379 2380 2382 Last presence update sent by another node: 2384 In a meeting for the next two hours. 2388 xa 2389 1 2390 2394 2395 Message sent in a conference room before the recipient arrived and 2396 cached for delivery to new entrants: 2398 2403 Thrice the brinded cat hath mew'd. 2404 2408 Cached In GC History 2409 2410 2412 7.11 jabber:x:oob - Out-of-Band Data 2414 The jabber:x:oob namespace enables nodes to exchange special messages 2415 that contain URIs along along with a description. It is expected 2416 that a node will perform an HTTP HEAD request to determine the MIME 2417 type and size of any file before retrieving it from a URL. 2419 7.11.1 Children 2421 o url - a Uniform Resource Locator for the file 2423 o desc - a natural language description of the file 2425 7.11.2 DTD 2427 2429 2430 2432 7.11.3 Schema 2434 2435 2441 2442 2443 2444 2445 2446 2447 2448 2450 2451 2453 2455 7.11.4 Examples 2457 A node sends a message to another node containing information about 2458 an out-of-band transfer: 2460 2461 URL Attached. 2462 2463 http://denmark/act4/letter-1.html 2464 There's a letter for you sir 2465 2466 2468 7.12 jabber:x:roster - Embedded Roster Items 2470 The jabber:x:roster namespace is used to send roster items from one 2471 Jabber Entity to another. 2473 7.12.1 Children 2475 An element scoped by the jabber:x:roster namespace may contain 2476 zero or more elements. An item element may contain the 2477 following attributes: 2479 o jid - the Jabber Identifier of the item 2481 o name - a natural-language name or nickname for the item 2483 An element may also contain one or more of the following 2484 children: 2486 o group - Natural-language name of a user-specified group for the 2487 purpose of categorizing contacts into groups. 2489 7.12.2 DTD 2491 2493 2494 2498 2500 7.12.3 Schema 2502 2503 2509 2510 2511 2512 2513 2514 2515 2517 2518 2519 2520 2521 2522 2523 2524 2525 2527 2529 2531 7.12.4 Examples 2533 Sending an embedded roster item to another node: 2535 2536 Visitors 2537 This message contains roster items. 2538 2539 2542 Visitors 2543 2544 2547 Visitors 2548 2549 2550 2552 8. Authentication Mechanisms 2554 Authentication is any process of verifying that a Jabber Entity is 2555 who or what it claims it is. Because nodes, hosts, and services are 2556 fundamentally different kinds of entities, authentication is the only 2557 area of Jabber communications that has been perceived to necessitate 2558 differences at the protocol level (as opposed to implementation 2559 level) between the treatment of nodes, hosts, and services. The 2560 standard authentication mechanisms are described in this section. 2562 8.1 Authentication of a Node by a Host 2564 The process by which a node is authenticated by a host is defined by 2565 the jabber:iq:auth namespace (Section 7.4). This process is used 2566 only within XML streams that are declared under the "jabber:client" 2567 namespace. (Note: because a host never authenticates with a node, 2568 there is no defined protocol by which such authentication would take 2569 place.) 2571 8.2 Authentication of a Host by Another Host 2573 8.2.1 Overview 2575 It became obvious to the developers of the Jabber protocol that they 2576 needed a method of verifying that a connection between two hosts 2577 could be trusted. Because the developers wished to avoid the 2578 overhead of building a network of trusted hosts, they sought a 2579 protocol-level system that would provide the necessary security. 2580 This method is called dialback and is used only within XML streams 2581 that are declared under the "jabber:server" namespace. 2583 The dialback protocol is used to prevent spoofing of a particular 2584 hostname and sending false data from it. Dialback is made possible 2585 by the existence of DNS, since one host can verify that another host 2586 which is connecting to it is authorized to represent a given host on 2587 the Jabber network. All DNS host resolutions must first resolve the 2588 host using an SRV [16] record of _jabber._tcp.host. If the SRV 2589 lookup fails, the fallback is a normal A lookup using the jabber- 2590 server port of 5269 assigned by the Internet Assigned Numbers 2591 Authority [12]. 2593 Note that the method used to generate and verify the keys used in the 2594 dialback protocol must take into account the hostnames being used, 2595 along with a secret known only by the receiving host and the random 2596 id on the stream. Generating unique but verifiable keys is important 2597 to prevent common man-in-the-middle attacks and host spoofing. 2599 In the description that follows we use the following terminology: 2601 o Originating Host - the host that is attempting to establish a 2602 connection between the two hosts 2604 o Receiving Host - the host that is trying to authenticate that the 2605 Originating Host represents the Jabber host which it claims to be 2607 o Authoritative Host - the host which is given when a DNS lookup is 2608 performed on the name that the Originating Host initially gave; 2609 for simple environments this will be the Originating Host, but it 2610 could be a separate machine in the Originating Host's network 2612 The following is a brief summary of the order of events in dialback: 2614 1. Originating Host establishes a connection to Receiving Host. 2616 2. Originating Host sends a 'key' value over the connection to 2617 Receiving Host. 2619 3. Receiving Host establishes a connection to Authoritative Host. 2621 4. Receiving Host sends the same 'key' value to Authoritative Host. 2623 5. Authoritative Host replies that key is valid or invalid. 2625 6. Receiving Host tells Originating Host whether it is authenticated 2626 or not. 2628 We can represent this flow of events graphically as follows: 2630 Originating Receiving 2631 Host Host 2632 ----------- --------- 2633 | | 2634 | establish connection | 2635 | ----------------------> | 2636 | | 2637 | send stream header | 2638 | ----------------------> | 2639 | | 2640 | establish connection | 2641 | <---------------------- | 2642 | | 2643 | send stream header | 2644 | <---------------------- | 2645 | | Authoritative 2646 | send dialback key | Host 2647 | ----------------------> | ------------- 2648 | | | 2649 | establish connection | 2650 | ----------------------> | 2651 | | 2652 | send stream header | 2653 | ----------------------> | 2654 | | 2655 | send stream header | 2656 | <---------------------- | 2657 | | 2658 | send dialback key | 2659 | ----------------------> | 2660 | | 2661 | validate dialback key | 2662 | <---------------------- | 2663 | 2664 | report dialback result | 2665 | <---------------------- | 2666 | | 2668 8.2.2 Dialback Protocol 2670 The traffic sent between the hosts is as follows: 2672 1. Originating Host establishes connection to Receiving Host 2674 2. Originating Host sends a stream header to Receiving Host (the 2675 'to' and 'from' attributes are not required): 2677 2681 Note: the value of the xmlns:db namespace declaration indicates 2682 to Receiving Host that Originating Host supports dialback. 2684 3. Receiving Host sends a stream header back to Originating Host 2685 (the 'to' and 'from' attributes are not required): 2687 2692 4. Originating Host sends a dialback key to Receiving Host: 2694 98AF014EDC0... 2698 Note: this key is not examined by Receiving Host, since the 2699 Receiving Host does not keep information about Originating Host 2700 between sessions. 2702 5. Receiving Host now establishes a connection back to Originating 2703 Host, getting the Authoritative Host. 2705 6. Receiving Host sends Authoritative Host a stream header (the 2706 'to' and 'from' attributes are not required): 2708 2712 7. Authoritative Host sends Receiving Host a stream header: 2714 2719 8. Receiving Host sends Authoritative Host a chunk indicating it 2720 wants Authoritative Host to verify a key: 2722 98AF014EDC0... 2725 Note: passed here are the hostnames, the original identifier 2726 from Receiving Host's stream header to Originating Host in step 2727 2, and the key Originating Host gave Receiving Host in step 3. 2728 Based on this information and shared secret information within 2729 the 'Originating Host' network, the key is verified. Any 2730 verifiable method can be used to generate the key. 2732 9. Authoritative Host sends a chunk back to Receiving Host 2733 indicating whether the key was valid or invalid: 2735 2741 or 2743 2749 10. Receiving Host informs Originating Host of the result: 2751 2756 Note: At this point the connection has either been validated via 2757 a type='valid', or reported as invalid. Once the connection is 2758 validated, data can be sent by the Originating Host and read by 2759 the Receiving Host; before that, all data chunks sent to 2760 Receiving Host are dropped. As a final guard against domain 2761 spoofing, the Receiving Host must validate all XML chunk 2762 received from the Originating Host to verify that the from 2763 address of each chunk includes the validated domain. 2765 8.3 Authentication of Services 2767 As noted under Section 5.2, there are two ways that a service and a 2768 host can communicate: 2770 1. The service initiates communications to the host. In this case 2771 the namespace declaration is "jabber:component:accept" (since the 2772 host "accepts" communications from the service). 2774 2. The host initiates communications to the service. In this case 2775 the namespace declaration is "jabber:component:connect" (since 2776 the host "connects" to the service). 2778 The authentication methods for these communication directions are 2779 defined in this section. 2781 8.3.1 Authentication of a Service by a Host 2783 When a service initiates a connection to a host, the host will want 2784 to verify the identity of the service so that it knows whether the 2785 service can be trusted. The first step is to negotiate the XML 2786 streams between the service and the host, scoped within the 2787 "jabber:component:accept" namespace: 2789 Initiation of XML stream from service to host: 2791 2796 XML stream sent in reply from host to service: 2798 2804 (Note: the XML stream returned from the host to the service contains 2805 an 'id' attribute. This ID functions as a session key for the 2806 service's connection to the host.) 2808 The next step is for the service to provide authentication 2809 credentials to the host. These credentials are sent in a element. The information contained in the handshake element is a 2811 concatenation of the stream id and a secret known by the host and the 2812 service, encrypted according to the SHA1 Secure Hash Algorithm [14] 2813 and represented as all lowercase hex. 2815 Handshake sent from service to host: 2817 aaee83c26aeeafcbabeabfcbcd50df997e0a2a1e 2819 If the host determines that the service's authentication credentials 2820 are valid, it will return an empty element to the 2821 service. 2823 Handshake validation sent from host to service: 2825 2827 If the host determines that the service's authentication credentials 2828 are not valid, it will return a stream error to the service and close 2829 the stream. 2831 Host sends stream error to service: 2833 Invalid handshake 2834 2836 8.3.2 Authentication of a Host by a Service 2838 When a host initiates a connection to a service, the service will 2839 want to verify the identity of the host so that it knows whether the 2840 host can be trusted (e.g., if a service accepts connections from 2841 multiple hosts). The first step is to negotiate the XML streams 2842 between the service and the host, scoped within the 2843 "jabber:component:connect" namespace. 2845 Initiation of XML stream from host to service: 2847 2852 XML stream sent in reply from service to host: 2854 2860 (Note: the XML stream returned from the service to the host contains 2861 an 'id' attribute. This ID functions as a session key for the host's 2862 connection to the service.) 2864 The next step is for the host to provide authentication credentials 2865 to the service. These credentials are sent in a 2866 element. The information contained in the handshake element is a 2867 concatenation of the stream id and a secret known by the host and the 2868 service, encrypted according to the SHA1 Secure Hash Algorithm [14] 2869 and represented as all lowercase hex. 2871 Handshake sent from host to service: 2873 aaee83c26aeeafcbabeabfcbcd50df997e0a2a1e 2875 If the service determines that the host's authentication credentials 2876 are valid, it will return an empty element to the host. 2878 Handshake validation sent from host to service: 2880 2882 If the service determines that the host's authentication credentials 2883 are not valid, it will return a stream error to the host and close 2884 the stream. 2886 Host sends stream error to service: 2888 Invalid handshake 2889 2891 9. Routing, Delivery, and Presence Guidelines 2893 9.1 Routing and Delivery of XML Chunks 2895 XML chunks that are not handled directly by a host (e.g., for the 2896 purpose of data storage) are routed or delivered to the intended 2897 recipient of the chunk as represented by a Jabber Identifier in the 2898 'to' attribute. The following rules apply: 2900 o If the Jabber Identifier contains a resource identifier 2901 (to="node@host/resource"), the chunk is delivered first to the 2902 resource that exactly matches the resource identifier, or 2903 secondarily to a resource that matches partially (e.g., resource 2904 "foo" partially matches resource identifier "foobar"). 2906 o If the Jabber Identifier contains a resource identifier and there 2907 are no matching resources, but there are other connected resources 2908 associated with the node, then message chunks are further 2909 processed as if no resource is specified (see next item). For all 2910 other chunks, the host should return them to the sender with a 2911 type of "error" and an appropriate error code (503) and message. 2913 o If the Jabber Identifier contains only a node@host and there is at 2914 least one connected resource available for the node, the host 2915 should deliver the chunk to an appropriate resource based on the 2916 availability state, priority, and connect time of the connected 2917 resource(s). 2919 o If the Jabber Identifier contains only a node@host and there are 2920 no connected resources available for the node (e.g., an IM user is 2921 offline), the host may choose to store the chunk (usually only 2922 message and presence subscription chunks) on behalf of the node 2923 and deliver the chunk when a resource becomes available for that 2924 node. 2926 9.2 Availability Tracking 2928 A host is responsible for keeping track of who has been notified of 2929 availability for a resource, and for ensuring that all of those 2930 entities are notified when the resource becomes unavailable. 2932 9.3 Presence Probe 2934 Hosts may discover the presence of remote entities on behalf of a 2935 connected node by sending a presence chunk of type "probe". The 2936 remote host is responsible for responding to the presence probe only 2937 when (1) the probing entity has been allowed to access the probed 2938 entity's presence (e.g., by server rules or user subscriptions) and 2939 (2) the probed entity is available. The probing entity's host then 2940 informs the probing entity of the probed entity's last known 2941 available presence (for all of the probed entity's resources if 2942 applicable). 2944 9.4 Presence Broadcast 2946 When a node first becomes available, the host sends presence probes 2947 to any remote entities that are subscribed to that node's presence. 2948 The host then sends the node's initial presence chunk and any future 2949 presence changes to any subscribed entities. 2951 9.5 Supported Namespaces 2953 If an entity receives an iq chunk in a namespace it does not 2954 understand, the entity should return an iq chunk of type "error" with 2955 an appropriate error element (code 400, bad request). If an entity 2956 receives a message chunk without a body and a namespace it does not 2957 understand, it must ignore that chunk. If an entity receives a 2958 message or presence chunk that contains XML data in an extended 2959 namespace it does not understand, the portion of the chunk that is in 2960 the unknown namespace should be ignored. 2962 10. Security Considerations 2964 10.1 SSL 2966 Hosts can additionally support normal SSL [17] connections for added 2967 security on port 5223 for node-to-host communications and 5270 for 2968 host-to-host communications. 2970 10.2 Secure Identity and Encryption 2972 Nodes may optionally support signing and encrypting messages and 2973 presence by using the Public Key Infrastructure (e.g., PGP/GnuPG), 2974 with the encrypted or signed data sent in an element in the 2975 jabber:x:encrypted or jabber:x:signed namespace. (These are draft 2976 protocols and are not covered in this document.) 2978 The Jabber model specifically does not require trust in the remote 2979 hosts. Although there may be benefits to a "trusted host" model, 2980 direct node-to-node trust is already in use in the SMTP protocol and 2981 allows those who desire a higher level of security to use it without 2982 requiring the significant increase in complexity throughout the 2983 architecture required to implement a trusted host model. 2985 10.3 Node Connections 2987 The IP address and method of access of nodes are never made 2988 available, nor are any connections other than the original host 2989 connection required. This protects the node's host from direct 2990 attack or identification by third parties via a gateway. 2992 10.4 Presence Information 2994 Presence subscriptions are enforced by the node's host. Only the 2995 approved entities are able to discover a node's availability. 2997 10.5 Host-to-Host Communications 2999 There is no necessity for any given Jabber host to communicate with 3000 other Jabber hosts, and host-to-host communications may be disabled 3001 by the administrator of any given Jabber deployment. This is 3002 especially valuable in non-public environments such as a company 3003 intranet. 3005 For additional host-to-host security measures such as prevention of 3006 spoofing, see Section 8.2. 3008 11. Multi-User Chat 3010 In addition to one-to-one conversations between two people or 3011 entities, Jabber also enables multi-user chat environments similar to 3012 those of Internet Relay Chat. In Jabber these environments are 3013 variously called chat rooms or conference rooms, and utilize a 3014 special message type of "groupchat". Each room is identified as a 3015 node@host, specifically as room-name@conference-service, where 3016 "conference-service" is the hostname at which the conference service 3017 is running. Each participant in a room is identified as a node@host/ 3018 resource, specifically room-name@conference-service/nickname, where 3019 "nickname" is the nickname of the participant (which may or may not 3020 be the participant's actual username). 3022 Because multi-user chat is not usually considered part of the core 3023 functionality provided by an IM system, we have decided to describe 3024 it separately from the main body of this document, even though all 3025 XML data sent in order to provide multi-user chat functionality is 3026 fully compliant with the base protocols. The following descriptions 3027 are divided by "use case" to highlight how the Jabber protocols have 3028 been used to provide limited multi-user chat functionality. 3030 11.1 Entering a Room 3032 An IM user or other Jabber Entity becomes a participant in a room by 3033 entering the room. The user does this by sending presence to the 3034 room. 3036 User enters room: 3038 JABBER USER SENDS: 3039 3042 JABBER USER RECEIVES: 3043 3047 11.2 Sending a Message to All Participants 3049 A participant can send a message to all other participants in the 3050 room by sending a message of type "groupchat" to the room itself. 3051 The conference service is then responsible for reflecting that 3052 message out to all the participants with a type of "groupchat". 3054 Participant sends message to all participants: 3056 PARTICIPANT SENDS: 3057 3059 Hello world 3060 3062 EACH PARTICIPANT RECEIVES: 3063 3067 Hello room! 3068 3070 11.3 Sending a Message to A Selected Participant 3072 A participant can send a message to a specific other participant in 3073 the room by sending a message of type other than "groupchat" to that 3074 participant. 3076 Participant sends message to a selected participant: 3078 PARTICIPANT SENDS: 3079 3082 Hi 3083 3085 RECIPIENT RECEIVES: 3086 3090 Hi 3091 3093 11.4 Changing Nickname 3095 A participant can change his or her nickname in a room by sending 3096 updated presence information to the room. 3098 Participant sends nickname change: 3100 PARTICIPANT SENDS: 3101 3103 PARTICIPANT RECEIVES: 3104 3109 3113 11.5 Exiting a Room 3115 A participant exits a room by sending presence of type "unavailable" 3116 to the room. 3118 User exits room: 3120 PARTICIPANT SENDS: 3121 3125 PARTICIPANT RECEIVES: 3126 3131 12. IMPP and Interoperability Notes 3133 12.1 Requirements Conformance 3135 The Jabber protocols presented herein are in near conformance to RFC 3136 2778 [18] and RFC 2779 [19]. Notable differences are: 3138 o RFC 2779, section 2.5 - Complete conformance with these 3139 requirements can be obtained by using the public key 3140 infrastructure via applications such as PGP or GnuPG. 3142 o RFC 2779, section 4.1, paragraph 10 - all MIME data is delivered 3143 via HTTP. 3145 Note: the Jabber protocols have been in evolution for approximately 3146 four years as of the date of this memo, thus they have not been 3147 designed in response to RFCs 2778 and 2779. 3149 12.2 Interoperability 3151 Jabber provides interoperability with certain non-Jabber instant 3152 messaging networks, but at the cost of reverse engineering each non- 3153 Jabber instant messaging protocol and operating a host-based gateway 3154 to that protocol. The form of interoperability that Jabber offers 3155 also requires the Jabber user to have a valid account on each non- 3156 Jabber instant messaging network. It is recognized that this form of 3157 interoperability is sub-optimal, and the Jabber community looks 3158 forward to assisting in the development of standards-based 3159 interoperability. 3161 13. Known Deficiencies 3163 13.1 Further Definition of Transport Layer 3165 The transport layer, currently implemented via XML streams, needs to 3166 be better defined and even further separated from the data to be 3167 transported. Ideally, any stateful, namespace-aware transport layer 3168 should be able to transport the common data types defined in the 3169 Jabber protocols. 3171 Because Jabber was designed as a lightweight transport layer for 3172 routing instant messages, presence, and related information, quality 3173 of service (QoS) did not rank high in the priorities of its 3174 designers. In addition, features such as multi-hop routing and end- 3175 to-end store and forward of messages would be desirable in large- 3176 scale or mission-critical implementations of the Jabber protocols. 3178 The Jabber protocols were built from the ground up to use XML, and 3179 the primary focus was on the exchange of small chunks of structured 3180 information. For this reason, the transport of binary payloads was 3181 not a priority and currently is supported only by sending them out of 3182 band (e.g., through HTTP PUTs to and GETs from a DAV server). Robust 3183 support for binary payloads would be desirable. 3185 The current method of separating discrete semantic units from the 3186 stream in Jabber is elegant because all the necessary framing 3187 information is inherent in the XML; it makes framing entirely 3188 independent of the underlying transport layer. However, it has 3189 significant performance disadvantages, since it requires a Jabber 3190 Entity to parse the XML for the entire XML chunk in order to extract 3191 a subset of the information from it. A less resource-intensive 3192 framing mechanism may be desirable. 3194 13.2 More Complete Namespace Support 3196 At present the Jabber protocols comply only with a subset of the XML 3197 namespace specification and do not offer the full flexibility of XML 3198 namespaces. In addition it would be beneficial for the Jabber 3199 protocols to enable types of availability other than those defined 3200 for the element through a properly namespaced sub-element of 3201 the presence data type. 3203 13.3 More Flexible Routing 3205 Existing Jabber implementations contain some hardcoded rules (based 3206 on and most recent connection time) for the routing of 3207 XML chunks to the resources associated with a node. A more flexible 3208 approach to routing would be desirable. In addition, full 3209 conformance with RFC 2396 [7] would be valuable, perhaps by 3210 prepending the string "jabber:" to the Jabber Identifier, resulting 3211 in a URI of the form "jabber:node@host/resource". 3213 13.4 More Robust Security 3215 While the current Jabber protocols use Secure Sockets Layer to 3216 provide transport-level encryption and node-level encryption (PGP/ 3217 GPG) for end-to-end message encryption, it would also be desirable to 3218 support network-wide authentication and trust based on the Public Key 3219 Infrastructure. This might be pursued through a Certificate 3220 Authority model, a Web of Trust model, or some combination of the 3221 two. In addition, XML encryption would be a valuable addition to the 3222 Jabber protocols. 3224 13.5 Improved Subscriptions Model 3226 The current specification overloads the presence element in order to 3227 provide a mechanism for subscription requests and responses. It is 3228 recognized that this solution is sub-optimal and a future protocol 3229 revision will address this deficiency by providing subscription 3230 functionality through the iq element and an appropriate namespace. 3231 Even further, a generic mechanism for publication and subscription 3232 (pub/sub) and the management of access control lists (ACLs) would be 3233 quite beneficial, perhaps on a model similar to the Presence and 3234 Availability Management [20] specfication. 3236 14. Future Specifications and Submissions 3238 Future specifications and submissions related to the Jabber protocols 3239 will most likely focus on a clear separation between the different 3240 protocol levels (e.g., routing, data transport, and messaging/ 3241 presence), as well as next-generation protocol enhancements that 3242 address the deficiencies described in the previous section. 3244 References 3246 [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, 3247 August 1982. 3249 [2] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. 3250 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 3251 2068, January 1997, . 3253 [3] World Wide Web Consortium, "HyperText Markup Language", January 3254 2000, . 3256 [4] World Wide Web Consortium, "Extensible Markup Language (XML) 3257 1.0 (Second Edition)", W3C xml, October 2000, . 3260 [5] XML-RPC.com, "XML-RPC", May 2001, . 3262 [6] World Wide Web Consortium, "SOAP", May 2000, . 3265 [7] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 3266 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 3267 1998, . 3269 [8] Braden, R., "Requirements for Internet Hosts - Communication 3270 Layers", STD 3, RFC 1122, October 1989. 3272 [9] Jeremie Miller, et al., "The jabberd Project", January 1998, 3273 . 3275 [10] Bradner, S., "Key words for use in RFCs to Indicate Requirement 3276 Levels", BCP 14, RFC 2119, March 1997. 3278 [11] University of Southern California, "Transmission Control 3279 Protocol", RFC 793, September 1981, . 3282 [12] Internet Assigned Numbers Authority, "Internet Assigned Numbers 3283 Authority", January 1998, . 3285 [13] World Wide Web Consortium, "Namespaces in XML", W3C xml-names, 3286 January 1999, . 3289 [14] World Wide Web Consortium, "Secure Hash Algorithm - Version 3290 1.0", October 1997, . 3293 [15] International Organization for Standardization, "Data elements 3294 and interchange formats - Information interchange - 3295 Representation of dates and times", ISO Standard 8601, June 3296 1988. 3298 [16] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the 3299 location of services (DNS SRV)", RFC 2052, October 1996. 3301 [17] Freier, A., Karlton, P. and P. Kocher, "The SSL Protocol - 3302 Version 3.0", November 1996, . 3305 [18] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and 3306 Instant Messaging", RFC 2778, February 2000, . 3309 [19] Day, M., Aggarwal, S., Mohr, G. and J. Vincent, "A Model for 3310 Presence and Instant Messaging", RFC 2779, February 2000, 3311 . 3313 [20] PAM Forum, "Presence and Availability Management", September 3314 2001, . 3316 Authors' Addresses 3318 Jeremie Miller 3319 Jabber Software Foundation 3320 1899 Wynkoop Street, Suite 600 3321 Denver, CO 80202 3322 US 3324 EMail: jeremie@jabber.org 3325 URI: http://www.jabber.org/ 3327 Peter Saint-Andre 3328 Jabber Software Foundation 3329 1899 Wynkoop Street, Suite 600 3330 Denver, CO 80202 3331 US 3333 EMail: stpeter@jabber.org 3334 URI: http://www.jabber.org/ 3335 James Barry 3336 Jabber, Inc. 3337 1899 Wynkoop Street, Suite 600 3338 Denver, CO 80202 3339 US 3341 EMail: jmbarry@jabber.com 3342 URI: http://www.jabber.com/ 3344 Appendix A. The element 3346 A standard error element is used for failed processing of XML chunks. 3347 This element is a child of the failed element. 3349 A.1 Attributes 3351 o code - a numerical error code corresponding to a specific error 3352 description. The numerical codes used in Jabber are nearly 3353 synchronous with HTTP error codes: 3355 * 302 (Redirect) - Whereas the HTTP spec contains eight different 3356 codes for redirection, Jabber contains only one (which is 3357 intended to stand for any redirection error). However, Jabber 3358 code 302 is being reserved for future functionality and is not 3359 implemented at this time. 3361 * 400 (Bad Request) - Jabber code 400 is used to inform a sender 3362 that a request could not be understood by the recipient because 3363 it cannot be understood. This might be generated when, for 3364 example, a Jabber Entity sends a message that does not have a 3365 'to' attribute, or when a node attempts to authenticate without 3366 sending a username. 3368 * 401 (Unauthorized) - Jabber code 401 is used to inform Jabber 3369 nodes that they have provided incorrect authorization 3370 information, e.g., an incorrect password or unknown username 3371 when attempting to authenticate with a Jabber host. 3373 * 402 (Payment Required) - Jabber code 402 is being reserved for 3374 future use and is not in use at this time. 3376 * 403 (Forbidden) - Jabber code 403 is used to inform a Jabber 3377 Entity that the its request was understood but that the 3378 recipient is refusing to fulfill it, e.g., if a node attempts 3379 to set information (e.g., preferences or profile information) 3380 associated with another node. 3382 * 404 (Not Found) - Jabber code 404 is used to inform a sender 3383 that no recipient was found matching the Jabber Identifier to 3384 which an XML chunk was sent, e.g., if a sender has attempted to 3385 send a message to a Jabber Identifier that does not exist. 3386 (Note: if the host of the intended recipient cannot be reached, 3387 an error code from the 500 series will be sent). 3389 * 405 (Not Allowed) - Jabber code 405 is used when the action 3390 requested is not allowed for the Jabber Identifier identified 3391 by the 'from' address, e.g., if a node attempts to set the time 3392 or version of a Jabber host. 3394 * 406 (Not Acceptable) - Jabber code 406 is used when an XML 3395 chunk is for some reason not acceptable to a host or other 3396 Jabber Entity. This might be generated when, for example, a 3397 node attempts to register with a host using an empty password. 3399 * 407 (Registration Required) - Jabber code 407 is used when a 3400 message or request is sent to a service that requires prior 3401 registration, e.g., if a node attempts to send a message 3402 through a gateway to a non-Jabber instant messaging system 3403 without having first registered with that gateway. 3405 * 408 (Request Timeout) - Jabber code 408 is returned when a 3406 recipient does not produce a response within the time that the 3407 sender was prepared to wait. 3409 * 500 (Internal Server Error) - Jabber code 500 is used when a 3410 Jabber host or service encounters an unexpected condition which 3411 prevents it from handling an XML chunk from a sender, e.g., if 3412 an authentication request is not handled by a host because the 3413 password could not be retrieved or if password storage fails 3414 when a node attempts to register with a host. 3416 * 501 (Not Implemented) - Jabber code 501 is used when the 3417 recipient does not support the functionality being requested by 3418 a sender, e.g., if a node sends an authentication request that 3419 does not contain the elements defined by at least one of the 3420 accepted authentication methods or when a node attempts to 3421 register with a host that does not allow registration. 3423 * 502 (Remote Server Error) - Jabber code 502 is used when 3424 delivery of an XML chunk fails because of an inability to reach 3425 the intended remote host or service. Specific examples of why 3426 this code is generated include a failure to connect to the 3427 remote host or resolve its hostname. 3429 * 503 (Service Unavailable) - Jabber code 503 is used when a 3430 sender requests a service that a recipient is currently unable 3431 to handle, usually for temporary reasons, e.g., if a sender 3432 attempts to send a message to a recipient that is offline but 3433 the recipient's host is not running an offline message storage 3434 service. 3436 * 504 (Remote Server Timeout) - Jabber code 504 is used when 3437 attempts to contact a remote host timeout, e.g., if an 3438 incorrect hostname is specified. 3440 A.2 Examples 3442 Message error: 3444 3448 Sleep dwell upon thine eyes 3449 Not Found 3450 3452 IQ Error: 3454 3459 3460 juliet 3461 juliet@somehost 3462 r0m30 3463 3464 Remote Server Error 3465 3467 Appendix B. Acknowledgments 3469 Thanks are due to all members of the Jabber Software Foundation. The 3470 following individuals have provided especially valuable assistance 3471 with the development of the Jabber protocols and/or comments on this 3472 document: 3474 o John Hager 3476 o Michael Lin 3478 o Peter Millard 3480 o Julian Missig 3482 o Thomas Muldowney 3484 o Iain Shigeoka 3486 o Dave Smith 3488 o Daniel Veillard 3490 o David Waite 3492 Full Copyright Statement 3494 Copyright (C) The Internet Society (2002). All Rights Reserved. 3496 This document and translations of it may be copied and furnished to 3497 others, and derivative works that comment on or otherwise explain it 3498 or assist in its implementation may be prepared, copied, published 3499 and distributed, in whole or in part, without restriction of any 3500 kind, provided that the above copyright notice and this paragraph are 3501 included on all such copies and derivative works. However, this 3502 document itself may not be modified in any way, such as by removing 3503 the copyright notice or references to the Internet Society or other 3504 Internet organizations, except as needed for the purpose of 3505 developing Internet standards in which case the procedures for 3506 copyrights defined in the Internet Standards process must be 3507 followed, or as required to translate it into languages other than 3508 English. 3510 The limited permissions granted above are perpetual and will not be 3511 revoked by the Internet Society or its successors or assigns. 3513 This document and the information contained herein is provided on an 3514 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3515 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 3516 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 3517 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3518 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3520 Acknowledgement 3522 Funding for the RFC Editor function is currently provided by the 3523 Internet Society.