idnits 2.17.1
draft-ietf-xmpp-core-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 separate sections for Informative/Normative
References. All references will be assumed normative when checking for
downward references.
** There are 21 instances of too long lines in the document, the longest
one being 6 characters in excess of 72.
== There are 3 instances of lines with non-RFC2606-compliant FQDNs in the
document.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
== The document seems to lack the recommended RFC 2119 boilerplate, even if
it appears to use RFC 2119 keywords.
(The document does seem to have the reference to RFC 2119 which the
ID-Checklist requires).
-- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not
defined in RFC 2119. If it is intended as a requirements expression, it
should be rewritten using one of the combinations defined in RFC 2119;
otherwise it should not be all-uppercase.
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (December 06, 2002) is 7810 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 370, but not defined
-- Possible downref: Non-RFC (?) normative reference: ref. '1'
== Outdated reference: A later version (-22) exists of draft-ietf-xmpp-im-00
** Downref: Normative reference to an Informational RFC: RFC 2779 (ref. '3')
** Obsolete normative reference: RFC 793 (ref. '5') (Obsoleted by RFC 9293)
-- Possible downref: Non-RFC (?) normative reference: ref. '6'
** Obsolete normative reference: RFC 2396 (ref. '7') (Obsoleted by RFC 3986)
** Downref: Normative reference to an Unknown state RFC: RFC 952 (ref. '8')
** Obsolete normative reference: RFC 2222 (ref. '10') (Obsoleted by RFC
4422, RFC 4752)
-- Possible downref: Non-RFC (?) normative reference: ref. '11'
** Obsolete normative reference: RFC 3066 (ref. '12') (Obsoleted by RFC
4646, RFC 4647)
** Obsolete normative reference: RFC 2052 (ref. '13') (Obsoleted by RFC
2782)
** Obsolete normative reference: RFC 2078 (ref. '15') (Obsoleted by RFC
2743)
Summary: 11 errors (**), 0 flaws (~~), 6 warnings (==), 6 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: June 6, 2003 Jabber Software Foundation
5 December 06, 2002
7 XMPP Core
8 draft-ietf-xmpp-core-00
10 Status of this Memo
12 This document is an Internet-Draft and is in full conformance with
13 all provisions of Section 10 of RFC2026.
15 Internet-Drafts are working documents of the Internet Engineering
16 Task Force (IETF), its areas, and its working groups. Note that
17 other groups may also distribute working documents as Internet-
18 Drafts.
20 Internet-Drafts are draft documents valid for a maximum of six months
21 and may be updated, replaced, or obsoleted by other documents at any
22 time. It is inappropriate to use Internet-Drafts as reference
23 material or to cite them other than as "work in progress."
25 The list of current Internet-Drafts can be accessed at http://
26 www.ietf.org/ietf/1id-abstracts.txt.
28 The list of Internet-Draft Shadow Directories can be accessed at
29 http://www.ietf.org/shadow.html.
31 This Internet-Draft will expire on June 6, 2003.
33 Copyright Notice
35 Copyright (C) The Internet Society (2002). All Rights Reserved.
37 Abstract
39 This document describes the core features of the eXtensible Messaging
40 and Presence Protocol (XMPP), which is used by the servers, clients,
41 and other applications that comprise the Jabber network.
43 Table of Contents
45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
46 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
47 1.2 Conventions Used in this Document . . . . . . . . . . . . . 4
48 1.3 Discussion Venue . . . . . . . . . . . . . . . . . . . . . . 4
49 1.4 Intellectual Property Notice . . . . . . . . . . . . . . . . 4
50 2. Generalized Architecture . . . . . . . . . . . . . . . . . . 5
51 2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
52 2.2 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
53 2.3 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
54 2.4 Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . 6
55 2.5 Network . . . . . . . . . . . . . . . . . . . . . . . . . . 6
56 3. Addressing Scheme . . . . . . . . . . . . . . . . . . . . . 7
57 3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7
58 3.2 Domain Identifier . . . . . . . . . . . . . . . . . . . . . 7
59 3.3 Node Identifier . . . . . . . . . . . . . . . . . . . . . . 7
60 3.4 Resource Identifier . . . . . . . . . . . . . . . . . . . . 8
61 4. XML Streams . . . . . . . . . . . . . . . . . . . . . . . . 9
62 4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 9
63 4.2 Restrictions . . . . . . . . . . . . . . . . . . . . . . . . 10
64 4.3 Stream Attributes . . . . . . . . . . . . . . . . . . . . . 10
65 4.4 Namespace Declarations . . . . . . . . . . . . . . . . . . . 11
66 4.5 Stream Features . . . . . . . . . . . . . . . . . . . . . . 12
67 4.6 Stream Errors . . . . . . . . . . . . . . . . . . . . . . . 13
68 4.7 Simple Streams Example . . . . . . . . . . . . . . . . . . . 13
69 5. Stream Authentication . . . . . . . . . . . . . . . . . . . 16
70 5.1 SASL Authentication . . . . . . . . . . . . . . . . . . . . 16
71 5.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 16
72 5.1.2 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 17
73 5.2 Dialback Authentication . . . . . . . . . . . . . . . . . . 19
74 5.2.1 Dialback Protocol . . . . . . . . . . . . . . . . . . . . . 21
75 6. XML Stanzas . . . . . . . . . . . . . . . . . . . . . . . . 25
76 6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 25
77 6.2 Common Attributes . . . . . . . . . . . . . . . . . . . . . 25
78 6.2.1 to . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
79 6.2.2 from . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
80 6.2.3 id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
81 6.2.4 type . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
82 6.2.5 xml:lang . . . . . . . . . . . . . . . . . . . . . . . . . . 26
83 6.3 Message Stanzas . . . . . . . . . . . . . . . . . . . . . . 26
84 6.3.1 Types of Message . . . . . . . . . . . . . . . . . . . . . . 26
85 6.3.2 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 27
86 6.4 Presence Stanzas . . . . . . . . . . . . . . . . . . . . . . 28
87 6.4.1 Types of Presence . . . . . . . . . . . . . . . . . . . . . 28
88 6.4.2 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 29
89 6.5 IQ Stanzas . . . . . . . . . . . . . . . . . . . . . . . . . 30
90 6.5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 30
91 6.5.2 Types of IQ . . . . . . . . . . . . . . . . . . . . . . . . 30
92 6.5.3 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 31
93 6.6 Extended Namespaces . . . . . . . . . . . . . . . . . . . . 31
94 7. XML Usage within XMPP . . . . . . . . . . . . . . . . . . . 33
95 7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 33
96 7.2 Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . 33
97 7.3 Validation . . . . . . . . . . . . . . . . . . . . . . . . . 33
98 7.4 Character Encodings . . . . . . . . . . . . . . . . . . . . 34
99 7.5 Inclusion of Text Declaration . . . . . . . . . . . . . . . 34
100 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 35
101 9. Internationalization Considerations . . . . . . . . . . . . 36
102 10. Security Considerations . . . . . . . . . . . . . . . . . . 37
103 10.1 Client-to-Server Communications . . . . . . . . . . . . . . 37
104 10.2 Server-to-Server Communications . . . . . . . . . . . . . . 37
105 10.3 Minimum Security Mechanisms . . . . . . . . . . . . . . . . 37
106 10.4 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . 37
107 References . . . . . . . . . . . . . . . . . . . . . . . . . 38
108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 39
109 A. Standard Error Codes . . . . . . . . . . . . . . . . . . . . 40
110 B. Formal Definitions . . . . . . . . . . . . . . . . . . . . . 42
111 B.1 streams namespace . . . . . . . . . . . . . . . . . . . . . 42
112 B.1.1 DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
113 B.1.2 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
114 B.2 SASL namespace . . . . . . . . . . . . . . . . . . . . . . . 43
115 B.2.1 DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
116 B.2.2 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
117 B.3 jabber:client namespace . . . . . . . . . . . . . . . . . . 45
118 B.3.1 DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
119 B.3.2 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
120 B.4 jabber:server namespace . . . . . . . . . . . . . . . . . . 49
121 B.4.1 DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
122 B.4.2 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
123 C. Revision History . . . . . . . . . . . . . . . . . . . . . . 54
124 C.1 Changes from draft-miller-xmpp-core-02 . . . . . . . . . . . 54
125 Full Copyright Statement . . . . . . . . . . . . . . . . . . 56
127 1. Introduction
129 1.1 Overview
131 The eXtensible Messaging and Presence Protocol (XMPP) is an open XML
132 [1] protocol for near-real-time messaging and presence. The protocol
133 was developed originally within the Jabber community starting in
134 1998, and since 2001 has continued to evolve under the auspices of
135 the Jabber Software Foundation and now the XMPP WG. Currently, there
136 exist multiple implementations of the protocol, mostly offered under
137 the name of Jabber. In addition, there are countless deployments of
138 these implementations, which provide instant messaging (IM) and
139 presence services at and among thousands of domains to a user base
140 that is estimated at over one million end users. The current
141 document defines the core constituents of XMPP; XMPP IM [2] defines
142 the extensions necessary to provide basic instant messaging and
143 presence functionality that addresses the requirements defined in RFC
144 2779 [3].
146 1.2 Conventions Used in this Document
148 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
149 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
150 "OPTIONAL" in this document are to be interpreted as described in RFC
151 2119 [4].
153 1.3 Discussion Venue
155 The authors welcome discussion and comments related to the topics
156 presented in this document, preferably on the "xmppwg@jabber.org"
157 mailing list (archives and subscription information are available at
158 http://www.jabber.org/cgi-bin/mailman/listinfo/xmppwg/).
160 1.4 Intellectual Property Notice
162 This document is in full compliance with all provisions of Section 10
163 of RFC 2026. Parts of this specification use the term "jabber" for
164 identifying namespaces and other protocol syntax. Jabber[tm] is a
165 registered trademark of Jabber, Inc. Jabber, Inc. grants permission
166 to the IETF for use of the Jabber trademark in association with this
167 specification and its successors, if any.
169 2. Generalized Architecture
171 2.1 Overview
173 Although XMPP is not wedded to any specific network architecture, to
174 this point it has usually been implemented via a typical client-
175 server architecture, wherein a client utilizing XMPP accesses a
176 server over a TCP [5] socket.
178 The following diagram provides a high-level overview of this
179 architecture (where "-" represents communications that use XMPP and
180 "=" represents communications that use any other protocol).
182 C1 - S1 - S2 - C3
183 / \
184 C2 - G1 = FN1 = FC1
186 The symbols are as follows:
188 o C1, C2, C3 -- XMPP clients
190 o S1, S2 -- XMPP servers
192 o G1 -- A gateway that translates between XMPP and the protocol(s)
193 used on a foreign messaging network
195 o FN1 -- A foreign messaging network
197 o FC1 -- A client on a foreign messaging network
199 2.2 Server
201 A server acts as an intelligent abstraction layer for XMPP
202 communications. Its primary responsibilities are to manage
203 connections from or sessions for other entities (in the form of XML
204 streams to and from authorized clients and other servers) and to
205 route appropriately-addressed XML data "stanzas" among such entities
206 over XML streams. Most XMPP-compliant servers also assume
207 responsibility for the storage of data that is used by clients (e.g.,
208 the contact list for each IM user); in this case, the XML data is
209 processed directly by the server itself on behalf of the client and
210 is not routed to another entity. Compliant server implementations
211 MUST ensure in-order processing of XML stanzas received from
212 connected clients, servers, and services.
214 2.3 Client
216 Most clients connect directly to a server over a TCP socket and use
217 XMPP to take full advantage of the functionality provided by a server
218 and any associated services. (Clients on foreign messaging networks
219 may also be part of the architecture, made accessable via a gateway
220 to that network.) Multiple resources (e.g., devices or locations) MAY
221 connect simultaneously to a server on behalf of each authorized
222 client, with each resource connecting over a discrete TCP socket and
223 differentiated by the resource identifier of a Jabber ID (Section 3)
224 (e.g., user@domain/home vs. user@domain/work). The port assigned by
225 the IANA [6] for connections between a Jabber client and a Jabber
226 server is 5222. For further details about client-to-server
227 communications for the purpose of instant messaging and presence,
228 refer to XMPP IM [2].
230 2.4 Gateway
232 A gateway is a special-purpose server-side service whose primary
233 function is to translate XMPP into the protocol(s) of another
234 messaging system, as well as to translate the return data back into
235 XMPP. Examples are gateways to Internet Relay Chat (IRC), Short
236 Message Service (SMS), SMTP, and foreign instant messaging networks
237 such as Yahoo!, MSN, ICQ, and AIM. Communications between gateways
238 and servers, and between gateways and the foreign messaging system,
239 are not defined in this document.
241 2.5 Network
243 Because each server is identified by a network address (typically a
244 DNS hostname) and because server-to-server communications are a
245 simple extension of the client-to-server protocol, in practice the
246 system consists of a network of servers that inter-communicate. Thus
247 user-a@domain1 is able to exchange messages, presence, and other
248 information with user-b@domain2. This pattern is familiar from
249 messaging protocols (such as SMTP) that make use of network
250 addressing standards. The usual method for providing a connection
251 between two servers is to open a TCP socket on the IANA-assigned port
252 5269 and to negotiate a connection using the Dialback Protocol
253 (Section 5.2) as defined in this document.
255 3. Addressing Scheme
257 3.1 Overview
259 Any entity that can be considered a network endpoint (i.e., an ID on
260 the network) and that can communicate using XMPP is considered a
261 Jabber Entity. All such entities are uniquely addressable in a form
262 that is consistent with RFC 2396 [7]. In particular, a valid Jabber
263 Identifier (JID) contains a set of ordered elements formed of a
264 domain identifier, node identifier, and resource identifier in the
265 following format: [node@]domain[/resource].
267 All JIDs are based on the foregoing structure. The most common use
268 of this structure is to identify an IM user, the server to which the
269 user connects, and the user's active session or connection (e.g., a
270 specific client) in the form of user@domain/resource. However, node
271 types other than clients are possible; for example, a specific chat
272 room is offered by a multi-user chat service is addressed as
273 room@service, where "room" is the name of the chat room and "service"
274 is the hostname of the multi-user chat service.
276 3.2 Domain Identifier
278 The domain identifier is the primary identifier and is the only
279 REQUIRED element of a JID (a simple domain identifier is a valid
280 JID). It usually represents the network gateway or "primary" server
281 to which other entities connect for XML routing and data management
282 capabilities. However, the entity referenced by a domain identifier
283 is not always a server, and may be a service that is addressed as a
284 subdomain of a server and that provides functionality above and
285 beyond the capabilities of a server (a multi-user chat service, a
286 user directory, a gateway to a foreign messaging system, etc.).
288 The domain identifier for every server or service that will
289 communicate over a network SHOULD resolve to a Fully Qualified Domain
290 Name, and a domain identifier SHOULD conform to RRC 952 [8] and REF
291 1123 [9]. Specifically, a domain identifier is case-insensitive 7-
292 bit ASCII and is limited to 255 bytes.
294 3.3 Node Identifier
296 The node identifier is an optional secondary identifier. It usually
297 represents the entity requesting and using network access provided by
298 the server or gateway (e.g., a client), although it can also
299 represent other kinds of entities (e.g., a multi-user chat room
300 associated with a multi-user chat service). The entity represented
301 by a node identifier is addressed within the context of a specific
302 domain (e.g., user@domain). Node identifiers are restricted to 256
303 bytes. A node identifier MAY contain any Unicode character higher
304 than #x20 with the exception of the following:
306 o #x22 (")
308 o #x26 (&)
310 o #x27 (')
312 o #x3A (:)
314 o #x3C (<)
316 o #x3E (>)
318 o #x40 (@)
320 o #x7F (del)
322 o #xFFFE (BOM)
324 o #xFFFF (BOM)
326 Case is preserved, but comparisons are made in case-normalized
327 canonical form.
329 3.4 Resource Identifier
331 The resource identifer is an optional third identifier. It
332 represents a specific session, connection (e.g., a device or
333 location), or object (e.g., a participant in a multi-user chat room)
334 belonging to the entity associated with a node identifier. An entity
335 may maintain multiple resources simultaneously. A resource
336 identifier is restricted to 256 bytes in length. A resource
337 identifier MAY include any Unicode character greater than #x20,
338 except #xFFFE and #xFFFF; if the Unicode character is a valid XML
339 character as defined in Section 2.2 of the XML specification [1], it
340 MUST be suitably escaped for inclusion within an XML stream.
341 Resource identifiers are case sensitive.
343 4. XML Streams
345 4.1 Overview
347 Two fundamental concepts make possible the rapid, asynchronous
348 exchange of relatively small payloads of structured information
349 between presence-aware entities: XML streams and, as a result,
350 discrete units of structured information that are referred to as "XML
351 stanzas". (Note: in this overview we use the example of
352 communications between a client and server; however XML streams are
353 more generalized and may be used for communications from server to
354 server and from service to server as well.)
356 In order to connect to a server, a client must initiate an XML stream
357 by sending a tag to the server, optionally preceded by a
358 text declaration specifying the XML version supported and the
359 character encoding. A compliant entity MUST accept any namespace
360 prefix on the element; however, for historical reasons some
361 entities MAY accept only a 'stream' prefix, resulting in use of a
362 element. The server SHOULD then reply with a second
363 XML stream back to the client, again optionally preceded by a text
364 declaration.
366 Within the context of an XML stream, a sender is able to send a
367 discrete semantic unit of structured information to any recipient.
368 This unit of structured information is a well-balanced XML stanza,
369 such as a message, presence, or IQ stanza (a stanza of an XML
370 document is said to be well-balanced if it matches production [43]
371 content of the XML specification [1]). These stanzas exist at the
372 direct child level (depth=1) of the root element. The
373 start of any XML stanza is unambiguously denoted by the element start
374 tag at depth=1 (e.g., ), and the end of any XML stanza is
375 unambiguously denoted by the corresponding close tag at depth=1
376 (e.g., ). Each XML stanza MAY contain child elements or
377 CDATA sections as necessary in order to convey the desired
378 information from the sender to the recipient. The session is closed
379 at the client's request by sending a closing tag to the
380 server.
382 Thus a client's session with a server can be seen as two open-ended
383 XML documents that are built up through the accumulation of the XML
384 stanzas that are sent over the course of the session (one from the
385 client to the server and one from the server to the client), and the
386 root element can be considered the document entity for
387 those streams. In essence, then, an XML stream acts as an envelope
388 for all the XML stanzas sent during a session. We can represent this
389 graphically as follows:
391 |-------------------|
392 | |
393 |-------------------|
394 | |
395 | |
396 | |
397 |-------------------|
398 | |
399 | |
400 | |
401 |-------------------|
402 | |
403 | |
404 | |
405 |-------------------|
406 | |
407 |-------------------|
409 4.2 Restrictions
411 XML streams are used to transport a subset of XML. Specifically, XML
412 streams SHOULD NOT contain processing instructions, non-predefined
413 entities (as defined in Section 4.6 of the XML specification [1]),
414 comments, or DTDs. Any such XML data SHOULD be ignored.
416 4.3 Stream Attributes
418 The attributes of the stream element are as follows (we now
419 generalize the endpoints by using the terms "initiating entity" and
420 "receiving entity"):
422 o to -- The 'to' attribute SHOULD be used only in the XML stream
423 from the initiating entity to the receiving entity, and MUST be
424 set to the JID of the receiving entity. There SHOULD be no 'to'
425 attribute set in the XML stream by which the receiving entity
426 replies to the initiating entity; however, if a 'to' attribute is
427 included, it SHOULD be ignored by the receiving entity.
429 o from -- The 'from' attribute SHOULD be used only in the XML stream
430 from the receiving entity to the initiating entity, and MUST be
431 set to the JID of the receiving entity granting access to the
432 initiating entity. There SHOULD be no 'from' attribute on the XML
433 stream sent from the initiating entity to the receiving entity;
434 however, if a 'from' attribute is included, it SHOULD be ignored
435 by the receiving entity.
437 o id -- The 'id' attribute SHOULD be used only in the XML stream
438 from the receiving entity to the initiating entity. This
439 attribute is a unique identifier created by the receiving entity
440 to function as a session key for the initiating entity's session
441 with the receiving entity. There SHOULD be no 'id' attribute on
442 the XML stream sent from the initiating entity to the receiving
443 entity; however, if an 'id' attribute is included, it SHOULD be
444 ignored by the receiving entity. The 'id' attribute is of type ID
445 as defined in section 3.3.1 of the XML specification [1] and
446 therefore MUST match the Name production as defined in section 2.3
447 of the XML specification [1]. Validity contraints on names within
448 XML documents (but not XML streams) are defined in the XML
449 specification [1]; however, because the stream in one direction
450 can be seen as a document that is built up over the length of a
451 session, at a minimum the value of an 'id' attribute MUST be
452 unique within that stream.
454 o version -- The 'version' attribute MAY be used in the XML stream
455 from the initiating entity to the receiving entity in order signal
456 compliance with the protocol defined herein; this is done by
457 setting the value of the attribute to "1.0". If the initiating
458 entity includes the version attribute, the receiving entity MUST
459 reciprocate by including the attribute in its response (if the
460 receiving entity supports XMPP 1.0).
462 We can summarize these values as follows:
464 | initiating to receiving | receiving to initiating
465 ------------------------------------------------------------
466 to | JID of receiver | ignored
467 from | ignored | JID of receiver
468 id | ignored | session key
469 version | signals XMPP 1.0 support | signals XMPP 1.0 support
471 4.4 Namespace Declarations
473 The stream element MAY also contain namespace declarations as defined
474 in the XML namespaces specification [11].
476 A stream namespace declaration is REQUIRED in both XML streams. A
477 compliant entity MUST accept any namespace prefix on the
478 element; however, for historical reasons some entities MAY accept
479 only a 'stream' prefix, resulting in use of a
480 element as the stream root. The value of the stream namespace MUST
481 be "http://etherx.jabber.org/streams".
483 A default namespace declaration ('xmlns') is REQUIRED and is used in
484 both XML streams in order to scope the allowable first-level children
485 of the root stream element for both streams. This namespace
486 declaration MUST be the same for the initiating stream and the
487 responding stream so that both streams are scoped consistently. The
488 default namespace declaration applies to the stream and all stanzas
489 sent within a stream.
491 XML streams function as containers for any XML stanzas sent
492 asynchronously between network endpoints. It should be possible to
493 scope an XML stream with any default namespace declaration, i.e., it
494 should be possible to send any properly-namespaced XML stanza over an
495 XML stream. A compliant implementation MUST support the following
496 two namespaces (for historical reasons, existing implementations MAY
497 support only these two default namespaces):
499 o jabber:client -- this default namespace is declared when the
500 stream is used for communications between a client and a server
502 o jabber:server -- this default namespace is declared when the
503 stream is used for communications between two servers
505 The jabber:client and jabber:server namespaces are nearly identical
506 but are used in different contexts (client-to-server communications
507 for jabber:client and server-to-server communications for
508 jabber:server). The only difference between the two is that the 'to'
509 and 'from' attributes are OPTIONAL on stanzas sent within
510 jabber:client, whereas they are REQUIRED on stanzas sent within
511 jabber:server. If a compliant implementation accepts a stream that
512 is scoped by the 'jabber:client' or 'jabber:server' namespace, it
513 MUST support all three core stanza types (message, presence, and IQ)
514 as described herein and defined in the DTD and schema.
516 4.5 Stream Features
518 The root stream element MAY contain a features child element (e.g.,
519 if the stream namespace prefix is 'stream'). This
520 is used to communicate generic stream-level capabilities including
521 stream-level features that can be negotiated as the streams are set
522 up. If the initiating entity sends a "version='1.0'" attribute in
523 its initiating stream element, the receiving entity MUST send a
524 features child element to the initiating entity if there are any
525 capabilities that need to be advertised or features that can be
526 negotiated for the stream. Currently this is used for SASL and TLS
527 negotiation only, but it could be used for other negotiable features
528 in the future. Examples are shown under Stream Authentication
529 (Section 5) below.
531 4.6 Stream Errors
533 The root stream element MAY contain an error child element (e.g.,
534 if the stream namespace prefix is 'stream'). The
535 error child SHOULD be sent by a Jabber entity (usually a server
536 rather than a client) if it perceives that a stream-level error has
537 occurred. Examples include the sending of invalid XML, the shutdown
538 of a server, an internal server error such as the shutdown of a
539 session manager, and an attempt by a client to authenticate as the
540 same resource that is currently connected. If an error occurs at the
541 level of the stream, the entity (initiating entity or receiving
542 entity) that detects the error SHOULD send a stream error to the
543 other entity specifying why the streams are being closed and then
544 send a closing tag. XML of the following form is sent
545 within the context of an existing stream:
547
548 ...
549
550 Error message (e.g., "Invalid XML")
551
552
554 4.7 Simple Streams Example
556 The following is a simple stream-based session of a client on a
557 server (where the "C" lines are sent from the client to the server,
558 and the "S" lines are sent from the server to the client):
560 A simple session:
562 C:
563
568 S:
569
575 ... authentication ...
576 C:
577 C: Watson come here, I need you!
578 C:
579 S:
580 S: I'm on my way!
581 S:
582 C:
583 S:
585 These are in actuality a sending stream and a receiving stream, which
586 can be viewed a-chronologically as two XML documents:
588 C:
589
594 C:
595 C: Watson come here, I need you!
596 C:
597 C:
599 S:
600
606 S:
607 S: I'm on my way!
608 S:
609 S:
611 A session gone bad:
613 C:
614
619 S:
620
626 C: Bad XML, no closing body tag!
627 S: Invalid XML
628 S:
630 5. Stream Authentication
632 XMPP includes two methods for enforcing authentication at the level
633 of XML streams. When one entity is already known to another (i.e.,
634 there is an existing trust relationship between the entities such as
635 that established when a user registers with a server or an
636 administrator configures a server to trust a service), the preferred
637 method for authenticating streams between the two entities uses an
638 XMPP adaptation of the Simple Authentication and Security Layer
639 (SASL) [10]. When there is no existing trust relationship between
640 the two entities, such trust MAY be established based on existing
641 trust in DNS; the authentication method used when two such entities
642 are servers is the server dialback protocol that is native to XMPP.
643 Both of these methods are described in this section.
645 5.1 SASL Authentication
647 5.1.1 Overview
649 The Simple Authentication and Security Layer (SASL) provides a
650 generalized method for adding authentication support to connection-
651 based protocols. XMPP uses a generic XML namespace profile for SASL
652 that conforms to section 4 ("Profiling Requirements") of RFC 2222
653 [10] (the namespace identifier for this protocol is http://
654 www.iana.org/assignments/sasl-mechanisms). If an entity (client,
655 server, or service) is capable of authenticating by means of SASL, it
656 MUST include the agreed-upon SASL namespace within the opening root
657 stream tag it uses to initiate communications.
659 The following example shows the use of SASL in client authentication
660 with a server, for which the steps involved are as follows:
662 1. The client requests SASL authentication by including the
663 appropriate namespace declaration (xmlns:sasl='http://
664 www.iana.org/assignments/sasl-mechanisms') in the opening XML
665 stream header sent to the server.
667 2. The server includes the xmlns:sasl namespace declaration in the
668 XML stream header sent in reply to the client.
670 3. The server responds with a list of available SASL authentication
671 mechanisms, each of which is a element included as a
672 child within a container element that is sent as a
673 first-level child of the root element.
675 4. The client selects a mechanism by sending a element
676 to the server; this element MAY optionally contain character
677 data.
679 5. If necessary, the server challenges the client by sending a
680 element to the client; this element MAY
681 optionally contain character data.
683 6. The client responds to challenge by sending a
684 element to the server; this element MAY optionally contain
685 character data.
687 7. If necessary, the server sends more challenges and the client
688 sends more responses.
690 This series of challenge/response pairs continues until one of three
691 things happens:
693 o The client aborts the handshake by sending a element
694 to the server.
696 o The server reports failure by sending a element to
697 the client.
699 o The server reports success by sending a element to
700 the client; this element MAY optionally contain character data.
702 Any character data contained within these elements MUST be encoded
703 using base64.
705 5.1.2 Example
707 The following example shows the data flow for a client authenticating
708 with a server using SASL.
710 Step 1: Client initiates stream to server:
712
718 Step 2: Server responds with a stream tag sent to the client:
720
726 Step 3: Server informs client of available authentication mechanisms:
728
729
730 DIGEST-MD5
731 PLAIN
732
733
735 Step 4: Client selects an authentication mechanism:
737
741 Step 5: Server sends a challenge to the client:
743
744 cmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIi
745 xxb3A9ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNz
746
748 Step 6: Client responds to the challenge:
750
751 dXNlcm5hbWU9InJvYiIscmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik
752 9BNk1HOXRFUUdtMmhoIixjbm9uY2U9Ik9BNk1IWGg2VnFUclJrIixuYz0w
753 MDAwMDAwMSxxb3A9YXV0aCxkaWdlc3QtdXJpPSJqYWJiZXIvY2F0YWNseX
754 NtLmN4IixyZXNwb25zZT1kMzg4ZGFkOTBkNGJiZDc2MGExNTIzMjFmMjE0
755 M2FmNyxjaGFyc2V0PXV0Zi04
756
758 Step 7: Server sends another challenge to the client:
760
761 cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA==
762
763 Step 8: Client responds to the challenge:
765
767 Step 9: Server informs client of successful authentication:
769
771 Step 9 (alt): Server informs client of failed authentication:
773
775 5.2 Dialback Authentication
777 XMPP includes a protocol-level method for verifying that a connection
778 between two servers can be trusted to some degree. The method is
779 called dialback and is used only within XML streams that are declared
780 under the "jabber:server" namespace.
782 The purpose of the dialback protocol is to make server spoofing more
783 difficult, and thus to make it more difficult to forge XML stanzas.
784 Dialback is not intended as a mechanism for securing or encrypting
785 the streams between servers, only for helping to prevent the spoofing
786 of a server and the sending of false data from it. Dialback is made
787 possible by the existence of DNS, since one server can verify that
788 another server which is connecting to it is authorized to represent a
789 given server on the Jabber network. All DNS hostname resolutions
790 MUST first resolve the hostname using an SRV [13] record of
791 _jabber._tcp.server. If the SRV lookup fails, the fallback is a
792 normal A lookup to determine the IP address, using the jabber-server
793 port of 5269 assigned by the Internet Assigned Numbers Authority [6].
795 Note that the method used to generate and verify the keys used in the
796 dialback protocol MUST take into account the hostnames being used,
797 along with a secret known only by the receiving server and the random
798 id per stream. Generating unique but verifiable keys is important to
799 prevent common man-in-the-middle attacks and server spoofing.
801 In the description that follows we use the following terminology:
803 o Originating Server -- the server that is attempting to establish a
804 connection between the two servers
806 o Receiving Server -- the server that is trying to authenticate that
807 the Originating Server represents the Jabber server which it
808 claims to be
810 o Authoritative Server -- the server which is given when a DNS
811 lookup is performed on the name that the Originating Server
812 initially gave; for simple environments this will be the
813 Originating Server, but it could be a separate machine in the
814 Originating Server's network
816 The following is a brief summary of the order of events in dialback:
818 1. Originating Server establishes a connection to Receiving Server.
820 2. Originating Server sends a 'key' value over the connection to
821 Receiving Server.
823 3. Receiving Server establishes a connection to Authoritative
824 Server.
826 4. Receiving Server sends the same 'key' value to Authoritative
827 Server.
829 5. Authoritative Server replies that key is valid or invalid.
831 6. Receiving Server tells Originating Server whether it is
832 authenticated or not.
834 We can represent this flow of events graphically as follows:
836 Originating Receiving
837 Server Server
838 ----------- ---------
839 | |
840 | establish connection |
841 | ----------------------> |
842 | |
843 | send stream header |
844 | ----------------------> |
845 | |
846 | establish connection |
847 | <---------------------- |
848 | |
849 | send stream header |
850 | <---------------------- |
851 | | Authoritative
852 | send dialback key | Server
853 | ----------------------> | -------------
854 | | |
855 | establish connection |
856 | ----------------------> |
857 | |
858 | send stream header |
859 | ----------------------> |
860 | |
861 | send stream header |
862 | <---------------------- |
863 | |
864 | send dialback key |
865 | ----------------------> |
866 | |
867 | validate dialback key |
868 | <---------------------- |
869 |
870 | report dialback result |
871 | <---------------------- |
872 | |
874 5.2.1 Dialback Protocol
876 The traffic sent between the servers is as follows:
878 1. Originating Server establishes connection to Receiving Server
880 2. Originating Server sends a stream header to Receiving Server
881 (the 'to' and 'from' attributes are NOT REQUIRED on the root
882 stream element):
884
889 Note: the value of the xmlns:db namespace declaration indicates
890 to Receiving Server that the Originating Server supports
891 dialback.
893 3. Receiving Server sends a stream header back to Originating
894 Server (the 'to' and 'from' attributes are NOT REQUIRED on the
895 root stream element):
897
903 4. Originating Server sends a dialback key to Receiving Server:
905
908 98AF014EDC0...
909
911 Note: this key is not examined by Receiving Server, since the
912 Receiving Server does not keep information about Originating
913 Server between sessions.
915 5. Receiving Server now establishes a connection back to
916 Originating Server, getting the Authoritative Server.
918 6. Receiving Server sends Authoritative Server a stream header (the
919 'to' and 'from' attributes are NOT REQUIRED on the root stream
920 element):
922
927 7. Authoritative Server sends Receiving Server a stream header:
929
935 8. Receiving Server sends Authoritative Server a stanza indicating
936 it wants Authoritative Server to verify a key:
938
942 98AF014EDC0...
943
945 Note: passed here are the hostnames, the original identifier
946 from Receiving Server's stream header to Originating Server in
947 step 2, and the key Originating Server gave Receiving Server in
948 step 3. Based on this information and shared secret information
949 within the 'Originating Server' network, the key is verified.
950 Any verifiable method can be used to generate the key.
952 9. Authoritative Server sends a stanza back to Receiving Server
953 verifying whether the key was valid or invalid:
955
961 or
963
969 10. Receiving Server informs Originating Server of the result:
971
976 Note: At this point the connection has either been validated via
977 a type='valid', or reported as invalid. Once the connection is
978 validated, data can be sent by the Originating Server and read
979 by the Receiving Server; before that, all data stanzas sent to
980 Receiving Server SHOULD be dropped. As a final guard against
981 domain spoofing, the Receiving Server MUST verify that all XML
982 stanzas received from the Originating Server include a 'from'
983 attribute and that the value of that attribute includes the
984 validated domain. In addition, all XML stanzas MUST include a
985 'to' attribute.
987 6. XML Stanzas
989 6.1 Overview
991 There are three core data elements for XMPP communications: , , and . These elements are sent as direct
993 (depth=1) children of the root element and are scoped by
994 one of the default namespaces identified in Section 4.4. Any such
995 direct child element of the root stream element is called an "XML
996 stanza".
998 6.2 Common Attributes
1000 Four attributes are common to message, presence, and IQ stanzas.
1001 These are defined below.
1003 6.2.1 to
1005 The 'to' attribute specifies the JID of the intended recipient for
1006 the stanza. In the 'jabber:client' namespace, a stanza SHOULD
1007 possess a 'to' attribute, although a stanza sent from a client to a
1008 server for handling by that server (e.g., presence sent to the server
1009 for broadcasting to other entities) MAY legitimately lack a 'to'
1010 attribute. In the 'jabber:server' namespace, a stanza MUST possess a
1011 'to' attribute.
1013 6.2.2 from
1015 The 'from' attribute specifies the JID of the sender.
1017 In the 'jabber:client' namespace, a client MUST NOT include a 'from'
1018 attribute on the stanzas it sends to a server; if a server receives a
1019 stanza from a client and the stanza possesses a 'from' attribute, it
1020 MUST ignore the value of the 'from' attribute. In addition, a server
1021 MUST stamp stanzas received from a client with the user@domain/
1022 resource (full JID) of the connected resource that generated the
1023 stanza. In the 'jabber:server' namespace, a stanza MUST possess a
1024 'from' attribute.
1026 A server MUST include a 'from' attribute on stanzas it routes to
1027 other servers. The domain identifier of the JID contained in the
1028 'from' attribute MUST match the hostname of the server as
1029 communicated in the dialback negotiation (or a subdomain thereof).
1031 6.2.3 id
1033 The optional 'id' attribute MAY be used to track stanzas sent and
1034 received. The 'id' attribute is generated by the sender. An 'id'
1035 attribute included in an IQ request of type "get" or "set" SHOULD be
1036 returned to the sender in any IQ response of type "result" or "error"
1037 generated by the recipient of the request. A recipient of a message
1038 or presence stanza MAY return that 'id' in any replies, but is NOT
1039 REQUIRED to do so.
1041 The 'id' attribute is of type ID as defined in section 3.3.1 of the
1042 XML specification [1] and therefore MUST match the Name production as
1043 defined in section 2.3 of the XML specification [1]. Validity
1044 contraints on names within XML documents (but not XML streams) are
1045 defined in the XML specification [1]; however, because the stream in
1046 one direction can be seen as a document that is built up over the
1047 length of a session, at a minimum the value of an 'id' attribute MUST
1048 be unique within that stream.
1050 6.2.4 type
1052 The 'type' attribute specifies detailed information about the purpose
1053 or context of the message, presence, or IQ stanza. The particular
1054 allowable values for the 'type' attribute vary depending on whether
1055 the stanza is a message, presence, or IQ, and thus are specified in
1056 the following sections.
1058 6.2.5 xml:lang
1060 Any message or presence stanza MAY possess an 'xml:lang' attribute
1061 specifying the default language of any CDATA sections of the stanza
1062 or its child elements. An IQ stanza SHOULD NOT possess an 'xml:lang'
1063 attribute, since it is merely a vessel for data in other namespaces
1064 and does not itself contain children that have CDATA. The value of
1065 the 'xml:lang' attribute MUST be a NMTOKEN and MUST conform to the
1066 format defined in RFC 3066 [12].
1068 6.3 Message Stanzas
1070 Message stanzas in the 'jabber:client' or 'jabber:server' namespace
1071 are used to "push" information to another entity. Common uses in the
1072 context of instant messaging include single messages, messages sent
1073 in the context of a chat conversation, messages sent in the context
1074 of a multi-user chat room, headlines, and errors. These messages
1075 types are identified more fully below.
1077 6.3.1 Types of Message
1079 The 'type' attribute of a message stanza is optional and specifies
1080 the conversational context of the message. The sending of a message
1081 stanza without a 'type' attribute signals that the message stanza is
1082 a single message. However, the 'type' attribute MAY also have one of
1083 the following values:
1085 o chat -- The message is sent in the context of a one-to-one chat
1086 conversation.
1088 o groupchat -- The message is sent in the context of a multi-user
1089 chat environment.
1091 o headline -- The message is generated by an automated service that
1092 delivers content (news, sports, market information, etc.).
1094 o error - A message returned to a sender specifying an error
1095 associated with a previous message sent by the sender (for a full
1096 list of error messages, see error codes (Appendix A))
1098 For detailed information about these message types, refer to XMPP IM
1099 [2].
1101 6.3.2 Children
1103 If a message stanza in the 'jabber:client' or 'jabber:server'
1104 namespace has no 'type' attribute or has a 'type' attribute with a
1105 value of "chat", "groupchat", or "headline", it MAY contain any of
1106 the following child elements (which MUST NOT contain mixed content):
1108 o body -- The textual contents of the message; normally included but
1109 NOT REQUIRED. The element MUST NOT possess any
1110 attributes, with the exception of the 'xml:lang' attribute.
1111 Multiple instances of the element MAY be included but only
1112 if each instance possesses an 'xml:lang' attribute with a distinct
1113 language value.
1115 o subject -- The subject of the message. The element
1116 MUST NOT possess any attributes, with the exception of the
1117 'xml:lang' attribute. Multiple instances of the
1118 element MAY be included but only if each instance possesses an
1119 'xml:lang' attribute with a distinct language value.
1121 o thread -- A random string that is generated by the sender and that
1122 MAY be copied back in replies; it is used for tracking a
1123 conversation thread between two entities. If used, it MUST be
1124 unique to that conversation thread within the stream and MUST be
1125 consistent throughout that conversation. Only one
1126 element MAY be included in a message stanza, and it MUST NOT
1127 possess any attributes.
1129 If the message stanza is of type "error", it MUST include an
1130 child, which in turn MUST possess a 'code' attribute corresponding to
1131 one of the standard error codes (Appendix A), MAY possess an
1132 'xml:lang' attribute, and MAY also contain PCDATA corresponding to a
1133 natural-language description of the error. An child MUST
1134 NOT be included if the stanza type is anything other than "error".
1136 As described under extended namespaces (Section 6.6), a message
1137 stanza MAY also contain any properly-namespaced child element (other
1138 than the core data elements, stream elements, or defined children
1139 thereof).
1141 6.4 Presence Stanzas
1143 Presence stanzas are used in the 'jabber:client' or 'jabber:server'
1144 namespace to express an entity's current availability status (offline
1145 or online, along with various sub-states of the latter) and to
1146 communicate that status to other entities. They are also used to
1147 negotiate and manage subscriptions to the presence of other entities.
1149 6.4.1 Types of Presence
1151 The 'type' attribute of a presence stanza is optional. A presence
1152 stanza that does not have a 'type' attribute is used to signal that
1153 the sender is online and available for communication. If included,
1154 the 'type' attribute specifies the availability state of the sender,
1155 a request to manage a subscription to another entity's presence, a
1156 request for another entity's current presence, or an error related to
1157 a previously-sent presence stanza. The 'type' attribute MAY have one
1158 of the following values:
1160 o unavailable -- Signals that the entity is no longer available for
1161 communication.
1163 o subscribe -- The sender wishes to subscribe to the recipient's
1164 presence.
1166 o subscribed -- The sender has allowed the recipient to receive
1167 their presence.
1169 o unsubscribe -- A notification that an entity is unsubscribing from
1170 another entity's presence.
1172 o unsubscribed -- The subscription request has been denied or a
1173 previously-granted subscription has been cancelled.
1175 o probe -- A request for an entity's current presence.
1177 o error -- An error has occurred regarding processing or delivery of
1178 a previously-sent presence stanza.
1180 Information about the subscription model used within XMPP can be
1181 found in XMPP IM [2].
1183 6.4.2 Children
1185 If a presence stanza possesses no 'type' attribute, it MAY contain
1186 any of the following child elements (note that the child
1187 MAY be sent in a presence stanza of type "unavailable" or, for
1188 historical reasons, "subscribe"):
1190 o show -- Describes the availability status of an entity or specific
1191 resource. Only one element MAY be included in a presence
1192 stanza, and it MUST NOT possess any attributes. The value SHOULD
1193 be one of the following (values other than these four MAY be
1194 ignored; additional availability types could be defined through a
1195 properly-namespaced child element of the presence stanza):
1197 * away -- The entity or resource is temporarily away.
1199 * chat -- The entity or resource is actively interested in
1200 chatting.
1202 * xa -- The entity or resource is away for an extended period (xa
1203 = "eXtended Away").
1205 * dnd -- The entity or resource is busy (dnd = "Do Not Disturb").
1207 o status -- An optional natural-language description of availability
1208 status. Normally used in conjunction with the show element to
1209 provide a detailed description of an availability state (e.g., "In
1210 a meeting"). The element MUST NOT possess any
1211 attributes, with the exception of the 'xml:lang' attribute.
1212 Multiple instances of the element MAY be included but
1213 only if each instance possesses an 'xml:lang' attribute with a
1214 distinct language value.
1216 o priority -- A non-negative integer representing the priority level
1217 of the connected resource, with zero as the lowest priority. Only
1218 one element MAY be included in a presence stanza, and
1219 it MUST NOT possess any attributes.
1221 If the presence stanza is of type "error", it MUST include an child, which in turn MUST possess a 'code' attribute corresponding
1223 to one of the standard error codes (Appendix A) and MAY contain
1224 PCDATA corresponding to a natural-language description of the error.
1225 An child MUST NOT be included if the stanza type is anything
1226 other than "error".
1228 As described under extended namespaces (Section 6.6), a presence
1229 stanza MAY also contain any properly-namespaced child element (other
1230 than the core data elements, stream elements, or defined children
1231 thereof).
1233 6.5 IQ Stanzas
1235 6.5.1 Overview
1237 Info/Query, or IQ, is a simple request-response mechanism. Just as
1238 HTTP is a request-response medium, IQ stanzas in the 'jabber:client'
1239 or 'jabber:server' namespace enable an entity to make a request of,
1240 and receive a response from, another entity. The data content of the
1241 request and response is defined by the namespace declaration of a
1242 direct child element of the iq element.
1244 Most IQ interactions follow a common pattern of structured data
1245 exchange such as get/result or set/result:
1247 Requesting Responding
1248 Entity Entity
1249 ---------- ----------
1250 | |
1251 | |
1252 | ---------------------> |
1253 | |
1254 | |
1255 | <--------------------- |
1256 | |
1257 | |
1258 | ---------------------> |
1259 | |
1260 | |
1261 | <--------------------- |
1262 | |
1264 An entity that receives a request of type 'get' or 'set' MUST reply
1265 with a response of type 'result' or 'error'.
1267 6.5.2 Types of IQ
1269 The 'type' attribute of an IQ stanza is REQUIRED. The 'type'
1270 attribute specifies a distinct step within a request-response
1271 interaction. The value SHOULD be one of the following (all other
1272 values MAY be ignored):
1274 o get -- The stanza is a request for information.
1276 o set -- The stanza provides required data, sets new values, or
1277 replaces existing values.
1279 o result -- The stanza is a response to a successful get or set
1280 request.
1282 o error -- An error has occurred regarding processing or delivery of
1283 a previously-sent get or set.
1285 6.5.3 Children
1287 An IQ stanza contains no children in the 'jabber:client' or
1288 'jabber:server' namespace since it is a vessel for XML in another
1289 namespace. As described under extended namespaces (Section 6.6), an
1290 IQ stanza MAY contain any properly-namespaced child element (other
1291 than the core data elements, stream elements, or defined children
1292 thereof).
1294 If the IQ stanza is of type "error", it MUST include an
1295 child, which in turn MUST possess a 'code' attribute corresponding to
1296 one of the standard error codes (Appendix A) and MAY contain PCDATA
1297 corresponding to a natural-language description of the error. An
1298 child MUST NOT be included if the stanza type is anything
1299 other than "error".
1301 6.6 Extended Namespaces
1303 While the core data elements defined in this document provide a basic
1304 level of functionality for messaging and presence, XMPP uses XML
1305 namespaces to extend the core data elements for the purpose of
1306 providing additional functionality. Thus a message, presence, or IQ
1307 stanza MAY house one or more optional child elements containing
1308 content that extends the meaning of the message (e.g., an encrypted
1309 form of the message body). This child element MAY be any element
1310 (other than the core data elements, stream elements, or defined
1311 children thereof). The child element MUST possess an 'xmlns'
1312 namespace declaration (other than the stream namespace and the
1313 default namespace) that defines all data contained within the child
1314 element.
1316 Support for any given extended namespace is OPTIONAL on the part of
1317 any implementation. If an entity does not understand such a
1318 namespace, it MUST ignore the associated XML data. If an entity
1319 receives an IQ stanza in a namespace it does not understand, the
1320 entity SHOULD return an IQ stanza of type "error" with an error
1321 element of code 400 (bad request). If an entity receives a message
1322 or presence stanza that contains XML data in an extended namespace it
1323 does not understand, the portion of the stanza that is in the unknown
1324 namespace SHOULD be ignored. If an entity receives a message stanza
1325 without a element but containing only a child element bound
1326 by a namespace it does not understand, it MUST ignore that stanza.
1328 7. XML Usage within XMPP
1330 7.1 Overview
1332 In essence, XMPP core consists of three interrelated parts:
1334 1. XML streams (Section 4), which provide a stateful means for
1335 transporting data in an asynchronous manner from one entity to
1336 another
1338 2. stream authentication using SASL authentication (Section 5.1) or
1339 the dialback protocol (Section 5.2)
1341 3. core data elements (Section 6) (message, presence, and iq), which
1342 provide a framework for communications between entities
1344 XML [1] is used to define each of these protocols, as described in
1345 detail in the following sections.
1347 In addition, XMPP contains protocol extensions (such as extended
1348 namespaces) that address the specific functionality required to
1349 create a basic instant messaging and presence application; these non-
1350 core protocol extensions are defined in XMPP IM [2].
1352 7.2 Namespaces
1354 XML Namespaces [11] are used within all XMPP-compliant XML to create
1355 strict boundaries of data ownership. The basic function of
1356 namespaces is to separate different vocabularies of XML elements that
1357 are structurally mixed together. Ensuring that XMPP-compliant XML is
1358 namespace-aware enables any XML to be structurally mixed with any
1359 data element within XMPP. Mainly for historical reasons, the default
1360 namespace for XMPP data stanzas MUST be one of the namespaces
1361 identified in Section 4.4.
1363 Additionally, XMPP is more strict about namespace prefixes than the
1364 XML namespace specification requires.
1366 7.3 Validation
1368 A server is not responsible for validating the XML elements forwarded
1369 to a client; an implementation MAY choose to provide only validated
1370 data elements but is NOT REQUIRED to do so. Clients SHOULD NOT rely
1371 on the ability to send data which does not conform to the schemas,
1372 and SHOULD ignore any non-conformant elements or attributes on the
1373 incoming XML stream. Validation of XML streams and stanzas is NOT
1374 REQUIRED or recommended, and DTDs and schemas are included herein for
1375 descriptive purposes only.
1377 7.4 Character Encodings
1379 Software implementing XML streams MUST support the UTF-8 and UTF-16
1380 encodings for received data. Software MUST NOT attempt to use any
1381 other encoding for transmitted data. The encodings of the transmit
1382 and receive streams are independent. Software MAY select either UTF-
1383 8 or UTF-16 for the transmitted stream, and SHOULD deduce the
1384 encoding of the received stream as described in the XML specification
1385 [1].
1387 7.5 Inclusion of Text Declaration
1389 An application MAY send a text declaration. Applications MUST follow
1390 the rules in the XML specification [1] concerning the circumstances
1391 in which a text declaration is included.
1393 8. IANA Considerations
1395 The IANA registers "jabber-client" and "jabber-server" as GSS-API
1396 [15] service names, as specified in Section 6.1.1; these service
1397 names are associated with TCP ports 5222 and 5269 respectively.
1399 9. Internationalization Considerations
1401 o If a client sends an xml:lang attribute on a stanza, the server
1402 MUST NOT modify or delete it.
1404 10. Security Considerations
1406 10.1 Client-to-Server Communications
1408 The SASL protocol for authenticating XML streams negotiated between a
1409 client and a server (defined under Section 5.1 above) provides a
1410 reliable mechanism for validating that a client connecting to a
1411 server is who it claims to be.
1413 The IP address and method of access of clients MUST NOT be made
1414 available by a server, nor are any connections other than the
1415 original server connection required. This helps protect the client's
1416 server from direct attack or identification by third parties.
1418 End-to-end encryption of message bodies and presence status
1419 information MAY be effected through use of OpenPGP [14].
1421 10.2 Server-to-Server Communications
1423 It is OPTIONAL for any given server to communicate with other
1424 servers, and server-to-server communications MAY be disabled by the
1425 administrator of any given deployment.
1427 If two servers would like to enable communications between
1428 themselves, they MUST form a relationship of trust at some level,
1429 either based on trust in DNS or based on a pre-existing trust
1430 relationship (e.g., through exchange of certificates). If two
1431 servers have a pre-existing trust relationship, they MAY use SASL
1432 Authentication (Section 5.1) for the purpose of authenticating each
1433 other. If they do not have a pre-existing relationship, they MUST
1434 use the Dialback Protocol (Section 5.2), which provides a reliable
1435 mechanism for preventing the spoofing of servers.
1437 10.3 Minimum Security Mechanisms
1439 Although service provisioning is a policy matter, at a minimum, all
1440 implementations MUST support the SASL DIGEST-MD5 mechanism for
1441 authentication.
1443 10.4 Firewalls
1445 Communications using XMPP occur over TCP sockets on port 5222
1446 (client-to-server) or port 5269 (server-to-server), as registered
1447 with the IANA [6]. Use of these well-known ports allows
1448 administrators to easily enable or disable XMPP activity through
1449 existing and commonly-deployed firewalls.
1451 References
1453 [1] World Wide Web Consortium, "Extensible Markup Language (XML)
1454 1.0 (Second Edition)", W3C xml, October 2000, .
1457 [2] Miller, J. and P. Saint-Andre, "XMPP Instant Messaging (draft-
1458 ietf-xmpp-im-00, work in progress)", December 2002.
1460 [3] Day, M., Aggarwal, S., Mohr, G. and J. Vincent, "A Model for
1461 Presence and Instant Messaging", RFC 2779, February 2000,
1462 .
1464 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
1465 Levels", BCP 14, RFC 2119, March 1997.
1467 [5] University of Southern California, "Transmission Control
1468 Protocol", RFC 793, September 1981, .
1471 [6] Internet Assigned Numbers Authority, "Internet Assigned Numbers
1472 Authority", January 1998, .
1474 [7] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
1475 Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1476 1998, .
1478 [8] Harrenstien, K., Stahl, M. and E. Feinler, "DoD Internet host
1479 table specification", RFC 952, October 1985.
1481 [9] Braden, R., "Requirements for Internet Hosts - Application and
1482 Support", STD 3, RFC 1123, October 1989.
1484 [10] Myers, J., "Simple Authentication and Security Layer (SASL)",
1485 RFC 2222, October 1997.
1487 [11] World Wide Web Consortium, "Namespaces in XML", W3C xml-names,
1488 January 1999, .
1491 [12] Alvestrand, H., "Tags for the Identification of Languages", BCP
1492 47, RFC 3066, January 2001.
1494 [13] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the
1495 location of services (DNS SRV)", RFC 2052, October 1996.
1497 [14] Elkins, M., Del Torto, D., Levien, R. and T. Roessler, "MIME
1498 Security with OpenPGP", RFC 3156, August 2001.
1500 [15] Linn, J., "Generic Security Service Application Program
1501 Interface, Version 2", RFC 2078, January 1997.
1503 Authors' Addresses
1505 Jeremie Miller
1506 Jabber Software Foundation
1507 1899 Wynkoop Street, Suite 600
1508 Denver, CO 80202
1509 US
1511 EMail: jeremie@jabber.org
1512 URI: http://www.jabber.org/people/jer.php
1514 Peter Saint-Andre
1515 Jabber Software Foundation
1516 1899 Wynkoop Street, Suite 600
1517 Denver, CO 80202
1518 US
1520 EMail: stpeter@jabber.org
1521 URI: http://www.jabber.org/people/stpeter.php
1523 Appendix A. Standard Error Codes
1525 A standard error element is used for failed processing of XML
1526 stanzas. This element is a child of the failed stanza and MUST
1527 include a 'code' attribute corresponding to one of the following
1528 error codes.
1530 o 302 (Redirect) - Whereas HTTP contains eight different codes for
1531 redirection, XMPP contains only one (which is intended to stand
1532 for any redirection error). However, code 302 is being reserved
1533 for future functionality and is not implemented at this time.
1535 o 400 (Bad Request) - Code 400 is used to inform a sender that a
1536 request could not be understood by the recipient. This might be
1537 generated when, for example, an entity sends a message that does
1538 not have a 'to' attribute.
1540 o 401 (Unauthorized) - Code 401 is used to inform clients that they
1541 have provided incorrect authorization information, e.g., an
1542 incorrect password or unknown username when attempting to
1543 authenticate with a server.
1545 o 402 (Payment Required) - Code 402 is being reserved for future
1546 use.
1548 o 403 (Forbidden) - Code 403 is used to inform an entity that the
1549 its request was understood but that the recipient is refusing to
1550 fulfill it, e.g., if a user attempts to set information associated
1551 with another user.
1553 o 404 (Not Found) - Code 404 is used to inform a sender that no
1554 recipient was found matching the JID to which an XML stanza was
1555 sent, e.g., if a sender has attempted to send a message to a JID
1556 that does not exist. (Note: if the server of the intended
1557 recipient cannot be reached, an error code from the 500 series
1558 must be sent).
1560 o 405 (Not Allowed) - Code 405 is used when the action requested is
1561 not allowed for the JID identified by the 'from' address, e.g., if
1562 a client attempts to set the time or version of a server.
1564 o 406 (Not Acceptable) - Code 406 is used when an XML stanza is for
1565 some reason not acceptable to a server or other entity. This
1566 might be generated when, for example, a user attempts to register
1567 with a server using an empty password.
1569 o 407 (Registration Required) - Code 407 is used when a message or
1570 request is sent to a service that requires prior registration,
1571 e.g., if a user attempts to send a message through a gateway to a
1572 foreign messaging system without having first registered with that
1573 gateway.
1575 o 408 (Request Timeout) - Code 408 is returned when a recipient does
1576 not produce a response within the time that the sender was
1577 prepared to wait.
1579 o 500 (Internal Server Error) - Code 500 is used when a server or
1580 service encounters an unexpected condition which prevents it from
1581 handling an XML stanza from a sender, e.g., if an authentication
1582 request is not handled by a server because the password could not
1583 be retrieved.
1585 o 501 (Not Implemented) - Code 501 is used when the recipient does
1586 not support the functionality being requested by a sender, e.g.,
1587 if a user attempts to register with a server that does not allow
1588 registration.
1590 o 502 (Remote Server Error) - Code 502 is used when delivery of an
1591 XML stanza fails because of an inability to reach the intended
1592 remote server or service, e.g., because a remote server's hostname
1593 could not be resolved.
1595 o 503 (Service Unavailable) - Code 503 is used when a sender
1596 requests a service that a recipient is temporarily unable to
1597 offer.
1599 o 504 (Remote Server Timeout) - Code 504 is used when attempts to
1600 contact a remote server timeout, e.g., if an incorrect hostname is
1601 specified.
1603 Appendix B. Formal Definitions
1605 B.1 streams namespace
1607 The namespace declaration for the root stream element is 'http://
1608 etherx.jabber.org/streams'.
1610 B.1.1 DTD
1612
1613
1614
1620
1621
1623 B.1.2 Schema
1625
1626
1632
1633
1634
1635
1636
1639
1642
1643
1644
1645
1646
1647
1648
1650
1652
1654 B.2 SASL namespace
1656 The namespace declaration for SASL-related elements is 'http://
1657 www.iana.org/assignments/sasl-mechanisms'.
1659 B.2.1 DTD
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1672 B.2.2 Schema
1674
1675
1681
1682
1683
1684
1685
1686
1687
1689
1691
1692
1693
1694
1695
1697
1698
1699
1700
1701
1703
1705 B.3 jabber:client namespace
1707 B.3.1 DTD
1709
1710
1713
1722
1723
1724
1725
1726
1728
1730
1739
1740
1741
1742
1744
1746
1753
1754
1759 B.3.2 Schema
1761
1762
1768
1769
1770
1771
1772
1773
1774
1775
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1797
1798
1799
1800
1801
1803
1804
1805
1806
1807
1809
1811
1812
1813
1814
1815
1816
1817
1818
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1853
1854
1855
1856
1857
1859
1861
1862
1863
1864
1865
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1886
1887
1888
1892
1893
1894
1896
1898 B.4 jabber:server namespace
1900 B.4.1 DTD
1902
1903
1906
1914
1915
1916
1917
1918
1920
1922
1931
1932
1933
1934
1936
1938
1945
1946
1951 B.4.2 Schema
1953
1954
1960
1961
1962
1963
1964
1965
1966
1967
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1989
1990
1991
1992
1993
1995
1996
1997
1998
1999
2001
2003
2004
2005
2006
2007
2008
2009
2010
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2045
2046
2047
2048
2049
2051
2053
2054
2055
2056
2057
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2078
2079
2080
2084
2085
2086
2088
2090 Appendix C. Revision History
2092 Note to RFC editor: please remove this entire appendix, and the
2093 corresponding entries in the table of contents, prior to publication.
2095 C.1 Changes from draft-miller-xmpp-core-02
2097 o Brought Streams Authentication section into line with discussion
2098 on list and at IETF 55 meeting.
2100 o Added information about the optional 'xml:lang' attribute per
2101 discussion on list and at IETF 55 meeting.
2103 o Specified that validation is neither required nor recommended, and
2104 that the formal definitions (DTDs and schemas) are included for
2105 descriptive purposes only.
2107 o Specified that the response to an IQ stanza of type 'get' or 'set'
2108 must be an IQ stanza of type 'result' or 'error'.
2110 o Specified that compliant server implementations must process
2111 stanzas in order.
2113 o Specified that for historical reasons some server implementations
2114 may accept 'stream:' as the only valid namespace prefix on the
2115 root stream element.
2117 o Clarified the difference between 'jabber:client' and
2118 'jabber:server' namespaces, namely, that 'to' and 'from'
2119 attributes are required on all stanzas in the latter but not the
2120 former.
2122 o Fixed typo in Step 9 of the dialback protocol (changed db:result
2123 to db:verify).
2125 o Removed references to TLS pending list discussion.
2127 o Removed the non-normative appendix on OpenPGP usage pending its
2128 inclusion in a separate I-D.
2130 o Simplified the architecture diagram, removed most references to
2131 services, and removed references to the 'jabber:component:*'
2132 namespaces.
2134 o Noted that XMPP activity respects firewall administration
2135 policies.
2137 o Further specified the scope and uniqueness of the 'id' attribute
2138 in all stanza types and the element in message stanzas.
2140 o Nomenclature changes: (1) from "chunks" to "stanzas"; (2) from
2141 "host" to "server" and from "node" to "client" (except with regard
2142 to definition of the addressing scheme).
2144 Full Copyright Statement
2146 Copyright (C) The Internet Society (2002). All Rights Reserved.
2148 This document and translations of it may be copied and furnished to
2149 others, and derivative works that comment on or otherwise explain it
2150 or assist in its implementation may be prepared, copied, published
2151 and distributed, in whole or in part, without restriction of any
2152 kind, provided that the above copyright notice and this paragraph are
2153 included on all such copies and derivative works. However, this
2154 document itself may not be modified in any way, such as by removing
2155 the copyright notice or references to the Internet Society or other
2156 Internet organizations, except as needed for the purpose of
2157 developing Internet standards in which case the procedures for
2158 copyrights defined in the Internet Standards process must be
2159 followed, or as required to translate it into languages other than
2160 English.
2162 The limited permissions granted above are perpetual and will not be
2163 revoked by the Internet Society or its successors or assigns.
2165 This document and the information contained herein is provided on an
2166 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
2167 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
2168 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
2169 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
2170 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2172 Acknowledgement
2174 Funding for the RFC Editor function is currently provided by the
2175 Internet Society.