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.