draft-ietf-xmpp-core-03.txt   draft-ietf-xmpp-core-04.txt 
Network Working Group P. Saint-Andre Network Working Group P. Saint-Andre
Internet-Draft J. Miller Internet-Draft J. Miller
Expires: August 22, 2003 Jabber Software Foundation Expires: August 27, 2003 Jabber Software Foundation
February 21, 2003 February 26, 2003
XMPP Core XMPP Core
draft-ietf-xmpp-core-03 draft-ietf-xmpp-core-04
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 22, 2003. This Internet-Draft will expire on August 27, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This document describes the core features of the eXtensible Messaging This document describes the core features of the Extensible Messaging
and Presence Protocol (XMPP), a protocol for streaming XML in near- and Presence Protocol (XMPP), a protocol for streaming XML in near-
real-time that is used mainly for the purpose of instant messaging real-time that is used mainly for the purpose of instant messaging
and presence by the servers, clients, and other applications that (IM) and presence by the servers, clients, and other applications
comprise the Jabber network. that comprise the Jabber network.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Discussion Venue . . . . . . . . . . . . . . . . . . . . . . 4 1.3 Discussion Venue . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Intellectual Property Notice . . . . . . . . . . . . . . . . 4 1.4 Intellectual Property Notice . . . . . . . . . . . . . . . . 4
2. Generalized Architecture . . . . . . . . . . . . . . . . . . 5 2. Generalized Architecture . . . . . . . . . . . . . . . . . . 5
2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
skipping to change at page 2, line 31 skipping to change at page 2, line 31
3.3 Node Identifier . . . . . . . . . . . . . . . . . . . . . . 7 3.3 Node Identifier . . . . . . . . . . . . . . . . . . . . . . 7
3.4 Resource Identifier . . . . . . . . . . . . . . . . . . . . 8 3.4 Resource Identifier . . . . . . . . . . . . . . . . . . . . 8
4. XML Streams . . . . . . . . . . . . . . . . . . . . . . . . 9 4. XML Streams . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2 Restrictions . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2 Restrictions . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3 Stream Attributes . . . . . . . . . . . . . . . . . . . . . 10 4.3 Stream Attributes . . . . . . . . . . . . . . . . . . . . . 10
4.4 Namespace Declarations . . . . . . . . . . . . . . . . . . . 11 4.4 Namespace Declarations . . . . . . . . . . . . . . . . . . . 11
4.5 Stream Features . . . . . . . . . . . . . . . . . . . . . . 12 4.5 Stream Features . . . . . . . . . . . . . . . . . . . . . . 12
4.6 Stream Errors . . . . . . . . . . . . . . . . . . . . . . . 12 4.6 Stream Errors . . . . . . . . . . . . . . . . . . . . . . . 12
4.7 Simple Streams Example . . . . . . . . . . . . . . . . . . . 14 4.7 Simple Streams Example . . . . . . . . . . . . . . . . . . . 14
5. Stream Authentication . . . . . . . . . . . . . . . . . . . 16 5. Stream Encryption . . . . . . . . . . . . . . . . . . . . . 16
5.1 SASL Authentication . . . . . . . . . . . . . . . . . . . . 16 5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.2 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1.2 Client-Server Example . . . . . . . . . . . . . . . . . . . 17 5.3 Client-Server Protocol . . . . . . . . . . . . . . . . . . . 17
5.2 Dialback Authentication . . . . . . . . . . . . . . . . . . 19 5.4 Certificate-Based Authentication . . . . . . . . . . . . . . 19
5.2.1 Dialback Protocol . . . . . . . . . . . . . . . . . . . . . 21 6. Stream Authentication . . . . . . . . . . . . . . . . . . . 20
6. Stream Encryption . . . . . . . . . . . . . . . . . . . . . 24 6.1 SASL Authentication . . . . . . . . . . . . . . . . . . . . 20
6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.2 Client-Server Example . . . . . . . . . . . . . . . . . . . 25 6.1.2 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.3 Certificate-Based Authentication . . . . . . . . . . . . . . 26 6.1.3 SASL Definition . . . . . . . . . . . . . . . . . . . . . . 22
7. XML Stanzas . . . . . . . . . . . . . . . . . . . . . . . . 27 6.1.4 Client-Server Protocol . . . . . . . . . . . . . . . . . . . 23
7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.2 Dialback Authentication . . . . . . . . . . . . . . . . . . 25
7.2 Common Attributes . . . . . . . . . . . . . . . . . . . . . 27 6.2.1 Dialback Protocol . . . . . . . . . . . . . . . . . . . . . 27
7.2.1 to . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 7. XML Stanzas . . . . . . . . . . . . . . . . . . . . . . . . 31
7.2.2 from . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.2.3 id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 7.2 Common Attributes . . . . . . . . . . . . . . . . . . . . . 31
7.2.4 type . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 7.2.1 to . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.2.5 xml:lang . . . . . . . . . . . . . . . . . . . . . . . . . . 28 7.2.2 from . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.3 Message Stanzas . . . . . . . . . . . . . . . . . . . . . . 28 7.2.3 id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.3.1 Types of Message . . . . . . . . . . . . . . . . . . . . . . 28 7.2.4 type . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
7.3.2 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 29 7.2.5 xml:lang . . . . . . . . . . . . . . . . . . . . . . . . . . 32
7.4 Presence Stanzas . . . . . . . . . . . . . . . . . . . . . . 30 7.3 Message Stanzas . . . . . . . . . . . . . . . . . . . . . . 32
7.4.1 Types of Presence . . . . . . . . . . . . . . . . . . . . . 30 7.3.1 Types of Message . . . . . . . . . . . . . . . . . . . . . . 32
7.4.2 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 31 7.3.2 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.5 IQ Stanzas . . . . . . . . . . . . . . . . . . . . . . . . . 32 7.4 Presence Stanzas . . . . . . . . . . . . . . . . . . . . . . 34
7.5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 32 7.4.1 Types of Presence . . . . . . . . . . . . . . . . . . . . . 34
7.5.2 Types of IQ . . . . . . . . . . . . . . . . . . . . . . . . 33 7.4.2 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7.5.3 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 34 7.5 IQ Stanzas . . . . . . . . . . . . . . . . . . . . . . . . . 36
7.6 Extended Namespaces . . . . . . . . . . . . . . . . . . . . 34 7.5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 36
8. XML Usage within XMPP . . . . . . . . . . . . . . . . . . . 35 7.5.2 Types of IQ . . . . . . . . . . . . . . . . . . . . . . . . 37
8.1 Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . 35 7.5.3 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 38
8.2 Validation . . . . . . . . . . . . . . . . . . . . . . . . . 35 7.6 Extended Namespaces . . . . . . . . . . . . . . . . . . . . 38
8.3 Character Encodings . . . . . . . . . . . . . . . . . . . . 35 8. XML Usage within XMPP . . . . . . . . . . . . . . . . . . . 40
8.4 Inclusion of Text Declaration . . . . . . . . . . . . . . . 35 8.1 Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . 40
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 36 8.2 Validation . . . . . . . . . . . . . . . . . . . . . . . . . 40
10. Internationalization Considerations . . . . . . . . . . . . 37 8.3 Character Encodings . . . . . . . . . . . . . . . . . . . . 40
11. Security Considerations . . . . . . . . . . . . . . . . . . 38 8.4 Inclusion of Text Declaration . . . . . . . . . . . . . . . 40
11.1 Client-to-Server Communications . . . . . . . . . . . . . . 38 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 41
11.2 Server-to-Server Communications . . . . . . . . . . . . . . 38 10. Internationalization Considerations . . . . . . . . . . . . 42
11.3 Minimum Security Mechanisms . . . . . . . . . . . . . . . . 38 11. Security Considerations . . . . . . . . . . . . . . . . . . 43
11.4 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . 39 11.1 Client-to-Server Communications . . . . . . . . . . . . . . 43
References . . . . . . . . . . . . . . . . . . . . . . . . . 40 11.2 Server-to-Server Communications . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 42 11.3 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . 43
A. Standard Error Codes . . . . . . . . . . . . . . . . . . . . 43 11.4 Minimum Security Mechanisms . . . . . . . . . . . . . . . . 43
B. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . 46 References . . . . . . . . . . . . . . . . . . . . . . . . . 45
B.1 streams namespace . . . . . . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 47
B.2 SASL namespace . . . . . . . . . . . . . . . . . . . . . . . 47 A. Standard Error Codes . . . . . . . . . . . . . . . . . . . . 48
B.3 Dialback namespace . . . . . . . . . . . . . . . . . . . . . 47 B. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . 51
B.4 jabber:client namespace . . . . . . . . . . . . . . . . . . 48 B.1 streams namespace . . . . . . . . . . . . . . . . . . . . . 51
B.5 jabber:server namespace . . . . . . . . . . . . . . . . . . 51 B.2 SASL namespace . . . . . . . . . . . . . . . . . . . . . . . 52
C. Revision History . . . . . . . . . . . . . . . . . . . . . . 55 B.3 Dialback namespace . . . . . . . . . . . . . . . . . . . . . 52
C.1 Changes from draft-ietf-xmpp-core-02 . . . . . . . . . . . . 55 B.4 jabber:client namespace . . . . . . . . . . . . . . . . . . 54
C.2 Changes from draft-ietf-xmpp-core-01 . . . . . . . . . . . . 55 B.5 jabber:server namespace . . . . . . . . . . . . . . . . . . 56
C.3 Changes from draft-ietf-xmpp-core-00 . . . . . . . . . . . . 55 C. Revision History . . . . . . . . . . . . . . . . . . . . . . 60
C.4 Changes from draft-miller-xmpp-core-02 . . . . . . . . . . . 55 C.1 Changes from draft-ietf-xmpp-core-03 . . . . . . . . . . . . 60
Full Copyright Statement . . . . . . . . . . . . . . . . . . 57 C.2 Changes from draft-ietf-xmpp-core-02 . . . . . . . . . . . . 60
C.3 Changes from draft-ietf-xmpp-core-01 . . . . . . . . . . . . 60
C.4 Changes from draft-ietf-xmpp-core-00 . . . . . . . . . . . . 60
C.5 Changes from draft-miller-xmpp-core-02 . . . . . . . . . . . 61
Full Copyright Statement . . . . . . . . . . . . . . . . . . 63
1. Introduction 1. Introduction
1.1 Overview 1.1 Overview
The eXtensible Messaging and Presence Protocol (XMPP) is an open XML The Extensible Messaging and Presence Protocol (XMPP) is an open XML
[1] protocol for near-real-time messaging, presence, and request- [1] protocol for near-real-time messaging, presence, and request-
response services. The protocol was developed originally within the response services. The protocol was developed originally within the
Jabber community starting in 1998, and since 2001 has continued to Jabber community starting in 1998, and since 2001 has continued to
evolve under the auspices of the Jabber Software Foundation and now evolve under the auspices of the Jabber Software Foundation [2] and
the XMPP WG. Currently, there exist multiple implementations of the now the XMPP WG. The current document defines the core features of
protocol, mostly offered under the name of Jabber. In addition, XMPP; XMPP IM [3] defines the extensions necessary to provide the
there are countless deployments of these implementations, which instant messaging (IM) and presence functionality defined in RFC 2779
provide instant messaging (IM) and presence services at and among [4].
tens of thousands of domains to a user base that is estimated at over
five million end users. The current document defines the core
features of XMPP; XMPP IM [2] defines the extensions necessary to
provide basic instant messaging and presence functionality that
addresses the requirements defined in RFC 2779 [3].
1.2 Terminology 1.2 Terminology
The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [4]. 2119 [5].
1.3 Discussion Venue 1.3 Discussion Venue
The authors welcome discussion and comments related to the topics The authors welcome discussion and comments related to the topics
presented in this document. The preferred forum is the presented in this document. The preferred forum is the
<xmppwg@jabber.org> mailing list, for which archives and subscription <xmppwg@jabber.org> mailing list, for which archives and subscription
information are available at <http://www.jabber.org/cgi-bin/mailman/ information are available at <http://www.jabber.org/cgi-bin/mailman/
listinfo/xmppwg/>. listinfo/xmppwg/>.
1.4 Intellectual Property Notice 1.4 Intellectual Property Notice
skipping to change at page 5, line 12 skipping to change at page 5, line 12
to the IETF for use of the Jabber trademark in association with this to the IETF for use of the Jabber trademark in association with this
specification and its successors, if any. specification and its successors, if any.
2. Generalized Architecture 2. Generalized Architecture
2.1 Overview 2.1 Overview
Although XMPP is not wedded to any specific network architecture, to Although XMPP is not wedded to any specific network architecture, to
this point it has usually been implemented via a typical client- this point it has usually been implemented via a typical client-
server architecture, wherein a client utilizing XMPP accesses a server architecture, wherein a client utilizing XMPP accesses a
server over a TCP [5] socket. server over a TCP [6] socket.
The following diagram provides a high-level overview of this The following diagram provides a high-level overview of this
architecture (where "-" represents communications that use XMPP and architecture (where "-" represents communications that use XMPP and
"=" represents communications that use any other protocol). "=" represents communications that use any other protocol).
C1 - S1 - S2 - C3 C1 - S1 - S2 - C3
/ \ / \
C2 - G1 = FN1 = FC1 C2 - G1 = FN1 = FC1
The symbols are as follows: The symbols are as follows:
skipping to change at page 5, line 40 skipping to change at page 5, line 40
o FN1 -- A foreign messaging network o FN1 -- A foreign messaging network
o FC1 -- A client on a foreign messaging network o FC1 -- A client on a foreign messaging network
2.2 Server 2.2 Server
A server acts as an intelligent abstraction layer for XMPP A server acts as an intelligent abstraction layer for XMPP
communications. Its primary responsibilities are to manage communications. Its primary responsibilities are to manage
connections from or sessions for other entities (in the form of XML connections from or sessions for other entities (in the form of XML
streams to and from authorized clients and other servers) and to streams to and from authorized clients, servers, and other entities)
route appropriately-addressed XML data "stanzas" among such entities and to route appropriately-addressed XML data "stanzas" among such
over XML streams. Most XMPP-compliant servers also assume entities over XML streams. Most XMPP-compliant servers also assume
responsibility for the storage of data that is used by clients (e.g., responsibility for the storage of data that is used by clients (e.g.,
the contact list for each IM user); in this case, the XML data is contact lists for users of XMPP-based IM applications); in this case,
processed directly by the server itself on behalf of the client and the XML data is processed directly by the server itself on behalf of
is not routed to another entity. Compliant server implementations the client and is not routed to another entity. Compliant server
MUST ensure in-order processing of XML stanzas received from implementations MUST ensure in-order processing of XML stanzas
connected clients, servers, and services. received from connected clients, servers, and services.
2.3 Client 2.3 Client
Most clients connect directly to a server over a TCP socket and use Most clients connect directly to a server over a TCP socket and use
XMPP to take full advantage of the functionality provided by a server XMPP to take full advantage of the functionality provided by a server
and any associated services, although it must be noted that there is and any associated services, although it must be noted that there is
no necessary coupling of an XML stream to a TCP socket (e.g., a no necessary coupling of an XML stream to a TCP socket (e.g., a
client COULD connect via HTTP polling or some other mechanism). client COULD connect via HTTP polling or some other mechanism).
Multiple resources (e.g., devices or locations) MAY connect Multiple resources (e.g., devices or locations) MAY connect
simultaneously to a server on behalf of each authorized client, with simultaneously to a server on behalf of each authorized client, with
each resource connecting over a discrete TCP socket and each resource connecting over a discrete TCP socket and
differentiated by the resource identifier of a JID (Section 3) (e.g., differentiated by the resource identifier of a JID (Section 3) (e.g.,
user@domain/home vs. user@domain/work). The port assigned by the user@domain/home vs. user@domain/work). The port assigned by the
IANA [6] for connections between a Jabber client and a Jabber server IANA [7] for connections between a Jabber client and a Jabber server
is 5222. For further details about client-to-server communications is 5222. For further details about client-to-server communications
expressly for the purpose of instant messaging and presence, refer to expressly for the purpose of instant messaging and presence, refer to
XMPP IM [2]. XMPP IM [3].
2.4 Gateway 2.4 Gateway
A gateway is a special-purpose server-side service whose primary A gateway is a special-purpose server-side service whose primary
function is to translate XMPP into the protocol(s) of another function is to translate XMPP into the protocol(s) of another
messaging system, as well as to translate the return data back into messaging system, as well as to translate the return data back into
XMPP. Examples are gateways to Internet Relay Chat (IRC), Short XMPP. Examples are gateways to Internet Relay Chat (IRC), Short
Message Service (SMS), SMTP, and foreign instant messaging networks Message Service (SMS), SMTP, and foreign instant messaging networks
such as Yahoo!, MSN, ICQ, and AIM. Communications between gateways such as Yahoo!, MSN, ICQ, and AIM. Communications between gateways
and servers, and between gateways and the foreign messaging system, and servers, and between gateways and the foreign messaging system,
skipping to change at page 6, line 45 skipping to change at page 6, line 45
Because each server is identified by a network address (typically a Because each server is identified by a network address (typically a
DNS hostname) and because server-to-server communications are a DNS hostname) and because server-to-server communications are a
straightforward extension of the client-to-server protocol, in straightforward extension of the client-to-server protocol, in
practice the system consists of a network of servers that inter- practice the system consists of a network of servers that inter-
communicate. Thus user-a@domain1 is able to exchange messages, communicate. Thus user-a@domain1 is able to exchange messages,
presence, and other information with user-b@domain2. This pattern is presence, and other information with user-b@domain2. This pattern is
familiar from messaging protocols (such as SMTP) that make use of familiar from messaging protocols (such as SMTP) that make use of
network addressing standards. The usual method for providing a network addressing standards. The usual method for providing a
connection between two servers is to open a TCP socket on the IANA- connection between two servers is to open a TCP socket on the IANA-
assigned port 5269 and to negotiate a connection using the Dialback assigned port 5269 and to negotiate a connection using the Dialback
Protocol (Section 5.2) defined in this document. Protocol (Section 6.2) defined in this document.
3. Addressing Scheme 3. Addressing Scheme
3.1 Overview 3.1 Overview
Any entity that can be considered a network endpoint (i.e., an ID on An entity is anything that can be considered a network endpoint
the network) and that can communicate using XMPP is considered a (i.e., an ID on the network) and that can communicate using XMPP.
Jabber Entity. All such entities are uniquely addressable in a form All such entities are uniquely addressable in a form that is
that is consistent with RFC 2396 [7]. In particular, a valid Jabber consistent with RFC 2396 [8]. In particular, a valid Jabber
Identifier (JID) contains a set of ordered elements formed of a Identifier (JID) contains a set of ordered elements formed of a
domain identifier, node identifier, and resource identifier in the domain identifier, node identifier, and resource identifier in the
following format: [node@]domain[/resource]. following format: [node@]domain[/resource].
All JIDs are based on the foregoing structure. The most common use All JIDs are based on the foregoing structure. The most common use
of this structure is to identify an IM user, the server to which the of this structure is to identify an IM user, the server to which the
user connects, and the user's active session or connection (e.g., a user connects, and the user's active session or connection (e.g., a
specific client) in the form of user@domain/resource. However, node specific client) in the form of user@domain/resource. However, node
types other than clients are possible; for example, a specific chat types other than clients are possible; for example, a specific chat
room offered by a multi-user chat service could be addressed as room offered by a multi-user chat service could be addressed as
skipping to change at page 7, line 42 skipping to change at page 7, line 42
It usually represents the network gateway or "primary" server to It usually represents the network gateway or "primary" server to
which other entities connect for XML routing and data management which other entities connect for XML routing and data management
capabilities. However, the entity referenced by a domain identifier capabilities. However, the entity referenced by a domain identifier
is not always a server, and may be a service that is addressed as a is not always a server, and may be a service that is addressed as a
subdomain of a server and that provides functionality above and subdomain of a server and that provides functionality above and
beyond the capabilities of a server (a multi-user chat service, a beyond the capabilities of a server (a multi-user chat service, a
user directory, a gateway to a foreign messaging system, etc.). user directory, a gateway to a foreign messaging system, etc.).
The domain identifier for every server or service that will The domain identifier for every server or service that will
communicate over a network SHOULD resolve to a Fully Qualified Domain communicate over a network SHOULD resolve to a Fully Qualified Domain
Name. A domain identifier MUST conform to RFC 952 [8] and RFC 1123 Name. A domain identifier MUST conform to RFC 952 [9] and RFC 1123
[9]. A domain identifier MUST be no more than 1023 bytes in length, [10]. A domain identifier MUST be no more than 1023 bytes in length,
and is subject to comparison in accordance with the rules defined in and is subject to comparison in accordance with the rules defined in
nameprep [10] profile of stringprep [11]. the nameprep [11] profile of stringprep [12].
3.3 Node Identifier 3.3 Node Identifier
The node identifier is an optional secondary identifier. It usually The node identifier is an optional secondary identifier. It usually
represents the entity requesting and using network access provided by represents the entity requesting and using network access provided by
the server or gateway (e.g., a client), although it can also the server or gateway (i.e., a client), although it can also
represent other kinds of entities (e.g., a multi-user chat room represent other kinds of entities (e.g., a multi-user chat room
associated with a multi-user chat service). The entity represented associated with a multi-user chat service). The entity represented
by a node identifier is addressed within the context of a specific by a node identifier is addressed within the context of a specific
domain (e.g., user@domain). domain; in the context of IM users this address is called a "bare
JID" and is of the form <user@domain>.
A node identifier MUST be no more than 1023 bytes in length and MUST A node identifier MUST be no more than 1023 bytes in length and MUST
conform to the nodeprep [12] profile of stringprep [11]. conform to the nodeprep [13] profile of stringprep [12].
3.4 Resource Identifier 3.4 Resource Identifier
The resource identifer is an optional third identifier. It The resource identifer is an optional third identifier. It
represents a specific session, connection (e.g., a device or represents a specific session, connection (e.g., a device or
location), or object (e.g., a participant in a multi-user chat room) location), or object (e.g., a participant in a multi-user chat room)
belonging to the entity associated with a node identifier. An entity belonging to the entity associated with a node identifier. An entity
may maintain multiple resources simultaneously. may maintain multiple resources simultaneously.
A resource identifier MUST be no more than 1023 bytes in length and A resource identifier MUST be no more than 1023 bytes in length and
MUST conform to the resourceprep [13] profile of stringprep [11]. MUST conform to the resourceprep [14] profile of stringprep [12].
4. XML Streams 4. XML Streams
4.1 Overview 4.1 Overview
Two fundamental concepts make possible the rapid, asynchronous Two fundamental concepts make possible the rapid, asynchronous
exchange of relatively small payloads of structured information exchange of relatively small payloads of structured information
between presence-aware entities: XML streams and, as a result, between presence-aware entities: XML streams and, as a result,
discrete units of structured information that are referred to as "XML discrete units of structured information that are referred to as "XML
stanzas". (Note: in this overview we use the example of stanzas". (Note: in this overview we use the example of
communications between a client and server; however XML streams are communications between a client and server; however XML streams are
more generalized and may be used for communications from server to more generalized and may be used for communications from server to
server and from service to server as well.) server and from service to server as well.)
In order to connect to a server, a client must initiate an XML stream In order to connect to a server, a client must initiate an XML stream
by sending a <stream> tag to the server, optionally preceded by a by sending an opening <stream> tag to the server, optionally preceded
text declaration specifying the XML version supported and the by a text declaration specifying the XML version supported and the
character encoding. A compliant entity SHOULD accept any namespace character encoding. A compliant entity SHOULD accept any namespace
prefix on the <stream/> element; however, for historical reasons some prefix on the <stream/> element; however, for historical reasons some
entities MAY accept only a 'stream' prefix, resulting in use of a entities MAY accept only a 'stream' prefix, resulting in use of a
<stream:stream/> element. The server SHOULD then reply with a second <stream:stream/> element. The server SHOULD then reply with a second
XML stream back to the client, again optionally preceded by a text XML stream back to the client, again optionally preceded by a text
declaration. declaration.
Within the context of an XML stream, a sender is able to send a Within the context of an XML stream, a sender is able to send a
discrete semantic unit of structured information to any recipient. discrete semantic unit of structured information to any recipient.
This unit of structured information is a well-balanced XML stanza, This unit of structured information is a well-balanced XML stanza,
skipping to change at page 9, line 46 skipping to change at page 9, line 46
depth=1 (e.g., <presence>), and the end of any XML stanza is depth=1 (e.g., <presence>), and the end of any XML stanza is
unambiguously denoted by the corresponding close tag at depth=1 unambiguously denoted by the corresponding close tag at depth=1
(e.g., </presence>). Each XML stanza MAY contain child elements or (e.g., </presence>). Each XML stanza MAY contain child elements or
CDATA sections as necessary in order to convey the desired CDATA sections as necessary in order to convey the desired
information from the sender to the recipient. The session is closed information from the sender to the recipient. The session is closed
at the client's request by sending a closing </stream> tag to the at the client's request by sending a closing </stream> tag to the
server (a session may also be closed by the server). server (a session may also be closed by the server).
Thus a client's session with a server can be seen as two open-ended Thus a client's session with a server can be seen as two open-ended
XML documents that are built up through the accumulation of the XML XML documents that are built up through the accumulation of the XML
stanzas that are sent over the course of the session (one from the stanzas sent over the course of the session (one from the client to
client to the server and one from the server to the client), and the the server and one from the server to the client), and the root
root <stream/> element can be considered the document entity for <stream/> element can be considered the document entity for those
those streams. In essence, then, an XML stream acts as an envelope streams. In essence, then, an XML stream acts as an envelope for all
for all the XML stanzas sent during a session. We can represent this the XML stanzas sent during a session. We can represent this
graphically as follows: graphically as follows:
|-------------------| |-------------------|
| <stream> | | <stream> |
|-------------------| |-------------------|
| <message to=''> | | <message to=''> |
| <body/> | | <body/> |
| </message> | | </message> |
|-------------------| |-------------------|
| <presence to=''> | | <presence to=''> |
skipping to change at page 11, line 35 skipping to change at page 11, line 35
| initiating to receiving | receiving to initiating | initiating to receiving | receiving to initiating
------------------------------------------------------------ ------------------------------------------------------------
to | JID of receiver | ignored to | JID of receiver | ignored
from | ignored | JID of receiver from | ignored | JID of receiver
id | ignored | session key id | ignored | session key
version | signals XMPP 1.0 support | signals XMPP 1.0 support version | signals XMPP 1.0 support | signals XMPP 1.0 support
4.4 Namespace Declarations 4.4 Namespace Declarations
The stream element MAY also contain namespace declarations as defined The stream element MAY also contain namespace declarations as defined
in the XML namespaces specification [14]. in the XML namespaces specification [15].
A default namespace declaration ('xmlns') is REQUIRED and is used in A default namespace declaration ('xmlns') is REQUIRED and is used in
both XML streams in order to scope the allowable first-level children both XML streams in order to scope the allowable first-level children
of the root stream element for both streams. This namespace of the root stream element for both streams. This namespace
declaration MUST be the same for the initiating stream and the declaration MUST be the same for the initiating stream and the
responding stream so that both streams are scoped consistently. The responding stream so that both streams are scoped consistently. The
default namespace declaration applies to the stream and all stanzas default namespace declaration applies to the stream and all stanzas
sent within a stream. sent within a stream.
A stream namespace declaration (e.g., 'xmlns:stream') is REQUIRED in A stream namespace declaration (e.g., 'xmlns:stream') is REQUIRED in
both XML streams. A compliant entity SHOULD accept any namespace both XML streams. A compliant entity SHOULD accept any namespace
prefix on the <stream/> element; however, for historical reasons some prefix on the <stream/> element; however, for historical reasons some
entities MAY accept only a 'stream' prefix, resulting in use of a entities MAY accept only a 'stream' prefix, resulting in use of a
<stream:stream/> element as the stream root. The value of the stream <stream:stream/> element as the stream root. The name of the stream
namespace MUST be "http://etherx.jabber.org/streams". namespace MUST be "http://etherx.jabber.org/streams".
XML streams function as containers for any XML stanzas sent XML streams function as containers for any XML stanzas sent
asynchronously between network endpoints. It should be possible to asynchronously between network endpoints. It should be possible to
scope an XML stream with any default namespace declaration, i.e., it scope an XML stream with any default namespace declaration, i.e., it
should be possible to send any properly-namespaced XML stanza over an should be possible to send any properly-namespaced XML stanza over an
XML stream. A compliant implementation MUST support the following XML stream. A compliant implementation MUST support the following
two namespaces (for historical reasons, existing implementations MAY two namespaces (for historical reasons, existing implementations MAY
support only these two default namespaces): support only these two default namespaces):
skipping to change at page 12, line 28 skipping to change at page 12, line 28
The jabber:client and jabber:server namespaces are nearly identical The jabber:client and jabber:server namespaces are nearly identical
but are used in different contexts (client-to-server communications but are used in different contexts (client-to-server communications
for jabber:client and server-to-server communications for for jabber:client and server-to-server communications for
jabber:server). The only difference between the two is that the 'to' jabber:server). The only difference between the two is that the 'to'
and 'from' attributes are OPTIONAL on stanzas sent within and 'from' attributes are OPTIONAL on stanzas sent within
jabber:client, whereas they are REQUIRED on stanzas sent within jabber:client, whereas they are REQUIRED on stanzas sent within
jabber:server. If a compliant implementation accepts a stream that jabber:server. If a compliant implementation accepts a stream that
is scoped by the 'jabber:client' or 'jabber:server' namespace, it is scoped by the 'jabber:client' or 'jabber:server' namespace, it
MUST support all three core stanza types (message, presence, and IQ) MUST support all three core stanza types (message, presence, and IQ)
as described herein and defined in the DTD and schema. as described herein and defined in the schema.
4.5 Stream Features 4.5 Stream Features
The root stream element MAY contain a features child element (e.g., The root stream element MAY contain a features child element (e.g.,
<stream:features/> if the stream namespace prefix is 'stream'). This <stream:features/> if the stream namespace prefix is 'stream'). This
is used to communicate generic stream-level capabilities including is used to communicate generic stream-level capabilities including
stream-level features that can be negotiated as the streams are set stream-level features that can be negotiated as the streams are set
up. If the initiating entity sends a "version='1.0'" attribute in up. If the initiating entity sends a "version='1.0'" attribute in
its initiating stream element, the receiving entity MUST send a its initiating stream element, the receiving entity MUST send a
features child element to the initiating entity if there are any features child element to the initiating entity if there are any
capabilities that need to be advertised or features that can be capabilities that need to be advertised or features that can be
negotiated for the stream. Currently this is used for SASL and TLS negotiated for the stream. Currently this is used for SASL and TLS
negotiation only, but it could be used for other negotiable features negotiation only, but it could be used for other negotiable features
in the future (examples are shown under Stream Authentication in the future (usage is defined under Stream Encryption (Section 5)
(Section 5) below). If an entity does not understand or support some and Stream Authentication (Section 6) below). If an entity does not
features, it SHOULD ignore them. understand or support some features, it SHOULD ignore them.
4.6 Stream Errors 4.6 Stream Errors
The root stream element MAY contain an error child element (e.g., The root stream element MAY contain an error child element (e.g.,
<stream:error/> if the stream namespace prefix is 'stream'). The <stream:error/> if the stream namespace prefix is 'stream'). The
error child MUST be sent by a Jabber entity (usually a server rather error child MUST be sent by a Jabber entity (usually a server rather
than a client) if it perceives that a stream-level error has than a client) if it perceives that a stream-level error has
occurred. Examples of error conditions include the sending of occurred. Examples of error conditions include the sending of
invalid XML, the shutdown of a server, an internal server error such invalid XML, the shutdown of a server, an internal server error such
as the shutdown of a session manager, and inclusion of an unsupported as the shutdown of a session manager, and inclusion of an unsupported
version number in the initiating stream header. It is assumed that version number in the initiating stream header. It is assumed that
all stream-level errors are unrecoverable; therefore, if an error all stream-level errors are unrecoverable; therefore, if an error
occurs at the level of the stream, the entity that detects the error occurs at the level of the stream, the entity that detects the error
MUST send a stream error to the other entity and then send a closing MUST send a stream error to the other entity and then send a closing
</stream> tag. Specifically, XML of the following form is sent </stream> tag. Specifically, XML of the following form is sent
within the context of an existing stream (the error element MUST within the context of an existing stream (the error element MUST
possess the 'code' attribute and MAY include CDATA): possess the 'code' attribute):
<stream:stream ...> <stream:stream ...>
... ...
<stream:error code='400'> <stream:error code='400'/>
Optional text description (e.g., "Bad XML")
</stream:error>
</stream:stream> </stream:stream>
If the error occurs while the stream is being set up, the receiving If the error occurs while the stream is being set up, the receiving
entity MUST still send the opening and closing stream tags and entity MUST still send the opening and closing stream tags and
include the error element as a child of the stream element. The include the error element as a child of the stream element. The
following example illustrates this principle (where the "C" lines are following example illustrates this principle (where the "C" lines are
sent from the client to the server, and the "S" lines are sent from sent from the client to the server, and the "S" lines are sent from
the server to the client): the server to the client):
C: <stream:stream C: <stream:stream
skipping to change at page 14, line 4 skipping to change at page 13, line 49
If the initiating entity provides an unknown host in the 'to' If the initiating entity provides an unknown host in the 'to'
attribute (or provides no 'to' attribute at all), the server SHOULD attribute (or provides no 'to' attribute at all), the server SHOULD
provide the server's authoritative hostname in the 'from' attribute provide the server's authoritative hostname in the 'from' attribute
of the stream header. of the stream header.
The following codes are defined for stream-level errors: The following codes are defined for stream-level errors:
o 302 - Redirect o 302 - Redirect
o 400 - Bad XML o 400 - Bad XML
o 404 - Unknown Host
o 404 - Unknown Host
o 410 - Gone o 410 - Gone
o 500 - Internal Server Error o 500 - Internal Server Error
o 505 - Version Not Supported o 505 - Version Not Supported
If the error is 302 ("Redirect"), the server SHOULD include CDATA If the error is 302 ("Redirect"), the server SHOULD include CDATA
specifying the alternate hostname or IP address to which the specifying the alternate hostname or IP address to which the
initiating entity may attempt to connect. initiating entity may attempt to connect.
skipping to change at page 16, line 5 skipping to change at page 16, line 5
<stream:stream <stream:stream
from='server' from='server'
id='id_123456789' id='id_123456789'
xmlns='jabber:client' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams' xmlns:stream='http://etherx.jabber.org/streams'
version='1.0'> version='1.0'>
C: <message><body>Bad XML, no closing body tag!</message> C: <message><body>Bad XML, no closing body tag!</message>
S: <stream:error code='400'/> S: <stream:error code='400'/>
S: </stream:stream> S: </stream:stream>
5. Stream Authentication 5. Stream Encryption
5.1 Overview
XMPP includes a method for securing the stream from tampering and
eavesdropping. This channel encryption method makes use of the
Transport Layer Security (TLS) [17] protocol, along with a "STARTTLS"
extension that is modelled on similar extensions for the IMAP [18],
POP3 [19], and ACAP [20] protocols as described in RFC 2595 [21].
The namespace identifier for the STARTTLS extension is 'http://
www.ietf.org/rfc/rfc2595.txt'. TLS may be used between any
initiating entity and any receiving entity (e.g., a stream from a
client to a server or from one server to another).
The following rules MUST be observed:
1. If the initiating entity is capable of using the STARTTLS
extension, it MUST include the "version='1.0'" flag in the
initiating stream header.
2. If the receiving entity is capable of using the STARTTLS
extension, it MUST send the <starttls/> element in the defined
namespace along with the list of features that it sends in
response to the opening stream tag received from the initiating
entity.
3. If the initiating entity chooses to use TLS for stream
encryption, TLS negotiation MUST be completed before proceeding
to authenticate the stream using SASL.
4. If TLS is used for stream encryption, the receiving entity MUST
close the stream whether the TLS negotiation results in success
or failure.
5. If the TLS negotiation is successful, TLS takes effect
immediately following the closing ">" character of the <starttls/
> element for the client and immediately following the closing
">" character of the <proceed> element for the server. A new
stream MUST then be initiated by the initiating entity.
6. If the TLS negotiation is successful, the receiving entity MUST
discard any knowledge obtained from the initiating entity before
TLS takes effect.
7. If the TLS negotiation is successful, the initiating entity MUST
discard any knowledge obtained from the receiving entity before
TLS takes effect.
8. If the TLS negotiation is successful, the receiving entity MUST
NOT offer the STARTTLS extension to the initiating entity along
with the other stream features that are offered when the stream
is restarted.
9. If TLS is used for stream encryption, SASL MUST NOT be used for
anything but stream authentication (i.e., a security layer MUST
NOT be negotiated using SASL). Conversely, if a security layer
is to be negotiated via SASL, TLS MUST NOT be used.
5.2 Narrative
When a client secures a stream with a server, the steps involved are
as follows:
1. The client opens a TCP connection and initiates the stream by
sending the opening XML stream header to the server, including
the "version='1.0'" flag.
2. The server responds by opening a TCP connection and sending an
XML stream header to the client.
3. The server offers the STARTTLS extension to the client by sending
it along with the list of supported stream features.
4. The client issues the STARTTLS command to instruct the server
that it wishes to begin a TLS negotiation to secure the stream.
5. The server MUST reply with either an empty <proceed/> element or
an empty <failure/> element, but keep the underlying TCP
connection open.
6. The client begins a TLS negotiation in accordance with RFC 2246
[17]. Upon completion of the negotiation, the client initiates a
new stream by sending a new opening XML stream header to the
server.
7. The server responds by sending an XML stream header to the client
along with the remaining available features (but NOT including
the STARTTLS element).
5.3 Client-Server Protocol
The following example shows the data flow for a client securing a
stream using STARTTLS.
Step 1: Client initiates stream to server:
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
to='capulet.com'
version='1.0'>
Step 2: Server responds by sending a stream tag to the client:
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
id='12345678'
version='1.0'>
Step 3: Server sends the STARTTLS extension to the client along with
authentication mechanisms and any other stream features:
<stream:features>
<starttls xmlns='http://www.ietf.org/rfc/rfc2595.txt'/>
<mechanisms xmlns='http://www.iana.org/assignments/sasl-mechanisms'>
<mechanism>DIGEST-MD5</mechanism>
<mechanism>PLAIN</mechanism>
</mechanisms>
</stream:features>
Step 4: Client sends the STARTTLS command to the server:
<starttls xmlns='http://www.ietf.org/rfc/rfc2595.txt'/>
Step 5: Server informs client to proceed:
<proceed xmlns='http://www.ietf.org/rfc/rfc2595.txt'/>
Step 5 (alt): Server informs client that TLS negotiation has faile
has failedd:
<failure xmlns='http://www.ietf.org/rfc/rfc2595.txt'/>
Step 6: Client and server complete TLS negotiation via TCP. When
finished, the client initiates a new stream to the server:
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
to='capulet.com'
version='1.0'>
Step 7: Server responds by sending a stream header to the client
along with any remaining negotiatiable stream features:
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
id='12345678'
version='1.0'>
<stream:features>
<mechanisms xmlns='http://www.iana.org/assignments/sasl-mechanisms'>
<mechanism>DIGEST-MD5</mechanism>
<mechanism>PLAIN</mechanism>
<mechanism>EXTERNAL</mechanism>
</mechanisms>
</stream:features>
5.4 Certificate-Based Authentication
If the client presents a valid client certificate during the TLS
negotiation, the server MAY offer the SASL EXTERNAL mechanism to the
client during stream authentication. (see RFC 2222 [16]). If the
client selects this mechanism for authentication, the authentication
credentials shall be taken from the presented certificate.
6. Stream Authentication
XMPP includes two methods for enforcing authentication at the level XMPP includes two methods for enforcing authentication at the level
of XML streams. When one entity is already known to another (i.e., of XML streams. When one entity is already known to another (i.e.,
there is an existing trust relationship between the entities such as there is an existing trust relationship between the entities such as
that established when a user registers with a server or an that established when a user registers with a server or an
administrator configures a server to trust another server), the administrator configures a server to trust another server), the
preferred method for authenticating streams between the two entities preferred method for authenticating streams between the two entities
uses an XMPP adaptation of the Simple Authentication and Security uses an XMPP adaptation of the Simple Authentication and Security
Layer (SASL) [15]. When there is no existing trust relationship Layer (SASL) [16]. When there is no existing trust relationship
between the two entities, such trust MAY be established based on between the two entities, such trust MAY be established based on
existing trust in DNS; the authentication method used when two such existing trust in DNS; the authentication method used when two such
entities are servers is the server dialback protocol that is native entities are servers is the server dialback protocol that is native
to XMPP (no such ad-hoc method is defined between a client and a to XMPP (no such ad-hoc method is defined between a client and a
server). Both of these methods are described in this section. server). Both of these methods are described in this section.
5.1 SASL Authentication Stream authentication is REQUIRED for all direct communications
between two entities; if an entity sends a stanza to an
unauthenticated stream, the receiving entity SHOULD silently drop the
stanza and MUST NOT process it.
5.1.1 Overview 6.1 SASL Authentication
6.1.1 Overview
The Simple Authentication and Security Layer (SASL) provides a The Simple Authentication and Security Layer (SASL) provides a
generalized method for adding authentication support to connection- generalized method for adding authentication support to connection-
based protocols. XMPP uses a generic XML namespace profile for SASL based protocols. XMPP uses a generic XML namespace profile for SASL
that conforms to section 4 ("Profiling Requirements") of RFC 2222 that conforms to section 4 ("Profiling Requirements") of RFC 2222
[15] (the namespace identifier for this protocol is 'http:// [16] (the namespace identifier for this protocol is 'http://
www.iana.org/assignments/sasl-mechanisms'). If an entity (client or www.iana.org/assignments/sasl-mechanisms').
server) is capable of authenticating by means of SASL, it MUST
include a 'version' attribute (set to a value of "1.0") within the
opening <stream/> tag.
The following example shows the use of SASL in client authentication The following rules MUST be observed:
with a server, for which the steps involved are as follows:
1. If TLS is used for stream encryption, SASL MUST NOT be used for
anything but stream authentication (i.e., a security layer MUST
NOT be negotiated using SASL). Conversely, if a security layer
is to be negotiated via SASL, TLS MUST NOT be used.
2. If the initiating entity is capable of authenticating via SASL,
it it MUST include the "version='1.0'" flag in the initiating
stream header.
3. If the receiving entity is capable of accepting authentications
via SASL, it MUST send one or more authentication mechanisms
within a <mechanisms/> element in response to the opening stream
tag received from the initiating entity.
4. If the SASL negotiation involves negotiation of a security layer,
the receiving entity MUST discard any knowledge obtained from the
initiating entity which was not obtained from the SASL
negotiation itself.
5. If the SASL negotiation involves negotiation of a security layer,
the initiating entity MUST discard any knowledge obtained from
the receiving entity which was not obtained from the SASL
negotiation itself.
6.1.2 Narrative
When a client authenticates with a server, the steps involved are as
follows:
1. The client requests SASL authentication by including a 'version' 1. The client requests SASL authentication by including a 'version'
attribute in the opening XML stream header sent to the server, attribute in the opening XML stream header sent to the server,
with the value set to "1.0". with the value set to "1.0".
2. After sending an XML stream header in response, the server sends 2. After sending an XML stream header in response, the server sends
a list of available SASL authentication mechanisms, each of which a list of available SASL authentication mechanisms, each of which
is a <mechanism/> element included as a child within a is a <mechanism/> element included as a child within a
<mechanisms/> container element that is sent as a first-level <mechanisms/> container element that is sent as a child of the
child of the root <stream/> element. first-level <features/> element. If channel encryption must be
established before a particular authentication mechanism may be
used, the server MUST NOT provide that mechanism in the list of
available SASL authentication methods.
3. The client selects a mechanism by sending an <auth/> element to 3. The client selects a mechanism by sending an <auth/> element to
the server; this element MAY optionally contain character data if the server; this element MAY optionally contain character data
the mechanism supports or requires it. (in SASL terminology the "initial response") if the mechanism
supports or requires it.
4. If necessary, the server challenges the client by sending a 4. If necessary, the server challenges the client by sending a
<challenge/> element to the client; this element MAY optionally <challenge/> element to the client; this element MAY optionally
contain character data. contain character data.
5. The client responds to the challenge by sending a <response/> 5. The client responds to the challenge by sending a <response/>
element to the server; this element MAY optionally contain element to the server; this element MAY optionally contain
character data. character data.
6. If necessary, the server sends more challenges and the client 6. If necessary, the server sends more challenges and the client
sends more responses. sends more responses.
This series of challenge/response pairs continues until one of three This series of challenge/response pairs continues until one of three
things happens: things happens:
o The client aborts the handshake by sending an <abort/> element to 1. The client aborts the handshake by sending an <abort/> element to
the server. the server.
o The server reports failure by sending a <failure/> element to the 2. The server reports failure of the handshake by sending a
client. <failure/> element to the client. The particular cause of
failure optionally may be communicated in the 'code' attribute of
the <failure/> element, and may be any one of 432 (password
transition is needed), 534 (authentication mechanism is too
weak), or 454 (temporary authentication failure).
o The server reports success by sending a <success/> element to the 3. The server reports success of the handshake by sending a
client; this element MAY optionally contain character data. <success/> element to the client; this element MAY optionally
contain character data (in SASL terminology "additional data with
success").
Any character data contained within these elements MUST be encoded Any character data contained within these elements MUST be encoded
using base64. using base64.
5.1.2 Client-Server Example 6.1.3 SASL Definition
Section 4 of the SASL specification [16] requires that the following
information be supplied by a protocol definition:
service name: "xmpp"
initiation sequence: After the initiating entity provides an opening
XML stream header and the receiving entity replies in kind, the
receiving entity provides a list of acceptable authentication
methods. The initiating entity chooses one method from the list
and sends it to the receiving entity as the value of the
'mechanism' attribute possesed by an <auth/> element, optionally
including an initial response to avoid a round trip.
exchange sequence: Challenges and responses are carried through the
exchange of <challenge/> elements from receiving entity to
initiating entity and <response/> elements from initiating entity
to receiving entity. The receiving entity reports failure by
sending a <failure/> element and success by sending a <success/>
element; the initiating entity aborts the exchange by sending an
<abort/> element.
security layer negotiation: If a security layer is negotiated, both
sides consider the original stream closed and new <stream/>
headers are sent by both entities. The security layer takes
effect immediately following the ">" character of the empty
<response/> element for the client and immediately following the
closing ">" character of the <succeed/> element for the server.
use of the authorization identity: The authorization identity, if
present, is unused by xmpp.
6.1.4 Client-Server Protocol
The following example shows the data flow for a client authenticating The following example shows the data flow for a client authenticating
with a server using SASL. with a server using SASL.
Step 1: Client initiates stream to server: Step 1: Client initiates stream to server:
<stream:stream <stream:stream
xmlns='jabber:client' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams' xmlns:stream='http://etherx.jabber.org/streams'
to='capulet.com' to='domain'
version='1.0'> version='1.0'>
Step 2: Server responds with a stream tag sent to the client: Step 2: Server responds with a stream tag sent to the client:
<stream:stream <stream:stream
xmlns='jabber:client' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams' xmlns:stream='http://etherx.jabber.org/streams'
id='12345678' id='12345678'
from='domain'
version='1.0'> version='1.0'>
Step 3: Server informs client of available authentication mechanisms: Step 3: Server informs client of available authentication mechanisms:
<stream:features> <stream:features>
<mechanisms xmlns='http://www.iana.org/assignments/sasl-mechanisms'> <mechanisms xmlns='http://www.iana.org/assignments/sasl-mechanisms'>
<mechanism>DIGEST-MD5</mechanism> <mechanism>DIGEST-MD5</mechanism>
<mechanism>PLAIN</mechanism> <mechanism>PLAIN</mechanism>
</mechanisms> </mechanisms>
</stream:features> </stream:features>
Step 4: Client selects an authentication mechanism: Step 4: Client selects an authentication mechanism ("initial
response"):
<auth <auth
xmlns='http://www.iana.org/assignments/sasl-mechanisms' xmlns='http://www.iana.org/assignments/sasl-mechanisms'
mechanism='DIGEST-MD5'/> mechanism='DIGEST-MD5'/>
Step 5: Server sends a base64-encoded challenge to the client: Step 5: Server sends a base64-encoded challenge to the client:
<challenge xmlns='http://www.iana.org/assignments/sasl-mechanisms'> <challenge xmlns='http://www.iana.org/assignments/sasl-mechanisms'>
cmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIi cmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIi
xxb3A9ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNz xxb3A9ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNz
</challenge> </challenge>
The decoded challenge is: The decoded challenge is:
realm="cataclysm.cx",nonce="OA6MG9tEQGm2hh",\ qop="auth",charset=utf- realm="cataclysm.cx",nonce="OA6MG9tEQGm2hh",\ qop="auth",charset=utf-
skipping to change at page 18, line 35 skipping to change at page 24, line 20
The decoded challenge is: The decoded challenge is:
realm="cataclysm.cx",nonce="OA6MG9tEQGm2hh",\ qop="auth",charset=utf- realm="cataclysm.cx",nonce="OA6MG9tEQGm2hh",\ qop="auth",charset=utf-
8,algorithm=md5-sess 8,algorithm=md5-sess
Step 6: Client responds to the challenge: Step 6: Client responds to the challenge:
<response xmlns='http://www.iana.org/assignments/sasl-mechanisms'> <response xmlns='http://www.iana.org/assignments/sasl-mechanisms'>
dXNlcm5hbWU9InJvYiIscmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik dXNlcm5hbWU9InJvYiIscmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik
9BNk1HOXRFUUdtMmhoIixjbm9uY2U9Ik9BNk1IWGg2VnFUclJrIixuYz0w 9BNk1HOXRFUUdtMmhoIixcIGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5j
MDAwMDAwMSxxb3A9YXV0aCxkaWdlc3QtdXJpPSJqYWJiZXIvY2F0YWNseX PTAwMDAwMDAxLHFvcD1hdXRoLFwgZGlnZXN0LXVyaT0ieG1wcC9jYXRhY2
NtLmN4IixyZXNwb25zZT1kMzg4ZGFkOTBkNGJiZDc2MGExNTIzMjFmMjE0 x5c20uY3giLFwgcmVzcG9uc2U9ZDM4OGRhZDkwZDRiYmQ3NjBhMTUyMzIxZ
M2FmNyxjaGFyc2V0PXV0Zi04 jIxNDNhZjcsY2hhcnNldD11dGYtOA==
</response> </response>
The decoded response is: The decoded response is:
username="rob",realm="cataclysm.cx",nonce="OA6MG9tEQGm2hh",\ username="rob",realm="cataclysm.cx",nonce="OA6MG9tEQGm2hh",\
cnonce="OA6MHXh6VqTrRk",nc=00000001,qop=auth,\ digest-uri="jabber/ cnonce="OA6MHXh6VqTrRk",nc=00000001,qop=auth,\ digest-uri="xmpp/
cataclysm.cx",\ cataclysm.cx",\
response=d388dad90d4bbd760a152321f2143af7,charset=utf-8 response=d388dad90d4bbd760a152321f2143af7,charset=utf-8
Step 7: Server sends another challenge to the client: Step 7: Server sends another challenge to the client:
<challenge xmlns='http://www.iana.org/assignments/sasl-mechanisms'> <challenge xmlns='http://www.iana.org/assignments/sasl-mechanisms'>
cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA== cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA==
</challenge> </challenge>
The decoded challenge is: The decoded challenge is:
rspauth=ea40f60335c427b5527b84dbabcdfffd rspauth=ea40f60335c427b5527b84dbabcdfffd
skipping to change at page 19, line 17 skipping to change at page 25, line 4
cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA== cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA==
</challenge> </challenge>
The decoded challenge is: The decoded challenge is:
rspauth=ea40f60335c427b5527b84dbabcdfffd rspauth=ea40f60335c427b5527b84dbabcdfffd
Step 8: Client responds to the challenge: Step 8: Client responds to the challenge:
<response xmlns='http://www.iana.org/assignments/sasl-mechanisms'/> <response xmlns='http://www.iana.org/assignments/sasl-mechanisms'/>
Step 9: Server informs client of successful authentication: Step 9: Server informs client of successful authentication:
<success xmlns='http://www.iana.org/assignments/sasl-mechanisms'/> <success xmlns='http://www.iana.org/assignments/sasl-mechanisms'/>
Step 9 (alt): Server informs client of failed authentication: Step 9 (alt): Server informs client of failed authentication:
<failure xmlns='http://www.iana.org/assignments/sasl-mechanisms'/> <failure code='454'
xmlns='http://www.iana.org/assignments/sasl-mechanisms'/>
5.2 Dialback Authentication Step 10: Client initiates a new stream to the server:
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
to='domain'
version='1.0'>
Step 11: Server responds by sending a stream header to the client,
with the stream already authenticated (not followed by further stream
features):
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
id='12345678'
from='domain'
version='1.0'>
6.2 Dialback Authentication
XMPP includes a protocol-level method for verifying that a connection XMPP includes a protocol-level method for verifying that a connection
between two servers can be trusted (at least as much as the DNS can between two servers can be trusted (at least as much as the DNS can
be trusted). The method is called dialback and is used only within be trusted). The method is called dialback and is used only within
XML streams that are declared under the "jabber:server" namespace. XML streams that are declared under the "jabber:server" namespace.
The purpose of the dialback protocol is to make server spoofing more The purpose of the dialback protocol is to make server spoofing more
difficult, and thus to make it more difficult to forge XML stanzas. difficult, and thus to make it more difficult to forge XML stanzas.
Dialback is not intended as a mechanism for securing or encrypting Dialback is not intended as a mechanism for securing or encrypting
the streams between servers, only for helping to prevent the spoofing the streams between servers, only for helping to prevent the spoofing
of a server and the sending of false data from it. Dialback is made of a server and the sending of false data from it. Dialback is made
possible by the existence of DNS, since one server can verify that possible by the existence of DNS, since one server can verify that
another server which is connecting to it is authorized to represent a another server which is connecting to it is authorized to represent a
given server on the Jabber network. All DNS hostname resolutions given server on the Jabber network. All DNS hostname resolutions
MUST first resolve the hostname using an SRV [22] record of MUST first resolve the hostname using an SRV [23] record of
_jabber._tcp.server. If the SRV lookup fails, the fallback is a _jabber._tcp.server. If the SRV lookup fails, the fallback is a
normal A lookup to determine the IP address, using the jabber-server normal A lookup to determine the IP address, using the jabber-server
port of 5269 assigned by the Internet Assigned Numbers Authority [6]. port of 5269 assigned by the Internet Assigned Numbers Authority [7].
Note that the method used to generate and verify the keys used in the Note that the method for generating and verifying the keys used in
dialback protocol MUST take into account the hostnames being used, the dialback protocol MUST take into account the hostnames being
along with a secret known only by the receiving server and the random used, along with a secret known only by the receiving server and the
ID generated for the stream. Generating unique but verifiable keys random ID generated for the stream. Generating unique but verifiable
is important to prevent common man-in-the-middle attacks and server keys is important to prevent common man-in-the-middle attacks and
spoofing. server spoofing.
In the description that follows we use the following terminology: In the description that follows we use the following terminology:
o Originating Server -- the server that is attempting to establish a o Originating Server -- the server that is attempting to establish a
connection between the two servers connection between the two servers
o Receiving Server -- the server that is trying to authenticate that o Receiving Server -- the server that is trying to authenticate that
Originating Server represents the Jabber server which it claims to Originating Server represents the Jabber server which it claims to
be be
skipping to change at page 21, line 33 skipping to change at page 27, line 38
| send dialback key | | send dialback key |
| ----------------------> | | ----------------------> |
| | | |
| validate dialback key | | validate dialback key |
| <---------------------- | | <---------------------- |
| |
| report dialback result | | report dialback result |
| <---------------------- | | <---------------------- |
| | | |
5.2.1 Dialback Protocol 6.2.1 Dialback Protocol
The traffic sent between the servers is as follows: The traffic sent between the servers is as follows:
1. Originating Server establishes TCP connection to Receiving 1. Originating Server establishes TCP connection to Receiving
Server Server
2. Originating Server sends a stream header to Receiving Server 2. Originating Server sends a stream header to Receiving Server
(the 'to' and 'from' attributes are NOT REQUIRED on the root (the 'to' and 'from' attributes are NOT REQUIRED on the root
stream element): stream element):
skipping to change at page 24, line 5 skipping to change at page 31, line 5
a type='valid', or reported as invalid. Once the connection is a type='valid', or reported as invalid. Once the connection is
validated, data can be sent by Originating Server and read by validated, data can be sent by Originating Server and read by
Receiving Server; before that, all data stanzas sent to Receiving Server; before that, all data stanzas sent to
Receiving Server SHOULD be dropped. As a final guard against Receiving Server SHOULD be dropped. As a final guard against
domain spoofing, Receiving Server MUST verify that all XML domain spoofing, Receiving Server MUST verify that all XML
stanzas received from Originating Server include a 'from' stanzas received from Originating Server include a 'from'
attribute and that the value of that attribute includes the attribute and that the value of that attribute includes the
validated domain. In addition, all XML stanzas MUST include a validated domain. In addition, all XML stanzas MUST include a
'to' attribute. 'to' attribute.
6. Stream Encryption
6.1 Overview
XMPP includes a method for securing the stream from tampering and
eavesdropping. This channel encryption method makes use of the
Transport Layer Security (TLS) [16] protocol, along with a "STARTTLS"
extension that is modelled on similar extensions for the IMAP [17],
POP3 [18], and ACAP [19] protocols as described in RFC 2595 [20].
The namespace identifier for the STARTTLS extension is 'http://
www.ietf.org/rfc/rfc2595.txt'. If an entity (client or server) is
capable of using this extension, it MUST include the <starttls/>
element in this namespace with the list of features that it sends in
response to the opening stream tag that was used to initiate
communications.
The following example shows the use of STARTTLS by a client to secure
a session with a server, for which the steps involved are as follows:
1. The client opens a TCP connection and initiates the stream by
sending the opening XML stream header to the server.
2. The server responds by opening a TCP connection and sending an
XML stream header to the client.
3. The server offers the STARTTLS extension to the client by
including it in the list of supported stream features.
4. The client issues the STARTTLS command to instruct the server
that it wishes to begin a TLS negotiation to secure the stream.
5. The server closes the XML stream, but keeps the underlying TCP
connection open. If the server is unable to prepare for the TLS
negotiation for some reason, it returns an error.
6. The client begins a TLS negotiation according to RFC 2246 [16].
Upon completion of the negotiation, the client initiates a new
stream by sending a new opening XML stream header to the server.
7. The server responds by sending an XML stream header to the
client.
Once the stream is secured, the server MUST NOT offer the STARTTLS
extension to the client.
6.2 Client-Server Example
The following example shows the data flow for a client securing a
stream using STARTTLS.
Step 1: Client initiates stream to server:
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
to='capulet.com'
version='1.0'>
Step 2: Server responds by sending a stream tag to the client:
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
id='12345678'
version='1.0'>
Step 3: Server sends STARTTLS extensions to the client along with
authentication mechanisms and any other stream features:
<stream:features>
<starttls xmlns='http://www.ietf.org/rfc/rfc2595.txt'/>
<mechanisms xmlns='http://www.iana.org/assignments/sasl-mechanisms'>
<mechanism>DIGEST-MD5</mechanism>
<mechanism>PLAIN</mechanism>
</mechanisms>
</stream:features>
Step 4: Client sends the STARTTLS command to the server:
<starttls xmlns='http://www.ietf.org/rfc/rfc2595.txt'/>
Step 5: Server closes the stream:
</stream:stream>
Step 5 (alt): Server fails to prepare for the TLS negotiation:
<error xmlns='http://www.ietf.org/rfc/rfc2595.txt'/>
Step 6: Client begins TLS negotiation. When it has finished, it
initiates a new stream to the server:
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
to='capulet.com'
version='1.0'>
Step 7: Server responds by sending a stream tag to the client:
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
id='12345678'
version='1.0'>
<stream:features>
<mechanisms xmlns='http://www.iana.org/assignments/sasl-mechanisms'>
<mechanism>DIGEST-MD5</mechanism>
<mechanism>PLAIN</mechanism>
<mechanism>EXTERNAL</mechanism>
</mechanisms>
</stream:features>
6.3 Certificate-Based Authentication
If the client presents a valid client certificate during the TLS
negotiation, the server MAY offer the SASL EXTERNAL mechanism to the
client (see RFC 2222 [15]). If the client selects this mechanism for
authentication, the authentication credentials shall be taken from
the presented certificate.
7. XML Stanzas 7. XML Stanzas
7.1 Overview 7.1 Overview
Once the XML streams in each direction have been authenticated and Once the XML streams in each direction have been authenticated and
(if desired) encrypted, XML stanzas can be sent over the streams. (if desired) encrypted, XML stanzas can be sent over the streams.
XML stanzas are the three core data elements for XMPP communications: XML stanzas are the three core data elements for XMPP communications:
<message/>, <presence/>, and <iq/>. These elements are sent as <message/>, <presence/>, and <iq/>. These elements are sent as
direct (depth=1) children of the root <stream/> element and are direct (depth=1) children of the root <stream/> element and are
scoped by one of the default namespaces identified in Section 4.4. scoped by one of the default namespaces identified in Section 4.4.
skipping to change at page 28, line 32 skipping to change at page 32, line 32
the following sections. the following sections.
7.2.5 xml:lang 7.2.5 xml:lang
Any message or presence stanza MAY possess an 'xml:lang' attribute Any message or presence stanza MAY possess an 'xml:lang' attribute
specifying the default language of any CDATA sections of the stanza specifying the default language of any CDATA sections of the stanza
or its child elements. An IQ stanza SHOULD NOT possess an 'xml:lang' or its child elements. An IQ stanza SHOULD NOT possess an 'xml:lang'
attribute, since it is merely a vessel for data in other namespaces attribute, since it is merely a vessel for data in other namespaces
and does not itself contain children that have CDATA. The value of and does not itself contain children that have CDATA. The value of
the 'xml:lang' attribute MUST be an NMTOKEN and MUST conform to the the 'xml:lang' attribute MUST be an NMTOKEN and MUST conform to the
format defined in RFC 3066 [21]. format defined in RFC 3066 [22].
7.3 Message Stanzas 7.3 Message Stanzas
Message stanzas in the 'jabber:client' or 'jabber:server' namespace Message stanzas in the 'jabber:client' or 'jabber:server' namespace
are used to "push" information to another entity. Common uses in the are used to "push" information to another entity. Common uses in the
context of instant messaging include single messages, messages sent context of instant messaging include single messages, messages sent
in the context of a chat conversation, messages sent in the context in the context of a chat conversation, messages sent in the context
of a multi-user chat room, headlines, and errors. These messages of a multi-user chat room, headlines, and errors. These messages
types are identified more fully below. types are identified more fully below.
7.3.1 Types of Message 7.3.1 Types of Message
The 'type' attribute of a message stanza is optional and specifies The 'type' attribute of a message stanza is OPTIONAL; if included, it
the conversational context of the message. The sending of a message specifies the conversational context of the message. The sending of
stanza without a 'type' attribute signals that the message stanza is a message stanza without a 'type' attribute signals that the message
a single message. However, the 'type' attribute MAY also have one of stanza is a single message. However, the 'type' attribute MAY also
the following values: have one of the following values:
o chat -- The message is sent in the context of a one-to-one chat o chat -- The message is sent in the context of a one-to-one chat
conversation. conversation.
o groupchat -- The message is sent in the context of a multi-user o groupchat -- The message is sent in the context of a multi-user
chat environment. chat environment.
o headline -- The message is generated by an automated service that o headline -- The message is generated by an automated service that
delivers content (news, sports, market information, etc.). delivers content (news, sports, market information, etc.).
o error - A message returned to a sender specifying an error o error - A message returned to a sender specifying an error
associated with a previous message sent by the sender (for a full associated with a previous message sent by the sender (for a full
list of error messages, see error codes (Appendix A)) list of error messages, see error codes (Appendix A)).
For detailed information about the meaning of these message types, For detailed information about the meaning of these message types,
refer to XMPP IM [2]. refer to XMPP IM [3].
7.3.2 Children 7.3.2 Children
If a message stanza in the 'jabber:client' or 'jabber:server' As described under extended namespaces (Section 7.6), a message
namespace has no 'type' attribute or has a 'type' attribute with a stanza MAY contain any properly-namespaced child element as long as
value of "chat", "groupchat", or "headline", it MAY contain any of the namespace name is not "jabber:client", "jabber:server", or
the following child elements (which MUST NOT contain mixed content): "http://etherx.jabber.org/streams", and as long as the element name
does not match that of one of the core data elements, stream
elements, or defined children thereof.
In accordance with the default namespace declaration, by default a
message stanza is in the 'jabber:client' or 'jabber:server'
namespace, which defines certain allowable children of message
stanzas. Specifically, if a message stanza has no 'type' attribute
or has a 'type' attribute with a value of "chat", "groupchat", or
"headline", it MAY contain any of the following child elements
without an explicit namespace declaration:
o body -- The textual contents of the message; normally included but o body -- The textual contents of the message; normally included but
NOT REQUIRED. The <body/> element MUST NOT possess any NOT REQUIRED. The <body/> element MUST NOT possess any
attributes, with the exception of the 'xml:lang' attribute. attributes, with the exception of the 'xml:lang' attribute.
Multiple instances of the <body/> element MAY be included but only Multiple instances of the <body/> element MAY be included but only
if each instance possesses an 'xml:lang' attribute with a distinct if each instance possesses an 'xml:lang' attribute with a distinct
language value. language value. The <body> element MUST NOT contain mixed
content.
o subject -- The subject of the message. The <subject/> element o subject -- The subject of the message. The <subject/> element
MUST NOT possess any attributes, with the exception of the MUST NOT possess any attributes, with the exception of the
'xml:lang' attribute. Multiple instances of the <subject/> 'xml:lang' attribute. Multiple instances of the <subject/>
element MAY be included for the purpose of providing alternate element MAY be included for the purpose of providing alternate
versions of the same subject, but only if each instance possesses versions of the same subject, but only if each instance possesses
an 'xml:lang' attribute with a distinct language value. an 'xml:lang' attribute with a distinct language value. The
<subject> element MUST NOT contain mixed content.
o thread -- A random string that is generated by the sender and that o thread -- A random string that is generated by the sender and that
MAY be copied back in replies; it is used for tracking a SHOULD be copied back in replies; it is used for tracking a
conversation thread (sometimes referred to as an "IM session") conversation thread (sometimes referred to as an "IM session")
between two entities. If used, it MUST be unique to that between two entities. If used, it MUST be unique to that
conversation thread within the stream and MUST be consistent conversation thread within the stream and MUST be consistent
throughout that conversation. The use of the <thread/> element is throughout that conversation. The use of the <thread/> element is
optional and is not used to identify individual messages, only optional and is not used to identify individual messages, only
conversations. The method for generating thread IDs SHOULD be as conversations. The method for generating thread IDs SHOULD be as
follows: (1) concatenate the sender's full JID (user@host/ follows: (1) concatenate the sender's full JID (user@host/
resource) with the recipient's full JID; (2) concatenate these JID resource) with the recipient's full JID; (2) concatenate these JID
strings with a full ISO-8601 timestamp including year, month, day, strings with a full ISO-8601 timestamp including year, month, day,
hours, minutes, seconds, and UTC offset if appropriate in the hours, minutes, seconds, and UTC offset in the following format:
following format: yyyy-mm-dd-Thh:mm:ss-hh:mm; (3) hash the yyyy-mm-dd-Thh:mm:ss-hh:mm; (3) hash the resulting string
resulting string according to the SHA1 algorithm; (4) convert the according to the SHA1 algorithm; (4) convert the hexidecimal SHA1
hexidecimal SHA1 output to all lowercase. Only one <thread/> output to all lowercase. Only one <thread/> element MAY be
element MAY be included in a message stanza, and it MUST NOT included in a message stanza, and it MUST NOT possess any
possess any attributes. The <thread/> element MUST be treated as attributes. The <thread/> element MUST be treated as an opaque
an opaque string by entities; no semantic meaning may be derived string by entities; no semantic meaning may be derived from it,
from it, and only exact, case-insensitve comparisons can be made and only exact, case-insensitve comparisons be made against it.
against it. The <thread> element MUST NOT contain mixed content.
If the message stanza is of type "error", it MUST include an <error/> If the message stanza is of type "error", it MUST include an <error/>
child, which in turn MUST possess a 'code' attribute corresponding to child, which in turn MUST possess a 'code' attribute corresponding to
one of the standard error codes (Appendix A), MAY possess an one of the standard error codes (Appendix A), MAY possess an
'xml:lang' attribute, and MAY also contain PCDATA corresponding to a 'xml:lang' attribute, and MAY also contain PCDATA corresponding to a
natural-language description of the error. An <error/> child MUST natural-language description of the error. An <error/> child MUST
NOT be included if the stanza type is anything other than "error". NOT be included if the stanza type is anything other than "error".
An entity that receives a message stanza of type 'error' MUST NOT An entity that receives a message stanza of type 'error' MUST NOT
respond to the stanza by sending a further message stanza of type respond to the stanza by sending a further message stanza of type
'error'; this helps to prevent looping. 'error'; this helps to prevent looping.
As described under extended namespaces (Section 7.6), a message
stanza MAY also contain any properly-namespaced child element (other
than the core data elements, stream elements, or defined children
thereof).
7.4 Presence Stanzas 7.4 Presence Stanzas
Presence stanzas are used in the 'jabber:client' or 'jabber:server' Presence stanzas are used in the 'jabber:client' or 'jabber:server'
namespace to express an entity's current availability status (offline namespace to express an entity's current availability status (offline
or online, along with various sub-states of the latter and optional or online, along with various sub-states of the latter and optional
user-defined descriptive tex and optional user-defined descriptive user-defined descriptive tex and optional user-defined descriptive
textt) and to communicate that status to other entities. They are textt) and to communicate that status to other entities. They are
also used to negotiate and manage subscriptions to the presence of also used to negotiate and manage subscriptions to the presence of
other entities. other entities.
skipping to change at page 31, line 24 skipping to change at page 35, line 30
o unsubscribed -- The subscription request has been denied or a o unsubscribed -- The subscription request has been denied or a
previously-granted subscription has been cancelled. previously-granted subscription has been cancelled.
o probe -- A request for an entity's current presence. In general o probe -- A request for an entity's current presence. In general
SHOULD NOT be sent by a client. SHOULD NOT be sent by a client.
o error -- An error has occurred regarding processing or delivery of o error -- An error has occurred regarding processing or delivery of
a previously-sent presence stanza. a previously-sent presence stanza.
Information about the subscription model used within XMPP can be Information about the subscription model used within XMPP can be
found in XMPP IM [2]. found in XMPP IM [3].
7.4.2 Children 7.4.2 Children
If a presence stanza possesses no 'type' attribute, it MAY contain As described under extended namespaces (Section 7.6), a presence
any of the following child elements (note that the <status/> child stanza MAY contain any properly-namespaced child element as long as
MAY be sent in a presence stanza of type "unavailable" or, for the namespace name is not "jabber:client", "jabber:server", or
historical reasons, "subscribe"): "http://etherx.jabber.org/streams", and as long as the element name
does not match that of one of the core data elements, stream
elements, or defined children thereof.
In accordance with the default namespace declaration, by default a
presence stanza is in the 'jabber:client' or 'jabber:server'
namespace, which defines certain allowable children of presence
stanzas. Specifically, if a presence stanza possesses no 'type'
attribute, it MAY contain any of the following child elements (note
that the <status/> child MAY be sent in a presence stanza of type
"unavailable" or, for historical reasons, "subscribe"):
o show -- Describes the availability status of an entity or specific o show -- Describes the availability status of an entity or specific
resource. Only one <show/> element MAY be included in a presence resource. Only one <show/> element MAY be included in a presence
stanza, and it MUST NOT possess any attributes. The value SHOULD stanza, and it MUST NOT possess any attributes. The value SHOULD
be one of the following (values other than these four MAY be be one of the following (values other than these four MAY be
ignored; additional availability types could be defined through a ignored; additional availability types could be defined through a
properly-namespaced child element of the presence stanza): properly-namespaced child element of the presence stanza):
* away -- The entity or resource is temporarily away. * away -- The entity or resource is temporarily away.
skipping to change at page 32, line 34 skipping to change at page 36, line 51
As described under extended namespaces (Section 7.6), a presence As described under extended namespaces (Section 7.6), a presence
stanza MAY also contain any properly-namespaced child element (other stanza MAY also contain any properly-namespaced child element (other
than the core data elements, stream elements, or defined children than the core data elements, stream elements, or defined children
thereof). thereof).
7.5 IQ Stanzas 7.5 IQ Stanzas
7.5.1 Overview 7.5.1 Overview
Info/Query, or IQ, is a request-response mechanism, similar in some Info/Query, or IQ, is a request-response mechanism, similar in some
ways to HTTP [28]. IQ stanzas in the 'jabber:client' or ways to HTTP [24]. IQ stanzas in the 'jabber:client' or
'jabber:server' namespace enable an entity to make a request of, and 'jabber:server' namespace enable an entity to make a request of, and
receive a response from, another entity. The data content of the receive a response from, another entity. The data content of the
request and response is defined by the namespace declaration of a request and response is defined by the namespace declaration of a
direct child element of the IQ element, and the interaction is direct child element of the IQ element, and the interaction is
tracked by the requesting entity through use of the 'id' attribute, tracked by the requesting entity through use of the 'id' attribute,
which responding entities SHOULD return in any response. which responding entities SHOULD return in any response.
Most IQ interactions follow a common pattern of structured data Most IQ interactions follow a common pattern of structured data
exchange such as get/result or set/result (although an error may be exchange such as get/result or set/result (although an error may be
returned in response to a request if appropriate): returned in response to a request if appropriate):
skipping to change at page 34, line 7 skipping to change at page 38, line 13
replaces existing values. replaces existing values.
o result -- The stanza is a response to a successful get or set o result -- The stanza is a response to a successful get or set
request. request.
o error -- An error has occurred regarding processing or delivery of o error -- An error has occurred regarding processing or delivery of
a previously-sent get or set. a previously-sent get or set.
7.5.3 Children 7.5.3 Children
An IQ stanza contains no children in the 'jabber:client' or As described under extended namespaces (Section 7.6), an IQ stanza
'jabber:server' namespace since it is a vessel for XML in another MAY contain any properly-namespaced child element as long as the
namespace. As described under extended namespaces (Section 7.6), an namespace name is not "jabber:client", "jabber"server", or "http://
IQ stanza MAY contain any properly-namespaced child element (other etherx.jabber.org/streams", and as long as the element name does not
than the core data elements, stream elements, or defined children match that of one of the core data elements, stream elements, or
thereof). defined children thereof. However, an IQ stanza contains no children
in the 'jabber:client' or 'jabber:server' namespace since it is a
vessel for XML in another namespace.
If the IQ stanza is of type "error", it MUST include an <error/> If the IQ stanza is of type "error", it MUST include an <error/>
child, which in turn MUST possess a 'code' attribute corresponding to child, which in turn MUST possess a 'code' attribute corresponding to
one of the standard error codes (Appendix A) and MAY contain PCDATA one of the standard error codes (Appendix A) and MAY contain PCDATA
corresponding to a natural-language description of the error. An corresponding to a natural-language description of the error. An
<error/> child MUST NOT be included if the stanza type is anything <error/> child MUST NOT be included if the stanza type is anything
other than "error". An entity that receives an IQ stanza of type other than "error". An entity that receives an IQ stanza of type
'error' MUST NOT respond to the stanza by sending a further IQ stanza 'error' MUST NOT respond to the stanza by sending a further IQ stanza
of type 'error'; this helps to prevent looping. of type 'error'; this helps to prevent looping.
7.6 Extended Namespaces 7.6 Extended Namespaces
While the core data elements defined in this document provide a basic While the core data elements in the "jabber:client" or
level of functionality for messaging and presence, XMPP uses XML "jabber:server" namespace (along with their attributes and child
namespaces to extend the core data elements for the purpose of elements) provide a basic level of functionality for messaging and
providing additional functionality. Thus a message, presence, or IQ presence, XMPP uses XML namespaces to extend the core data elements
stanza MAY house one or more optional child elements containing for the purpose of providing additional functionality. Thus a
content that extends the meaning of the message (e.g., an encrypted message, presence, or IQ stanza MAY house one or more optional child
form of the message body). This child element MAY be any element elements containing content that extends the meaning of the message
(other than the core data elements, stream elements, or defined (e.g., an encrypted form of the message body). This child element
children thereof). The child element MUST possess an 'xmlns' MAY be any element (other than the core data elements, stream
namespace declaration (other than the stream namespace and the elements, or defined children thereof). The child element MUST
default namespace) that defines all data contained within the child possess an 'xmlns' namespace declaration (other than the stream
element. namespace and the default namespace) that defines all data contained
within the child element.
Support for any given extended namespace is OPTIONAL on the part of Support for any given extended namespace is OPTIONAL on the part of
any implementation. If an entity does not understand such a any implementation. If an entity does not understand such a
namespace, it MUST ignore the associated XML data (if the stanza is namespace, it MUST ignore the associated XML data (if the stanza is
being routed on to another entity, ignore means "pass it on being routed on to another entity, ignore means "pass it on
untouched"). If an entity receives an IQ stanza in a namespace it untouched"). If an entity receives an IQ stanza in a namespace it
does not understand, the entity SHOULD return an IQ stanza of type does not understand, the entity SHOULD return an IQ stanza of type
"error" with an error element of code 400 (bad request). If an "error" with an error element of code 501 (Not Implemented). If an
entity receives a message or presence stanza that contains XML data entity receives a message or presence stanza that contains XML data
in an extended namespace it does not understand, the portion of the in an extended namespace it does not understand, the portion of the
stanza that is in the unknown namespace SHOULD be ignored. If an stanza that is in the unknown namespace SHOULD be ignored. If an
entity receives a message stanza without a <body/> element but entity receives a message stanza without a <body/> element but
containing only a child element bound by a namespace it does not containing only a child element bound by a namespace it does not
understand, it MUST ignore the entire stanza. understand, it MUST ignore the entire stanza.
8. XML Usage within XMPP 8. XML Usage within XMPP
8.1 Namespaces 8.1 Namespaces
XML Namespaces [14] are used within all XMPP-compliant XML to create XML Namespaces [15] are used within all XMPP-compliant XML to create
strict boundaries of data ownership. The basic function of strict boundaries of data ownership. The basic function of
namespaces is to separate different vocabularies of XML elements that namespaces is to separate different vocabularies of XML elements that
are structurally mixed together. Ensuring that XMPP-compliant XML is are structurally mixed together. Ensuring that XMPP-compliant XML is
namespace-aware enables any XML to be structurally mixed with any namespace-aware enables any XML to be structurally mixed with any
data element within XMPP. Mainly for historical reasons, the default data element within XMPP.
namespace for XMPP data stanzas MUST be one of the namespaces
identified in Section 4.4.
Additionally, XMPP is more strict about namespace prefixes than the Additionally, XMPP is more strict about namespace prefixes than the
XML namespace specification requires. XML namespace specification requires.
8.2 Validation 8.2 Validation
A server is not responsible for validating the XML elements forwarded A server is not responsible for validating the XML elements forwarded
to a client; an implementation MAY choose to provide only validated to a client; an implementation MAY choose to provide only validated
data elements but is NOT REQUIRED to do so. Clients SHOULD NOT rely data elements but is NOT REQUIRED to do so. Clients SHOULD NOT rely
on the ability to send data which does not conform to the schemas, on the ability to send data which does not conform to the schemas,
and SHOULD ignore any non-conformant elements or attributes on the and SHOULD ignore any non-conformant elements or attributes on the
incoming XML stream. Validation of XML streams and stanzas is NOT incoming XML stream. Validation of XML streams and stanzas is NOT
REQUIRED or recommended, and DTDs and schemas are included herein for REQUIRED or recommended, and schemas are included herein for
descriptive purposes only. descriptive purposes only.
8.3 Character Encodings 8.3 Character Encodings
Software implementing XML streams MUST support the UTF-8 (RFC 2279 Software implementing XML streams MUST support the UTF-8 (RFC 2279
[24]) and UTF-16 (RFC 2781 [25]) transformations of Universal [25]) and UTF-16 (RFC 2781 [26]) transformations of Universal
Character Set (ISO/IEC 10646-1 [26]) characters. Software MUST NOT Character Set (ISO/IEC 10646-1 [27]) characters. Software MUST NOT
attempt to use any other encoding for transmitted data. The attempt to use any other encoding for transmitted data. The
encodings of the transmitted and received streams are independent. encodings of the transmitted and received streams are independent.
Software MAY select either UTF-8 or UTF-16 for the transmitted Software MAY select either UTF-8 or UTF-16 for the transmitted
stream, and SHOULD deduce the encoding of the received stream as stream, and SHOULD deduce the encoding of the received stream as
described in the XML specification [1]. For historical reasons, described in the XML specification [1]. For historical reasons,
existing implementations MAY support UTF-8 only. existing implementations MAY support UTF-8 only.
8.4 Inclusion of Text Declaration 8.4 Inclusion of Text Declaration
An application MAY send a text declaration. Applications MUST follow An application MAY send a text declaration. Applications MUST follow
the rules in the XML specification [1] regarding the circumstances in the rules in the XML specification [1] regarding the circumstances
which a text declaration is included. under which a text declaration is included.
9. IANA Considerations 9. IANA Considerations
The IANA registers "jabber-client" and "jabber-server" as service The IANA registers "xmpp" as a GSSAPI [29] service name, as specified
names associated with TCP ports 5222 and 5269 respectively. in Section 6.1.3.
Additionally, the IANA registers "jabber-client" and "jabber-server"
as keywords for TCP ports 5222 and 5269 respectively.
10. Internationalization Considerations 10. Internationalization Considerations
Usage of the 'xml:lang' attribute is described above. If a client Usage of the 'xml:lang' attribute is described above. If a client
includes an 'xml:lang' attribute in a stanza, the server MUST NOT includes an 'xml:lang' attribute in a stanza, the server MUST NOT
modify or delete it. modify or delete it.
11. Security Considerations 11. Security Considerations
11.1 Client-to-Server Communications 11.1 Client-to-Server Communications
The SASL protocol for authenticating XML streams negotiated between a The TLS protocol for encrypting XML streams provides a reliable
client and a server (defined under Section 5.1 above) provides a mechanism for helping to ensure the privacy and data integrity of
reliable mechanism for validating that a client connecting to a data exchanged between two entities.
server is who it claims to be.
The SASL protocol for authenticating XML streams (defined under
Section 6.1 above) provides a reliable mechanism for validating that
a client connecting to a server is who it claims to be.
The IP address and method of access of clients MUST NOT be made The IP address and method of access of clients MUST NOT be made
available by a server, nor are any connections other than the available by a server, nor are any connections other than the
original server connection required. This helps protect the client's original server connection required. This helps protect the client's
server from direct attack or identification by third parties. server from direct attack or identification by third parties.
End-to-end encryption of message bodies and presence status End-to-end encryption of message bodies and presence status
information MAY be effected through use of the methods defined in information MAY be effected through use of the methods defined in
End-to-End Object Encryption in XMPP [27]. End-to-End Object Encryption in XMPP [28].
11.2 Server-to-Server Communications 11.2 Server-to-Server Communications
It is OPTIONAL for any given server to communicate with other It is OPTIONAL for any given server to communicate with other
servers, and server-to-server communications MAY be disabled by the servers, and server-to-server communications MAY be disabled by the
administrator of any given deployment. administrator of any given deployment.
If two servers would like to enable communications between If two servers would like to enable communications between
themselves, they MUST form a relationship of trust at some level, themselves, they MUST form a relationship of trust at some level,
either based on trust in DNS or based on a pre-existing trust either based on trust in DNS or based on a pre-existing trust
relationship (e.g., through exchange of certificates). If two relationship (e.g., through exchange of certificates). If two
servers have a pre-existing trust relationship, they MAY use SASL servers have a pre-existing trust relationship, they MAY use SASL
Authentication (Section 5.1) for the purpose of authenticating each Authentication (Section 6.1) for the purpose of authenticating each
other. If they do not have a pre-existing relationship, they MUST other. If they do not have a pre-existing relationship, they MUST
use the Dialback Protocol (Section 5.2), which provides a reliable use the Dialback Protocol (Section 6.2), which provides a reliable
mechanism for preventing the spoofing of servers. mechanism for preventing the spoofing of servers.
11.3 Minimum Security Mechanisms 11.3 Firewalls
Communications using XMPP occur over TCP sockets on port 5222
(client-to-server) or port 5269 (server-to-server), as registered
with the IANA [7]. Use of these well-known ports allows
administrators to easily enable or disable XMPP activity through
existing and commonly-deployed firewalls.
11.4 Minimum Security Mechanisms
Although service provisioning is a policy matter, at a minimum, all Although service provisioning is a policy matter, at a minimum, all
implementations MUST support the following mechanisms: implementations MUST support the following mechanisms:
for authentication: the SASL DIGEST-MD5 mechanism for authentication: the SASL DIGEST-MD5 mechanism
for confidentiality: TLS (using the TLS_RSA_WITH_3DES_EDE_CBC_SHA for confidentiality: TLS (using the TLS_RSA_WITH_3DES_EDE_CBC_SHA
cipher) cipher)
for both: TLS (using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher for both: TLS (using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher
supporting client-side certificates) supporting client-side certificates)
11.4 Firewalls
Communications using XMPP occur over TCP sockets on port 5222
(client-to-server) or port 5269 (server-to-server), as registered
with the IANA [6]. Use of these well-known ports allows
administrators to easily enable or disable XMPP activity through
existing and commonly-deployed firewalls.
References References
[1] World Wide Web Consortium, "Extensible Markup Language (XML) [1] World Wide Web Consortium, "Extensible Markup Language (XML)
1.0 (Second Edition)", W3C xml, October 2000, <http:// 1.0 (Second Edition)", W3C xml, October 2000, <http://
www.w3.org/TR/2000/REC-xml-20001006>. www.w3.org/TR/2000/REC-xml-20001006>.
[2] Saint-Andre, P. and J. Miller, "XMPP Instant Messaging (draft- [2] Jabber Software Foundation, "Jabber Software Foundation",
ietf-xmpp-im-02, work in progress)", February 2003. August 2001, <http://www.jabber.org/>.
[3] Day, M., Aggarwal, S., Mohr, G. and J. Vincent, "A Model for [3] Saint-Andre, P. and J. Miller, "XMPP Instant Messaging (draft-
ietf-xmpp-im-04, work in progress)", February 2003.
[4] Day, M., Aggarwal, S., Mohr, G. and J. Vincent, "A Model for
Presence and Instant Messaging", RFC 2779, February 2000, Presence and Instant Messaging", RFC 2779, February 2000,
<http://www.ietf.org/rfc/rfc2779.txt>. <http://www.ietf.org/rfc/rfc2779.txt>.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[5] University of Southern California, "Transmission Control [6] University of Southern California, "Transmission Control
Protocol", RFC 793, September 1981, <http://www.ietf.org/rfc/ Protocol", RFC 793, September 1981, <http://www.ietf.org/rfc/
rfc0793.txt>. rfc0793.txt>.
[6] Internet Assigned Numbers Authority, "Internet Assigned Numbers [7] Internet Assigned Numbers Authority, "Internet Assigned Numbers
Authority", January 1998, <http://www.iana.org/>. Authority", January 1998, <http://www.iana.org/>.
[7] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform [8] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998, <http://www.ietf.org/rfc/rfc2396.txt>. 1998, <http://www.ietf.org/rfc/rfc2396.txt>.
[8] Harrenstien, K., Stahl, M. and E. Feinler, "DoD Internet host [9] Harrenstien, K., Stahl, M. and E. Feinler, "DoD Internet host
table specification", RFC 952, October 1985. table specification", RFC 952, October 1985.
[9] Braden, R., "Requirements for Internet Hosts - Application and [10] Braden, R., "Requirements for Internet Hosts - Application and
Support", STD 3, RFC 1123, October 1989. Support", STD 3, RFC 1123, October 1989.
[10] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile [11] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile
for Internationalized Domain Names (draft-ietf-idn-nameprep-11, for Internationalized Domain Names (draft-ietf-idn-nameprep-11,
work in progress)", June 2002. work in progress)", June 2002.
[11] Hoffman, P. and M. Blanchet, "Preparation of Internationalized [12] Hoffman, P. and M. Blanchet, "Preparation of Internationalized
Strings ("stringprep")", RFC 3454, December 2002. Strings ("stringprep")", RFC 3454, December 2002.
[12] Saint-Andre, P. and J. Hildebrand, "Nodeprep: A Stringprep [13] Saint-Andre, P. and J. Hildebrand, "Nodeprep: A Stringprep
Profile for Node Identifiers in XMPP (draft-ietf-xmpp-nodeprep- Profile for Node Identifiers in XMPP (draft-ietf-xmpp-nodeprep-
01, work in progress)", February 2003. 01, work in progress)", February 2003.
[13] Saint-Andre, P. and J. Hildebrand, "Resourceprep: A Stringprep [14] Saint-Andre, P. and J. Hildebrand, "Resourceprep: A Stringprep
Profile for Resource Identifiers in XMPP (draft-ietf-xmpp- Profile for Resource Identifiers in XMPP (draft-ietf-xmpp-
resourceprep-01, work in progress)", February 2003. resourceprep-01, work in progress)", February 2003.
[14] World Wide Web Consortium, "Namespaces in XML", W3C xml-names, [15] World Wide Web Consortium, "Namespaces in XML", W3C xml-names,
January 1999, <http://www.w3.org/TR/1999/REC-xml-names- January 1999, <http://www.w3.org/TR/1999/REC-xml-names-
19990114/>. 19990114/>.
[15] Myers, J., "Simple Authentication and Security Layer (SASL)", [16] Myers, J., "Simple Authentication and Security Layer (SASL)",
RFC 2222, October 1997. RFC 2222, October 1997.
[16] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and [17] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and
P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January
1999. 1999.
[17] Crispin, M., "Internet Message Access Protocol - Version [18] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 2060, December 1996. 4rev1", RFC 2060, December 1996.
[18] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD [19] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD
53, RFC 1939, May 1996. 53, RFC 1939, May 1996.
[19] Newman, C. and J. Myers, "ACAP -- Application Configuration [20] Newman, C. and J. Myers, "ACAP -- Application Configuration
Access Protocol", RFC 2244, November 1997. Access Protocol", RFC 2244, November 1997.
[20] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, [21] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595,
June 1999. June 1999.
[21] Alvestrand, H., "Tags for the Identification of Languages", BCP [22] Alvestrand, H., "Tags for the Identification of Languages", BCP
47, RFC 3066, January 2001. 47, RFC 3066, January 2001.
[22] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the [23] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the
location of services (DNS SRV)", RFC 2052, October 1996. location of services (DNS SRV)", RFC 2052, October 1996.
[23] Elkins, M., Del Torto, D., Levien, R. and T. Roessler, "MIME [24] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,
Security with OpenPGP", RFC 3156, August 2001. Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[24] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC [25] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998. 2279, January 1998.
[25] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", [26] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646",
RFC 2781, February 2000. RFC 2781, February 2000.
[26] International Organization for Standardization, "Information [27] International Organization for Standardization, "Information
Technology - Universal Multiple-octet coded Character Set (UCS) Technology - Universal Multiple-octet coded Character Set (UCS)
- Amendment 2: UCS Transformation Format 8 (UTF-8)", ISO - Amendment 2: UCS Transformation Format 8 (UTF-8)", ISO
Standard 10646-1 Addendum 2, October 1996. Standard 10646-1 Addendum 2, October 1996.
[27] Saint-Andre, P. and J. Hildebrand, "End-to-End Object [28] Saint-Andre, P. and J. Hildebrand, "End-to-End Object
Encryption in XMPP (draft-ietf-xmpp-e2e-00, work in progress)", Encryption in XMPP (draft-ietf-xmpp-e2e-00, work in progress)",
February 2003. February 2003.
[28] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., [29] Linn, J., "Generic Security Service Application Program
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- Interface, Version 2", RFC 2078, January 1997.
HTTP/1.1", RFC 2616, June 1999.
Authors' Addresses Authors' Addresses
Peter Saint-Andre Peter Saint-Andre
Jabber Software Foundation Jabber Software Foundation
EMail: stpeter@jabber.org EMail: stpeter@jabber.org
URI: http://www.jabber.org/people/stpeter.php URI: http://www.jabber.org/people/stpeter.php
Jeremie Miller Jeremie Miller
Jabber Software Foundation Jabber Software Foundation
EMail: jeremie@jabber.org EMail: jeremie@jabber.org
URI: http://www.jabber.org/people/jer.php URI: http://www.jabber.org/people/jer.php
Appendix A. Standard Error Codes Appendix A. Standard Error Codes
A standard error element is used for failed processing of XML A standard error element is used for failed processing of XML stanzas
stanzas. This element is a child of the failed stanza and MUST within the "jabber:client" or "jabber:server" namespace. This
include a 'code' attribute corresponding to appropriate error element is a child of the failed stanza and MUST include a 'code'
condition. attribute corresponding to an appropriate error condition.
In general the standard error codes were "borrowed" from those used In general the standard error codes were "borrowed" from those used
in HTTP [28] early in the development of XMPP within the Jabber in HTTP [24] early in the development of XMPP within the Jabber
community. The first digit of the error code defines the class of community. The first digit of the error code defines the class of
response. The last two digits do not have any categorization role. response. The last two digits do not have any categorization role.
There are five possible values for the first digit: There are five possible values for the first digit:
o 1xx: Informational - Request received, continuing process [not o 1xx: Informational - Request received, continuing process [not
currently used within XMPP] currently used within XMPP]
o 2xx: Success - The action was successfully received, understood, o 2xx: Success - The action was successfully received, understood,
and accepted [not currently used within XMPP] and accepted [not currently used within XMPP]
o 3xx: Redirection - Further action must be taken in order to o 3xx: Redirection - Further action must be taken in order to
complete the request complete the request
o 4xx: Client Error - The request contains bad syntax or cannot be o 4xx: Sender Error - The sender's request contains bad syntax or
fulfilled cannot be fulfilled
o 5xx: Server Error - The server failed to fulfill an apparently o 5xx: Receiver Error - The receiving or routing entity (often but
valid request not always a server) failed to fulfill an apparently valid request
The individual values of the numeric status/error codes defined for The individual values of the numeric status/error codes defined for
XMPP, and an example set of corresponding textual descriptions, are XMPP, and an example set of corresponding textual descriptions, are
presented below. The textual descriptions listed here are only presented below. The textual descriptions listed here are only
recommendations -- they MAY be replaced by local equivalents without recommendations -- they MAY be replaced by local equivalents without
affecting the protocol. affecting the protocol.
o 302 (Redirect) - Code 302 is used when a server needs to redirect o 302 (Redirect) - Code 302 is used when a server needs to redirect
stream initiation requests to another hostname or IP address. stream initiation requests to another hostname or IP address.
skipping to change at page 44, line 37 skipping to change at page 49, line 37
o 407 (Registration Required) - Code 407 is used when a message or o 407 (Registration Required) - Code 407 is used when a message or
request is sent to a service that requires prior registration, request is sent to a service that requires prior registration,
e.g., if a user attempts to send a message through a gateway to a e.g., if a user attempts to send a message through a gateway to a
foreign messaging system without having first registered with that foreign messaging system without having first registered with that
gateway. gateway.
o 408 (Request Timeout) - Code 408 is returned when a recipient does o 408 (Request Timeout) - Code 408 is returned when a recipient does
not produce a response within the time that the sender was not produce a response within the time that the sender was
prepared to wait. prepared to wait.
o 409 (Conflict) - Code 409 is returned when a recipient does not o 409 (Conflict) - Code 409 is returned when a request cannot be
produce a response within the time that the sender was prepared to fulfilled because of an inherent conflict (e.g., because a client
wait. attempts to authorize a resouce name that is already in use).
o 410 (Gone) - Code 410 is returned by a server when the hostname o 410 (Gone) - Code 410 is returned by a server when the hostname
requested by an entity initiating a stream request is no longer requested by an entity initiating a stream request is no longer
provided by a server. provided by a server.
o 500 (Internal Server Error) - Code 500 is used when a server or o 500 (Internal Server Error) - Code 500 is used when a server or
service encounters an unexpected condition which prevents it from service encounters an unexpected condition which prevents it from
handling a stream initiation request or an XML stanza from a handling a stream initiation request or an XML stanza from a
sender. sender.
skipping to change at page 47, line 36 skipping to change at page 52, line 36
<xs:element name='mechanism'/> <xs:element name='mechanism'/>
<xs:element name='auth'> <xs:element name='auth'>
<xs:complexType> <xs:complexType>
<xs:attribute name='mechanism' type='xs:string' use='optional'/> <xs:attribute name='mechanism' type='xs:string' use='optional'/>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:element name='challenge' type='xs:string'/> <xs:element name='challenge' type='xs:string'/>
<xs:element name='response' type='xs:string'/> <xs:element name='response' type='xs:string'/>
<xs:element name='abort' type='xs:string'/> <xs:element name='abort'/>
<xs:element name='success' type='xs:string'/> <xs:element name='success'/>
<xs:element name='failure' type='xs:string'/> <xs:element name='failure'>
<xs:complexType>
<xs:attribute name='code' type='xs:string' use='optional'/>
</xs:complexType>
</xs:element>
</xs:schema> </xs:schema>
B.3 Dialback namespace B.3 Dialback namespace
<?xml version='1.0' encoding='UTF-8'?> <?xml version='1.0' encoding='UTF-8'?>
<xs:schema <xs:schema
xmlns:xsd='http://www.w3.org/2001/XMLSchema' xmlns:xsd='http://www.w3.org/2001/XMLSchema'
targetNamespace='jabber:server:dialback' targetNamespace='jabber:server:dialback'
xmlns='jabber:server:dialback' xmlns='jabber:server:dialback'
elementFormDefault='qualified'> elementFormDefault='qualified'>
<xs:element name='result'> <xs:element name='result'>
<xs:complexType> <xs:complexType>
<xs:simpleContent> <xs:simpleContent>
<xs:extension base='xs:string'> <xs:extension base='xs:string'>
skipping to change at page 55, line 10 skipping to change at page 60, line 10
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
</xs:schema> </xs:schema>
Appendix C. Revision History Appendix C. Revision History
Note to RFC editor: please remove this entire appendix, and the Note to RFC editor: please remove this entire appendix, and the
corresponding entries in the table of contents, prior to publication. corresponding entries in the table of contents, prior to publication.
C.1 Changes from draft-ietf-xmpp-core-02 C.1 Changes from draft-ietf-xmpp-core-03
o Clarified rules and procedures for TLS and SASL.
o Amplified stream error code syntax per list discussion.
o Made numerous small editorial changes.
C.2 Changes from draft-ietf-xmpp-core-02
o Added dialback schema. o Added dialback schema.
o Removed all DTDs since schemas are provide more complete o Removed all DTDs since schemas provide more complete definitions.
definitions.
o Added stream error codes. o Added stream error codes.
o Clarified error code "philosophy". o Clarified error code "philosophy".
C.2 Changes from draft-ietf-xmpp-core-01 C.3 Changes from draft-ietf-xmpp-core-01
o Updated the addressing restrictions per list discussion and added o Updated the addressing restrictions per list discussion and added
references to the new nodeprep and resourceprep profiles. references to the new nodeprep and resourceprep profiles.
o Corrected error in Stream Authentication regarding version='1.0' o Corrected error in Stream Authentication regarding "version='1.0'"
flag. flag.
o Made numerous small editorial changes. o Made numerous small editorial changes.
C.3 Changes from draft-ietf-xmpp-core-00 C.4 Changes from draft-ietf-xmpp-core-00
o Added information about TLS from list discussion. o Added information about TLS from list discussion.
o Clarified meaning of "ignore" based on list discussion. o Clarified meaning of "ignore" based on list discussion.
o Clarified information about Universal Character Set data and o Clarified information about Universal Character Set data and
character encodings. character encodings.
o Provided base64-decoded information for examples. o Provided base64-decoded information for examples.
o Fixed several errors in the schemas. o Fixed several errors in the schemas.
o Made numerous small editorial fixes. o Made numerous small editorial fixes.
C.4 Changes from draft-miller-xmpp-core-02 C.5 Changes from draft-miller-xmpp-core-02
o Brought Streams Authentication section into line with discussion o Brought Streams Authentication section into line with discussion
on list and at IETF 55 meeting. on list and at IETF 55 meeting.
o Added information about the optional 'xml:lang' attribute per o Added information about the optional 'xml:lang' attribute per
discussion on list and at IETF 55 meeting. discussion on list and at IETF 55 meeting.
o Specified that validation is neither required nor recommended, and o Specified that validation is neither required nor recommended, and
that the formal definitions (DTDs and schemas) are included for that the formal definitions (DTDs and schemas) are included for
descriptive purposes only. descriptive purposes only.
 End of changes. 128 change blocks. 
413 lines changed or deleted 588 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/