draft-ietf-xmpp-core-06.txt   draft-ietf-xmpp-core-07.txt 
Network Working Group P. Saint-Andre Network Working Group P. Saint-Andre
Internet-Draft J. Miller Internet-Draft J. Miller
Expires: September 24, 2003 Jabber Software Foundation Expires: October 1, 2003 Jabber Software Foundation
March 26, 2003 April 2, 2003
XMPP Core XMPP Core
draft-ietf-xmpp-core-06 draft-ietf-xmpp-core-07
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 September 24, 2003. This Internet-Draft will expire on October 1, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This document describes the core features of the Extensible Messaging This document describes the core features of the Extensible Messaging
and Presence Protocol (XMPP), a protocol for streaming XML in near- and Presence Protocol (XMPP), a protocol for streaming XML elements
real-time that is used mainly for the purpose of instant messaging in order to exchange messages and presence information in close to
(IM) and presence by the servers, clients, and other applications real time. XMPP is used mainly for the purpose of building instant
that comprise the Jabber network. messaging (IM) and presence applications, such as the servers and
clients that comprise the Jabber network.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Discussion Venue . . . . . . . . . . . . . . . . . . . . . . 5 1.3 Discussion Venue . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Intellectual Property Notice . . . . . . . . . . . . . . . . 5 1.4 Intellectual Property Notice . . . . . . . . . . . . . . . . 5
2. Generalized Architecture . . . . . . . . . . . . . . . . . . 6 2. Generalized Architecture . . . . . . . . . . . . . . . . . . 6
2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
skipping to change at page 2, line 25 skipping to change at page 2, line 25
2.3 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.4 Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5 Network . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.5 Network . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Addressing Scheme . . . . . . . . . . . . . . . . . . . . . 8 3. Addressing Scheme . . . . . . . . . . . . . . . . . . . . . 8
3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Domain Identifier . . . . . . . . . . . . . . . . . . . . . 8 3.2 Domain Identifier . . . . . . . . . . . . . . . . . . . . . 8
3.3 Node Identifier . . . . . . . . . . . . . . . . . . . . . . 8 3.3 Node Identifier . . . . . . . . . . . . . . . . . . . . . . 8
3.4 Resource Identifier . . . . . . . . . . . . . . . . . . . . 9 3.4 Resource Identifier . . . . . . . . . . . . . . . . . . . . 9
4. XML Streams . . . . . . . . . . . . . . . . . . . . . . . . 10 4. XML Streams . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2 Restrictions . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2 Stream Attributes . . . . . . . . . . . . . . . . . . . . . 11
4.3 Stream Attributes . . . . . . . . . . . . . . . . . . . . . 11 4.3 Namespace Declarations . . . . . . . . . . . . . . . . . . . 12
4.4 Namespace Declarations . . . . . . . . . . . . . . . . . . . 12 4.4 Stream Features . . . . . . . . . . . . . . . . . . . . . . 13
4.5 Stream Features . . . . . . . . . . . . . . . . . . . . . . 13 4.5 Stream Errors . . . . . . . . . . . . . . . . . . . . . . . 13
4.6 Stream Errors . . . . . . . . . . . . . . . . . . . . . . . 14 4.5.1 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.6.1 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.5.2 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.6.2 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.5.3 Conditions . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.6.3 Conditions . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.5.4 Extensibility . . . . . . . . . . . . . . . . . . . . . . . 16
4.6.4 Extensibility . . . . . . . . . . . . . . . . . . . . . . . 16 4.6 Simple Streams Example . . . . . . . . . . . . . . . . . . . 16
4.7 Simple Streams Example . . . . . . . . . . . . . . . . . . . 16
5. Stream Encryption . . . . . . . . . . . . . . . . . . . . . 18 5. Stream Encryption . . . . . . . . . . . . . . . . . . . . . 18
5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.2 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.2 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.3 Client-to-Server Example . . . . . . . . . . . . . . . . . . 19 5.3 Client-to-Server Example . . . . . . . . . . . . . . . . . . 20
5.4 Server-to-Server Example . . . . . . . . . . . . . . . . . . 21 5.4 Server-to-Server Example . . . . . . . . . . . . . . . . . . 21
6. Stream Authentication . . . . . . . . . . . . . . . . . . . 24 6. Stream Authentication . . . . . . . . . . . . . . . . . . . 24
6.1 SASL Authentication . . . . . . . . . . . . . . . . . . . . 24 6.1 SASL Authentication . . . . . . . . . . . . . . . . . . . . 24
6.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.1.2 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.1.2 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.1.3 SASL Definition . . . . . . . . . . . . . . . . . . . . . . 26 6.1.3 SASL Definition . . . . . . . . . . . . . . . . . . . . . . 26
6.1.4 Client-to-Server Example . . . . . . . . . . . . . . . . . . 27 6.1.4 Client-to-Server Example . . . . . . . . . . . . . . . . . . 27
6.1.5 Server-to-Server Example . . . . . . . . . . . . . . . . . . 29 6.1.5 Server-to-Server Example . . . . . . . . . . . . . . . . . . 29
6.2 Dialback Authentication . . . . . . . . . . . . . . . . . . 32 6.2 Dialback Authentication . . . . . . . . . . . . . . . . . . 32
6.2.1 Dialback Protocol . . . . . . . . . . . . . . . . . . . . . 34 6.2.1 Dialback Protocol . . . . . . . . . . . . . . . . . . . . . 34
skipping to change at page 3, line 25 skipping to change at page 3, line 24
7.5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 43 7.5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.5.2 Types of IQ . . . . . . . . . . . . . . . . . . . . . . . . 43 7.5.2 Types of IQ . . . . . . . . . . . . . . . . . . . . . . . . 43
7.5.3 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 44 7.5.3 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 44
7.6 Extended Namespaces . . . . . . . . . . . . . . . . . . . . 44 7.6 Extended Namespaces . . . . . . . . . . . . . . . . . . . . 44
7.7 Stanza Errors . . . . . . . . . . . . . . . . . . . . . . . 45 7.7 Stanza Errors . . . . . . . . . . . . . . . . . . . . . . . 45
7.7.1 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 7.7.1 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
7.7.2 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 7.7.2 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
7.7.3 Conditions . . . . . . . . . . . . . . . . . . . . . . . . . 46 7.7.3 Conditions . . . . . . . . . . . . . . . . . . . . . . . . . 46
7.7.4 Extensibility . . . . . . . . . . . . . . . . . . . . . . . 47 7.7.4 Extensibility . . . . . . . . . . . . . . . . . . . . . . . 47
8. XML Usage within XMPP . . . . . . . . . . . . . . . . . . . 48 8. XML Usage within XMPP . . . . . . . . . . . . . . . . . . . 48
8.1 Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . 48 8.1 Restrictions . . . . . . . . . . . . . . . . . . . . . . . . 48
8.2 Validation . . . . . . . . . . . . . . . . . . . . . . . . . 48 8.2 Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . 48
8.3 Character Encodings . . . . . . . . . . . . . . . . . . . . 48 8.3 Validation . . . . . . . . . . . . . . . . . . . . . . . . . 48
8.4 Inclusion of Text Declaration . . . . . . . . . . . . . . . 48 8.4 Character Encodings . . . . . . . . . . . . . . . . . . . . 49
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 49 8.5 Inclusion of Text Declaration . . . . . . . . . . . . . . . 49
10. Internationalization Considerations . . . . . . . . . . . . 50 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 50
11. Security Considerations . . . . . . . . . . . . . . . . . . 51 9.1 XML Namespace Name for Stream Errors . . . . . . . . . . . . 50
11.1 High Security . . . . . . . . . . . . . . . . . . . . . . . 51 9.2 XML Namespace Name for Stanza Errors . . . . . . . . . . . . 50
11.2 Client-to-Server Communications . . . . . . . . . . . . . . 51 9.3 Existing Registrations . . . . . . . . . . . . . . . . . . . 50
11.3 Server-to-Server Communications . . . . . . . . . . . . . . 51 10. Internationalization Considerations . . . . . . . . . . . . 51
11.4 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . 52 11. Security Considerations . . . . . . . . . . . . . . . . . . 52
11.5 Mandatory to Implement Technologies . . . . . . . . . . . . 52 11.1 High Security . . . . . . . . . . . . . . . . . . . . . . . 52
References . . . . . . . . . . . . . . . . . . . . . . . . . 53 11.2 Client-to-Server Communications . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 55 11.3 Server-to-Server Communications . . . . . . . . . . . . . . 52
A. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . 56 11.4 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . 53
A.1 Streams namespace . . . . . . . . . . . . . . . . . . . . . 56 11.5 Mandatory to Implement Technologies . . . . . . . . . . . . 53
A.2 TLS namespace . . . . . . . . . . . . . . . . . . . . . . . 57 References . . . . . . . . . . . . . . . . . . . . . . . . . 54
A.3 SASL namespace . . . . . . . . . . . . . . . . . . . . . . . 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 56
A.4 Dialback namespace . . . . . . . . . . . . . . . . . . . . . 58 A. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . 57
A.5 Client namespace . . . . . . . . . . . . . . . . . . . . . . 59 A.1 Streams namespace . . . . . . . . . . . . . . . . . . . . . 57
A.6 Server namespace . . . . . . . . . . . . . . . . . . . . . . 62 A.2 TLS namespace . . . . . . . . . . . . . . . . . . . . . . . 58
A.7 Stream error namespace . . . . . . . . . . . . . . . . . . . 65 A.3 SASL namespace . . . . . . . . . . . . . . . . . . . . . . . 58
A.8 Stanza error namespace . . . . . . . . . . . . . . . . . . . 66 A.4 Dialback namespace . . . . . . . . . . . . . . . . . . . . . 59
B. Provisional Namespace Names . . . . . . . . . . . . . . . . 68 A.5 Client namespace . . . . . . . . . . . . . . . . . . . . . . 60
C. Revision History . . . . . . . . . . . . . . . . . . . . . . 69 A.6 Server namespace . . . . . . . . . . . . . . . . . . . . . . 63
C.1 Changes from draft-ietf-xmpp-core-05 . . . . . . . . . . . . 69 A.7 Stream error namespace . . . . . . . . . . . . . . . . . . . 66
C.2 Changes from draft-ietf-xmpp-core-04 . . . . . . . . . . . . 69 A.8 Stanza error namespace . . . . . . . . . . . . . . . . . . . 67
C.3 Changes from draft-ietf-xmpp-core-03 . . . . . . . . . . . . 69 B. Revision History . . . . . . . . . . . . . . . . . . . . . . 69
C.4 Changes from draft-ietf-xmpp-core-02 . . . . . . . . . . . . 69 B.1 Changes from draft-ietf-xmpp-core-06 . . . . . . . . . . . . 69
C.5 Changes from draft-ietf-xmpp-core-01 . . . . . . . . . . . . 70 B.2 Changes from draft-ietf-xmpp-core-05 . . . . . . . . . . . . 69
C.6 Changes from draft-ietf-xmpp-core-00 . . . . . . . . . . . . 70 B.3 Changes from draft-ietf-xmpp-core-04 . . . . . . . . . . . . 69
C.7 Changes from draft-miller-xmpp-core-02 . . . . . . . . . . . 70 B.4 Changes from draft-ietf-xmpp-core-03 . . . . . . . . . . . . 70
B.5 Changes from draft-ietf-xmpp-core-02 . . . . . . . . . . . . 70
B.6 Changes from draft-ietf-xmpp-core-01 . . . . . . . . . . . . 70
B.7 Changes from draft-ietf-xmpp-core-00 . . . . . . . . . . . . 70
B.8 Changes from draft-miller-xmpp-core-02 . . . . . . . . . . . 71
Full Copyright Statement . . . . . . . . . . . . . . . . . . 72 Full Copyright Statement . . . . . . . . . . . . . . . . . . 72
1. Introduction 1. Introduction
1.1 Overview 1.1 Overview
The Extensible Messaging and Presence Protocol (XMPP) is an open XML The Extensible Messaging and Presence Protocol (XMPP) is an open XML
[1] protocol for near-real-time messaging, presence, and request- [1] protocol for near-real-time messaging, presence, and request-
response services. The protocol was developed originally within the response services. The basic syntax and semantics were developed
Jabber community starting in 1998, and has continued to evolve under originally within the Jabber open-source community, mainly in 1999.
the auspices of the Jabber Software Foundation [2] (since June 2001) In 2002, the XMPP WG was chartered with developing an adaptation of
and the XMPP WG (since November 2002). The current document defines the Jabber protocol that would be suitable as an IETF instant
the core features of XMPP; XMPP IM [3] defines the extensions messaging and presence technology. As a result of work by the XMPP
necessary to provide the instant messaging (IM) and presence WG, the current document defines the core features of XMPP; XMPP IM
functionality defined in RFC 2779 [4]. [2] defines the extensions required to provide the instant messaging
(IM) and presence functionality defined in RFC 2779 [3].
1.2 Terminology 1.2 Terminology
The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [5]. 2119 [4].
1.3 Discussion Venue 1.3 Discussion Venue
The authors welcome discussion and comments related to the topics The authors welcome discussion and comments related to the topics
presented in this document. The preferred forum is the presented in this document. The preferred forum is the
<xmppwg@jabber.org> mailing list, for which archives and subscription <xmppwg@jabber.org> mailing list, for which archives and subscription
information are available at <http://www.jabber.org/cgi-bin/mailman/ information are available at <http://www.jabber.org/cgi-bin/mailman/
listinfo/xmppwg/>. listinfo/xmppwg/>.
1.4 Intellectual Property Notice 1.4 Intellectual Property Notice
skipping to change at page 6, line 12 skipping to change at page 6, line 12
to the IETF for use of the Jabber trademark in association with this to the IETF for use of the Jabber trademark in association with this
specification and its successors, if any. specification and its successors, if any.
2. Generalized Architecture 2. Generalized Architecture
2.1 Overview 2.1 Overview
Although XMPP is not wedded to any specific network architecture, to Although XMPP is not wedded to any specific network architecture, to
this point it has usually been implemented via a typical client- this point it has usually been implemented via a typical client-
server architecture, wherein a client utilizing XMPP accesses a server architecture, wherein a client utilizing XMPP accesses a
server over a TCP [6] socket. server over a TCP [5] socket.
The following diagram provides a high-level overview of this The following diagram provides a high-level overview of this
architecture (where "-" represents communications that use XMPP and architecture (where "-" represents communications that use XMPP and
"=" represents communications that use any other protocol). "=" represents communications that use any other protocol).
C1 - S1 - S2 - C3 C1 - S1 - S2 - C3
/ \ / \
C2 - G1 = FN1 = FC1 C2 - G1 = FN1 = FC1
The symbols are as follows: The symbols are as follows:
skipping to change at page 7, line 17 skipping to change at page 7, line 17
Most clients connect directly to a server over a TCP socket and use Most clients connect directly to a server over a TCP socket and use
XMPP to take full advantage of the functionality provided by a server XMPP to take full advantage of the functionality provided by a server
and any associated services, although it must be noted that there is and any associated services, although it must be noted that there is
no necessary coupling of an XML stream to a TCP socket (e.g., a no necessary coupling of an XML stream to a TCP socket (e.g., a
client COULD connect via HTTP polling or some other mechanism). client COULD connect via HTTP polling or some other mechanism).
Multiple resources (e.g., devices or locations) MAY connect Multiple resources (e.g., devices or locations) MAY connect
simultaneously to a server on behalf of each authorized client, with simultaneously to a server on behalf of each authorized client, with
each resource connecting over a discrete TCP socket and each resource connecting over a discrete TCP socket and
differentiated by the resource identifier of a JID (Section 3) (e.g., differentiated by the resource identifier of a JID (Section 3) (e.g.,
user@domain/home vs. user@domain/work). The port registered with user@domain/home vs. user@domain/work). The port registered with
the IANA [7] for connections between a Jabber client and a Jabber the IANA [6] for connections between a Jabber client and a Jabber
server is 5222. For further details about client-to-server server is 5222. For further details about client-to-server
communications expressly for the purpose of instant messaging and communications expressly for the purpose of instant messaging and
presence, refer to XMPP IM [3]. presence, refer to XMPP IM [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 SIMPLE, Internet Relay Chat (IRC), XMPP. Examples are gateways to SIMPLE, Internet Relay Chat (IRC),
Short Message Service (SMS), SMTP, and foreign instant messaging Short Message Service (SMS), SMTP, and foreign instant messaging
networks such as Yahoo!, MSN, ICQ, and AIM. Communications between networks such as Yahoo!, MSN, ICQ, and AIM. Communications between
gateways and servers, and between gateways and the foreign messaging gateways and servers, and between gateways and the foreign messaging
skipping to change at page 8, line 12 skipping to change at page 8, line 12
connection between any two servers: server dialback (Section 6.2) and connection between any two servers: server dialback (Section 6.2) and
SASL authentication (Section 6.1). SASL authentication (Section 6.1).
3. Addressing Scheme 3. Addressing Scheme
3.1 Overview 3.1 Overview
An entity is anything that can be considered a network endpoint An entity is anything that can be considered a network endpoint
(i.e., an ID on the network) and that can communicate using XMPP. (i.e., an ID on the network) and that can communicate using XMPP.
All such entities are uniquely addressable in a form that is All such entities are uniquely addressable in a form that is
consistent with RFC 2396 [8]. In particular, a valid Jabber consistent with RFC 2396 [7]. In particular, a valid Jabber
Identifier (JID) contains a set of ordered elements formed of a Identifier (JID) contains a set of ordered elements formed of a
domain identifier, node identifier, and resource identifier in the domain identifier, node identifier, and resource identifier in the
following format: [node@]domain[/resource]. following format: [node@]domain[/resource].
All JIDs are based on the foregoing structure. The most common use All JIDs are based on the foregoing structure. The most common use
of this structure is to identify an IM user, the server to which the of this structure is to identify an IM user, the server to which the
user connects, and the user's active session or connection (e.g., a user connects, and the user's active session or connection (e.g., a
specific client) in the form of user@domain/resource. However, node specific client) in the form of user@domain/resource. However, node
types other than clients are possible; for example, a specific chat types other than clients are possible; for example, a specific chat
room offered by a multi-user chat service could be addressed as room offered by a multi-user chat service could be addressed as
skipping to change at page 8, line 44 skipping to change at page 8, line 44
It usually represents the network gateway or "primary" server to It usually represents the network gateway or "primary" server to
which other entities connect for XML routing and data management which other entities connect for XML routing and data management
capabilities. However, the entity referenced by a domain identifier capabilities. However, the entity referenced by a domain identifier
is not always a server, and may be a service that is addressed as a is not always a server, and may be a service that is addressed as a
subdomain of a server and that provides functionality above and subdomain of a server and that provides functionality above and
beyond the capabilities of a server (a multi-user chat service, a beyond the capabilities of a server (a multi-user chat service, a
user directory, a gateway to a foreign messaging system, etc.). user directory, a gateway to a foreign messaging system, etc.).
The domain identifier for every server or service that will The domain identifier for every server or service that will
communicate over a network SHOULD resolve to a Fully Qualified Domain communicate over a network SHOULD resolve to a Fully Qualified Domain
Name. A domain identifier MUST conform to RFC 952 [9] and RFC 1123 Name. A domain identifier MUST conform to RFC 952 [8] and RFC 1123
[10]. A domain identifier MUST be no more than 1023 bytes in length [9]. A domain identifier MUST be no more than 1023 bytes in length
and MUST conform to the nameprep [11] profile of stringprep [12]. and MUST conform to the nameprep [10] profile of stringprep [11].
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 (i.e., a client), although it can also the server or gateway (i.e., a client), although it can also
represent other kinds of entities (e.g., a multi-user chat room represent other kinds of entities (e.g., a multi-user chat room
associated with a multi-user chat service). The entity represented associated with a multi-user chat service). The entity represented
by a node identifier is addressed within the context of a specific by a node identifier is addressed within the context of a specific
domain; within IM applications of XMPP this address is called a "bare domain; within IM applications of XMPP this address is called a "bare
JID" and is of the form <user@domain>. JID" and is of the form <user@domain>.
A node identifier MUST be no more than 1023 bytes in length and MUST A node identifier MUST be no more than 1023 bytes in length and MUST
conform to the nodeprep [13] profile of stringprep [12]. conform to the nodeprep [12] profile of stringprep [11].
3.4 Resource Identifier 3.4 Resource Identifier
The resource identifer is an optional tertiary identifier. It The resource identifer is an optional tertiary identifier. It
usually represents a specific session, connection (e.g., a device or usually represents a specific session, connection (e.g., a device or
location), or object (e.g., a participant in a multi-user chat room) location), or object (e.g., a participant in a multi-user chat room)
belonging to the entity associated with a node identifier. An entity belonging to the entity associated with a node identifier. An entity
may maintain multiple resources simultaneously. may maintain multiple resources simultaneously.
A resource identifier MUST be no more than 1023 bytes in length and A resource identifier MUST be no more than 1023 bytes in length and
MUST conform to the resourceprep [14] profile of stringprep [12]. MUST conform to the resourceprep [13] profile of stringprep [11].
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 XML stanzas: between presence-aware entities: XML streams and XML stanzas:
Definition of XML stream: An XML stream is a container for the Definition of XML stream: An XML stream is a container for the
exchange of XML elements between any two entities over a network. exchange of XML elements between any two entities over a network.
An XML stream is negotiated from an initiating entity (usually a An XML stream is negotiated from an initiating entity (usually a
client or server) to a receiving entity (usually a server), client or server) to a receiving entity (usually a server),
normally over a TCP socket. An XML stream corresponds to the normally over a TCP socket. An XML stream corresponds to the
initiating entity's session with the receiving entity. The start initiating entity's "session" with the receiving entity. The
of the XML stream is denoted unambiguously by an opening XML start of the XML stream is denoted unambiguously by an opening XML
<stream> tag with appropriate attributes and namespace <stream> tag with appropriate attributes and namespace
declarations. The end of the XML stream is denoted unambiguously declarations, and the end of the XML stream is denoted
be a closing XML </stream> tag. unambiguously be a closing XML </stream> tag. An XML stream is
unidirectional; in order to enable bidirectional information
exchange, one stream must be negotiated from initiating entity to
receiving entity and another stream must be negotiated from
receiving entity to initiating entity.
Definition of XML stanza: An XML stanza is a discrete semantic unit Definition of XML stanza: An XML stanza is a discrete semantic unit
of structured information that is sent from one entity to another of structured information that is sent from one entity to another
over an XML stream. An XML stanza exists at the direct child over an XML stream. An XML stanza exists at the direct child
level of the root <stream/> element and is said to be well- level of the root <stream/> element and is said to be well-
balanced if it matches production [43] content of the XML balanced if it matches production [43] content of the XML
specification [1]). The start of any XML stanza is denoted specification [1]). The start of any XML stanza is denoted
unambiguously by the element start tag at depth=1 (e.g., unambiguously by the element start tag at depth=1 (e.g.,
<presence>), and the end of any XML stanza is denoted <presence>), and the end of any XML stanza is denoted
unambiguously by the corresponding close tag at depth=1 (e.g., </ unambiguously by the corresponding close tag at depth=1 (e.g., </
skipping to change at page 11, line 29 skipping to change at page 11, line 34
|-------------------| |-------------------|
| <iq to=''> | | <iq to=''> |
| <query/> | | <query/> |
| </iq> | | </iq> |
|-------------------| |-------------------|
| ... | | ... |
|-------------------| |-------------------|
| </stream> | | </stream> |
|-------------------| |-------------------|
4.2 Restrictions 4.2 Stream Attributes
XML streams are used to transport a subset of XML. Specifically, XML
streams SHOULD NOT contain processing instructions, predefined
entities (as defined in Section 4.6 of the XML specification [1]),
comments, or DTDs. Any such XML data SHOULD be ignored by a
compliant implementation.
4.3 Stream Attributes
The attributes of the stream element are as follows: The attributes of the stream element are as follows:
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
from the initiating entity to the receiving entity, and MUST be from the initiating entity to the receiving entity, and MUST be
set to the XMPP address of the receiving entity. There SHOULD be set to the XMPP address of the receiving entity. There SHOULD be
no 'to' attribute set in the XML stream by which the receiving no 'to' attribute set in the XML stream by which the receiving
entity replies to the initiating entity; however, if a 'to' entity replies to the initiating entity; however, if a 'to'
attribute is included, it SHOULD be ignored by the initiating attribute is included, it SHOULD be ignored by the initiating
entity. entity.
skipping to change at page 12, line 36 skipping to change at page 12, line 32
We can summarize these values as follows: We can summarize these values as follows:
| 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.3 Namespace Declarations
The stream element MAY contain namespace declarations as defined in The stream element MAY contain namespace declarations as defined in
the XML namespaces specification [15]. the XML namespaces specification [14].
A default namespace declaration ('xmlns') is REQUIRED and is used in A default namespace declaration ('xmlns') is REQUIRED and is used in
both XML streams in order to scope the allowable first-level children both XML streams in order to scope the allowable first-level children
of the root stream element for both streams. This namespace of the root stream element for both streams. This namespace
declaration MUST be the same for the initiating stream and the declaration MUST be the same for the initiating stream and the
responding stream so that both streams are scoped consistently. The responding stream so that both streams are scoped consistently. The
default namespace declaration applies to the stream and all stanzas default namespace declaration applies to the stream and all stanzas
sent within a stream. sent within a stream.
A stream namespace declaration (e.g., 'xmlns:stream') is REQUIRED in A stream namespace declaration (e.g., 'xmlns:stream') is REQUIRED in
skipping to change at page 13, line 34 skipping to change at page 13, line 30
but are used in different contexts (client-to-server communications but are used in different contexts (client-to-server communications
for jabber:client and server-to-server communications for for jabber:client and server-to-server communications for
jabber:server). The only difference between the two is that the 'to' jabber:server). The only difference between the two is that the 'to'
and 'from' attributes are OPTIONAL on stanzas sent within and 'from' attributes are OPTIONAL on stanzas sent within
jabber:client, whereas they are REQUIRED on stanzas sent within jabber:client, whereas they are REQUIRED on stanzas sent within
jabber:server. If a compliant implementation accepts a stream that jabber:server. If a compliant implementation accepts a stream that
is scoped by the 'jabber:client' or 'jabber:server' namespace, it is scoped by the 'jabber:client' or 'jabber:server' namespace, it
MUST support all three core stanza types (message, presence, and IQ) MUST support all three core stanza types (message, presence, and IQ)
as described herein and defined in the schema. as described herein and defined in the schema.
4.5 Stream Features 4.4 Stream Features
The root stream element MAY contain a features child element (e.g., The root stream element MAY contain a features child element (e.g.,
<stream:features/> if the stream namespace prefix is 'stream'). This <stream:features/> if the stream namespace prefix is 'stream'). This
is used to communicate generic stream-level capabilities including is used to communicate generic stream-level capabilities including
stream-level features that can be negotiated as the streams are set stream-level features that can be negotiated as the streams are set
up. If the initiating entity sends a "version='1.0'" flag in its up. If the initiating entity sends a "version='1.0'" flag in its
initiating stream element, the receiving entity MUST send a features initiating stream element, the receiving entity MUST send a features
child element to the initiating entity if there are any capabilities child element to the initiating entity if there are any capabilities
that need to be advertised or features that can be negotiated for the that need to be advertised or features that can be negotiated for the
stream. Currently this is used for SASL and TLS negotiation only, stream. Currently this is used for SASL and TLS negotiation only,
but it could be used for other negotiable features in the future but it could be used for other negotiable features in the future
(usage is defined under Stream Encryption (Section 5) and Stream (usage is defined under Stream Encryption (Section 5) and Stream
Authentication (Section 6) below). If an entity does not understand Authentication (Section 6) below). If an entity does not understand
or support some features, it SHOULD ignore them. or support some features, it SHOULD ignore them.
4.6 Stream Errors 4.5 Stream Errors
The root stream element MAY contain an error child element (e.g., The root stream element MAY contain an error child element (e.g.,
<stream:error/> if the stream namespace prefix is 'stream'). The <stream:error/> if the stream namespace prefix is 'stream'). The
error child MUST be sent by a Jabber entity (usually a server rather error child MUST be sent by a Jabber entity (usually a server rather
than a client) if it perceives that a stream-level error has than a client) if it perceives that a stream-level error has
occurred. occurred.
4.6.1 Rules 4.5.1 Rules
The following rules apply to stream-level errors: The following rules apply to stream-level errors:
o It is assumed that all stream-level errors are unrecoverable; o It is assumed that all stream-level errors are unrecoverable;
therefore, if an error occurs at the level of the stream, the therefore, if an error occurs at the level of the stream, the
entity that detects the error MUST send a stream error to the entity that detects the error MUST send a stream error to the
other entity and then send a closing </stream> tag. other entity and then send a closing </stream> tag.
o If the error occurs while the stream is being set up, the o If the error occurs while the stream is being set up, the
receiving entity MUST still send the opening and closing stream receiving entity MUST still send the opening and closing stream
tags and include the error element as a child of the stream tags and include the error element as a child of the stream
element. In this case, if the initiating entity provides an element. In this case, if the initiating entity provides an
unknown host in the 'to' attribute (or provides no 'to' attribute unknown host in the 'to' attribute (or provides no 'to' attribute
at all), the server SHOULD provide the server's authoritative at all), the server SHOULD provide the server's authoritative
hostname in the 'from' attribute of the stream header. hostname in the 'from' attribute of the stream header.
4.6.2 Syntax 4.5.2 Syntax
The syntax for stream errors is as follows: The syntax for stream errors is as follows:
<stream:error class='error-class'> <stream:error class='error-class'>
<stream-condition xmlns='urn:ietf:rfc:xmppcore-rfc-number:streams'> <stream-condition xmlns='urn:ietf:params:xml:ns:xmpp-streams'>
<descriptive-element-name/> <descriptive-element-name/>
</stream-condition> </stream-condition>
</stream:error> </stream:error>
The value of the 'class' attribute must be one of the following: The value of the 'class' attribute must be one of the following:
o address -- the condition relates to the JID or domain to which the o address -- the condition relates to the JID or domain to which the
stream was addressed stream was addressed
o format -- the condition relates to XML format or structure o format -- the condition relates to XML format or structure
skipping to change at page 15, line 4 skipping to change at page 14, line 43
o address -- the condition relates to the JID or domain to which the o address -- the condition relates to the JID or domain to which the
stream was addressed stream was addressed
o format -- the condition relates to XML format or structure o format -- the condition relates to XML format or structure
o redirect -- the condition relates to a host redirection o redirect -- the condition relates to a host redirection
o server -- the condition relates to the internal state of the o server -- the condition relates to the internal state of the
server server
The <stream-condition/> element MUST contain a child element that The <stream-condition/> element MUST contain a child element that
specifies a particular stream-level error condition, as defined in specifies a particular stream-level error condition, as defined in
the next section. (Note: the XML namespace name the next section. (Note: the XML namespace name
'urn:ietf:rfc:xmppcore-rfc-number:streams' that scopes the <stream- 'urn:ietf:params:xml:ns:xmpp-streams' that scopes the <stream-
condition/> element adheres to the format defined in RFC 2648 [16].) condition/> element adheres to the format defined in The IETF XML
Registry [15].)
4.6.3 Conditions 4.5.3 Conditions
The following stream-level error conditions are defined: The following stream-level error conditions are defined:
o <host-gone/> -- the value of the 'to' attribute provided by the o <host-gone/> -- the value of the 'to' attribute provided by the
initiating entity in the stream header corresponds to a hostname initiating entity in the stream header corresponds to a hostname
that is no longer hosted by the server; the associated class is that is no longer hosted by the server; the associated class is
"address". "address".
o <host-unknown/> -- the value of the 'to' attribute provided by the o <host-unknown/> -- the value of the 'to' attribute provided by the
initiating entity in the stream header does not correspond to a initiating entity in the stream header does not correspond to a
skipping to change at page 16, line 11 skipping to change at page 16, line 5
o <unsupported-version/> -- the value of the 'version' attribute o <unsupported-version/> -- the value of the 'version' attribute
provided by the initiating entity in the stream header specifies a provided by the initiating entity in the stream header specifies a
version of XMPP that is not supported by the server; this element version of XMPP that is not supported by the server; this element
MAY contain CDATA specifying the XMPP version(s) supported by the MAY contain CDATA specifying the XMPP version(s) supported by the
server; the associated class is "format". server; the associated class is "format".
o <xml-not-well-formed/> -- the initiating entity has sent XML that o <xml-not-well-formed/> -- the initiating entity has sent XML that
is not well-formed as defined by the XML specification [1]; the is not well-formed as defined by the XML specification [1]; the
associated class is "format". associated class is "format".
4.6.4 Extensibility 4.5.4 Extensibility
If desired, an XMPP application MAY provide custom error information; If desired, an XMPP application MAY provide custom error information;
this MUST be contained in a properly-namespaced child of the <stream- this MUST be contained in a properly-namespaced child of the <stream-
condition/> element (i.e., the namespace name MUST NOT be one of the condition/> element (i.e., the namespace name MUST NOT be one of the
namespace names defined herein). namespace names defined herein).
4.7 Simple Streams Example 4.6 Simple Streams Example
The following is a stream-based session of a client on a server The following is a stream-based session of a client on a server
(where the "C" lines are sent from the client to the server, and the (where the "C" lines are sent from the client to the server, and the
"S" lines are sent from the server to the client): "S" lines are sent from the server to the client):
A basic session: A basic session:
C: <?xml version='1.0'?> C: <?xml version='1.0'?>
<stream:stream <stream:stream
to='domain' to='domain'
skipping to change at page 17, line 45 skipping to change at page 17, line 45
version='1.0'> version='1.0'>
S: <?xml version='1.0'?> S: <?xml version='1.0'?>
<stream:stream <stream:stream
from='server' from='server'
id='id_123456789' id='id_123456789'
xmlns='jabber:client' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams' xmlns:stream='http://etherx.jabber.org/streams'
version='1.0'> version='1.0'>
C: <message><body>Bad XML, no closing body tag!</message> C: <message><body>Bad XML, no closing body tag!</message>
S: <stream:error class='client'> S: <stream:error class='client'>
<stream-condition xmlns='urn:ietf:rfc:xmppcore-rfc-number:streams'> <stream-condition xmlns='urn:ietf:params:xml:ns:xmpp-streams'>
<xml-not-well-formed/> <xml-not-well-formed/>
</stream-condition> </stream-condition>
</stream:error> </stream:error>
S: </stream:stream> S: </stream:stream>
5. Stream Encryption 5. Stream Encryption
5.1 Overview 5.1 Overview
XMPP includes a method for securing the stream from tampering and XMPP includes a method for securing the stream from tampering and
eavesdropping. This channel encryption method makes use of the eavesdropping. This channel encryption method makes use of the
Transport Layer Security (TLS) [17] protocol, along with a "STARTTLS" Transport Layer Security (TLS) [16] protocol, along with a "STARTTLS"
extension that is modelled on similar extensions for the IMAP [18], extension that is modelled on similar extensions for the IMAP [17],
POP3 [19], and ACAP [20] protocols as described in RFC 2595 [21]. POP3 [18], and ACAP [19] protocols as described in RFC 2595 [20].
The namespace identifier for the STARTTLS extension is 'http:// The namespace identifier for the STARTTLS extension is 'http://
www.ietf.org/rfc/rfc2595.txt'. TLS may be used between any www.ietf.org/rfc/rfc2595.txt'. TLS SHOULD be used between any
initiating entity and any receiving entity (e.g., a stream from a initiating entity and any receiving entity (e.g., a stream from a
client to a server or from one server to another). client to a server or from one server to another).
The following rules MUST be observed: The following rules MUST be observed:
1. If the initiating entity is capable of using the STARTTLS 1. If the initiating entity is capable of using the STARTTLS
extension, it MUST include the "version='1.0'" flag in the extension, it MUST include the "version='1.0'" flag in the
initiating stream header. initiating stream header.
2. If the receiving entity is capable of using the STARTTLS 2. If the receiving entity is capable of using the STARTTLS
extension, it MUST send the <starttls/> element in the defined extension, it MUST send the <starttls/> element in the defined
namespace along with the list of features that it sends in namespace along with the list of features that it sends in
response to the opening stream tag received from the initiating response to the opening stream tag received from the initiating
entity. entity.
3. If the initiating entity chooses to use TLS for stream 3. If the initiating entity chooses to use TLS for stream
encryption, TLS negotiation MUST be completed before proceeding encryption, TLS negotiation MUST be completed before proceeding
to authenticate the stream using SASL. to authenticate the stream using SASL.
4. If the TLS negotiation is successful, TLS takes effect 4. The initiating entity MUST validate the certificate presented by
immediately following the closing ">" character of the <starttls/ the receiving entity:
> element for the client and immediately following the closing
">" character of the <proceed> element for the server. A new
stream MUST then be initiated by the initiating entity.
5. If the TLS negotiation is successful, the receiving entity MUST 1. If the initiating entity has been configured with a set of
trusted roots, either a well-known public set or a manually
configured Certificate Authority (e.g., an organization's
own Certificate Authority), normal certificate validation
processing is appropriate.
2. If the initiating entity has been configured with the
receiving entity's public key or certificate, a simple
comparison is appropriate.
If the above methods fail, the certificate MAY be presented to a
user for approval; the user SHOULD be given the option to store
the certificate and not ask again for at least some reasonable
period of time.
5. If the TLS negotiation is successful, TLS takes effect
immediately following the closing ">" character of the
<starttls/> element for the client and immediately following the
closing ">" character of the <proceed> element for the server.
A new stream MUST then be initiated by the initiating entity.
6. If the TLS negotiation is successful, the receiving entity MUST
discard any knowledge obtained from the initiating entity before discard any knowledge obtained from the initiating entity before
TLS takes effect. TLS takes effect.
6. If the TLS negotiation is successful, the initiating entity MUST 7. If the TLS negotiation is successful, the initiating entity MUST
discard any knowledge obtained from the receiving entity before discard any knowledge obtained from the receiving entity before
TLS takes effect. TLS takes effect.
7. If the TLS negotiation is successful, the receiving entity MUST 8. If the TLS negotiation is successful, the receiving entity MUST
NOT offer the STARTTLS extension to the initiating entity along NOT offer the STARTTLS extension to the initiating entity along
with the other stream features that are offered when the stream with the other stream features that are offered when the stream
is restarted. is restarted.
8. Whether the TLS negotiation results in success or failure, the 9. Whether the TLS negotiation results in success or failure, the
initiating entity SHOULD continue with SASL negotiation. initiating entity SHOULD continue with SASL negotiation.
9. If TLS is used for stream encryption, SASL MUST NOT be used for 10. If TLS is used for stream encryption, SASL MUST NOT be used for
anything but stream authentication (i.e., a security layer MUST anything but stream authentication (i.e., a security layer MUST
NOT be negotiated using SASL). Conversely, if a security layer NOT be negotiated using SASL). Conversely, if a security layer
is to be negotiated via SASL, TLS MUST NOT be used. is to be negotiated via SASL, TLS MUST NOT be used.
5.2 Narrative 5.2 Narrative
When an initiating entity secures a stream with a receiving entity, When an initiating entity secures a stream with a receiving entity,
the steps involved are as follows: the steps involved are as follows:
1. Then initiating entity opens a TCP connection and initiates the 1. Then initiating entity opens a TCP connection and initiates the
skipping to change at page 19, line 38 skipping to change at page 20, line 10
4. Then initiating entity issues the STARTTLS command to instruct 4. Then initiating entity issues the STARTTLS command to instruct
the receiving entity that it wishes to begin a TLS negotiation to the receiving entity that it wishes to begin a TLS negotiation to
secure the stream. secure the stream.
5. The receiving entity MUST reply with either an empty <proceed/> 5. The receiving entity MUST reply with either an empty <proceed/>
element or an empty <failure/> element, but keep the underlying element or an empty <failure/> element, but keep the underlying
TCP connection open. TCP connection open.
6. Then initiating entity begins a TLS negotiation in accordance 6. Then initiating entity begins a TLS negotiation in accordance
with RFC 2246 [17]. Upon completion of the negotiation, then with RFC 2246 [16]. Upon completion of the negotiation, then
initiating entity initiates a new stream by sending a new opening initiating entity initiates a new stream by sending a new opening
XML stream header to the receiving entity. XML stream header to the receiving entity.
7. The receiving entity responds by sending an XML stream header to 7. The receiving entity responds by sending an XML stream header to
then initiating entity along with the remaining available then initiating entity along with the remaining available
features (but NOT including the STARTTLS element). features (but NOT including the STARTTLS element).
5.3 Client-to-Server Example 5.3 Client-to-Server Example
The following example shows the data flow for a client securing a The following example shows the data flow for a client securing a
skipping to change at page 24, line 14 skipping to change at page 24, line 14
6. Stream Authentication 6. Stream Authentication
XMPP includes two methods for enforcing authentication at the level XMPP includes two methods for enforcing authentication at the level
of XML streams. When one entity is already known to another (i.e., of XML streams. When one entity is already known to another (i.e.,
there is an existing trust relationship between the entities such as there is an existing trust relationship between the entities such as
that established when a user registers with a server or an that established when a user registers with a server or an
administrator configures a server to trust another server), the administrator configures a server to trust another server), the
preferred method for authenticating streams between the two entities preferred method for authenticating streams between the two entities
uses an XMPP adaptation of the Simple Authentication and Security uses an XMPP adaptation of the Simple Authentication and Security
Layer (SASL) [22]. When there is no existing trust relationship Layer (SASL) [21]. When there is no existing trust relationship
between two servers, some level of trust MAY be established based on between two servers, some level of trust MAY be established based on
existing trust in DNS; the authentication method used in this case is existing trust in DNS; the authentication method used in this case is
the server dialback protocol that is native to XMPP (no such ad-hoc the server dialback protocol that is native to XMPP (no such ad-hoc
method is defined between a client and a server). If SASL is used method is defined between a client and a server). If SASL is used
for server-to-server authentication, the servers MUST NOT use for server-to-server authentication, the servers MUST NOT use
dialback. Both SASL authentication and dialback are described in dialback. Both SASL authentication and dialback are described in
this section. this section.
Stream authentication is REQUIRED for all direct communications Stream authentication is REQUIRED for all direct communications
between two entities; if an entity sends a stanza to an between two entities; if an entity sends a stanza to an
skipping to change at page 24, line 36 skipping to change at page 24, line 36
stanza and MUST NOT process it. stanza and MUST NOT process it.
6.1 SASL Authentication 6.1 SASL Authentication
6.1.1 Overview 6.1.1 Overview
The Simple Authentication and Security Layer (SASL) provides a The Simple Authentication and Security Layer (SASL) provides a
generalized method for adding authentication support to connection- generalized method for adding authentication support to connection-
based protocols. XMPP uses a generic XML namespace profile for SASL based protocols. XMPP uses a generic XML namespace profile for SASL
that conforms to section 4 ("Profiling Requirements") of RFC 2222 that conforms to section 4 ("Profiling Requirements") of RFC 2222
[22] (the namespace identifier for this protocol is 'http:// [21] (the namespace identifier for this protocol is 'http://
www.iana.org/assignments/sasl-mechanisms'). www.iana.org/assignments/sasl-mechanisms').
The following rules MUST be observed: The following rules MUST be observed:
1. If TLS is used for stream encryption, SASL MUST NOT be used for 1. If TLS is used for stream encryption, SASL MUST NOT be used for
anything but stream authentication (i.e., a security layer MUST anything but stream authentication (i.e., a security layer MUST
NOT be negotiated using SASL). Conversely, if a security layer NOT be negotiated using SASL). Conversely, if a security layer
is to be negotiated via SASL, TLS MUST NOT be used. is to be negotiated via SASL, TLS MUST NOT be used.
2. If the initiating entity is capable of authenticating via SASL, 2. If the initiating entity is capable of authenticating via SASL,
skipping to change at page 25, line 36 skipping to change at page 25, line 36
entity sends a list of available SASL authentication mechanisms, entity sends a list of available SASL authentication mechanisms,
each of which is a <mechanism/> element included as a child 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 child
of the first-level <features/> element. If channel encryption of the first-level <features/> element. If channel encryption
must be established before a particular authentication mechanism must be established before a particular authentication mechanism
may be used, the receiving entity MUST NOT provide that mechanism may be used, the receiving entity MUST NOT provide that mechanism
in the list of available SASL authentication methods. If the in the list of available SASL authentication methods. If the
initiating entity presents a valid initiating entity certificate initiating entity presents a valid initiating entity certificate
during TLS negotiation, the receiving entity MAY offer the SASL during TLS negotiation, the receiving entity MAY offer the SASL
EXTERNAL mechanism to the initiating entity during stream EXTERNAL mechanism to the initiating entity during stream
authentication (see RFC 2222 [22]). authentication (see RFC 2222 [21]).
3. The initiating entity selects a mechanism by sending an <auth/> 3. The initiating entity selects a mechanism by sending an <auth/>
element to the receiving entity; this element MAY optionally element to the receiving entity; this element MAY optionally
contain character data (in SASL terminology the "initial contain character data (in SASL terminology the "initial
response") if the mechanism supports or requires it. If the response") if the mechanism supports or requires it. If the
initiating entity selects the EXTERNAL mechanism for initiating entity selects the EXTERNAL mechanism for
authentication, the authentication credentials shall be taken authentication, the authentication credentials shall be taken
from the certificate presented during TLS negotiation. from the certificate presented during TLS negotiation.
4. If necessary, the receiving entity challenges the initiating 4. If necessary, the receiving entity challenges the initiating
skipping to change at page 26, line 33 skipping to change at page 26, line 33
3. The receiving entity reports success of the handshake by sending 3. The receiving entity reports success of the handshake by sending
a <success/> element to the initiating entity; this element MAY a <success/> element to the initiating entity; this element MAY
optionally contain character data (in SASL terminology optionally contain character data (in SASL terminology
"additional data with success"). "additional data with success").
Any character data contained within these elements MUST be encoded Any character data contained within these elements MUST be encoded
using base64. using base64.
6.1.3 SASL Definition 6.1.3 SASL Definition
Section 4 of the SASL specification [22] requires that the following Section 4 of the SASL specification [21] requires that the following
information be supplied by a protocol definition: information be supplied by a protocol definition:
service name: "xmpp" service name: "xmpp"
initiation sequence: After the initiating entity provides an opening initiation sequence: After the initiating entity provides an opening
XML stream header and the receiving entity replies in kind, the XML stream header and the receiving entity replies in kind, the
receiving entity provides a list of acceptable authentication receiving entity provides a list of acceptable authentication
methods. The initiating entity chooses one method from the list methods. The initiating entity chooses one method from the list
and sends it to the receiving entity as the value of the and sends it to the receiving entity as the value of the
'mechanism' attribute possesed by an <auth/> element, optionally 'mechanism' attribute possesed by an <auth/> element, optionally
skipping to change at page 32, line 24 skipping to change at page 32, line 24
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 as is done via SASL and TLS, only for the streams between servers as is done via SASL and TLS, only for
helping to prevent the spoofing of a server and the sending of false helping to prevent the spoofing of a server and the sending of false
data from it. Domains requiring more robust security SHOULD use TLS data from it. Domains requiring more robust security SHOULD use TLS
or SASL as defined above. or SASL as defined above.
Server dialback is made possible by the existence of DNS, since one Server dialback is made possible by the existence of DNS, since one
server can verify that another server which is connecting to it is server can verify that another server which is connecting to it is
authorized to represent a given server on the Jabber network. All authorized to represent a given server on the Jabber network. All
DNS hostname resolutions MUST first resolve the hostname using an SRV DNS hostname resolutions MUST first resolve the hostname using an SRV
[24] record of _jabber._tcp.server. If the SRV lookup fails, the [23] record of _jabber._tcp.server. If the SRV lookup fails, the
fallback is a normal A lookup to determine the IP address, using the fallback is a normal A lookup to determine the IP address, using the
jabber-server port of 5269 assigned by the Internet Assigned Numbers jabber-server port of 5269 assigned by the Internet Assigned Numbers
Authority [7]. Authority [6].
Note: the method for generating and verifying the keys used in the Note: the method for generating and verifying 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 generated for the stream. Generating unique but verifiable keys ID generated for the stream. Generating unique but verifiable keys
is important to prevent common man-in-the-middle attacks and server is important to prevent common man-in-the-middle attacks and server
spoofing. spoofing.
In the description that follows we use the following terminology: In the description that follows we use the following terminology:
skipping to change at page 38, line 43 skipping to change at page 38, line 43
the following sections. the following sections.
7.2.5 xml:lang 7.2.5 xml:lang
Any message or presence stanza MAY possess an 'xml:lang' attribute Any message or presence stanza MAY possess an 'xml:lang' attribute
specifying the default language of any CDATA sections of the stanza specifying the default language of any CDATA sections of the stanza
or its child elements. An IQ stanza SHOULD NOT possess an 'xml:lang' or its child elements. An IQ stanza SHOULD NOT possess an 'xml:lang'
attribute, since it is merely a vessel for data in other namespaces attribute, since it is merely a vessel for data in other namespaces
and does not itself contain children that have CDATA. The value of and does not itself contain children that have CDATA. The value of
the 'xml:lang' attribute MUST be an NMTOKEN and MUST conform to the the 'xml:lang' attribute MUST be an NMTOKEN and MUST conform to the
format defined in RFC 3066 [23]. format defined in RFC 3066 [22].
7.3 Message Stanzas 7.3 Message Stanzas
Message stanzas in the 'jabber:client' or 'jabber:server' namespace Message stanzas in the 'jabber:client' or 'jabber:server' namespace
are used to "push" information to another entity. Common uses in the are used to "push" information to another entity. Common uses in the
context of instant messaging include single messages, messages sent context of instant messaging include single messages, messages sent
in the context of a chat conversation, messages sent in the context in the context of a chat conversation, messages sent in the context
of a multi-user chat room, headlines, and errors. These messages of a multi-user chat room, headlines, and errors. These messages
types are identified more fully below. types are identified more fully below.
skipping to change at page 39, line 22 skipping to change at page 39, line 22
o chat o chat
o error o error
o groupchat o groupchat
o headline o headline
For information about the meaning of these message types, refer to For information about the meaning of these message types, refer to
XMPP IM [3]. XMPP IM [2].
7.3.2 Children 7.3.2 Children
As described under extended namespaces (Section 7.6), a message As described under extended namespaces (Section 7.6), a message
stanza MAY contain any properly-namespaced child element as long as stanza MAY contain any properly-namespaced child element as long as
the namespace name is not "jabber:client", "jabber:server", or the namespace name is not "jabber:client", "jabber:server", or
"http://etherx.jabber.org/streams", and as long as the element name "http://etherx.jabber.org/streams", and as long as the element name
does not match that of one of the core data elements, stream does not match that of one of the core data elements, stream
elements, or defined children thereof. elements, or defined children thereof.
skipping to change at page 41, line 38 skipping to change at page 41, line 38
o unsubscribed -- The subscription request has been denied or a o unsubscribed -- The subscription request has been denied or a
previously-granted subscription has been cancelled. previously-granted subscription has been cancelled.
o probe -- A request for an entity's current presence. In general o probe -- A request for an entity's current presence. In general
SHOULD NOT be sent by a client. SHOULD NOT be sent by a client.
o error -- An error has occurred regarding processing or delivery of o error -- An error has occurred regarding processing or delivery of
a previously-sent presence stanza. a previously-sent presence stanza.
Information about the subscription model used within XMPP can be Information about the subscription model used within XMPP can be
found in XMPP IM [3]. found in XMPP IM [2].
7.4.2 Children 7.4.2 Children
As described under extended namespaces (Section 7.6), a presence As described under extended namespaces (Section 7.6), a presence
stanza MAY contain any properly-namespaced child element as long as stanza MAY contain any properly-namespaced child element as long as
the namespace name is not "jabber:client", "jabber:server", or the namespace name is not "jabber:client", "jabber:server", or
"http://etherx.jabber.org/streams", and as long as the element name "http://etherx.jabber.org/streams", and as long as the element name
does not match that of one of the core data elements, stream does not match that of one of the core data elements, stream
elements, or defined children thereof. elements, or defined children thereof.
skipping to change at page 42, line 29 skipping to change at page 42, line 29
o away o away
o chat o chat
o xa o xa
o dnd o dnd
For information about the meaning of these values, refer to XMPP IM For information about the meaning of these values, refer to XMPP IM
[3]. [2].
7.4.2.2 Status 7.4.2.2 Status
The optional <status/> element specifies a natural-language The optional <status/> element specifies a natural-language
description of availability status. It is normally used in description of availability status. It is normally used in
conjunction with the show element to provide a detailed description conjunction with the show element to provide a detailed description
of an availability state (e.g., "In a meeting"). The <status/> of an availability state (e.g., "In a meeting"). The <status/>
element MUST NOT possess any attributes, with the exception of the element MUST NOT possess any attributes, with the exception of the
'xml:lang' attribute. Multiple instances of the <status/> element 'xml:lang' attribute. Multiple instances of the <status/> element
MAY be included but only if each instance possesses an 'xml:lang' MAY be included but only if each instance possesses an 'xml:lang'
attribute with a distinct language value. attribute with a distinct language value.
7.4.2.3 Priority 7.4.2.3 Priority
The optional <priority/> element specifies the priority level of the The optional <priority/> element specifies the priority level of the
connected resource. The value may be any integer between -128 to connected resource. The value may be any integer between -128 to
127. Only one <priority/> element MAY be included in a presence 127. Only one <priority/> element MAY be included in a presence
stanza, and it MUST NOT possess any attributes. For information stanza, and it MUST NOT possess any attributes. For information
regarding the use of priority values in stanza routing within IM regarding the use of priority values in stanza routing within IM
applications, see XMPP IM [3]. applications, see XMPP IM [2].
7.5 IQ Stanzas 7.5 IQ Stanzas
7.5.1 Overview 7.5.1 Overview
Info/Query, or IQ, is a request-response mechanism, similar in some Info/Query, or IQ, is a request-response mechanism, similar in some
ways to HTTP [25]. IQ stanzas in the 'jabber:client' or ways to HTTP [24]. IQ stanzas in the 'jabber:client' or
'jabber:server' namespace enable an entity to make a request of, and 'jabber:server' namespace enable an entity to make a request of, and
receive a response from, another entity. The data content of the receive a response from, another entity. The data content of the
request and response is defined by the namespace declaration of a request and response is defined by the namespace declaration of a
direct child element of the IQ element, and the interaction is direct child element of the IQ element, and the interaction is
tracked by the requesting entity through use of the 'id' attribute, tracked by the requesting entity through use of the 'id' attribute,
which responding entities SHOULD return in any response. which responding entities SHOULD return in any response.
Most IQ interactions follow a common pattern of structured data Most IQ interactions follow a common pattern of structured data
exchange such as get/result or set/result (although an error may be exchange such as get/result or set/result (although an error may be
returned in response to a request if appropriate): returned in response to a request if appropriate):
skipping to change at page 45, line 17 skipping to change at page 45, line 17
ignored. If an entity receives a message stanza without a <body/> ignored. If an entity receives a message stanza without a <body/>
element but containing only a child element bound by a namespace it element but containing only a child element bound by a namespace it
does not understand, it MUST ignore the entire stanza. If an entity does not understand, it MUST ignore the entire stanza. If an entity
receives an IQ stanza in a namespace it does not understand, the receives an IQ stanza in a namespace it does not understand, the
entity SHOULD return an IQ stanza of type "error" with an error entity SHOULD return an IQ stanza of type "error" with an error
condition of <feature-not-implemented/>. condition of <feature-not-implemented/>.
7.7 Stanza Errors 7.7 Stanza Errors
As defined below, stanza-related errors are handled in a manner As defined below, stanza-related errors are handled in a manner
similar to stream errors (Section 4.6). similar to stream errors (Section 4.5).
7.7.1 Rules 7.7.1 Rules
The following rules apply to stanza-related errors: The following rules apply to stanza-related errors:
o A stanza of type "error" MUST contain an <error/> child element. o A stanza of type "error" MUST contain an <error/> child element.
o The receiving or processing entity that returns an error to the o The receiving or processing entity that returns an error to the
sending entity SHOULD include the original XML sent along with the sending entity SHOULD include the original XML sent along with the
<error/> element and its children so that the sender can inspect <error/> element and its children so that the sender can inspect
skipping to change at page 45, line 44 skipping to change at page 45, line 44
o An <error/> child MUST NOT be included if the stanza type is o An <error/> child MUST NOT be included if the stanza type is
something other than "error". something other than "error".
7.7.2 Syntax 7.7.2 Syntax
The syntax for stanza-related errors is as follows: The syntax for stanza-related errors is as follows:
<stanza-name to='sender' type='error'> <stanza-name to='sender' type='error'>
[include sender XML here] [include sender XML here]
<error class='error-class'> <error class='error-class'>
<stanza-condition xmlns='urn:ietf:rfc:xmppcore-rfc-number:stanzas'> <stanza-condition xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>
<descriptive-element-name/> <descriptive-element-name/>
</stanza-condition> </stanza-condition>
</error> </error>
</stanza-name> </stanza-name>
The stanza name is one of message, presence, or iq. The stanza name is one of message, presence, or iq.
The value of the 'class' attribute must be one of the following: The value of the 'class' attribute must be one of the following:
o access -- the condition relates to access rights, permissions, or o access -- the condition relates to access rights, permissions, or
authorization authorization
o address -- the condition relates to the JID or domain to which the o address -- the condition relates to the JID or domain to which the
stanza was addressed stanza was addressed
o app -- the condition is particular to an application and is o app -- the condition is particular to an application and is
specified in a namespace other than 'urn:ietf:rfc:xmppcore-rfc- specified in a namespace other than 'urn:ietf:params:xml:ns:xmpp-
number:stanzas' stanzas'
o format -- the condition relates to XML format or structure o format -- the condition relates to XML format or structure
o recipient -- the condition relates to the state or capabilities of o recipient -- the condition relates to the state or capabilities of
the recipient (which may be the server) the recipient (which may be the server)
o server -- the condition relates to the internal state of the o server -- the condition relates to the internal state of the
server server
The <stanza-condition/> element MUST contain a child element that The <stanza-condition/> element MUST contain a child element that
specifies a particular stanza-related error condition, as defined in specifies a particular stanza-related error condition, as defined in
the next section. (Note: the XML namespace name the next section. (Note: the XML namespace name
'urn:ietf:rfc:xmppcore-rfc-number:stanzas' that scopes the <stanza- 'urn:ietf:params:xml:ns:xmpp-stanzas' that scopes the <stanza-
condition/> element adheres to the format defined in RFC 2648 [16].) condition/> element adheres to the format defined in The IETF XML
Registry [15].)
7.7.3 Conditions 7.7.3 Conditions
The following stanza-related error conditions are defined: The following stanza-related error conditions are defined:
o <bad-request/> -- the sender has sent XML that is malformed or o <bad-request/> -- the sender has sent XML that is malformed or
cannot be processed (e.g., a client-generated stanza includes a cannot be processed (e.g., a client-generated stanza includes a
'from' address, or an IQ stanza includes an unrecognized value of 'from' address, or an IQ stanza includes an unrecognized value of
the 'type' attribute); the associated class is "format". the 'type' attribute); the associated class is "format".
skipping to change at page 48, line 7 skipping to change at page 48, line 7
7.7.4 Extensibility 7.7.4 Extensibility
If desired, an XMPP application MAY provide custom error information; If desired, an XMPP application MAY provide custom error information;
this MUST be contained in a properly-namespaced child of the <stanza- this MUST be contained in a properly-namespaced child of the <stanza-
condition/> element (i.e., the namespace name MUST NOT be one of condition/> element (i.e., the namespace name MUST NOT be one of
namespace names defined herein). namespace names defined herein).
8. XML Usage within XMPP 8. XML Usage within XMPP
8.1 Namespaces 8.1 Restrictions
XML Namespaces [15] are used within all XMPP-compliant XML to create XMPP is a simplified and specialized protocol for streaming XML
elements in order to exchange messages and presence information in
close to real time. Because XMPP does not require the parsing of
arbitrary and complete XML documents, there is no requirement that
XMPP must support the full XML specification [1]. In particular, the
following restrictions apply:
With regard to XML generation, an XMPP implementation MUST NOT inject
into an XML stream any of the following:
o comments (as defined in Section 2.5 of the XML specification [1])
o processing instructions (Section 2.6)
o internal or external DTD subsets (Section 2.8)
o internal or external entity references (Section 4.2) with the
exception of predefined entities (Section 4.6)
With regard to XML processing, if an XMPP implementation receives
such restricted XML data, it MUST ignore the data.
8.2 Namespaces
XML Namespaces [14] 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. data element within XMPP.
Additionally, XMPP is more strict about namespace prefixes than the Additionally, XMPP is more strict about namespace prefixes than the
XML namespace specification requires. XML namespace specification requires.
8.2 Validation 8.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 or another server; an implementation MAY choose to to a client or another server; an implementation MAY choose to
provide only validated data elements but is NOT REQUIRED to do so. provide only validated data elements but is NOT REQUIRED to do so.
Clients SHOULD NOT rely on the ability to send data which does not Clients SHOULD NOT rely on the ability to send data which does not
conform to the schemas, and SHOULD ignore any non-conformant elements conform to the schemas, and SHOULD ignore any non-conformant elements
or attributes on the incoming XML stream. Validation of XML streams or attributes on the incoming XML stream. Validation of XML streams
and stanzas is NOT REQUIRED or recommended, and schemas are included and stanzas is NOT REQUIRED or recommended, and schemas are included
herein for descriptive purposes only. herein for descriptive purposes only.
8.3 Character Encodings 8.4 Character Encodings
Software implementing XML streams MUST support the UTF-8 (RFC 2279 Software implementing XML streams MUST support the UTF-8 (RFC 2279
[26]) and UTF-16 (RFC 2781 [27]) transformations of Universal [25]) and UTF-16 (RFC 2781 [26]) transformations of Universal
Character Set (ISO/IEC 10646-1 [28]) characters. Software MUST NOT Character Set (ISO/IEC 10646-1 [27]) characters. Software MUST NOT
attempt to use any other encoding for transmitted data. The attempt to use any other encoding for transmitted data. The
encodings of the transmitted and received streams are independent. encodings of the transmitted and received streams are independent.
Software MAY select either UTF-8 or UTF-16 for the transmitted Software MAY select either UTF-8 or UTF-16 for the transmitted
stream, and SHOULD deduce the encoding of the received stream as stream, and SHOULD deduce the encoding of the received stream as
described in the XML specification [1]. For historical reasons, described in the XML specification [1]. For historical reasons,
existing implementations MAY support UTF-8 only. existing implementations MAY support UTF-8 only.
8.4 Inclusion of Text Declaration 8.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] regarding the circumstances the rules in the XML specification [1] regarding the circumstances
under which a text declaration is included. under which a text declaration is included.
9. IANA Considerations 9. IANA Considerations
The IANA registers "xmpp" as a GSSAPI [30] service name, as specified 9.1 XML Namespace Name for Stream Errors
A URN sub-namespace for XMPP stream error tags is defined as follows.
URI: urn:ietf:params:xml:ns:xmpp-streams
Specification: [RFCXXXX]
Description: This is the XML namespace name for XMPP stream errors as
defined by [RFCXXXX].
Registrant Contact: IETF, XMPP Working Group, <xmppwg@jabber.org>
9.2 XML Namespace Name for Stanza Errors
A URN sub-namespace for XMPP stanza error tags is defined as follows.
URI: urn:ietf:params:xml:ns:xmpp-stanzas
Specification: [RFCXXXX]
Description: This is the XML namespace name for XMPP stanza errors as
defined by [RFCXXXX].
Registrant Contact: IETF, XMPP Working Group, <xmppwg@jabber.org>
9.3 Existing Registrations
The IANA registers "xmpp" as a GSSAPI [29] service name, as specified
in Section 6.1.3. in Section 6.1.3.
Additionally, the IANA registers "jabber-client" and "jabber-server" Additionally, the IANA registers "jabber-client" and "jabber-server"
as keywords for TCP ports 5222 and 5269 respectively. as keywords for TCP ports 5222 and 5269 respectively.
10. Internationalization Considerations 10. Internationalization Considerations
Usage of the 'xml:lang' attribute is described above. If a client Usage of the 'xml:lang' attribute is described above. If a client
includes an 'xml:lang' attribute in a stanza, the server MUST NOT includes an 'xml:lang' attribute in a stanza, the server MUST NOT
modify or delete it. modify or delete it.
skipping to change at page 51, line 37 skipping to change at page 52, line 37
Section 6.1) provides a reliable mechanism for validating that a Section 6.1) provides a reliable mechanism for validating that a
client connecting to a server is who it claims to be. client connecting to a server is who it claims to be.
The IP address and method of access of clients MUST NOT be made The IP address and method of access of clients MUST NOT be made
available by a server, nor are any connections other than the available by a server, nor are any connections other than the
original server connection required. This helps protect the client's original server connection required. This helps protect the client's
server from direct attack or identification by third parties. server from direct attack or identification by third parties.
End-to-end encryption of message bodies and presence status End-to-end encryption of message bodies and presence status
information MAY be effected through use of the methods defined in information MAY be effected through use of the methods defined in
End-to-End Object Encryption in XMPP [29]. End-to-End Object Encryption in XMPP [28].
11.3 Server-to-Server Communications 11.3 Server-to-Server Communications
A compliant implementation MUST support both TLS and SASL for inter- A compliant implementation MUST support both TLS and SASL for inter-
domain communications. For historical reasons, a compliant domain communications. For historical reasons, a compliant
implementation SHOULD also support the lower-security Dialback implementation SHOULD also support the lower-security Dialback
Protocol (Section 6.2), which provides a mechanism for helping to Protocol (Section 6.2), which provides a mechanism for helping to
prevent the spoofing of domains. prevent the spoofing of domains.
Because service provisioning is a matter of policy, it is OPTIONAL Because service provisioning is a matter of policy, it is OPTIONAL
skipping to change at page 52, line 10 skipping to change at page 53, line 10
to-server communications MAY be disabled by the administrator of any to-server communications MAY be disabled by the administrator of any
given deployment. If a particular domain enables inter-domain given deployment. If a particular domain enables inter-domain
communications, it SHOULD enable high security. In the absence of communications, it SHOULD enable high security. In the absence of
high security, a domain MAY use server dialback for inter-domain high security, a domain MAY use server dialback for inter-domain
communications. communications.
11.4 Firewalls 11.4 Firewalls
Communications using XMPP normally occur over TCP sockets on port Communications using XMPP normally occur over TCP sockets on port
5222 (client-to-server) or port 5269 (server-to-server), as 5222 (client-to-server) or port 5269 (server-to-server), as
registered with the IANA [7]. Use of these well-known ports allows registered 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.
11.5 Mandatory to Implement Technologies 11.5 Mandatory to Implement Technologies
At a minimum, all implementations MUST support the following At a minimum, all implementations MUST support the following
mechanisms: mechanisms:
for authentication: the SASL DIGEST-MD5 mechanism for authentication: the SASL DIGEST-MD5 mechanism
skipping to change at page 53, line 11 skipping to change at page 54, line 11
for both: TLS (using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher for both: TLS (using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher
supporting client-side certificates) supporting client-side certificates)
References References
[1] World Wide Web Consortium, "Extensible Markup Language (XML) [1] World Wide Web Consortium, "Extensible Markup Language (XML)
1.0 (Second Edition)", W3C xml, October 2000, <http:// 1.0 (Second Edition)", W3C xml, October 2000, <http://
www.w3.org/TR/2000/REC-xml-20001006>. www.w3.org/TR/2000/REC-xml-20001006>.
[2] Jabber Software Foundation, "Jabber Software Foundation", [2] Saint-Andre, P. and J. Miller, "XMPP Instant Messaging (draft-
August 2001, <http://www.jabber.org/>. ietf-xmpp-im-07, work in progress)", April 2003.
[3] Saint-Andre, P. and J. Miller, "XMPP Instant Messaging (draft-
ietf-xmpp-im-06, work in progress)", March 2003.
[4] Day, M., Aggarwal, S., Mohr, G. and J. Vincent, "A Model for [3] Day, M., Aggarwal, S., Mohr, G. and J. Vincent, "A Model for
Presence and Instant Messaging", RFC 2779, February 2000, Presence and Instant Messaging", RFC 2779, February 2000,
<http://www.ietf.org/rfc/rfc2779.txt>. <http://www.ietf.org/rfc/rfc2779.txt>.
[5] 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.
[6] 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>.
[7] 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/>.
[8] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform [7] 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>.
[9] Harrenstien, K., Stahl, M. and E. Feinler, "DoD Internet host [8] Harrenstien, K., Stahl, M. and E. Feinler, "DoD Internet host
table specification", RFC 952, October 1985. table specification", RFC 952, October 1985.
[10] Braden, R., "Requirements for Internet Hosts - Application and [9] Braden, R., "Requirements for Internet Hosts - Application and
Support", STD 3, RFC 1123, October 1989. Support", STD 3, RFC 1123, October 1989.
[11] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile [10] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile
for Internationalized Domain Names (draft-ietf-idn-nameprep-11, for Internationalized Domain Names (draft-ietf-idn-nameprep-11,
work in progress)", June 2002. work in progress)", June 2002.
[12] Hoffman, P. and M. Blanchet, "Preparation of Internationalized [11] Hoffman, P. and M. Blanchet, "Preparation of Internationalized
Strings ("stringprep")", RFC 3454, December 2002. Strings ("stringprep")", RFC 3454, December 2002.
[13] Saint-Andre, P. and J. Hildebrand, "Nodeprep: A Stringprep [12] Saint-Andre, P. and J. Hildebrand, "Nodeprep: A Stringprep
Profile for Node Identifiers in XMPP (draft-ietf-xmpp-nodeprep- Profile for Node Identifiers in XMPP (draft-ietf-xmpp-nodeprep-
01, work in progress)", February 2003. 01, work in progress)", February 2003.
[14] Saint-Andre, P. and J. Hildebrand, "Resourceprep: A Stringprep [13] Saint-Andre, P. and J. Hildebrand, "Resourceprep: A Stringprep
Profile for Resource Identifiers in XMPP (draft-ietf-xmpp- Profile for Resource Identifiers in XMPP (draft-ietf-xmpp-
resourceprep-01, work in progress)", February 2003. resourceprep-01, work in progress)", February 2003.
[15] World Wide Web Consortium, "Namespaces in XML", W3C xml-names, [14] 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/>.
[16] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, [15] Mealling, M., "The IANA XML Registry", draft-mealling-iana-
August 1999. xmlns-registry-04 (work in progress), June 2002.
[17] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and [16] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and
P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January
1999. 1999.
[18] Crispin, M., "Internet Message Access Protocol - Version [17] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 2060, December 1996. 4rev1", RFC 2060, December 1996.
[19] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD [18] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD
53, RFC 1939, May 1996. 53, RFC 1939, May 1996.
[20] Newman, C. and J. Myers, "ACAP -- Application Configuration [19] Newman, C. and J. Myers, "ACAP -- Application Configuration
Access Protocol", RFC 2244, November 1997. Access Protocol", RFC 2244, November 1997.
[21] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, [20] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595,
June 1999. June 1999.
[22] Myers, J., "Simple Authentication and Security Layer (SASL)", [21] Myers, J., "Simple Authentication and Security Layer (SASL)",
RFC 2222, October 1997. RFC 2222, October 1997.
[23] Alvestrand, H., "Tags for the Identification of Languages", BCP [22] Alvestrand, H., "Tags for the Identification of Languages", BCP
47, RFC 3066, January 2001. 47, RFC 3066, January 2001.
[24] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the [23] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the
location of services (DNS SRV)", RFC 2052, October 1996. location of services (DNS SRV)", RFC 2052, October 1996.
[25] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., [24] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999. HTTP/1.1", RFC 2616, June 1999.
[26] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC [25] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998. 2279, January 1998.
[27] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", [26] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646",
RFC 2781, February 2000. RFC 2781, February 2000.
[28] International Organization for Standardization, "Information [27] International Organization for Standardization, "Information
Technology - Universal Multiple-octet coded Character Set (UCS) Technology - Universal Multiple-octet coded Character Set (UCS)
- Amendment 2: UCS Transformation Format 8 (UTF-8)", ISO - Amendment 2: UCS Transformation Format 8 (UTF-8)", ISO
Standard 10646-1 Addendum 2, October 1996. Standard 10646-1 Addendum 2, October 1996.
[29] Saint-Andre, P. and J. Hildebrand, "End-to-End Object [28] Saint-Andre, P. and J. Hildebrand, "End-to-End Object
Encryption in XMPP (draft-ietf-xmpp-e2e-00, work in progress)", Encryption in XMPP (draft-ietf-xmpp-e2e-00, work in progress)",
February 2003. February 2003.
[30] Linn, J., "Generic Security Service Application Program [29] 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
Peter Saint-Andre Peter Saint-Andre
Jabber Software Foundation Jabber Software Foundation
EMail: stpeter@jabber.org EMail: stpeter@jabber.org
URI: http://www.jabber.org/people/stpeter.php URI: http://www.jabber.org/people/stpeter.php
skipping to change at page 66, line 6 skipping to change at page 67, line 6
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
</xs:schema> </xs:schema>
A.7 Stream error namespace A.7 Stream error namespace
<?xml version='1.0' encoding='UTF-8'?> <?xml version='1.0' encoding='UTF-8'?>
<xs:schema <xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema' xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:ietf:rfc:xmppcore-rfc-number:streams' targetNamespace='urn:ietf:params:xml:ns:xmpp-streams'
xmlns='urn:ietf:rfc:xmppcore-rfc-number:streams' xmlns='urn:ietf:params:xml:ns:xmpp-streams'
elementFormDefault='qualified'> elementFormDefault='qualified'>
<xs:element name='stream-condition'> <xs:element name='stream-condition'>
<xs:complexType> <xs:complexType>
<xs:any <xs:any
namespace='##other' namespace='##other'
minOccurs='0' minOccurs='0'
maxOccurs='1'/> maxOccurs='1'/>
<xs:choice maxOccurs='1'> <xs:choice maxOccurs='1'>
<xs:element ref='host-gone'/> <xs:element ref='host-gone'/>
skipping to change at page 66, line 49 skipping to change at page 67, line 49
<xs:element name='xml-not-well-formed' type='xs:string'/> <xs:element name='xml-not-well-formed' type='xs:string'/>
</xs:schema> </xs:schema>
A.8 Stanza error namespace A.8 Stanza error namespace
<?xml version='1.0' encoding='UTF-8'?> <?xml version='1.0' encoding='UTF-8'?>
<xs:schema <xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema' xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:ietf:rfc:xmppcore-rfc-number:stanzas' targetNamespace='urn:ietf:params:xml:ns:xmpp-stanzas'
xmlns='urn:ietf:rfc:xmppcore-rfc-number:stanzas' xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'
elementFormDefault='qualified'> elementFormDefault='qualified'>
<xs:element name='stanza-condition'> <xs:element name='stanza-condition'>
<xs:complexType> <xs:complexType>
<xs:any <xs:any
namespace='##other' namespace='##other'
minOccurs='0' minOccurs='0'
maxOccurs='1'/> maxOccurs='1'/>
<xs:choice maxOccurs='1'> <xs:choice maxOccurs='1'>
<xs:element ref='bad-request'/> <xs:element ref='bad-request'/>
skipping to change at page 68, line 5 skipping to change at page 69, line 5
<xs:element name='jid-not-found' type='xs:string'/> <xs:element name='jid-not-found' type='xs:string'/>
<xs:element name='not-allowed' type='xs:string'/> <xs:element name='not-allowed' type='xs:string'/>
<xs:element name='recipient-unavailable' type='xs:string'/> <xs:element name='recipient-unavailable' type='xs:string'/>
<xs:element name='registration-required' type='xs:string'/> <xs:element name='registration-required' type='xs:string'/>
<xs:element name='remote-server-not-found' type='xs:string'/> <xs:element name='remote-server-not-found' type='xs:string'/>
<xs:element name='remote-server-timeout' type='xs:string'/> <xs:element name='remote-server-timeout' type='xs:string'/>
<xs:element name='service-unavailable' type='xs:string'/> <xs:element name='service-unavailable' type='xs:string'/>
</xs:schema> </xs:schema>
Appendix B. Provisional Namespace Names Appendix B. Revision History
Note to RFC editor: prior to publication, the string 'xmppcore-rfc-
number' must be replaced in all instances by the RFC number assigned
to this draft. (In addition, please remove this appendix, and the
corresponding entry in the table of contents, prior to publication.)
Appendix C. Revision History
Note to RFC editor: please remove this entire appendix, and the Note to RFC editor: please remove this entire appendix, and the
corresponding entries in the table of contents, prior to publication. corresponding entries in the table of contents, prior to publication.
C.1 Changes from draft-ietf-xmpp-core-05 B.1 Changes from draft-ietf-xmpp-core-06
o Added text regarding certificate validation in TLS negotiation per
list discussion.
o Clarified nature of XML restrictions per discussion with W3C, and
moved XML Restrictions subsection under "XML Usage within XMPP".
o Further clarified that XML streams are unidirectional.
o Changed stream error and stanza error namespace names to conform
to the format defined in The IETF XML Registry [15].
o Removed note to RFC editor regarding provisional namespace names.
B.2 Changes from draft-ietf-xmpp-core-05
o Added <invalid-namespace/> as a stream error condition. o Added <invalid-namespace/> as a stream error condition.
o Adjusted security considerations per discussion at IETF 56 and on o Adjusted security considerations per discussion at IETF 56 and on
list. list.
C.2 Changes from draft-ietf-xmpp-core-04 B.3 Changes from draft-ietf-xmpp-core-04
o Added server-to-server examples for TLS and SASL. o Added server-to-server examples for TLS and SASL.
o Changed error syntax, rules, and examples based on list o Changed error syntax, rules, and examples based on list
discussion. discussion.
o Added schemas for the TLS, stream error, and stanza error o Added schemas for the TLS, stream error, and stanza error
namespaces. namespaces.
o Added note to RFC editor regarding provisional namespace names. o Added note to RFC editor regarding provisional namespace names.
o Made numerous small editorial changes and clarified text o Made numerous small editorial changes and clarified text
throughout. throughout.
C.3 Changes from draft-ietf-xmpp-core-03 B.4 Changes from draft-ietf-xmpp-core-03
o Clarified rules and procedures for TLS and SASL. o Clarified rules and procedures for TLS and SASL.
o Amplified stream error code syntax per list discussion. o Amplified stream error code syntax per list discussion.
o Made numerous small editorial changes. o Made numerous small editorial changes.
C.4 Changes from draft-ietf-xmpp-core-02 B.5 Changes from draft-ietf-xmpp-core-02
o Added dialback schema. o Added dialback schema.
o Removed all DTDs since schemas provide more complete definitions. o Removed all DTDs since schemas provide more complete definitions.
o Added stream error codes. o Added stream error codes.
o Clarified error code "philosophy". o Clarified error code "philosophy".
C.5 Changes from draft-ietf-xmpp-core-01 B.6 Changes from draft-ietf-xmpp-core-01
o Updated the addressing restrictions per list discussion and added o Updated the addressing restrictions per list discussion and added
references to the new nodeprep and resourceprep profiles. references to the new nodeprep and resourceprep profiles.
o Corrected error in Stream Authentication regarding "version='1.0'" o Corrected error in Stream Authentication regarding "version='1.0'"
flag. flag.
o Made numerous small editorial changes. o Made numerous small editorial changes.
C.6 Changes from draft-ietf-xmpp-core-00 B.7 Changes from draft-ietf-xmpp-core-00
o Added information about TLS from list discussion. o Added information about TLS from list discussion.
o Clarified meaning of "ignore" based on list discussion. o Clarified meaning of "ignore" based on list discussion.
o Clarified information about Universal Character Set data and o Clarified information about Universal Character Set data and
character encodings. character encodings.
o Provided base64-decoded information for examples. o Provided base64-decoded information for examples.
o Fixed several errors in the schemas. o Fixed several errors in the schemas.
o Made numerous small editorial fixes. o Made numerous small editorial fixes.
C.7 Changes from draft-miller-xmpp-core-02 B.8 Changes from draft-miller-xmpp-core-02
o Brought Streams Authentication section into line with discussion o Brought Streams Authentication section into line with discussion
on list and at IETF 55 meeting. on list and at IETF 55 meeting.
o Added information about the optional 'xml:lang' attribute per o Added information about the optional 'xml:lang' attribute per
discussion on list and at IETF 55 meeting. discussion on list and at IETF 55 meeting.
o Specified that validation is neither required nor recommended, and o Specified that validation is neither required nor recommended, and
that the formal definitions (DTDs and schemas) are included for that the formal definitions (DTDs and schemas) are included for
descriptive purposes only. descriptive purposes only.
 End of changes. 104 change blocks. 
189 lines changed or deleted 268 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/