draft-ietf-xmpp-core-00.txt   draft-ietf-xmpp-core-01.txt 
Network Working Group J. Miller Network Working Group J. Miller
Internet-Draft P. Saint-Andre Internet-Draft P. Saint-Andre
Expires: June 6, 2003 Jabber Software Foundation Expires: July 18, 2003 Jabber Software Foundation
December 06, 2002 January 17, 2003
XMPP Core XMPP Core
draft-ietf-xmpp-core-00 draft-ietf-xmpp-core-01
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 June 6, 2003. This Internet-Draft will expire on July 18, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). 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), which is used by the servers, clients, and Presence Protocol (XMPP), which is used by the servers, clients,
and other applications that comprise the Jabber network. and other applications that comprise the Jabber network.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
skipping to change at page 2, line 29 skipping to change at page 2, line 29
3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Domain Identifier . . . . . . . . . . . . . . . . . . . . . 7 3.2 Domain Identifier . . . . . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . . . . . . . 13 4.6 Stream Errors . . . . . . . . . . . . . . . . . . . . . . . 12
4.7 Simple Streams Example . . . . . . . . . . . . . . . . . . . 13 4.7 Simple Streams Example . . . . . . . . . . . . . . . . . . . 13
5. Stream Authentication . . . . . . . . . . . . . . . . . . . 16 5. Stream Authentication . . . . . . . . . . . . . . . . . . . 15
5.1 SASL Authentication . . . . . . . . . . . . . . . . . . . . 16 5.1 SASL Authentication . . . . . . . . . . . . . . . . . . . . 15
5.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1.2 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.1.2 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.2 Dialback Authentication . . . . . . . . . . . . . . . . . . 19 5.2 Dialback Authentication . . . . . . . . . . . . . . . . . . 18
5.2.1 Dialback Protocol . . . . . . . . . . . . . . . . . . . . . 21 5.2.1 Dialback Protocol . . . . . . . . . . . . . . . . . . . . . 20
6. XML Stanzas . . . . . . . . . . . . . . . . . . . . . . . . 25 6. Stream Encryption . . . . . . . . . . . . . . . . . . . . . 24
6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.2 Common Attributes . . . . . . . . . . . . . . . . . . . . . 25 6.2 Protocol Example . . . . . . . . . . . . . . . . . . . . . . 25
6.2.1 to . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.3 Certificate-Based Authentication . . . . . . . . . . . . . . 26
6.2.2 from . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7. XML Stanzas . . . . . . . . . . . . . . . . . . . . . . . . 27
6.2.3 id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.2.4 type . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 7.2 Common Attributes . . . . . . . . . . . . . . . . . . . . . 27
6.2.5 xml:lang . . . . . . . . . . . . . . . . . . . . . . . . . . 26 7.2.1 to . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.3 Message Stanzas . . . . . . . . . . . . . . . . . . . . . . 26 7.2.2 from . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.3.1 Types of Message . . . . . . . . . . . . . . . . . . . . . . 26 7.2.3 id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.3.2 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 27 7.2.4 type . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.4 Presence Stanzas . . . . . . . . . . . . . . . . . . . . . . 28 7.2.5 xml:lang . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.4.1 Types of Presence . . . . . . . . . . . . . . . . . . . . . 28 7.3 Message Stanzas . . . . . . . . . . . . . . . . . . . . . . 28
6.4.2 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 29 7.3.1 Types of Message . . . . . . . . . . . . . . . . . . . . . . 28
6.5 IQ Stanzas . . . . . . . . . . . . . . . . . . . . . . . . . 30 7.3.2 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 30 7.4 Presence Stanzas . . . . . . . . . . . . . . . . . . . . . . 30
6.5.2 Types of IQ . . . . . . . . . . . . . . . . . . . . . . . . 30 7.4.1 Types of Presence . . . . . . . . . . . . . . . . . . . . . 30
6.5.3 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 31 7.4.2 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.6 Extended Namespaces . . . . . . . . . . . . . . . . . . . . 31 7.5 IQ Stanzas . . . . . . . . . . . . . . . . . . . . . . . . . 32
7. XML Usage within XMPP . . . . . . . . . . . . . . . . . . . 33 7.5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 32
7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 33 7.5.2 Types of IQ . . . . . . . . . . . . . . . . . . . . . . . . 33
7.2 Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . 33 7.5.3 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.3 Validation . . . . . . . . . . . . . . . . . . . . . . . . . 33 7.6 Extended Namespaces . . . . . . . . . . . . . . . . . . . . 33
7.4 Character Encodings . . . . . . . . . . . . . . . . . . . . 34 8. XML Usage within XMPP . . . . . . . . . . . . . . . . . . . 35
7.5 Inclusion of Text Declaration . . . . . . . . . . . . . . . 34 8.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 35
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 35 8.2 Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . 35
9. Internationalization Considerations . . . . . . . . . . . . 36 8.3 Validation . . . . . . . . . . . . . . . . . . . . . . . . . 35
10. Security Considerations . . . . . . . . . . . . . . . . . . 37 8.4 Character Encodings . . . . . . . . . . . . . . . . . . . . 36
10.1 Client-to-Server Communications . . . . . . . . . . . . . . 37 8.5 Inclusion of Text Declaration . . . . . . . . . . . . . . . 36
10.2 Server-to-Server Communications . . . . . . . . . . . . . . 37 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 37
10.3 Minimum Security Mechanisms . . . . . . . . . . . . . . . . 37 10. Internationalization Considerations . . . . . . . . . . . . 38
10.4 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . 37 11. Security Considerations . . . . . . . . . . . . . . . . . . 39
References . . . . . . . . . . . . . . . . . . . . . . . . . 38 11.1 Client-to-Server Communications . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 39 11.2 Server-to-Server Communications . . . . . . . . . . . . . . 39
A. Standard Error Codes . . . . . . . . . . . . . . . . . . . . 40 11.3 Minimum Security Mechanisms . . . . . . . . . . . . . . . . 39
B. Formal Definitions . . . . . . . . . . . . . . . . . . . . . 42 11.4 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . 40
B.1 streams namespace . . . . . . . . . . . . . . . . . . . . . 42 References . . . . . . . . . . . . . . . . . . . . . . . . . 41
B.1.1 DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 42
B.1.2 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 A. Standard Error Codes . . . . . . . . . . . . . . . . . . . . 44
B.2 SASL namespace . . . . . . . . . . . . . . . . . . . . . . . 43 B. Formal Definitions . . . . . . . . . . . . . . . . . . . . . 46
B.2.1 DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 B.1 streams namespace . . . . . . . . . . . . . . . . . . . . . 46
B.2.2 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 B.1.1 DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
B.3 jabber:client namespace . . . . . . . . . . . . . . . . . . 45 B.1.2 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
B.3.1 DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 B.2 SASL namespace . . . . . . . . . . . . . . . . . . . . . . . 47
B.3.2 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 B.2.1 DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
B.4 jabber:server namespace . . . . . . . . . . . . . . . . . . 49 B.2.2 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
B.4.1 DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 B.3 jabber:client namespace . . . . . . . . . . . . . . . . . . 49
B.4.2 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 B.3.1 DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
C. Revision History . . . . . . . . . . . . . . . . . . . . . . 54 B.3.2 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
C.1 Changes from draft-miller-xmpp-core-02 . . . . . . . . . . . 54 B.4 jabber:server namespace . . . . . . . . . . . . . . . . . . 53
Full Copyright Statement . . . . . . . . . . . . . . . . . . 56 B.4.1 DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
B.4.2 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
C. Revision History . . . . . . . . . . . . . . . . . . . . . . 58
C.1 Changes from draft-ietf-xmpp-core-00 . . . . . . . . . . . . 58
C.2 Changes from draft-miller-xmpp-core-02 . . . . . . . . . . . 58
Full Copyright Statement . . . . . . . . . . . . . . . . . . 60
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 and presence. The protocol [1] protocol for near-real-time messaging and presence. The protocol
was developed originally within the Jabber community starting in was developed originally within the Jabber community starting in
1998, and since 2001 has continued to evolve under the auspices of 1998, and since 2001 has continued to evolve under the auspices of
the Jabber Software Foundation and now the XMPP WG. Currently, there the Jabber Software Foundation and now the XMPP WG. Currently, there
skipping to change at page 6, line 14 skipping to change at page 6, line 14
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. (Clients on foreign messaging networks and any associated services. (Clients on foreign messaging networks
may also be part of the architecture, made accessable via a gateway may also be part of the architecture, made accessable via a gateway
to that network.) Multiple resources (e.g., devices or locations) MAY to that network.) Multiple resources (e.g., devices or locations) MAY
connect simultaneously to a server on behalf of each authorized connect simultaneously to a server on behalf of each authorized
client, with each resource connecting over a discrete TCP socket and client, with each resource connecting over a discrete TCP socket and
differentiated by the resource identifier of a Jabber ID (Section 3) differentiated by the resource identifier of a JID (Section 3) (e.g.,
(e.g., user@domain/home vs. user@domain/work). The port assigned by user@domain/home vs. user@domain/work). The port assigned by the
the IANA [6] for connections between a Jabber client and a Jabber IANA [6] for connections between a Jabber client and a Jabber server
server is 5222. For further details about client-to-server is 5222. For further details about client-to-server communications
communications for the purpose of instant messaging and presence, for the purpose of instant messaging and presence, refer to XMPP IM
refer to XMPP IM [2]. [2].
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 7, line 12 skipping to change at page 7, line 12
5269 and to negotiate a connection using the Dialback Protocol 5269 and to negotiate a connection using the Dialback Protocol
(Section 5.2) as defined in this document. (Section 5.2) as 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 Any entity that can be considered a network endpoint (i.e., an ID on
the network) and that can communicate using XMPP is considered a the network) and that can communicate using XMPP is considered a
Jabber Entity. All such entities are uniquely addressable in a form Jabber Entity. All such entities are uniquely addressable in a form
that is consistent with RFC 2396 [7]. In particular, a valid Jabber that is consistent with RFC 2396 [13]. 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 is offered by a multi-user chat service is addressed as room offered by a multi-user chat service could be addressed as
room@service, where "room" is the name of the chat room and "service" room@service, where "room" is the name of the chat room and "service"
is the hostname of the multi-user chat service. is the hostname of the multi-user chat service.
3.2 Domain Identifier 3.2 Domain Identifier
The domain identifier is the primary identifier and is the only The domain identifier is the primary identifier and is the only
REQUIRED element of a JID (a simple domain identifier is a valid REQUIRED element of a JID (a simple domain identifier is a valid
JID). It usually represents the network gateway or "primary" server JID). It usually represents the network gateway or "primary" server
to which other entities connect for XML routing and data management to 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, and a domain identifier SHOULD conform to RRC 952 [8] and REF Name, and a domain identifier SHOULD conform to RFC 952 [14] and RFC
1123 [9]. Specifically, a domain identifier is case-insensitive 7- 1123 [15]. Specifically, a domain identifier is case-insensitive 7-
bit ASCII and is limited to 255 bytes. bit ASCII and is limited to 255 bytes.
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 (e.g., 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). Node identifiers are restricted to 256 domain (e.g., user@domain). Node identifiers are restricted to 255
bytes. A node identifier MAY contain any Unicode character higher bytes. A node identifier MAY contain any valid, properly transformed
than #x20 with the exception of the following: UCS character (see Character Encodings (Section 8.4), as long as the
character code either is higher than #x20 or is not one of the
following:
o #x22 (") o #x22 (")
o #x26 (&) o #x26 (&)
o #x27 (') o #x27 (')
o #x3A (:) o #x3A (:)
o #x3C (<) o #x3C (<)
skipping to change at page 8, line 37 skipping to change at page 8, line 39
Case is preserved, but comparisons are made in case-normalized Case is preserved, but comparisons are made in case-normalized
canonical form. canonical form.
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. A resource may maintain multiple resources simultaneously. A resource
identifier is restricted to 256 bytes in length. A resource identifier is restricted to 255 bytes in length. A resource
identifier MAY include any Unicode character greater than #x20, identifier MAY include any valid, properly transformed UCS character
except #xFFFE and #xFFFF; if the Unicode character is a valid XML (see Character Encodings (Section 8.4)) greater than #x20, except
character as defined in Section 2.2 of the XML specification [1], it #xFFFE and #xFFFF; if the character is a valid XML character as
MUST be suitably escaped for inclusion within an XML stream. defined in Section 2.2 of the XML specification [1], it MUST be
Resource identifiers are case sensitive. suitably escaped for inclusion within an XML stream. Resource
identifiers are case sensitive.
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 a <stream> tag to the server, optionally preceded by a
text declaration specifying the XML version supported and the text declaration specifying the XML version supported and the
character encoding. A compliant entity MUST 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,
such as a message, presence, or IQ stanza (a stanza of an XML such as a message, presence, or IQ stanza (a stanza of an XML
skipping to change at page 10, line 26 skipping to change at page 10, line 26
| <iq to=''> | | <iq to=''> |
| <query/> | | <query/> |
| </iq> | | </iq> |
|-------------------| |-------------------|
| </stream> | | </stream> |
|-------------------| |-------------------|
4.2 Restrictions 4.2 Restrictions
XML streams are used to transport a subset of XML. Specifically, XML XML streams are used to transport a subset of XML. Specifically, XML
streams SHOULD NOT contain processing instructions, non-predefined streams SHOULD NOT contain processing instructions, predefined
entities (as defined in Section 4.6 of the XML specification [1]), entities (as defined in Section 4.6 of the XML specification [1]),
comments, or DTDs. Any such XML data SHOULD be ignored. comments, or DTDs. Any such XML data SHOULD be ignored.
4.3 Stream Attributes 4.3 Stream Attributes
The attributes of the stream element are as follows (we now The attributes of the stream element are as follows (we now
generalize the endpoints by using the terms "initiating entity" and generalize the endpoints by using the terms "initiating entity" and
"receiving entity"): "receiving entity"):
o to -- The 'to' attribute SHOULD be used only in the XML stream o to -- The 'to' attribute SHOULD be used only in the XML stream
skipping to change at page 11, line 10 skipping to change at page 11, line 10
however, if a 'from' attribute is included, it SHOULD be ignored however, if a 'from' attribute is included, it SHOULD be ignored
by the receiving entity. by the receiving entity.
o id -- The 'id' attribute SHOULD be used only in the XML stream o id -- The 'id' attribute SHOULD be used only in the XML stream
from the receiving entity to the initiating entity. This from the receiving entity to the initiating entity. This
attribute is a unique identifier created by the receiving entity attribute is a unique identifier created by the receiving entity
to function as a session key for the initiating entity's session to function as a session key for the initiating entity's session
with the receiving entity. There SHOULD be no 'id' attribute on with the receiving entity. There SHOULD be no 'id' attribute on
the XML stream sent from the initiating entity to the receiving the XML stream sent from the initiating entity to the receiving
entity; however, if an 'id' attribute is included, it SHOULD be entity; however, if an 'id' attribute is included, it SHOULD be
ignored by the receiving entity. The 'id' attribute is of type ID ignored by the receiving entity.
as defined in section 3.3.1 of the XML specification [1] and
therefore MUST match the Name production as defined in section 2.3
of the XML specification [1]. Validity contraints on names within
XML documents (but not XML streams) are defined in the XML
specification [1]; however, because the stream in one direction
can be seen as a document that is built up over the length of a
session, at a minimum the value of an 'id' attribute MUST be
unique within that stream.
o version -- The 'version' attribute MAY be used in the XML stream o version -- The 'version' attribute MAY be used in the XML stream
from the initiating entity to the receiving entity in order signal from the initiating entity to the receiving entity in order signal
compliance with the protocol defined herein; this is done by compliance with the protocol defined herein; this is done by
setting the value of the attribute to "1.0". If the initiating setting the value of the attribute to "1.0". If the initiating
entity includes the version attribute, the receiving entity MUST entity includes the version attribute, the receiving entity MUST
reciprocate by including the attribute in its response (if the reciprocate by including the attribute in its response (if the
receiving entity supports XMPP 1.0). receiving entity supports XMPP 1.0).
We can summarize these values as follows: We can summarize these values as follows:
skipping to change at page 11, line 40 skipping to change at page 11, line 32
| 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 [11]. in the XML namespaces specification [16].
A stream namespace declaration is REQUIRED in both XML streams. A
compliant entity MUST accept any namespace prefix on the <stream/>
element; however, for historical reasons some entities MAY accept
only a 'stream' prefix, resulting in use of a <stream:stream/>
element as the stream root. The value of the stream namespace MUST
be "http://etherx.jabber.org/streams".
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
both XML streams. A compliant entity MUST accept any namespace
prefix on the <stream/> element; however, for historical reasons some
entities MAY accept only a 'stream' prefix, resulting in use of a
<stream:stream/> element as the stream root. The value of the stream
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):
o jabber:client -- this default namespace is declared when the o jabber:client -- this default namespace is declared when the
stream is used for communications between a client and a server stream is used for communications between a client and a server
skipping to change at page 12, line 47 skipping to change at page 12, line 39
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 (examples are shown under Stream Authentication
(Section 5) below. (Section 5) below). If an entity does not 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 SHOULD be sent by a Jabber entity (usually a server error child SHOULD be sent by a Jabber entity (usually a server
rather than a client) if it perceives that a stream-level error has rather than a client) if it perceives that a stream-level error has
occurred. Examples include the sending of invalid XML, the shutdown occurred. Examples include the sending of invalid XML, the shutdown
of a server, an internal server error such as the shutdown of a of a server, an internal server error such as the shutdown of a
session manager, and an attempt by a client to authenticate as the session manager, and an attempt by a client to authenticate as the
skipping to change at page 16, line 14 skipping to change at page 15, line 14
5. Stream Authentication 5. 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 a service), the preferred administrator configures a server to trust a service), the preferred
method for authenticating streams between the two entities uses an method for authenticating streams between the two entities uses an
XMPP adaptation of the Simple Authentication and Security Layer XMPP adaptation of the Simple Authentication and Security Layer
(SASL) [10]. When there is no existing trust relationship between (SASL) [12]. When there is no existing trust relationship between
the two entities, such trust MAY be established based on existing the two entities, such trust MAY be established based on existing
trust in DNS; the authentication method used when two such entities trust in DNS; the authentication method used when two such entities
are servers is the server dialback protocol that is native to XMPP. are servers is the server dialback protocol that is native to XMPP.
Both of these methods are described in this section. Both of these methods are described in this section.
5.1 SASL Authentication 5.1 SASL Authentication
5.1.1 Overview 5.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
[10] (the namespace identifier for this protocol is http:// [12] (the namespace identifier for this protocol is http://
www.iana.org/assignments/sasl-mechanisms). If an entity (client, www.iana.org/assignments/sasl-mechanisms). If an entity (client,
server, or service) is capable of authenticating by means of SASL, it server, or service) is capable of authenticating by means of SASL, it
MUST include the agreed-upon SASL namespace within the opening root MUST include the agreed-upon SASL namespace within the opening root
stream tag it uses to initiate communications. stream tag it uses to initiate communications.
The following example shows the use of SASL in client authentication The following example shows the use of SASL in client authentication
with a server, for which the steps involved are as follows: with a server, for which the steps involved are as follows:
1. The client requests SASL authentication by including the 1. The client requests SASL authentication by including the
appropriate namespace declaration (xmlns:sasl='http:// appropriate namespace declaration (xmlns:sasl='http://
skipping to change at page 16, line 50 skipping to change at page 15, line 50
stream header sent to the server. stream header sent to the server.
2. The server includes the xmlns:sasl namespace declaration in the 2. The server includes the xmlns:sasl namespace declaration in the
XML stream header sent in reply to the client. XML stream header sent in reply to the client.
3. The server responds with a list of available SASL authentication 3. The server responds with a list of available SASL authentication
mechanisms, each of which is a <mechanism/> element included as a mechanisms, each of which is a <mechanism/> element included as a
child within a <mechanisms/> container element that is sent as a child within a <mechanisms/> container element that is sent as a
first-level child of the root <stream/> element. first-level child of the root <stream/> element.
4. The client selects a mechanism by sending a <sasl:auth/> element 4. The client selects a mechanism by sending an <auth/> element to
to the server; this element MAY optionally contain character the server; this element MAY optionally contain character data if
data. the mechanism supports or requires it.
5. If necessary, the server challenges the client by sending a 5. If necessary, the server challenges the client by sending a
<sasl:challenge/> element to the client; this element MAY <challenge/> element to the client; this element MAY optionally
optionally contain character data. contain character data.
6. The client responds to challenge by sending a <sasl:response/> 6. The client responds to challenge by sending a <response/> element
element to the server; this element MAY optionally contain to the server; this element MAY optionally contain character
character data. data.
7. If necessary, the server sends more challenges and the client 7. 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 a <sasl:abort/> element o The client aborts the handshake by sending a <abort/> element to
to the server. the server.
o The server reports failure by sending a <sasl:failure/> element to o The server reports failure by sending a <failure/> element to the
the client. client.
o The server reports success by sending a <sasl:success/> element to o The server reports success by sending a <success/> element to the
the client; this element MAY optionally contain character data. client; this element MAY optionally contain character data.
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 Example 5.1.2 Example
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:
skipping to change at page 18, line 27 skipping to change at page 17, line 27
<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:
<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 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:
realm="cataclysm.cx",nonce="OA6MG9tEQGm2hh",\ qop="auth",charset=utf-
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 9BNk1HOXRFUUdtMmhoIixjbm9uY2U9Ik9BNk1IWGg2VnFUclJrIixuYz0w
MDAwMDAwMSxxb3A9YXV0aCxkaWdlc3QtdXJpPSJqYWJiZXIvY2F0YWNseX MDAwMDAwMSxxb3A9YXV0aCxkaWdlc3QtdXJpPSJqYWJiZXIvY2F0YWNseX
NtLmN4IixyZXNwb25zZT1kMzg4ZGFkOTBkNGJiZDc2MGExNTIzMjFmMjE0 NtLmN4IixyZXNwb25zZT1kMzg4ZGFkOTBkNGJiZDc2MGExNTIzMjFmMjE0
M2FmNyxjaGFyc2V0PXV0Zi04 M2FmNyxjaGFyc2V0PXV0Zi04
</response> </response>
The decoded response is:
username="rob",realm="cataclysm.cx",nonce="OA6MG9tEQGm2hh",\
cnonce="OA6MHXh6VqTrRk",nc=00000001,qop=auth,\ digest-uri="jabber/
cataclysm.cx",\
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:
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:
skipping to change at page 19, line 31 skipping to change at page 18, line 45
under the "jabber:server" namespace. 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 [13] record of MUST first resolve the hostname using an SRV [18] 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 [6].
Note that the method used to generate and verify the keys used in the Note that the method used to generate and verify the keys used in the
dialback protocol MUST take into account the hostnames being used, dialback protocol MUST take into account the hostnames being used,
along with a secret known only by the receiving server and the random along with a secret known only by the receiving server and the random
id per stream. Generating unique but verifiable keys is important to ID per stream. Generating unique but verifiable keys is important to
prevent common man-in-the-middle attacks and server spoofing. prevent common man-in-the-middle attacks and 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
the Originating Server represents the Jabber server which it the Originating Server represents the Jabber server which it
claims to be claims to be
skipping to change at page 25, line 5 skipping to change at page 24, 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 the Originating Server and read validated, data can be sent by the Originating Server and read
by the Receiving Server; before that, all data stanzas sent to by the 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, the Receiving Server MUST verify that all XML domain spoofing, the Receiving Server MUST verify that all XML
stanzas received from the Originating Server include a 'from' stanzas received from the 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. XML Stanzas 6. Stream Encryption
6.1 Overview 6.1 Overview
XMPP includes a method for securing the stream from tampering and
eavesdropping. This method makes use of the Transport Layer Security
(TLS) [7] protocol, along with a "STARTTLS" extension that is
modelled on similar extensions for the IMAP [8], POP3 [9], and ACAP
[10] protocols as described in RFC 2595 [11].
The namespace identifier for the STARTTLS extension is http://
www.ietf.org/rfc/rfc2595.txt. If an entity (client, server or
service) 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 wich the steps involved are as follows:
1. The client initiates the stream by sending the opening XML stream
header to the server.
2. The server responds by 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
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 [7].
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 Protocol 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'>
<stream:features>
<mechanisms xmlns='http://www.iana.org/assignments/sasl-mechanisms'>
<mechanism>DIGEST-MD5</mechanism>
<mechanism>PLAIN</mechanism>
<mechanism>EXTERNAL</mechanism>
</mechanisms>
</stream:features>
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'>
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 [12]). If the client selects this mechanism for
authentication, the authentication credentials shall be taken from
the presented certificate.
7. XML Stanzas
7.1 Overview
There are three core data elements for XMPP communications: <message/ There are three core data elements for XMPP communications: <message/
>, <presence/>, and <iq/>. These elements are sent as direct >, <presence/>, and <iq/>. These elements are sent as direct
(depth=1) children of the root <stream/> element and are scoped by (depth=1) children of the root <stream/> element and are scoped by
one of the default namespaces identified in Section 4.4. Any such one of the default namespaces identified in Section 4.4. Any such
direct child element of the root stream element is called an "XML direct child element of the root stream element is called an "XML
stanza". stanza".
6.2 Common Attributes 7.2 Common Attributes
Four attributes are common to message, presence, and IQ stanzas. Four attributes are common to message, presence, and IQ stanzas.
These are defined below. These are defined below.
6.2.1 to 7.2.1 to
The 'to' attribute specifies the JID of the intended recipient for The 'to' attribute specifies the JID of the intended recipient for
the stanza. In the 'jabber:client' namespace, a stanza SHOULD the stanza. In the 'jabber:client' namespace, a stanza SHOULD
possess a 'to' attribute, although a stanza sent from a client to a possess a 'to' attribute, although a stanza sent from a client to a
server for handling by that server (e.g., presence sent to the server server for handling by that server (e.g., presence sent to the server
for broadcasting to other entities) MAY legitimately lack a 'to' for broadcasting to other entities) MAY legitimately lack a 'to'
attribute. In the 'jabber:server' namespace, a stanza MUST possess a attribute. In the 'jabber:server' namespace, a stanza MUST possess a
'to' attribute. 'to' attribute.
6.2.2 from 7.2.2 from
The 'from' attribute specifies the JID of the sender. The 'from' attribute specifies the JID of the sender.
In the 'jabber:client' namespace, a client MUST NOT include a 'from' In the 'jabber:client' namespace, a client MUST NOT include a 'from'
attribute on the stanzas it sends to a server; if a server receives a attribute on the stanzas it sends to a server; if a server receives a
stanza from a client and the stanza possesses a 'from' attribute, it stanza from a client and the stanza possesses a 'from' attribute, it
MUST ignore the value of the 'from' attribute. In addition, a server MUST ignore the value of the 'from' attribute. In addition, a server
MUST stamp stanzas received from a client with the user@domain/ MUST stamp stanzas received from a client with the user@domain/
resource (full JID) of the connected resource that generated the resource (full JID) of the connected resource that generated the
stanza. In the 'jabber:server' namespace, a stanza MUST possess a stanza. In the 'jabber:server' namespace, a stanza MUST possess a
'from' attribute. 'from' attribute.
A server MUST include a 'from' attribute on stanzas it routes to A server MUST include a 'from' attribute on stanzas it routes to
other servers. The domain identifier of the JID contained in the other servers. The domain identifier of the JID contained in the
'from' attribute MUST match the hostname of the server as 'from' attribute MUST match the hostname of the server as
communicated in the dialback negotiation (or a subdomain thereof). communicated in the dialback negotiation (or a subdomain thereof).
6.2.3 id 7.2.3 id
The optional 'id' attribute MAY be used to track stanzas sent and The optional 'id' attribute MAY be used to track stanzas sent and
received. The 'id' attribute is generated by the sender. An 'id' received. The 'id' attribute is generated by the sender. An 'id'
attribute included in an IQ request of type "get" or "set" SHOULD be attribute included in an IQ request of type "get" or "set" SHOULD be
returned to the sender in any IQ response of type "result" or "error" returned to the sender in any IQ response of type "result" or "error"
generated by the recipient of the request. A recipient of a message generated by the recipient of the request. A recipient of a message
or presence stanza MAY return that 'id' in any replies, but is NOT or presence stanza MAY return that 'id' in any replies, but is NOT
REQUIRED to do so. REQUIRED to do so.
The 'id' attribute is of type ID as defined in section 3.3.1 of the The value of the 'id' attribute is not intended to be unique --
XML specification [1] and therefore MUST match the Name production as globally, within a domain, or within a stream. It is generated by a
defined in section 2.3 of the XML specification [1]. Validity sender only for internal tracking of information within the sending
contraints on names within XML documents (but not XML streams) are application.
defined in the XML specification [1]; however, because the stream in
one direction can be seen as a document that is built up over the
length of a session, at a minimum the value of an 'id' attribute MUST
be unique within that stream.
6.2.4 type 7.2.4 type
The 'type' attribute specifies detailed information about the purpose The 'type' attribute specifies detailed information about the purpose
or context of the message, presence, or IQ stanza. The particular or context of the message, presence, or IQ stanza. The particular
allowable values for the 'type' attribute vary depending on whether allowable values for the 'type' attribute vary depending on whether
the stanza is a message, presence, or IQ, and thus are specified in the stanza is a message, presence, or IQ, and thus are specified in
the following sections. the following sections.
6.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 a NMTOKEN and MUST conform to the the 'xml:lang' attribute MUST be a NMTOKEN and MUST conform to the
format defined in RFC 3066 [12]. format defined in RFC 3066 [17].
6.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.
6.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 and specifies
the conversational context of the message. The sending of a message the conversational context of the message. The sending of a message
stanza without a 'type' attribute signals that the message stanza is stanza without a 'type' attribute signals that the message stanza is
a single message. However, the 'type' attribute MAY also have one of a single message. However, the 'type' attribute MAY also have one of
the following values: 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.
skipping to change at page 27, line 22 skipping to change at page 29, line 18
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 these message types, refer to XMPP IM For detailed information about these message types, refer to XMPP IM
[2]. [2].
6.3.2 Children 7.3.2 Children
If a message stanza in the 'jabber:client' or 'jabber:server' If a message stanza in the 'jabber:client' or 'jabber:server'
namespace has no 'type' attribute or has a 'type' attribute with a namespace has no 'type' attribute or has a 'type' attribute with a
value of "chat", "groupchat", or "headline", it MAY contain any of value of "chat", "groupchat", or "headline", it MAY contain any of
the following child elements (which MUST NOT contain mixed content): the following child elements (which MUST NOT contain mixed content):
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.
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 but only if each instance possesses an element MAY be included for the purpose of providing alternate
'xml:lang' attribute with a distinct language value. versions of the same subject, but only if each instance possesses
an 'xml:lang' attribute with a distinct language value.
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 MAY be copied back in replies; it is used for tracking a
conversation thread between two entities. If used, it MUST be conversation thread (sometimes referred to as an "IM session")
unique to that conversation thread within the stream and MUST be between two entities. If used, it MUST be unique to that
consistent throughout that conversation. Only one <thread/> conversation thread within the stream and MUST be consistent
element MAY be included in a message stanza, and it MUST NOT throughout that conversation. The use of the <thread/> element is
possess any attributes. optional and is not used to identify individual messages, only
conversations. The recommended method for generating thread IDs
is to concatenate the sender's full JID, the recipient's full JID,
and an absolute date and time, then hash the resulting string
according to the SHA1 algorithm. Only one <thread/> element MAY
be included in a message stanza, and it MUST NOT possess any
attributes. The <thread/> element MUST be treated as an opaque
string by entities; no semantic meaning may be derived from it,
and only exact, case insensitve comparisons can be made against
it.
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".
As described under extended namespaces (Section 6.6), a message As described under extended namespaces (Section 7.6), a message
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).
6.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 to or online, along with various sub-states of the latter) and to
communicate that status to other entities. They are also used to communicate that status to other entities. They are also used to
negotiate and manage subscriptions to the presence of other entities. negotiate and manage subscriptions to the presence of other entities.
6.4.1 Types of Presence 7.4.1 Types of Presence
The 'type' attribute of a presence stanza is optional. A presence The 'type' attribute of a presence stanza is optional. A presence
stanza that does not have a 'type' attribute is used to signal that stanza that does not have a 'type' attribute is used to signal that
the sender is online and available for communication. If included, the sender is online and available for communication. If included,
the 'type' attribute specifies the availability state of the sender, the 'type' attribute specifies the availability state of the sender,
a request to manage a subscription to another entity's presence, a a request to manage a subscription to another entity's presence, a
request for another entity's current presence, or an error related to request for another entity's current presence, or an error related to
a previously-sent presence stanza. The 'type' attribute MAY have one a previously-sent presence stanza. The 'type' attribute MAY have one
of the following values: of the following values:
skipping to change at page 28, line 48 skipping to change at page 31, line 5
o subscribed -- The sender has allowed the recipient to receive o subscribed -- The sender has allowed the recipient to receive
their presence. their presence.
o unsubscribe -- A notification that an entity is unsubscribing from o unsubscribe -- A notification that an entity is unsubscribing from
another entity's presence. another entity's presence.
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. o probe -- A request for an entity's current presence. In general
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 [2].
6.4.2 Children 7.4.2 Children
If a presence stanza possesses no 'type' attribute, it MAY contain If a presence stanza possesses no 'type' attribute, it MAY contain
any of the following child elements (note that the <status/> child any of the following child elements (note that the <status/> child
MAY be sent in a presence stanza of type "unavailable" or, for MAY be sent in a presence stanza of type "unavailable" or, for
historical reasons, "subscribe"): 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
skipping to change at page 29, line 41 skipping to change at page 31, line 47
o status -- An optional natural-language description of availability o status -- An optional natural-language description of availability
status. Normally used in conjunction with the show element to status. Normally used in conjunction with the show element to
provide a detailed description of an availability state (e.g., "In provide a detailed description of an availability state (e.g., "In
a meeting"). The <status/> element MUST NOT possess any a meeting"). The <status/> 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 <status/> element MAY be included but Multiple instances of the <status/> element MAY be included but
only if each instance possesses an 'xml:lang' attribute with a only if each instance possesses an 'xml:lang' attribute with a
distinct language value. distinct language value.
o priority -- A non-negative integer representing the priority level o priority -- An optional element specifying the priority level of
of the connected resource, with zero as the lowest priority. Only the connected resource. The value may be any integer between -128
one <priority/> element MAY be included in a presence stanza, and to 127. Only one <priority/> element MAY be included in a
it MUST NOT possess any attributes. presence stanza, and it MUST NOT possess any attributes.
If the presence stanza is of type "error", it MUST include an <error/ If the presence stanza is of type "error", it MUST include an <error/
> child, which in turn MUST possess a 'code' attribute corresponding > child, which in turn MUST possess a 'code' attribute corresponding
to one of the standard error codes (Appendix A) and MAY contain to one of the standard error codes (Appendix A) and MAY contain
PCDATA corresponding to a natural-language description of the error. PCDATA corresponding to a natural-language description of the error.
An <error/> child MUST NOT be included if the stanza type is anything An <error/> child MUST NOT be included if the stanza type is anything
other than "error". other than "error".
As described under extended namespaces (Section 6.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).
6.5 IQ Stanzas 7.5 IQ Stanzas
6.5.1 Overview 7.5.1 Overview
Info/Query, or IQ, is a simple request-response mechanism. Just as Info/Query, or IQ, is a simple request-response mechanism. Just as
HTTP is a request-response medium, IQ stanzas in the 'jabber:client' HTTP is a request-response medium, so IQ stanzas in the
or 'jabber:server' namespace enable an entity to make a request of, 'jabber:client' or 'jabber:server' namespace enable an entity to make
and receive a response from, another entity. The data content of the a request of, and receive a response from, another entity. The data
request and response is defined by the namespace declaration of a content of the request and response is defined by the namespace
direct child element of the iq element. declaration of a direct child element of the IQ element, and the
interaction is tracked by the requesting entity through use of the
'id' attribute, 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: exchange such as get/result or set/result (although an error may be
returned in response to a request if appropriate):
Requesting Responding Requesting Responding
Entity Entity Entity Entity
---------- ---------- ---------- ----------
| | | |
| <iq type="get"> | | <iq type='get' id='1'> |
| ---------------------> | | ------------------------> |
| | | |
| <iq type="result"> | | <iq type='result' id='1'> |
| <--------------------- | | <------------------------ |
| | | |
| <iq type="set"> | | <iq type='set' id='2'> |
| ---------------------> | | ------------------------> |
| | | |
| <iq type="result"> | | <iq type='result' id='2'> |
| <--------------------- | | <------------------------ |
| | | |
An entity that receives a request of type 'get' or 'set' MUST reply An entity that receives an IQ request of type 'get' or 'set' MUST
with a response of type 'result' or 'error'. reply with an IQ response of type 'result' or 'error' (which response
SHOULD preserve the 'id' attribute of the request). An entity that
receives a stanza of type 'result' or 'error' MUST NOT respond to the
stanza by sending a further IQ response of type 'result' or 'error';
however, as shown above, the requesting entity MAY send another
request (e.g., an IQ of type 'set' in order to provide required
information discovered through a get/result pair).
6.5.2 Types of IQ 7.5.2 Types of IQ
The 'type' attribute of an IQ stanza is REQUIRED. The 'type' The 'type' attribute of an IQ stanza is REQUIRED. The 'type'
attribute specifies a distinct step within a request-response attribute specifies a distinct step within a request-response
interaction. The value SHOULD be one of the following (all other interaction. The value SHOULD be one of the following (all other
values MAY be ignored): values MAY be ignored):
o get -- The stanza is a request for information. o get -- The stanza is a request for information.
o set -- The stanza provides required data, sets new values, or o set -- The stanza provides required data, sets new values, or
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.
6.5.3 Children 7.5.3 Children
An IQ stanza contains no children in the 'jabber:client' or An IQ stanza contains no children in the 'jabber:client' or
'jabber:server' namespace since it is a vessel for XML in another 'jabber:server' namespace since it is a vessel for XML in another
namespace. As described under extended namespaces (Section 6.6), an namespace. As described under extended namespaces (Section 7.6), an
IQ stanza MAY contain any properly-namespaced child element (other IQ stanza MAY 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).
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". other than "error".
6.6 Extended Namespaces 7.6 Extended Namespaces
While the core data elements defined in this document provide a basic While the core data elements defined in this document provide a basic
level of functionality for messaging and presence, XMPP uses XML level of functionality for messaging and presence, XMPP uses XML
namespaces to extend the core data elements for the purpose of namespaces to extend the core data elements for the purpose of
providing additional functionality. Thus a message, presence, or IQ providing additional functionality. Thus a message, presence, or IQ
stanza MAY house one or more optional child elements containing stanza MAY house one or more optional child elements containing
content that extends the meaning of the message (e.g., an encrypted content that extends the meaning of the message (e.g., an encrypted
form of the message body). This child element MAY be any element form of the message body). This child element MAY be any element
(other than the core data elements, stream elements, or defined (other than the core data elements, stream elements, or defined
children thereof). The child element MUST possess an 'xmlns' children thereof). The child element MUST possess an 'xmlns'
namespace declaration (other than the stream namespace and the namespace declaration (other than the stream namespace and the
default namespace) that defines all data contained within the child default namespace) that defines all data contained within the child
element. 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 an entity namespace, it MUST ignore the associated XML data (if the stanza is
receives an IQ stanza in a namespace it does not understand, the being routed on to another entity, ignore means "pass it on
entity SHOULD return an IQ stanza of type "error" with an error untouched"). If an entity receives an IQ stanza in a namespace it
element of code 400 (bad request). If an entity receives a message does not understand, the entity SHOULD return an IQ stanza of type
or presence stanza that contains XML data in an extended namespace it "error" with an error element of code 400 (bad request). If an
does not understand, the portion of the stanza that is in the unknown entity receives a message or presence stanza that contains XML data
namespace SHOULD be ignored. If an entity receives a message stanza in an extended namespace it does not understand, the portion of the
without a <body/> element but containing only a child element bound stanza that is in the unknown namespace SHOULD be ignored. If an
by a namespace it does not understand, it MUST ignore that stanza. entity receives a message stanza without a <body/> element but
containing only a child element bound by a namespace it does not
understand, it MUST ignore that stanza.
7. XML Usage within XMPP 8. XML Usage within XMPP
7.1 Overview 8.1 Overview
In essence, XMPP core consists of three interrelated parts: In essence, XMPP core consists of three interrelated parts:
1. XML streams (Section 4), which provide a stateful means for 1. XML streams (Section 4), which provide a stateful means for
transporting data in an asynchronous manner from one entity to transporting data in an asynchronous manner from one entity to
another another
2. stream authentication using SASL authentication (Section 5.1) or 2. stream authentication using SASL authentication (Section 5.1) or
the dialback protocol (Section 5.2) the dialback protocol (Section 5.2)
3. core data elements (Section 6) (message, presence, and iq), which 3. XML stanzas (Section 7) (message, presence, and IQ), which
provide a framework for communications between entities provide a framework for communications between entities
XML [1] is used to define each of these protocols, as described in XML [1] is used to define each of these protocols, as described in
detail in the following sections. detail in the following sections.
In addition, XMPP contains protocol extensions (such as extended In addition, XMPP contains protocol extensions (such as extended
namespaces) that address the specific functionality required to namespaces) that address the specific functionality required to
create a basic instant messaging and presence application; these non- create a basic instant messaging and presence application; these non-
core protocol extensions are defined in XMPP IM [2]. core protocol extensions are defined in XMPP IM [2].
7.2 Namespaces 8.2 Namespaces
XML Namespaces [11] are used within all XMPP-compliant XML to create XML Namespaces [16] 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. Mainly for historical reasons, the default
namespace for XMPP data stanzas MUST be one of the namespaces namespace for XMPP data stanzas MUST be one of the namespaces
identified in Section 4.4. 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.
7.3 Validation 8.3 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 DTDs and schemas are included herein for
descriptive purposes only. descriptive purposes only.
7.4 Character Encodings 8.4 Character Encodings
Software implementing XML streams MUST support the UTF-8 and UTF-16 Software implementing XML streams MUST support the UTF-8 (RFC 2279
encodings for received data. Software MUST NOT attempt to use any [20]) and UTF-16 (RFC 2781 [21]) transformations of Universal
other encoding for transmitted data. The encodings of the transmit Character Set (ISO/IEC 10646-1 [22]) characters. Software MUST NOT
and receive streams are independent. Software MAY select either UTF- attempt to use any other encoding for transmitted data. The
8 or UTF-16 for the transmitted stream, and SHOULD deduce the encodings of the transmit and receive streams are independent.
encoding of the received stream as described in the XML specification Software MAY select either UTF-8 or UTF-16 for the transmitted
[1]. stream, and SHOULD deduce the encoding of the received stream as
described in the XML specification [1]. For historical reasons,
existing implementations MAY support UTF-8 only.
7.5 Inclusion of Text Declaration 8.5 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] concerning the circumstances the rules in the XML specification [1] concerning the circumstances
in which a text declaration is included. in which a text declaration is included.
8. IANA Considerations 9. IANA Considerations
The IANA registers "jabber-client" and "jabber-server" as GSS-API The IANA registers "jabber-client" and "jabber-server" as GSS-API
[15] service names, as specified in Section 6.1.1; these service [23] service names, as specified in Section 6.1.1; these service
names are associated with TCP ports 5222 and 5269 respectively. names are associated with TCP ports 5222 and 5269 respectively.
9. Internationalization Considerations 10. Internationalization Considerations
o If a client sends an xml:lang attribute on a stanza, the server o If a client sends an xml:lang attribute on a stanza, the server
MUST NOT modify or delete it. MUST NOT modify or delete it.
10. Security Considerations 11. Security Considerations
10.1 Client-to-Server Communications 11.1 Client-to-Server Communications
The SASL protocol for authenticating XML streams negotiated between a The SASL protocol for authenticating XML streams negotiated between a
client and a server (defined under Section 5.1 above) provides a client and a server (defined under Section 5.1 above) provides a
reliable mechanism for validating that a client connecting to a reliable mechanism for validating that a client connecting to a
server is who it claims to be. 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 OpenPGP [14]. information MAY be effected through use of OpenPGP [19].
10.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 5.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 5.2), which provides a reliable
mechanism for preventing the spoofing of servers. mechanism for preventing the spoofing of servers.
10.3 Minimum Security Mechanisms 11.3 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 SASL DIGEST-MD5 mechanism for implementations MUST support the following mechanisms:
authentication.
10.4 Firewalls for authentication: the SASL DIGEST-MD5 mechanism
for confidentiality: 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)
11.4 Firewalls
Communications using XMPP occur over TCP sockets on port 5222 Communications using XMPP occur over TCP sockets on port 5222
(client-to-server) or port 5269 (server-to-server), as registered (client-to-server) or port 5269 (server-to-server), as registered
with the IANA [6]. Use of these well-known ports allows with the IANA [6]. Use of these well-known ports allows
administrators to easily enable or disable XMPP activity through administrators to easily enable or disable XMPP activity through
existing and commonly-deployed firewalls. 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)
skipping to change at page 38, line 28 skipping to change at page 41, line 28
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement [4] 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 [5] 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 [6] 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 [7] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and
P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January
1999.
[8] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 2060, December 1996.
[9] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD
53, RFC 1939, May 1996.
[10] Newman, C. and J. Myers, "ACAP -- Application Configuration
Access Protocol", RFC 2244, November 1997.
[11] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595,
June 1999.
[12] Myers, J., "Simple Authentication and Security Layer (SASL)",
RFC 2222, October 1997.
[13] 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 [14] 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 [15] Braden, R., "Requirements for Internet Hosts - Application and
Support", STD 3, RFC 1123, October 1989. Support", STD 3, RFC 1123, October 1989.
[10] Myers, J., "Simple Authentication and Security Layer (SASL)", [16] World Wide Web Consortium, "Namespaces in XML", W3C xml-names,
RFC 2222, October 1997.
[11] 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/>.
[12] Alvestrand, H., "Tags for the Identification of Languages", BCP [17] Alvestrand, H., "Tags for the Identification of Languages", BCP
47, RFC 3066, January 2001. 47, RFC 3066, January 2001.
[13] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the [18] 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.
[14] Elkins, M., Del Torto, D., Levien, R. and T. Roessler, "MIME [19] Elkins, M., Del Torto, D., Levien, R. and T. Roessler, "MIME
Security with OpenPGP", RFC 3156, August 2001. Security with OpenPGP", RFC 3156, August 2001.
[15] Linn, J., "Generic Security Service Application Program [20] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998.
[21] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646",
RFC 2781, February 2000.
[22] International Organization for Standardization, "Information
Technology - Universal Multiple-octet coded Character Set (UCS)
- Amendment 2: UCS Transformation Format 8 (UTF-8)", ISO
Standard 10646-1 Addendum 2, October 1996.
[23] Linn, J., "Generic Security Service Application Program
Interface, Version 2", RFC 2078, January 1997. Interface, Version 2", RFC 2078, January 1997.
Authors' Addresses Authors' Addresses
Jeremie Miller Jeremie Miller
Jabber Software Foundation Jabber Software Foundation
1899 Wynkoop Street, Suite 600 1899 Wynkoop Street, Suite 600
Denver, CO 80202 Denver, CO 80202
US US
skipping to change at page 51, line 8 skipping to change at page 55, line 8
<?xml version='1.0' encoding='UTF-8'?> <?xml version='1.0' encoding='UTF-8'?>
<xsd:schema <xsd:schema
xmlns:xsd='http://www.w3.org/2001/XMLSchema' xmlns:xsd='http://www.w3.org/2001/XMLSchema'
targetNamespace='http://www.jabber.org/protocol' targetNamespace='http://www.jabber.org/protocol'
xmlns='http://www.jabber.org/protocol' xmlns='http://www.jabber.org/protocol'
elementFormDefault='qualified'> elementFormDefault='qualified'>
<xsd:element name='message'> <xsd:element name='message'>
<xsd:complexType mixed='true'> <xsd:complexType mixed='true'>
<xsd:choice> <xsd:choice maxOccurs='unbounded'>
<xsd:element ref='body' minOccurs='0' maxOccurs='unbounded'/> <xsd:element ref='body' minOccurs='0' maxOccurs='unbounded'/>
<xsd:element ref='subject' minOccurs='0' maxOccurs='unbounded'/> <xsd:element ref='subject' minOccurs='0' maxOccurs='unbounded'/>
<xsd:element ref='thread' minOccurs='0' maxOccurs='1'/> <xsd:element ref='thread' minOccurs='0' maxOccurs='1'/>
<xsd:element ref='error' minOccurs='0' maxOccurs='1'/> <xsd:element ref='error' minOccurs='0' maxOccurs='1'/>
<xsd:any <xsd:any
namespace='##other' namespace='##other'
minOccurs='0' minOccurs='0'
maxOccurs='unbounded'/> maxOccurs='unbounded'/>
</xsd:choice> </xsd:choice>
<xsd:attribute name='to' type='xsd:string' use='required'/> <xsd:attribute name='to' type='xsd:string' use='required'/>
skipping to change at page 51, line 51 skipping to change at page 55, line 51
<xsd:element name='subject' type='xsd:string'> <xsd:element name='subject' type='xsd:string'>
<xsd:complexType> <xsd:complexType>
<xsd:attribute name='xml:lang' type='xsd:NMTOKEN' use='optional'/> <xsd:attribute name='xml:lang' type='xsd:NMTOKEN' use='optional'/>
</xsd:complexType> </xsd:complexType>
</xsd:element> </xsd:element>
<xsd:element name='thread' type='xsd:string'/> <xsd:element name='thread' type='xsd:string'/>
<xsd:element name='presence'> <xsd:element name='presence'>
<xsd:complexType> <xsd:complexType>
<xsd:choice> <xsd:choice maxOccurs='unbounded'>
<xsd:element ref='show' minOccurs='0' maxOccurs='1'/> <xsd:element ref='show' minOccurs='0' maxOccurs='1'/>
<xsd:element ref='status' minOccurs='0' maxOccurs='unbounded'/> <xsd:element ref='status' minOccurs='0' maxOccurs='unbounded'/>
<xsd:element ref='priority' minOccurs='0' maxOccurs='1'/> <xsd:element ref='priority' minOccurs='0' maxOccurs='1'/>
<xsd:element ref='error' minOccurs='0' maxOccurs='1'/> <xsd:element ref='error' minOccurs='0' maxOccurs='1'/>
<xsd:any <xsd:any
namespace='##other' namespace='##other'
minOccurs='0' minOccurs='0'
maxOccurs='unbounded'/> maxOccurs='unbounded'/>
</xsd:choice> </xsd:choice>
<xsd:attribute name='to' type='xsd:string' use='required'/> <xsd:attribute name='to' type='xsd:string' use='required'/>
skipping to change at page 52, line 49 skipping to change at page 56, line 49
</xsd:restriction> </xsd:restriction>
</xsd:simpleType> </xsd:simpleType>
</xsd:element> </xsd:element>
<xsd:element name='status' type='xsd:string'> <xsd:element name='status' type='xsd:string'>
<xsd:complexType> <xsd:complexType>
<xsd:attribute name='xml:lang' type='xsd:NMTOKEN' use='optional'/> <xsd:attribute name='xml:lang' type='xsd:NMTOKEN' use='optional'/>
</xsd:complexType> </xsd:complexType>
</xsd:element> </xsd:element>
<xsd:element name='priority' type='xsd:nonNegativeInteger'/> <xsd:element name='priority' type='xsd:byte'/>
<xsd:element name='iq'> <xsd:element name='iq'>
<xsd:complexType mixed='true'> <xsd:complexType mixed='true'>
<xsd:choice> <xsd:choice maxOccurs='unbounded'>
<xsd:element ref='error' minOccurs='0' maxOccurs='1'/> <xsd:element ref='error' minOccurs='0' maxOccurs='1'/>
<xsd:any <xsd:any
namespace='##other' namespace='##other'
minOccurs='0' minOccurs='0'
maxOccurs='unbounded'/> maxOccurs='unbounded'/>
</xsd:choice> </xsd:choice>
<xsd:attribute name='to' type='xsd:string' use='required'/> <xsd:attribute name='to' type='xsd:string' use='required'/>
<xsd:attribute name='from' type='xsd:string' use='required'/> <xsd:attribute name='from' type='xsd:string' use='required'/>
<xsd:attribute name='id' type='xsd:ID' use='optional'/> <xsd:attribute name='id' type='xsd:ID' use='optional'/>
<xsd:attribute name='type' use='required'> <xsd:attribute name='type' use='required'>
skipping to change at page 54, line 10 skipping to change at page 58, line 10
</xsd:complexType> </xsd:complexType>
</xsd:element> </xsd:element>
</xsd:schema> </xsd: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-miller-xmpp-core-02 C.1 Changes from draft-ietf-xmpp-core-00
o Added information about TLS from list discussion.
o Clarified meaning of "ignore" based on list discussion.
o Clarified information about Universal Character Set data and
character encodings.
o Provided base64-decoded information for examples.
o Fixed several errors in the schemas.
o Made numerous small editorial fixes.
C.2 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.
skipping to change at page 56, line 7 skipping to change at page 60, line 7
o Further specified the scope and uniqueness of the 'id' attribute o Further specified the scope and uniqueness of the 'id' attribute
in all stanza types and the <thread/> element in message stanzas. in all stanza types and the <thread/> element in message stanzas.
o Nomenclature changes: (1) from "chunks" to "stanzas"; (2) from o Nomenclature changes: (1) from "chunks" to "stanzas"; (2) from
"host" to "server" and from "node" to "client" (except with regard "host" to "server" and from "node" to "client" (except with regard
to definition of the addressing scheme). to definition of the addressing scheme).
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 101 change blocks. 
232 lines changed or deleted 441 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/