draft-ietf-xmpp-core-01.txt   draft-ietf-xmpp-core-02.txt 
Network Working Group J. Miller Network Working Group P. Saint-Andre
Internet-Draft P. Saint-Andre Internet-Draft J. Miller
Expires: July 18, 2003 Jabber Software Foundation Expires: August 4, 2003 Jabber Software Foundation
January 17, 2003 February 03, 2003
XMPP Core XMPP Core
draft-ietf-xmpp-core-01 draft-ietf-xmpp-core-02
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 July 18, 2003. This Internet-Draft will expire on August 4, 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), which is used by the servers, clients, and Presence Protocol (XMPP), a protocol for streaming XML in near-
and other applications that comprise the Jabber network. real-time that is used mainly for the purpose of instant messaging
and presence by the servers, clients, and other applications that
comprise the Jabber network.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Conventions Used in this Document . . . . . . . . . . . . . 4 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Discussion Venue . . . . . . . . . . . . . . . . . . . . . . 4 1.3 Discussion Venue . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Intellectual Property Notice . . . . . . . . . . . . . . . . 4 1.4 Intellectual Property Notice . . . . . . . . . . . . . . . . 4
2. Generalized Architecture . . . . . . . . . . . . . . . . . . 5 2. Generalized Architecture . . . . . . . . . . . . . . . . . . 5
2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.4 Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.5 Network . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.5 Network . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Addressing Scheme . . . . . . . . . . . . . . . . . . . . . 7 3. Addressing Scheme . . . . . . . . . . . . . . . . . . . . . 7
3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7
skipping to change at page 2, line 34 skipping to change at page 2, line 34
4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2 Restrictions . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2 Restrictions . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3 Stream Attributes . . . . . . . . . . . . . . . . . . . . . 10 4.3 Stream Attributes . . . . . . . . . . . . . . . . . . . . . 10
4.4 Namespace Declarations . . . . . . . . . . . . . . . . . . . 11 4.4 Namespace Declarations . . . . . . . . . . . . . . . . . . . 11
4.5 Stream Features . . . . . . . . . . . . . . . . . . . . . . 12 4.5 Stream Features . . . . . . . . . . . . . . . . . . . . . . 12
4.6 Stream Errors . . . . . . . . . . . . . . . . . . . . . . . 12 4.6 Stream Errors . . . . . . . . . . . . . . . . . . . . . . . 12
4.7 Simple Streams Example . . . . . . . . . . . . . . . . . . . 13 4.7 Simple Streams Example . . . . . . . . . . . . . . . . . . . 13
5. Stream Authentication . . . . . . . . . . . . . . . . . . . 15 5. Stream Authentication . . . . . . . . . . . . . . . . . . . 15
5.1 SASL Authentication . . . . . . . . . . . . . . . . . . . . 15 5.1 SASL Authentication . . . . . . . . . . . . . . . . . . . . 15
5.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1.2 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1.2 Client-Server Example . . . . . . . . . . . . . . . . . . . 16
5.2 Dialback Authentication . . . . . . . . . . . . . . . . . . 18 5.2 Dialback Authentication . . . . . . . . . . . . . . . . . . 18
5.2.1 Dialback Protocol . . . . . . . . . . . . . . . . . . . . . 20 5.2.1 Dialback Protocol . . . . . . . . . . . . . . . . . . . . . 20
6. Stream Encryption . . . . . . . . . . . . . . . . . . . . . 24 6. Stream Encryption . . . . . . . . . . . . . . . . . . . . . 23
6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.2 Protocol Example . . . . . . . . . . . . . . . . . . . . . . 25 6.2 Client-Server Example . . . . . . . . . . . . . . . . . . . 24
6.3 Certificate-Based Authentication . . . . . . . . . . . . . . 26 6.3 Certificate-Based Authentication . . . . . . . . . . . . . . 25
7. XML Stanzas . . . . . . . . . . . . . . . . . . . . . . . . 27 7. XML Stanzas . . . . . . . . . . . . . . . . . . . . . . . . 26
7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 27 7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.2 Common Attributes . . . . . . . . . . . . . . . . . . . . . 27 7.2 Common Attributes . . . . . . . . . . . . . . . . . . . . . 26
7.2.1 to . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 7.2.1 to . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.2.2 from . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 7.2.2 from . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.2.3 id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 7.2.3 id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.2.4 type . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 7.2.4 type . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.2.5 xml:lang . . . . . . . . . . . . . . . . . . . . . . . . . . 28 7.2.5 xml:lang . . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.3 Message Stanzas . . . . . . . . . . . . . . . . . . . . . . 28 7.3 Message Stanzas . . . . . . . . . . . . . . . . . . . . . . 27
7.3.1 Types of Message . . . . . . . . . . . . . . . . . . . . . . 28 7.3.1 Types of Message . . . . . . . . . . . . . . . . . . . . . . 27
7.3.2 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 29 7.3.2 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 28
7.4 Presence Stanzas . . . . . . . . . . . . . . . . . . . . . . 30 7.4 Presence Stanzas . . . . . . . . . . . . . . . . . . . . . . 29
7.4.1 Types of Presence . . . . . . . . . . . . . . . . . . . . . 30 7.4.1 Types of Presence . . . . . . . . . . . . . . . . . . . . . 29
7.4.2 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 31 7.4.2 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.5 IQ Stanzas . . . . . . . . . . . . . . . . . . . . . . . . . 32 7.5 IQ Stanzas . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 32 7.5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.5.2 Types of IQ . . . . . . . . . . . . . . . . . . . . . . . . 33 7.5.2 Types of IQ . . . . . . . . . . . . . . . . . . . . . . . . 32
7.5.3 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 33 7.5.3 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.6 Extended Namespaces . . . . . . . . . . . . . . . . . . . . 33 7.6 Extended Namespaces . . . . . . . . . . . . . . . . . . . . 33
8. XML Usage within XMPP . . . . . . . . . . . . . . . . . . . 35 8. XML Usage within XMPP . . . . . . . . . . . . . . . . . . . 34
8.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 35 8.1 Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . 34
8.2 Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . 35 8.2 Validation . . . . . . . . . . . . . . . . . . . . . . . . . 34
8.3 Validation . . . . . . . . . . . . . . . . . . . . . . . . . 35 8.3 Character Encodings . . . . . . . . . . . . . . . . . . . . 34
8.4 Character Encodings . . . . . . . . . . . . . . . . . . . . 36 8.4 Inclusion of Text Declaration . . . . . . . . . . . . . . . 34
8.5 Inclusion of Text Declaration . . . . . . . . . . . . . . . 36 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 35
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 37 10. Internationalization Considerations . . . . . . . . . . . . 36
10. Internationalization Considerations . . . . . . . . . . . . 38 11. Security Considerations . . . . . . . . . . . . . . . . . . 37
11. Security Considerations . . . . . . . . . . . . . . . . . . 39 11.1 Client-to-Server Communications . . . . . . . . . . . . . . 37
11.1 Client-to-Server Communications . . . . . . . . . . . . . . 39 11.2 Server-to-Server Communications . . . . . . . . . . . . . . 37
11.2 Server-to-Server Communications . . . . . . . . . . . . . . 39 11.3 Minimum Security Mechanisms . . . . . . . . . . . . . . . . 37
11.3 Minimum Security Mechanisms . . . . . . . . . . . . . . . . 39 11.4 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . 38
11.4 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . 40 References . . . . . . . . . . . . . . . . . . . . . . . . . 39
References . . . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 42 A. Standard Error Codes . . . . . . . . . . . . . . . . . . . . 42
A. Standard Error Codes . . . . . . . . . . . . . . . . . . . . 44 B. Formal Definitions . . . . . . . . . . . . . . . . . . . . . 44
B. Formal Definitions . . . . . . . . . . . . . . . . . . . . . 46 B.1 streams namespace . . . . . . . . . . . . . . . . . . . . . 44
B.1 streams namespace . . . . . . . . . . . . . . . . . . . . . 46 B.1.1 DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
B.1.1 DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 B.1.2 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
B.1.2 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 B.2 SASL namespace . . . . . . . . . . . . . . . . . . . . . . . 45
B.2 SASL namespace . . . . . . . . . . . . . . . . . . . . . . . 47 B.2.1 DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
B.2.1 DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 B.2.2 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
B.2.2 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 B.3 jabber:client namespace . . . . . . . . . . . . . . . . . . 47
B.3 jabber:client namespace . . . . . . . . . . . . . . . . . . 49 B.3.1 DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
B.3.1 DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 B.3.2 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
B.3.2 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 B.4 jabber:server namespace . . . . . . . . . . . . . . . . . . 51
B.4 jabber:server namespace . . . . . . . . . . . . . . . . . . 53 B.4.1 DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
B.4.1 DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 B.4.2 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
B.4.2 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 C. Revision History . . . . . . . . . . . . . . . . . . . . . . 56
C. Revision History . . . . . . . . . . . . . . . . . . . . . . 58 C.1 Changes from draft-ietf-xmpp-core-01 . . . . . . . . . . . . 56
C.1 Changes from draft-ietf-xmpp-core-00 . . . . . . . . . . . . 58 C.2 Changes from draft-ietf-xmpp-core-00 . . . . . . . . . . . . 56
C.2 Changes from draft-miller-xmpp-core-02 . . . . . . . . . . . 58 C.3 Changes from draft-miller-xmpp-core-02 . . . . . . . . . . . 56
Full Copyright Statement . . . . . . . . . . . . . . . . . . 60 Full Copyright Statement . . . . . . . . . . . . . . . . . . 58
1. Introduction 1. Introduction
1.1 Overview 1.1 Overview
The eXtensible Messaging and Presence Protocol (XMPP) is an open XML The eXtensible Messaging and Presence Protocol (XMPP) is an open XML
[1] protocol for near-real-time messaging and presence. The protocol [1] protocol for near-real-time messaging and presence. The protocol
was developed originally within the Jabber community starting in was developed originally within the Jabber community starting in
1998, and since 2001 has continued to evolve under the auspices of 1998, and since 2001 has continued to evolve under the auspices of
the Jabber Software Foundation and now the XMPP WG. Currently, there the Jabber Software Foundation and now the XMPP WG. Currently, there
exist multiple implementations of the protocol, mostly offered under exist multiple implementations of the protocol, mostly offered under
the name of Jabber. In addition, there are countless deployments of the name of Jabber. In addition, there are countless deployments of
these implementations, which provide instant messaging (IM) and these implementations, which provide instant messaging (IM) and
presence services at and among thousands of domains to a user base presence services at and among tens of thousands of domains to a user
that is estimated at over one million end users. The current base that is estimated at over five million end users. The current
document defines the core constituents of XMPP; XMPP IM [2] defines document defines the core features of XMPP; XMPP IM [2] defines the
the extensions necessary to provide basic instant messaging and extensions necessary to provide basic instant messaging and presence
presence functionality that addresses the requirements defined in RFC functionality that addresses the requirements defined in RFC 2779
2779 [3]. [3].
1.2 Conventions Used in this Document 1.2 Terminology
The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [4]. 2119 [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, preferably on the "xmppwg@jabber.org" presented in this document. The preferred forum is the
mailing list (archives and subscription information are available at <xmppwg@jabber.org> mailing list, for which archives and subscription
http://www.jabber.org/cgi-bin/mailman/listinfo/xmppwg/). information are available at <http://www.jabber.org/cgi-bin/mailman/
listinfo/xmppwg/>.
1.4 Intellectual Property Notice 1.4 Intellectual Property Notice
This document is in full compliance with all provisions of Section 10 This document is in full compliance with all provisions of Section 10
of RFC 2026. Parts of this specification use the term "jabber" for of RFC 2026. Parts of this specification use the term "jabber" for
identifying namespaces and other protocol syntax. Jabber[tm] is a identifying namespaces and other protocol syntax. Jabber[tm] is a
registered trademark of Jabber, Inc. Jabber, Inc. grants permission registered trademark of Jabber, Inc. Jabber, Inc. grants permission
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.
skipping to change at page 5, line 29 skipping to change at page 5, line 29
/ \ / \
C2 - G1 = FN1 = FC1 C2 - G1 = FN1 = FC1
The symbols are as follows: The symbols are as follows:
o C1, C2, C3 -- XMPP clients o C1, C2, C3 -- XMPP clients
o S1, S2 -- XMPP servers o S1, S2 -- XMPP servers
o G1 -- A gateway that translates between XMPP and the protocol(s) o G1 -- A gateway that translates between XMPP and the protocol(s)
used on a foreign messaging network used on a foreign (non-XMPP) messaging network
o FN1 -- A foreign messaging network o FN1 -- A foreign messaging network
o FC1 -- A client on a foreign messaging network o FC1 -- A client on a foreign messaging network
2.2 Server 2.2 Server
A server acts as an intelligent abstraction layer for XMPP A server acts as an intelligent abstraction layer for XMPP
communications. Its primary responsibilities are to manage communications. Its primary responsibilities are to manage
connections from or sessions for other entities (in the form of XML connections from or sessions for other entities (in the form of XML
skipping to change at page 6, line 18 skipping to change at page 6, line 18
XMPP to take full advantage of the functionality provided by a server XMPP to take full advantage of the functionality provided by a server
and any associated services. (Clients on foreign messaging networks and any associated services. (Clients on foreign messaging networks
may also be part of the architecture, made accessable via a gateway may also be part of the architecture, made accessable via a gateway
to that network.) Multiple resources (e.g., devices or locations) MAY to that network.) Multiple resources (e.g., devices or locations) MAY
connect simultaneously to a server on behalf of each authorized connect simultaneously to a server on behalf of each authorized
client, with each resource connecting over a discrete TCP socket and client, with each resource connecting over a discrete TCP socket and
differentiated by the resource identifier of a JID (Section 3) (e.g., differentiated by the resource identifier of a JID (Section 3) (e.g.,
user@domain/home vs. user@domain/work). The port assigned by the user@domain/home vs. user@domain/work). The port assigned by the
IANA [6] for connections between a Jabber client and a Jabber server IANA [6] for connections between a Jabber client and a Jabber server
is 5222. For further details about client-to-server communications is 5222. For further details about client-to-server communications
for the purpose of instant messaging and presence, refer to XMPP IM expressly for the purpose of instant messaging and presence, refer to
[2]. 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 Internet Relay Chat (IRC), Short XMPP. Examples are gateways to Internet Relay Chat (IRC), Short
Message Service (SMS), SMTP, and foreign instant messaging networks Message Service (SMS), SMTP, and foreign instant messaging networks
such as Yahoo!, MSN, ICQ, and AIM. Communications between gateways such as Yahoo!, MSN, ICQ, and AIM. Communications between gateways
and servers, and between gateways and the foreign messaging system, and servers, and between gateways and the foreign messaging system,
are not defined in this document. are not defined in this document.
2.5 Network 2.5 Network
Because each server is identified by a network address (typically a Because each server is identified by a network address (typically a
DNS hostname) and because server-to-server communications are a DNS hostname) and because server-to-server communications are a
simple extension of the client-to-server protocol, in practice the straightforward extension of the client-to-server protocol, in
system consists of a network of servers that inter-communicate. Thus practice the system consists of a network of servers that inter-
user-a@domain1 is able to exchange messages, presence, and other communicate. Thus user-a@domain1 is able to exchange messages,
information with user-b@domain2. This pattern is familiar from presence, and other information with user-b@domain2. This pattern is
messaging protocols (such as SMTP) that make use of network familiar from messaging protocols (such as SMTP) that make use of
addressing standards. The usual method for providing a connection network addressing standards. The usual method for providing a
between two servers is to open a TCP socket on the IANA-assigned port connection between two servers is to open a TCP socket on the IANA-
5269 and to negotiate a connection using the Dialback Protocol assigned port 5269 and to negotiate a connection using the Dialback
(Section 5.2) as defined in this document. Protocol (Section 5.2) defined in this document.
3. Addressing Scheme 3. Addressing Scheme
3.1 Overview 3.1 Overview
Any entity that can be considered a network endpoint (i.e., an ID on Any entity that can be considered a network endpoint (i.e., an ID on
the network) and that can communicate using XMPP is considered a the network) and that can communicate using XMPP is considered a
Jabber Entity. All such entities are uniquely addressable in a form Jabber Entity. All such entities are uniquely addressable in a form
that is consistent with RFC 2396 [13]. In particular, a valid Jabber that is 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
room@service, where "room" is the name of the chat room and "service" room@service (where "room" is the name of the chat room and "service"
is the hostname of the multi-user chat service. is the hostname of the multi-user chat service) and a specific
occupant of such a room could be addressed as room@service/nick
(where "nick" is the occupant's room nickname).
3.2 Domain Identifier 3.2 Domain Identifier
The domain identifier is the primary identifier and is the only The domain identifier is the primary identifier and is the only
REQUIRED element of a JID (a simple domain identifier is a valid REQUIRED element of a JID (a mere domain identifier is a valid JID).
JID). It usually represents the network gateway or "primary" server It usually represents the network gateway or "primary" server to
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, and a domain identifier SHOULD conform to RFC 952 [14] and RFC Name. A domain identifier MUST conform to RFC 952 [8] and RFC 1123
1123 [15]. Specifically, a domain identifier is case-insensitive 7- [9]. A domain identifier MUST be no more than 1023 bytes in length,
bit ASCII and is limited to 255 bytes. and is subject to comparison in accordance with the rules defined in
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 (e.g., a client), although it can also the server or gateway (e.g., a client), although it can also
represent other kinds of entities (e.g., a multi-user chat room represent other kinds of entities (e.g., a multi-user chat room
associated with a multi-user chat service). The entity represented associated with a multi-user chat service). The entity represented
by a node identifier is addressed within the context of a specific by a node identifier is addressed within the context of a specific
domain (e.g., user@domain). Node identifiers are restricted to 255 domain (e.g., user@domain).
bytes. A node identifier MAY contain any valid, properly transformed
UCS character (see Character Encodings (Section 8.4), as long as the
character code either is higher than #x20 or is not one of the
following:
o #x22 (")
o #x26 (&)
o #x27 (')
o #x3A (:)
o #x3C (<)
o #x3E (>)
o #x40 (@)
o #x7F (del)
o #xFFFE (BOM)
o #xFFFF (BOM)
Case is preserved, but comparisons are made in case-normalized A node identifier MUST be no more than 1023 bytes in length and MUST
canonical form. conform to the nodeprep [12] profile of stringprep [11].
3.4 Resource Identifier 3.4 Resource Identifier
The resource identifer is an optional third identifier. It The resource identifer is an optional third identifier. It
represents a specific session, connection (e.g., a device or represents a specific session, connection (e.g., a device or
location), or object (e.g., a participant in a multi-user chat room) location), or object (e.g., a participant in a multi-user chat room)
belonging to the entity associated with a node identifier. An entity belonging to the entity associated with a node identifier. An entity
may maintain multiple resources simultaneously. A resource may maintain multiple resources simultaneously.
identifier is restricted to 255 bytes in length. A resource
identifier MAY include any valid, properly transformed UCS character A resource identifier MUST be no more than 1023 bytes in length and
(see Character Encodings (Section 8.4)) greater than #x20, except MUST conform to the resourceprep [13] profile of stringprep [11].
#xFFFE and #xFFFF; if the character is a valid XML character as
defined in Section 2.2 of the XML specification [1], it MUST be
suitably escaped for inclusion within an XML stream. Resource
identifiers are case sensitive.
4. XML Streams 4. XML Streams
4.1 Overview 4.1 Overview
Two fundamental concepts make possible the rapid, asynchronous Two fundamental concepts make possible the rapid, asynchronous
exchange of relatively small payloads of structured information exchange of relatively small payloads of structured information
between presence-aware entities: XML streams and, as a result, between presence-aware entities: XML streams and, as a result,
discrete units of structured information that are referred to as "XML discrete units of structured information that are referred to as "XML
stanzas". (Note: in this overview we use the example of stanzas". (Note: in this overview we use the example of
skipping to change at page 9, line 34 skipping to change at page 9, line 34
<stream:stream/> element. The server SHOULD then reply with a second <stream:stream/> element. The server SHOULD then reply with a second
XML stream back to the client, again optionally preceded by a text XML stream back to the client, again optionally preceded by a text
declaration. declaration.
Within the context of an XML stream, a sender is able to send a Within the context of an XML stream, a sender is able to send a
discrete semantic unit of structured information to any recipient. discrete semantic unit of structured information to any recipient.
This unit of structured information is a well-balanced XML stanza, This unit of structured information is a well-balanced XML stanza,
such as a message, presence, or IQ stanza (a stanza of an XML such as a message, presence, or IQ stanza (a stanza of an XML
document is said to be well-balanced if it matches production [43] document is said to be well-balanced if it matches production [43]
content of the XML specification [1]). These stanzas exist at the content of the XML specification [1]). These stanzas exist at the
direct child level (depth=1) of the root <stream/> element. The direct child level of the root <stream/> element. The start of any
start of any XML stanza is unambiguously denoted by the element start XML stanza is unambiguously denoted by the element start tag at
tag at depth=1 (e.g., <presence>), and the end of any XML stanza is depth=1 (e.g., <presence>), and the end of any XML stanza is
unambiguously denoted by the corresponding close tag at depth=1 unambiguously denoted by the corresponding close tag at depth=1
(e.g., </presence>). Each XML stanza MAY contain child elements or (e.g., </presence>). Each XML stanza MAY contain child elements or
CDATA sections as necessary in order to convey the desired CDATA sections as necessary in order to convey the desired
information from the sender to the recipient. The session is closed information from the sender to the recipient. The session is closed
at the client's request by sending a closing </stream> tag to the at the client's request by sending a closing </stream> tag to the
server. server (a session may also be closed by the server).
Thus a client's session with a server can be seen as two open-ended Thus a client's session with a server can be seen as two open-ended
XML documents that are built up through the accumulation of the XML XML documents that are built up through the accumulation of the XML
stanzas that are sent over the course of the session (one from the stanzas that are sent over the course of the session (one from the
client to the server and one from the server to the client), and the client to the server and one from the server to the client), and the
root <stream/> element can be considered the document entity for root <stream/> element can be considered the document entity for
those streams. In essence, then, an XML stream acts as an envelope those streams. In essence, then, an XML stream acts as an envelope
for all the XML stanzas sent during a session. We can represent this for all the XML stanzas sent during a session. We can represent this
graphically as follows: graphically as follows:
skipping to change at page 10, line 20 skipping to change at page 10, line 20
| </message> | | </message> |
|-------------------| |-------------------|
| <presence to=''> | | <presence to=''> |
| <show/> | | <show/> |
| </presence> | | </presence> |
|-------------------| |-------------------|
| <iq to=''> | | <iq to=''> |
| <query/> | | <query/> |
| </iq> | | </iq> |
|-------------------| |-------------------|
| ... |
|-------------------|
| </stream> | | </stream> |
|-------------------| |-------------------|
4.2 Restrictions 4.2 Restrictions
XML streams are used to transport a subset of XML. Specifically, XML XML streams are used to transport a subset of XML. Specifically, XML
streams SHOULD NOT contain processing instructions, predefined streams SHOULD NOT contain processing instructions, predefined
entities (as defined in Section 4.6 of the XML specification [1]), entities (as defined in Section 4.6 of the XML specification [1]),
comments, or DTDs. Any such XML data SHOULD be ignored. comments, or DTDs. Any such XML data SHOULD be ignored by a
compliant implementation.
4.3 Stream Attributes 4.3 Stream Attributes
The attributes of the stream element are as follows (we now The attributes of the stream element are as follows (we now
generalize the endpoints by using the terms "initiating entity" and generalize the endpoints by using the terms "initiating entity" and
"receiving entity"): "receiving entity"):
o to -- The 'to' attribute SHOULD be used only in the XML stream o to -- The 'to' attribute SHOULD be used only in the XML stream
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 JID of the receiving entity. There SHOULD be no 'to' set to the JID of the receiving entity. There SHOULD be no 'to'
attribute set in the XML stream by which the receiving entity attribute set in the XML stream by which the receiving entity
replies to the initiating entity; however, if a 'to' attribute is replies to the initiating entity; however, if a 'to' attribute is
included, it SHOULD be ignored by the receiving entity. included, it SHOULD be ignored by the initiating entity.
o from -- The 'from' attribute SHOULD be used only in the XML stream o from -- The 'from' attribute SHOULD be used only in the XML stream
from the receiving entity to the initiating entity, and MUST be from the receiving entity to the initiating entity, and MUST be
set to the JID of the receiving entity granting access to the set to the JID of the receiving entity granting access to the
initiating entity. There SHOULD be no 'from' attribute on the XML initiating entity. There SHOULD be no 'from' attribute on the XML
stream sent from the initiating entity to the receiving entity; stream sent from the initiating entity to the receiving entity;
however, if a 'from' attribute is included, it SHOULD be ignored however, if a 'from' attribute is included, it SHOULD be ignored
by the receiving entity. by the receiving entity.
o id -- The 'id' attribute SHOULD be used only in the XML stream o id -- The 'id' attribute SHOULD be used only in the XML stream
skipping to change at page 11, line 32 skipping to change at page 11, line 35
| initiating to receiving | receiving to initiating | initiating to receiving | receiving to initiating
------------------------------------------------------------ ------------------------------------------------------------
to | JID of receiver | ignored to | JID of receiver | ignored
from | ignored | JID of receiver from | ignored | JID of receiver
id | ignored | session key id | ignored | session key
version | signals XMPP 1.0 support | signals XMPP 1.0 support version | signals XMPP 1.0 support | signals XMPP 1.0 support
4.4 Namespace Declarations 4.4 Namespace Declarations
The stream element MAY also contain namespace declarations as defined The stream element MAY also contain namespace declarations as defined
in the XML namespaces specification [16]. in 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
both XML streams. A compliant entity MUST accept any namespace both XML streams. A compliant entity SHOULD accept any namespace
prefix on the <stream/> element; however, for historical reasons some prefix on the <stream/> element; however, for historical reasons some
entities MAY accept only a 'stream' prefix, resulting in use of a entities MAY accept only a 'stream' prefix, resulting in use of a
<stream:stream/> element as the stream root. The value of the stream <stream:stream/> element as the stream root. The value of the stream
namespace MUST be "http://etherx.jabber.org/streams". namespace MUST be "http://etherx.jabber.org/streams".
XML streams function as containers for any XML stanzas sent XML streams function as containers for any XML stanzas sent
asynchronously between network endpoints. It should be possible to asynchronously between network endpoints. It should be possible to
scope an XML stream with any default namespace declaration, i.e., it scope an XML stream with any default namespace declaration, i.e., it
should be possible to send any properly-namespaced XML stanza over an should be possible to send any properly-namespaced XML stanza over an
XML stream. A compliant implementation MUST support the following XML stream. A compliant implementation MUST support the following
skipping to change at page 12, line 41 skipping to change at page 12, line 44
is used to communicate generic stream-level capabilities including is used to communicate generic stream-level capabilities including
stream-level features that can be negotiated as the streams are set stream-level features that can be negotiated as the streams are set
up. If the initiating entity sends a "version='1.0'" attribute in up. If the initiating entity sends a "version='1.0'" attribute in
its initiating stream element, the receiving entity MUST send a its initiating stream element, the receiving entity MUST send a
features child element to the initiating entity if there are any features child element to the initiating entity if there are any
capabilities that need to be advertised or features that can be capabilities that need to be advertised or features that can be
negotiated for the stream. Currently this is used for SASL and TLS negotiated for the stream. Currently this is used for SASL and TLS
negotiation only, but it could be used for other negotiable features negotiation only, but it could be used for other negotiable features
in the future (examples are shown under Stream Authentication in the future (examples are shown under Stream Authentication
(Section 5) below). If an entity does not understand or support some (Section 5) below). If an entity does not understand or support some
features, it should ignore them. features, it SHOULD ignore them.
4.6 Stream Errors 4.6 Stream Errors
The root stream element MAY contain an error child element (e.g., The root stream element MAY contain an error child element (e.g.,
<stream:error/> if the stream namespace prefix is 'stream'). The <stream:error/> if the stream namespace prefix is 'stream'). The
error child SHOULD be sent by a Jabber entity (usually a server error child SHOULD be sent by a Jabber entity (usually a server
rather than a client) if it perceives that a stream-level error has rather than a client) if it perceives that a stream-level error has
occurred. Examples include the sending of invalid XML, the shutdown occurred. Examples include the sending of invalid XML, the shutdown
of a server, an internal server error such as the shutdown of a of a server, an internal server error such as the shutdown of a
session manager, and an attempt by a client to authenticate as the session manager, and an attempt by a client to authenticate as the
skipping to change at page 13, line 20 skipping to change at page 13, line 22
<stream:stream ...> <stream:stream ...>
... ...
<stream:error> <stream:error>
Error message (e.g., "Invalid XML") Error message (e.g., "Invalid XML")
</stream:error> </stream:error>
</stream:stream> </stream:stream>
4.7 Simple Streams Example 4.7 Simple Streams Example
The following is a simple stream-based session of a client on a The following is a stream-based session of a client on a server
server (where the "C" lines are sent from the client to the server, (where the "C" lines are sent from the client to the server, and the
and the "S" lines are sent from the server to the client): "S" lines are sent from the server to the client):
A simple session: A basic session:
C: <?xml version='1.0'?> C: <?xml version='1.0'?>
<stream:stream <stream:stream
to='server' to='server'
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'>
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'>
... authentication ... ... authentication ...
C: <message from='me@mydomain' to='you@yourdomain'> C: <message from='alex@graham-bell' to='watson@graham-bell'>
C: <body>Watson come here, I need you!</body> C: <body>Watson come here, I want you!</body>
C: </message> C: </message>
S: <message from='you@yourdomain' to='me@mydomain'> S: <message from='watson@graham-bell' to='alex@graham-bell'>
S: <body>I'm on my way!</body> S: <body>I'm on my way!</body>
S: </message> S: </message>
C: </stream:stream> C: </stream:stream>
S: </stream:stream> S: </stream:stream>
These are in actuality a sending stream and a receiving stream, which These are in actuality a sending stream and a receiving stream, which
can be viewed a-chronologically as two XML documents: can be viewed a-chronologically as two XML documents:
C: <?xml version='1.0'?> C: <?xml version='1.0'?>
<stream:stream <stream:stream
to='server' to='server'
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 from='me@mydomain' to='you@yourdomain'> C: <message from='alex@graham-bell' to='watson@graham-bell'>
C: <body>Watson come here, I need you!</body> C: <body>Watson come here, I want you!</body>
C: </message> C: </message>
C: </stream:stream> C: </stream:stream>
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'>
S: <message from='you@yourdomain' to='me@mydomain'> S: <message from='watson@graham-bell' to='alex@graham-bell'>
S: <body>I'm on my way!</body> S: <body>I'm on my way!</body>
S: </message> S: </message>
S: </stream:stream> S: </stream:stream>
A session gone bad: A session gone bad:
C: <?xml version='1.0'?> C: <?xml version='1.0'?>
<stream:stream <stream:stream
to='server' to='server'
xmlns='jabber:client' xmlns='jabber:client'
skipping to change at page 15, line 11 skipping to change at page 15, line 11
C: <message><body>Bad XML, no closing body tag!</message> C: <message><body>Bad XML, no closing body tag!</message>
S: <stream:error>Invalid XML</stream:error> S: <stream:error>Invalid XML</stream:error>
S: </stream:stream> S: </stream:stream>
5. Stream Authentication 5. Stream Authentication
XMPP includes two methods for enforcing authentication at the level XMPP includes two methods for enforcing authentication at the level
of XML streams. When one entity is already known to another (i.e., of XML streams. When one entity is already known to another (i.e.,
there is an existing trust relationship between the entities such as there is an existing trust relationship between the entities such as
that established when a user registers with a server or an that established when a user registers with a server or an
administrator configures a server to trust a service), the preferred administrator configures a server to trust another server), the
method for authenticating streams between the two entities uses an preferred method for authenticating streams between the two entities
XMPP adaptation of the Simple Authentication and Security Layer uses an XMPP adaptation of the Simple Authentication and Security
(SASL) [12]. When there is no existing trust relationship between Layer (SASL) [15]. When there is no existing trust relationship
the two entities, such trust MAY be established based on existing between the two entities, such trust MAY be established based on
trust in DNS; the authentication method used when two such entities existing trust in DNS; the authentication method used when two such
are servers is the server dialback protocol that is native to XMPP. entities are servers is the server dialback protocol that is native
Both of these methods are described in this section. to XMPP (no such ad-hoc method is defined between a client and a
server). Both of these methods are described in this section.
5.1 SASL Authentication 5.1 SASL Authentication
5.1.1 Overview 5.1.1 Overview
The Simple Authentication and Security Layer (SASL) provides a The Simple Authentication and Security Layer (SASL) provides a
generalized method for adding authentication support to connection- generalized method for adding authentication support to connection-
based protocols. XMPP uses a generic XML namespace profile for SASL based protocols. XMPP uses a generic XML namespace profile for SASL
that conforms to section 4 ("Profiling Requirements") of RFC 2222 that conforms to section 4 ("Profiling Requirements") of RFC 2222
[12] (the namespace identifier for this protocol is http:// [15] (the namespace identifier for this protocol is 'http://
www.iana.org/assignments/sasl-mechanisms). If an entity (client, www.iana.org/assignments/sasl-mechanisms'). If an entity (client or
server, or service) is capable of authenticating by means of SASL, it server) is capable of authenticating by means of SASL, it MUST
MUST include the agreed-upon SASL namespace within the opening root include a 'version' attribute (set to a value of "1.0") within the
stream tag it uses to initiate communications. opening <stream/> tag.
The following example shows the use of SASL in client authentication The following example shows the use of SASL in client authentication
with a server, for which the steps involved are as follows: with a server, for which the steps involved are as follows:
1. The client requests SASL authentication by including the 1. The client requests SASL authentication by including a 'version'
appropriate namespace declaration (xmlns:sasl='http:// attribute in the opening XML stream header sent to the server,
www.iana.org/assignments/sasl-mechanisms') in the opening XML with the value set to "1.0".
stream header sent to the server.
2. The server includes the xmlns:sasl namespace declaration in the
XML stream header sent in reply to the client.
3. The server responds with a list of available SASL authentication 2. After sending an XML stream header in response, the server sends
mechanisms, each of which is a <mechanism/> element included as a a list of available SASL authentication mechanisms, each of which
child within a <mechanisms/> container element that is sent as a is a <mechanism/> element included as a child within a
first-level child of the root <stream/> element. <mechanisms/> container element that is sent as a first-level
child of the root <stream/> element.
4. The client selects a mechanism by sending an <auth/> element to 3. The client selects a mechanism by sending an <auth/> element to
the server; this element MAY optionally contain character data if the server; this element MAY optionally contain character data if
the mechanism supports or requires it. the mechanism supports or requires it.
5. If necessary, the server challenges the client by sending a 4. If necessary, the server challenges the client by sending a
<challenge/> element to the client; this element MAY optionally <challenge/> element to the client; this element MAY optionally
contain character data. contain character data.
6. The client responds to challenge by sending a <response/> element 5. The client responds to the challenge by sending a <response/>
to the server; this element MAY optionally contain character element to the server; this element MAY optionally contain
data. character data.
7. If necessary, the server sends more challenges and the client 6. If necessary, the server sends more challenges and the client
sends more responses. sends more responses.
This series of challenge/response pairs continues until one of three This series of challenge/response pairs continues until one of three
things happens: things happens:
o The client aborts the handshake by sending a <abort/> element to o The client aborts the handshake by sending an <abort/> element to
the server. the server.
o The server reports failure by sending a <failure/> element to the o The server reports failure by sending a <failure/> element to the
client. client.
o The server reports success by sending a <success/> element to the o The server reports success by sending a <success/> element to the
client; this element MAY optionally contain character data. client; this element MAY optionally contain character data.
Any character data contained within these elements MUST be encoded Any character data contained within these elements MUST be encoded
using base64. using base64.
5.1.2 Example 5.1.2 Client-Server Example
The following example shows the data flow for a client authenticating The following example shows the data flow for a client authenticating
with a server using SASL. with a server using SASL.
Step 1: Client initiates stream to server: Step 1: Client initiates stream to server:
<stream:stream <stream:stream
xmlns='jabber:client' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams' xmlns:stream='http://etherx.jabber.org/streams'
to='capulet.com' to='capulet.com'
skipping to change at page 18, line 33 skipping to change at page 18, line 29
<success xmlns='http://www.iana.org/assignments/sasl-mechanisms'/> <success xmlns='http://www.iana.org/assignments/sasl-mechanisms'/>
Step 9 (alt): Server informs client of failed authentication: Step 9 (alt): Server informs client of failed authentication:
<failure xmlns='http://www.iana.org/assignments/sasl-mechanisms'/> <failure xmlns='http://www.iana.org/assignments/sasl-mechanisms'/>
5.2 Dialback Authentication 5.2 Dialback Authentication
XMPP includes a protocol-level method for verifying that a connection XMPP includes a protocol-level method for verifying that a connection
between two servers can be trusted to some degree. The method is between two servers can be trusted (at least as much as the DNS can
called dialback and is used only within XML streams that are declared be trusted). The method is called dialback and is used only within
under the "jabber:server" namespace. XML streams that are declared under the "jabber:server" namespace.
The purpose of the dialback protocol is to make server spoofing more The purpose of the dialback protocol is to make server spoofing more
difficult, and thus to make it more difficult to forge XML stanzas. difficult, and thus to make it more difficult to forge XML stanzas.
Dialback is not intended as a mechanism for securing or encrypting Dialback is not intended as a mechanism for securing or encrypting
the streams between servers, only for helping to prevent the spoofing the streams between servers, only for helping to prevent the spoofing
of a server and the sending of false data from it. Dialback is made of a server and the sending of false data from it. Dialback is made
possible by the existence of DNS, since one server can verify that possible by the existence of DNS, since one server can verify that
another server which is connecting to it is authorized to represent a another server which is connecting to it is authorized to represent a
given server on the Jabber network. All DNS hostname resolutions given server on the Jabber network. All DNS hostname resolutions
MUST first resolve the hostname using an SRV [18] record of MUST first resolve the hostname using an SRV [22] record of
_jabber._tcp.server. If the SRV lookup fails, the fallback is a _jabber._tcp.server. If the SRV lookup fails, the fallback is a
normal A lookup to determine the IP address, using the jabber-server normal A lookup to determine the IP address, using the jabber-server
port of 5269 assigned by the Internet Assigned Numbers Authority [6]. port of 5269 assigned by the Internet Assigned Numbers Authority [6].
Note that the method used to generate and verify the keys used in the Note that the method used to generate and verify the keys used in the
dialback protocol MUST take into account the hostnames being used, dialback protocol MUST take into account the hostnames being used,
along with a secret known only by the receiving server and the random along with a secret known only by the receiving server and the random
ID per stream. Generating unique but verifiable keys is important to ID generated for the stream. Generating unique but verifiable keys
prevent common man-in-the-middle attacks and server spoofing. is important to prevent common man-in-the-middle attacks and server
spoofing.
In the description that follows we use the following terminology: In the description that follows we use the following terminology:
o Originating Server -- the server that is attempting to establish a o Originating Server -- the server that is attempting to establish a
connection between the two servers connection between the two servers
o Receiving Server -- the server that is trying to authenticate that o Receiving Server -- the server that is trying to authenticate that
the Originating Server represents the Jabber server which it Originating Server represents the Jabber server which it claims to
claims to be be
o Authoritative Server -- the server which is given when a DNS o Authoritative Server -- the server that is given when a DNS lookup
lookup is performed on the name that the Originating Server is performed on the name that Originating Server initially gave;
initially gave; for simple environments this will be the for basic environments this will be Originating Server, but it
Originating Server, but it could be a separate machine in the could be a separate machine in Originating Server's network
Originating Server's network
The following is a brief summary of the order of events in dialback: The following is a brief summary of the order of events in dialback:
1. Originating Server establishes a connection to Receiving Server. 1. Originating Server establishes a connection to Receiving Server.
2. Originating Server sends a 'key' value over the connection to 2. Originating Server sends a 'key' value over the connection to
Receiving Server. Receiving Server.
3. Receiving Server establishes a connection to Authoritative 3. Receiving Server establishes a connection to Authoritative
Server. Server.
skipping to change at page 20, line 30 skipping to change at page 20, line 17
| | Authoritative | | Authoritative
| send dialback key | Server | send dialback key | Server
| ----------------------> | ------------- | ----------------------> | -------------
| | | | | |
| establish connection | | establish connection |
| ----------------------> | | ----------------------> |
| | | |
| send stream header | | send stream header |
| ----------------------> | | ----------------------> |
| | | |
| establish connection |
| <---------------------- |
| |
| send stream header | | send stream header |
| <---------------------- | | <---------------------- |
| | | |
| send dialback key | | send dialback key |
| ----------------------> | | ----------------------> |
| | | |
| validate dialback key | | validate dialback key |
| <---------------------- | | <---------------------- |
| |
| report dialback result | | report dialback result |
| <---------------------- | | <---------------------- |
| | | |
5.2.1 Dialback Protocol 5.2.1 Dialback Protocol
The traffic sent between the servers is as follows: The traffic sent between the servers is as follows:
1. Originating Server establishes connection to Receiving Server 1. Originating Server establishes TCP connection to Receiving
Server
2. Originating Server sends a stream header to Receiving Server 2. Originating Server sends a stream header to Receiving Server
(the 'to' and 'from' attributes are NOT REQUIRED on the root (the 'to' and 'from' attributes are NOT REQUIRED on the root
stream element): stream element):
<stream:stream <stream:stream
xmlns:stream='http://etherx.jabber.org/streams' xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server' xmlns='jabber:server'
xmlns:db='jabber:server:dialback'> xmlns:db='jabber:server:dialback'>
Note: the value of the xmlns:db namespace declaration indicates Note: the value of the xmlns:db namespace declaration indicates
to Receiving Server that the Originating Server supports to Receiving Server that Originating Server supports dialback.
dialback.
3. Receiving Server sends a stream header back to Originating 3. Receiving Server sends a stream header back to Originating
Server (the 'to' and 'from' attributes are NOT REQUIRED on the Server (the 'to' and 'from' attributes are NOT REQUIRED on the
root stream element): root stream element):
<stream:stream <stream:stream
xmlns:stream='http://etherx.jabber.org/streams' xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server' xmlns='jabber:server'
xmlns:db='jabber:server:dialback' xmlns:db='jabber:server:dialback'
id='457F9224A0...'> id='457F9224A0...'>
4. Originating Server sends a dialback key to Receiving Server: 4. Originating Server sends a dialback key to Receiving Server:
<db:result <db:result
to='Receiving Server' to='Receiving Server'
from='Originating Server'> from='Originating Server'>
98AF014EDC0... 98AF014EDC0...
</db:result> </db:result>
Note: this key is not examined by Receiving Server, since the Note: this key is not examined by Receiving Server, since
Receiving Server does not keep information about Originating Receiving Server does not keep information about Originating
Server between sessions. Server between sessions.
5. Receiving Server now establishes a connection back to 5. Receiving Server now establishes a connection back to
Originating Server, getting the Authoritative Server. Originating Server, getting Authoritative Server.
6. Receiving Server sends Authoritative Server a stream header (the 6. Receiving Server sends Authoritative Server a stream header (the
'to' and 'from' attributes are NOT REQUIRED on the root stream 'to' and 'from' attributes are NOT REQUIRED on the root stream
element): element):
<stream:stream <stream:stream
xmlns:stream='http://etherx.jabber.org/streams' xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server' xmlns='jabber:server'
xmlns:db='jabber:server:dialback'> xmlns:db='jabber:server:dialback'>
skipping to change at page 23, line 12 skipping to change at page 22, line 45
10. Receiving Server informs Originating Server of the result: 10. Receiving Server informs Originating Server of the result:
<db:result <db:result
from='Receiving Server' from='Receiving Server'
to='Originating Server' to='Originating Server'
type='valid'/> type='valid'/>
Note: At this point the connection has either been validated via Note: At this point the connection has either been validated via
a type='valid', or reported as invalid. Once the connection is a type='valid', or reported as invalid. Once the connection is
validated, data can be sent by the Originating Server and read validated, data can be sent by Originating Server and read by
by the Receiving Server; before that, all data stanzas sent to Receiving Server; before that, all data stanzas sent to
Receiving Server SHOULD be dropped. As a final guard against Receiving Server SHOULD be dropped. As a final guard against
domain spoofing, the Receiving Server MUST verify that all XML domain spoofing, Receiving Server MUST verify that all XML
stanzas received from the Originating Server include a 'from' stanzas received from Originating Server include a 'from'
attribute and that the value of that attribute includes the attribute and that the value of that attribute includes the
validated domain. In addition, all XML stanzas MUST include a validated domain. In addition, all XML stanzas MUST include a
'to' attribute. 'to' attribute.
6. Stream Encryption 6. Stream Encryption
6.1 Overview 6.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 method makes use of the Transport Layer Security eavesdropping. This channel encryption method makes use of the
(TLS) [7] protocol, along with a "STARTTLS" extension that is Transport Layer Security (TLS) [16] protocol, along with a "STARTTLS"
modelled on similar extensions for the IMAP [8], POP3 [9], and ACAP extension that is modelled on similar extensions for the IMAP [17],
[10] protocols as described in RFC 2595 [11]. 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. If an entity (client, server or www.ietf.org/rfc/rfc2595.txt'. If an entity (client or server) is
service) is capable of using this extension, it MUST include the capable of using this extension, it MUST include the <starttls/>
<starttls/> element in this namespace with the list of features that element in this namespace with the list of features that it sends in
it sends in response to the opening stream tag that was used to response to the opening stream tag that was used to initiate
initiate communications. communications.
The following example shows the use of STARTTLS by a client to secure The following example shows the use of STARTTLS by a client to secure
a session with a server, for wich the steps involved are as follows: a session with a server, for which the steps involved are as follows:
1. The client initiates the stream by sending the opening XML stream 1. The client opens a TCP connection and initiates the stream by
header to the server. sending the opening XML stream header to the server.
2. The server responds by sending an XML stream header to the 2. The server responds by opening a TCP connection and sending an
client. XML stream header to the client.
3. The server offers the STARTTLS extension to the client by 3. The server offers the STARTTLS extension to the client by
including it in the list of supported stream features. including it in the list of supported stream features.
4. The client issues the STARTTLS command to instruct the server 4. The client issues the STARTTLS command to instruct the server
that it wishes to begin a TLS negotiation to secure the stream. that it wishes to begin a TLS negotiation to secure the stream.
5. The server closes the XML stream, but keeps the underlying 5. The server closes the XML stream, but keeps the underlying TCP
connection open. If the server is unable to prepare for the TLS connection open. If the server is unable to prepare for the TLS
negotiation for some reason, it returns an error. negotiation for some reason, it returns an error.
6. The client begins a TLS negotiation according to RFC 2246 [7]. 6. The client begins a TLS negotiation according to RFC 2246 [16].
Upon completion of the negotiation, the client initiates a new Upon completion of the negotiation, the client initiates a new
stream by sending a new opening XML stream header to the server. stream by sending a new opening XML stream header to the server.
7. The server responds by sending an XML stream header to the 7. The server responds by sending an XML stream header to the
client. client.
Once the stream is secured, the server MUST NOT offer the STARTTLS Once the stream is secured, the server MUST NOT offer the STARTTLS
extension to the client. extension to the client.
6.2 Protocol Example 6.2 Client-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
stream using STARTTLS. stream using STARTTLS.
Step 1: Client initiates stream to server: Step 1: Client initiates stream to server:
<stream:stream <stream:stream
xmlns='jabber:client' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams' xmlns:stream='http://etherx.jabber.org/streams'
to='capulet.com' to='capulet.com'
skipping to change at page 26, line 5 skipping to change at page 25, line 5
<starttls xmlns='http://www.ietf.org/rfc/rfc2595.txt'/> <starttls xmlns='http://www.ietf.org/rfc/rfc2595.txt'/>
Step 5: Server closes the stream: Step 5: Server closes the stream:
</stream:stream> </stream:stream>
Step 5 (alt): Server fails to prepare for the TLS negotiation: Step 5 (alt): Server fails to prepare for the TLS negotiation:
<error xmlns='http://www.ietf.org/rfc/rfc2595.txt'/> <error xmlns='http://www.ietf.org/rfc/rfc2595.txt'/>
Step 6: Client begins TLS negotiation. When it has finished, it Step 6: Client begins TLS negotiation. When it has finished, it
initiates a new stream to the server:: initiates a new stream to the server:
<stream:stream <stream:stream
xmlns='jabber:client' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams' xmlns:stream='http://etherx.jabber.org/streams'
to='capulet.com' to='capulet.com'
version='1.0'> version='1.0'>
<stream:features>
<mechanisms xmlns='http://www.iana.org/assignments/sasl-mechanisms'>
<mechanism>DIGEST-MD5</mechanism>
<mechanism>PLAIN</mechanism>
<mechanism>EXTERNAL</mechanism>
</mechanisms>
</stream:features>
Step 7: Server responds by sending a stream tag to the client: Step 7: Server responds by sending a stream tag to the client:
<stream:stream <stream:stream
xmlns='jabber:client' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams' xmlns:stream='http://etherx.jabber.org/streams'
id='12345678' id='12345678'
version='1.0'> version='1.0'>
<stream:features>
<mechanisms xmlns='http://www.iana.org/assignments/sasl-mechanisms'>
<mechanism>DIGEST-MD5</mechanism>
<mechanism>PLAIN</mechanism>
<mechanism>EXTERNAL</mechanism>
</mechanisms>
</stream:features>
6.3 Certificate-Based Authentication 6.3 Certificate-Based Authentication
If the client presents a valid client certificate during the TLS If the client presents a valid client certificate during the TLS
negotiation, the server MAY offer the SASL EXTERNAL mechanism to the negotiation, the server MAY offer the SASL EXTERNAL mechanism to the
client (see RFC 2222 [12]). If the client selects this mechanism for client (see RFC 2222 [15]). If the client selects this mechanism for
authentication, the authentication credentials shall be taken from authentication, the authentication credentials shall be taken from
the presented certificate. the presented certificate.
7. XML Stanzas 7. XML Stanzas
7.1 Overview 7.1 Overview
There are three core data elements for XMPP communications: <message/ Once the XML streams in each direction have been authenticated and
>, <presence/>, and <iq/>. These elements are sent as direct (if desired) encrypted, XML stanzas can be sent over the streams.
(depth=1) children of the root <stream/> element and are scoped by XML stanzas are the three core data elements for XMPP communications:
one of the default namespaces identified in Section 4.4. Any such <message/>, <presence/>, and <iq/>. These elements are sent as
direct child element of the root stream element is called an "XML direct (depth=1) children of the root <stream/> element and are
stanza". scoped by one of the default namespaces identified in Section 4.4.
7.2 Common Attributes 7.2 Common Attributes
Four attributes are common to message, presence, and IQ stanzas. Five attributes are common to message, presence, and IQ stanzas.
These are defined below. These are defined below.
7.2.1 to 7.2.1 to
The 'to' attribute specifies the JID of the intended recipient for The 'to' attribute specifies the JID of the intended recipient for
the stanza. In the 'jabber:client' namespace, a stanza SHOULD the stanza. In the 'jabber:client' namespace, a stanza SHOULD
possess a 'to' attribute, although a stanza sent from a client to a possess a 'to' attribute, although a stanza sent from a client to a
server for handling by that server (e.g., presence sent to the server server for handling by that server (e.g., presence sent to the server
for broadcasting to other entities) MAY legitimately lack a 'to' for broadcasting to other entities) MAY legitimately lack a 'to'
attribute. In the 'jabber:server' namespace, a stanza MUST possess a attribute. In the 'jabber:server' namespace, a stanza MUST possess a
skipping to change at page 27, line 41 skipping to change at page 26, line 41
7.2.2 from 7.2.2 from
The 'from' attribute specifies the JID of the sender. The 'from' attribute specifies the JID of the sender.
In the 'jabber:client' namespace, a client MUST NOT include a 'from' In the 'jabber:client' namespace, a client MUST NOT include a 'from'
attribute on the stanzas it sends to a server; if a server receives a attribute on the stanzas it sends to a server; if a server receives a
stanza from a client and the stanza possesses a 'from' attribute, it stanza from a client and the stanza possesses a 'from' attribute, it
MUST ignore the value of the 'from' attribute. In addition, a server MUST ignore the value of the 'from' attribute. In addition, a server
MUST stamp stanzas received from a client with the user@domain/ MUST stamp stanzas received from a client with the user@domain/
resource (full JID) of the connected resource that generated the resource (full JID) of the connected resource that generated the
stanza. In the 'jabber:server' namespace, a stanza MUST possess a stanza.
'from' attribute.
A server MUST include a 'from' attribute on stanzas it routes to In the 'jabber:server' namespace, a stanza MUST possess a 'from'
other servers. The domain identifier of the JID contained in the attribute. In particular, a server MUST include a 'from' attribute
'from' attribute MUST match the hostname of the server as on stanzas it routes to other servers. The domain identifier of the
communicated in the dialback negotiation (or a subdomain thereof). JID contained in the 'from' attribute MUST match the hostname of the
server as communicated in the dialback negotiation (or a subdomain
thereof).
7.2.3 id 7.2.3 id
The optional 'id' attribute MAY be used to track stanzas sent and The optional 'id' attribute MAY be used to track stanzas sent and
received. The 'id' attribute is generated by the sender. An 'id' received. The 'id' attribute is generated by the sender. An 'id'
attribute included in an IQ request of type "get" or "set" SHOULD be attribute included in an IQ request of type "get" or "set" SHOULD be
returned to the sender in any IQ response of type "result" or "error" returned to the sender in any IQ response of type "result" or "error"
generated by the recipient of the request. A recipient of a message generated by the recipient of the request. A recipient of a message
or presence stanza MAY return that 'id' in any replies, but is NOT or presence stanza MAY return that 'id' in any replies, but is NOT
REQUIRED to do so. REQUIRED to do so.
skipping to change at page 28, line 30 skipping to change at page 27, line 31
the stanza is a message, presence, or IQ, and thus are specified in the stanza is a message, presence, or IQ, and thus are specified in
the following sections. the following sections.
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 a NMTOKEN and MUST conform to the the 'xml:lang' attribute MUST be an NMTOKEN and MUST conform to the
format defined in RFC 3066 [17]. format defined in RFC 3066 [21].
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 29, line 15 skipping to change at page 28, line 16
o groupchat -- The message is sent in the context of a multi-user o groupchat -- The message is sent in the context of a multi-user
chat environment. chat environment.
o headline -- The message is generated by an automated service that o headline -- The message is generated by an automated service that
delivers content (news, sports, market information, etc.). delivers content (news, sports, market information, etc.).
o error - A message returned to a sender specifying an error o error - A message returned to a sender specifying an error
associated with a previous message sent by the sender (for a full associated with a previous message sent by the sender (for a full
list of error messages, see error codes (Appendix A)) list of error messages, see error codes (Appendix A))
For detailed information about these message types, refer to XMPP IM For detailed information about the meaning of these message types,
[2]. refer to XMPP IM [2].
7.3.2 Children 7.3.2 Children
If a message stanza in the 'jabber:client' or 'jabber:server' If a message stanza in the 'jabber:client' or 'jabber:server'
namespace has no 'type' attribute or has a 'type' attribute with a namespace has no 'type' attribute or has a 'type' attribute with a
value of "chat", "groupchat", or "headline", it MAY contain any of value of "chat", "groupchat", or "headline", it MAY contain any of
the following child elements (which MUST NOT contain mixed content): the following child elements (which MUST NOT contain mixed content):
o body -- The textual contents of the message; normally included but o body -- The textual contents of the message; normally included but
NOT REQUIRED. The <body/> element MUST NOT possess any NOT REQUIRED. The <body/> element MUST NOT possess any
skipping to change at page 29, line 46 skipping to change at page 28, line 47
versions of the same subject, but only if each instance possesses versions of the same subject, but only if each instance possesses
an 'xml:lang' attribute with a distinct language value. an 'xml:lang' attribute with a distinct language value.
o thread -- A random string that is generated by the sender and that o thread -- A random string that is generated by the sender and that
MAY be copied back in replies; it is used for tracking a MAY be copied back in replies; it is used for tracking a
conversation thread (sometimes referred to as an "IM session") conversation thread (sometimes referred to as an "IM session")
between two entities. If used, it MUST be unique to that between two entities. If used, it MUST be unique to that
conversation thread within the stream and MUST be consistent conversation thread within the stream and MUST be consistent
throughout that conversation. The use of the <thread/> element is throughout that conversation. The use of the <thread/> element is
optional and is not used to identify individual messages, only optional and is not used to identify individual messages, only
conversations. The recommended method for generating thread IDs conversations. The method for generating thread IDs SHOULD be as
is to concatenate the sender's full JID, the recipient's full JID, follows: (1) concatenate the sender's full JID (user@host/
and an absolute date and time, then hash the resulting string resource) with the recipient's full JID; (2) concatenate these JID
according to the SHA1 algorithm. Only one <thread/> element MAY strings with a full ISO-8601 timestamp including year, month, day,
be included in a message stanza, and it MUST NOT possess any hours, minutes, seconds, and UTC offset if appropriate in the
attributes. The <thread/> element MUST be treated as an opaque following format: yyyy-mm-dd-Thh:mm:ss-hh:mm; (3) hash the
string by entities; no semantic meaning may be derived from it, resulting string according to the SHA1 algorithm; (4) convert the
and only exact, case insensitve comparisons can be made against hexidecimal SHA1 output to all lowercase. Only one <thread/>
it. element MAY be included in a message stanza, and it MUST NOT
possess any attributes. The <thread/> element MUST be treated as
an opaque string by entities; no semantic meaning may be derived
from it, and only exact, case-insensitve comparisons can be made
against it.
If the message stanza is of type "error", it MUST include an <error/> If the message stanza is of type "error", it MUST include an <error/>
child, which in turn MUST possess a 'code' attribute corresponding to child, which in turn MUST possess a 'code' attribute corresponding to
one of the standard error codes (Appendix A), MAY possess an one of the standard error codes (Appendix A), MAY possess an
'xml:lang' attribute, and MAY also contain PCDATA corresponding to a 'xml:lang' attribute, and MAY also contain PCDATA corresponding to a
natural-language description of the error. An <error/> child MUST natural-language description of the error. An <error/> child MUST
NOT be included if the stanza type is anything other than "error". NOT be included if the stanza type is anything other than "error".
An entity that receives a message stanza of type 'error' MUST NOT
respond to the stanza by sending a further message stanza of type
'error'; this helps to prevent looping.
As described under extended namespaces (Section 7.6), a message As described under extended namespaces (Section 7.6), a message
stanza MAY also contain any properly-namespaced child element (other stanza MAY also contain any properly-namespaced child element (other
than the core data elements, stream elements, or defined children than the core data elements, stream elements, or defined children
thereof). thereof).
7.4 Presence Stanzas 7.4 Presence Stanzas
Presence stanzas are used in the 'jabber:client' or 'jabber:server' Presence stanzas are used in the 'jabber:client' or 'jabber:server'
namespace to express an entity's current availability status (offline namespace to express an entity's current availability status (offline
or online, along with various sub-states of the latter) and to or online, along with various sub-states of the latter and optional
communicate that status to other entities. They are also used to user-defined descriptive tex and optional user-defined descriptive
negotiate and manage subscriptions to the presence of other entities. textt) and to communicate that status to other entities. They are
also used to negotiate and manage subscriptions to the presence of
other entities.
7.4.1 Types of Presence 7.4.1 Types of Presence
The 'type' attribute of a presence stanza is optional. A presence The 'type' attribute of a presence stanza is optional. A presence
stanza that does not have a 'type' attribute is used to signal that stanza that does not have a 'type' attribute is used to signal to the
the sender is online and available for communication. If included, server that the sender is online and available for communication. If
the 'type' attribute specifies the availability state of the sender, included, the 'type' attribute specifies the availability state of
a request to manage a subscription to another entity's presence, a the sender, a request to manage a subscription to another entity's
request for another entity's current presence, or an error related to presence, a request for another entity's current presence, or an
a previously-sent presence stanza. The 'type' attribute MAY have one error related to a previously-sent presence stanza. The 'type'
of the following values: attribute MAY have one of the following values:
o unavailable -- Signals that the entity is no longer available for o unavailable -- Signals that the entity is no longer available for
communication. communication.
o subscribe -- The sender wishes to subscribe to the recipient's o subscribe -- The sender wishes to subscribe to the recipient's
presence. presence.
o subscribed -- The sender has allowed the recipient to receive o subscribed -- The sender has allowed the recipient to receive
their presence. their presence.
skipping to change at page 32, line 8 skipping to change at page 31, line 20
o priority -- An optional element specifying the priority level of o priority -- An optional element specifying the priority level of
the connected resource. The value may be any integer between -128 the connected resource. The value may be any integer between -128
to 127. Only one <priority/> element MAY be included in a to 127. Only one <priority/> element MAY be included in a
presence stanza, and it MUST NOT possess any attributes. presence stanza, and it MUST NOT possess any attributes.
If the presence stanza is of type "error", it MUST include an <error/ If the presence stanza is of type "error", it MUST include an <error/
> child, which in turn MUST possess a 'code' attribute corresponding > child, which in turn MUST possess a 'code' attribute corresponding
to one of the standard error codes (Appendix A) and MAY contain to one of the standard error codes (Appendix A) and MAY contain
PCDATA corresponding to a natural-language description of the error. PCDATA corresponding to a natural-language description of the error.
An <error/> child MUST NOT be included if the stanza type is anything An <error/> child MUST NOT be included if the stanza type is anything
other than "error". other than "error". An entity that receives a presence stanza of
type 'error' MUST NOT respond to the stanza by sending a further
presence stanza of type 'error'; this helps to prevent looping.
As described under extended namespaces (Section 7.6), a presence As described under extended namespaces (Section 7.6), a presence
stanza MAY also contain any properly-namespaced child element (other stanza MAY also contain any properly-namespaced child element (other
than the core data elements, stream elements, or defined children than the core data elements, stream elements, or defined children
thereof). thereof).
7.5 IQ Stanzas 7.5 IQ Stanzas
7.5.1 Overview 7.5.1 Overview
Info/Query, or IQ, is a simple request-response mechanism. Just as Info/Query, or IQ, is a request-response mechanism. Just as HTTP is
HTTP is a request-response medium, so IQ stanzas in the a request-response medium, so IQ stanzas in the 'jabber:client' or
'jabber:client' or 'jabber:server' namespace enable an entity to make 'jabber:server' namespace enable an entity to make a request of, and
a request of, and receive a response from, another entity. The data receive a response from, another entity. The data content of the
content of the request and response is defined by the namespace request and response is defined by the namespace declaration of a
declaration of a direct child element of the IQ element, and the direct child element of the IQ element, and the interaction is
interaction is tracked by the requesting entity through use of the tracked by the requesting entity through use of the 'id' attribute,
'id' attribute, which responding entities SHOULD return in any which responding entities SHOULD return in any response.
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):
Requesting Responding Requesting Responding
Entity Entity Entity Entity
---------- ---------- ---------- ----------
| | | |
| <iq type='get' id='1'> | | <iq type='get' id='1'> |
skipping to change at page 33, line 43 skipping to change at page 33, line 19
namespace. As described under extended namespaces (Section 7.6), an namespace. As described under extended namespaces (Section 7.6), an
IQ stanza MAY contain any properly-namespaced child element (other IQ stanza MAY contain any properly-namespaced child element (other
than the core data elements, stream elements, or defined children than the core data elements, stream elements, or defined children
thereof). thereof).
If the IQ stanza is of type "error", it MUST include an <error/> If the IQ stanza is of type "error", it MUST include an <error/>
child, which in turn MUST possess a 'code' attribute corresponding to child, which in turn MUST possess a 'code' attribute corresponding to
one of the standard error codes (Appendix A) and MAY contain PCDATA one of the standard error codes (Appendix A) and MAY contain PCDATA
corresponding to a natural-language description of the error. An corresponding to a natural-language description of the error. An
<error/> child MUST NOT be included if the stanza type is anything <error/> child MUST NOT be included if the stanza type is anything
other than "error". other than "error". An entity that receives an IQ stanza of type
'error' MUST NOT respond to the stanza by sending a further IQ stanza
of type 'error'; this helps to prevent looping.
7.6 Extended Namespaces 7.6 Extended Namespaces
While the core data elements defined in this document provide a basic While the core data elements defined in this document provide a basic
level of functionality for messaging and presence, XMPP uses XML level of functionality for messaging and presence, XMPP uses XML
namespaces to extend the core data elements for the purpose of namespaces to extend the core data elements for the purpose of
providing additional functionality. Thus a message, presence, or IQ providing additional functionality. Thus a message, presence, or IQ
stanza MAY house one or more optional child elements containing stanza MAY house one or more optional child elements containing
content that extends the meaning of the message (e.g., an encrypted content that extends the meaning of the message (e.g., an encrypted
form of the message body). This child element MAY be any element form of the message body). This child element MAY be any element
skipping to change at page 34, line 25 skipping to change at page 33, line 50
namespace, it MUST ignore the associated XML data (if the stanza is namespace, it MUST ignore the associated XML data (if the stanza is
being routed on to another entity, ignore means "pass it on being routed on to another entity, ignore means "pass it on
untouched"). If an entity receives an IQ stanza in a namespace it untouched"). If an entity receives an IQ stanza in a namespace it
does not understand, the entity SHOULD return an IQ stanza of type does not understand, the entity SHOULD return an IQ stanza of type
"error" with an error element of code 400 (bad request). If an "error" with an error element of code 400 (bad request). If an
entity receives a message or presence stanza that contains XML data entity receives a message or presence stanza that contains XML data
in an extended namespace it does not understand, the portion of the in an extended namespace it does not understand, the portion of the
stanza that is in the unknown namespace SHOULD be ignored. If an stanza that is in the unknown namespace SHOULD be ignored. If an
entity receives a message stanza without a <body/> element but entity receives a message stanza without a <body/> element but
containing only a child element bound by a namespace it does not containing only a child element bound by a namespace it does not
understand, it MUST ignore that stanza. understand, it MUST ignore the entire stanza.
8. XML Usage within XMPP 8. XML Usage within XMPP
8.1 Overview 8.1 Namespaces
In essence, XMPP core consists of three interrelated parts:
1. XML streams (Section 4), which provide a stateful means for
transporting data in an asynchronous manner from one entity to
another
2. stream authentication using SASL authentication (Section 5.1) or
the dialback protocol (Section 5.2)
3. XML stanzas (Section 7) (message, presence, and IQ), which
provide a framework for communications between entities
XML [1] is used to define each of these protocols, as described in
detail in the following sections.
In addition, XMPP contains protocol extensions (such as extended
namespaces) that address the specific functionality required to
create a basic instant messaging and presence application; these non-
core protocol extensions are defined in XMPP IM [2].
8.2 Namespaces
XML Namespaces [16] are used within all XMPP-compliant XML to create 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. Mainly for historical reasons, the default data element within XMPP. Mainly for historical reasons, the default
namespace for XMPP data stanzas MUST be one of the namespaces namespace for XMPP data stanzas MUST be one of the namespaces
identified in Section 4.4. identified in Section 4.4.
Additionally, XMPP is more strict about namespace prefixes than the Additionally, XMPP is more strict about namespace prefixes than the
XML namespace specification requires. XML namespace specification requires.
8.3 Validation 8.2 Validation
A server is not responsible for validating the XML elements forwarded A server is not responsible for validating the XML elements forwarded
to a client; an implementation MAY choose to provide only validated to a client; an implementation MAY choose to provide only validated
data elements but is NOT REQUIRED to do so. Clients SHOULD NOT rely data elements but is NOT REQUIRED to do so. Clients SHOULD NOT rely
on the ability to send data which does not conform to the schemas, on the ability to send data which does not conform to the schemas,
and SHOULD ignore any non-conformant elements or attributes on the and SHOULD ignore any non-conformant elements or attributes on the
incoming XML stream. Validation of XML streams and stanzas is NOT incoming XML stream. Validation of XML streams and stanzas is NOT
REQUIRED or recommended, and DTDs and schemas are included herein for REQUIRED or recommended, and DTDs and schemas are included herein for
descriptive purposes only. descriptive purposes only.
8.4 Character Encodings 8.3 Character Encodings
Software implementing XML streams MUST support the UTF-8 (RFC 2279 Software implementing XML streams MUST support the UTF-8 (RFC 2279
[20]) and UTF-16 (RFC 2781 [21]) transformations of Universal [24]) and UTF-16 (RFC 2781 [25]) transformations of Universal
Character Set (ISO/IEC 10646-1 [22]) characters. Software MUST NOT Character Set (ISO/IEC 10646-1 [26]) 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 transmit and receive 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.5 Inclusion of Text Declaration 8.4 Inclusion of Text Declaration
An application MAY send a text declaration. Applications MUST follow An application MAY send a text declaration. Applications MUST follow
the rules in the XML specification [1] concerning the circumstances the rules in the XML specification [1] regarding the circumstances in
in which a text declaration is included. which a text declaration is included.
9. IANA Considerations 9. IANA Considerations
The IANA registers "jabber-client" and "jabber-server" as GSS-API The IANA registers "jabber-client" and "jabber-server" as service
[23] service names, as specified in Section 6.1.1; these service names associated with TCP ports 5222 and 5269 respectively.
names are associated with TCP ports 5222 and 5269 respectively.
10. Internationalization Considerations 10. Internationalization Considerations
o If a client sends an xml:lang attribute on a stanza, the server Usage of the 'xml:lang' attribute is described above. If a client
MUST NOT modify or delete it. includes an 'xml:lang' attribute in a stanza, the server MUST NOT
modify or delete it.
11. Security Considerations 11. Security Considerations
11.1 Client-to-Server Communications 11.1 Client-to-Server Communications
The SASL protocol for authenticating XML streams negotiated between a The SASL protocol for authenticating XML streams negotiated between a
client and a server (defined under Section 5.1 above) provides a client and a server (defined under Section 5.1 above) provides a
reliable mechanism for validating that a client connecting to a reliable mechanism for validating that a client connecting to a
server is who it claims to be. server is who it claims to be.
The IP address and method of access of clients MUST NOT be made The IP address and method of access of clients MUST NOT be made
available by a server, nor are any connections other than the available by a server, nor are any connections other than the
original server connection required. This helps protect the client's original server connection required. This helps protect the client's
server from direct attack or identification by third parties. server from direct attack or identification by third parties.
End-to-end encryption of message bodies and presence status End-to-end encryption of message bodies and presence status
information MAY be effected through use of OpenPGP [19]. information MAY be effected through use of the methods defined in
End-to-End Object Encryption in XMPP [27].
11.2 Server-to-Server Communications 11.2 Server-to-Server Communications
It is OPTIONAL for any given server to communicate with other It is OPTIONAL for any given server to communicate with other
servers, and server-to-server communications MAY be disabled by the servers, and server-to-server communications MAY be disabled by the
administrator of any given deployment. administrator of any given deployment.
If two servers would like to enable communications between If two servers would like to enable communications between
themselves, they MUST form a relationship of trust at some level, themselves, they MUST form a relationship of trust at some level,
either based on trust in DNS or based on a pre-existing trust either based on trust in DNS or based on a pre-existing trust
skipping to change at page 41, line 11 skipping to change at page 39, line 11
with the IANA [6]. Use of these well-known ports allows with the IANA [6]. Use of these well-known ports allows
administrators to easily enable or disable XMPP activity through administrators to easily enable or disable XMPP activity through
existing and commonly-deployed firewalls. existing and commonly-deployed firewalls.
References References
[1] World Wide Web Consortium, "Extensible Markup Language (XML) [1] World Wide Web Consortium, "Extensible Markup Language (XML)
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] Miller, J. and P. Saint-Andre, "XMPP Instant Messaging (draft- [2] Saint-Andre, P. and J. Miller, "XMPP Instant Messaging (draft-
ietf-xmpp-im-00, work in progress)", December 2002. ietf-xmpp-im-02, work in progress)", February 2003.
[3] 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>.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[5] University of Southern California, "Transmission Control [5] University of Southern California, "Transmission Control
Protocol", RFC 793, September 1981, <http://www.ietf.org/rfc/ Protocol", RFC 793, September 1981, <http://www.ietf.org/rfc/
rfc0793.txt>. rfc0793.txt>.
[6] Internet Assigned Numbers Authority, "Internet Assigned Numbers [6] Internet Assigned Numbers Authority, "Internet Assigned Numbers
Authority", January 1998, <http://www.iana.org/>. Authority", January 1998, <http://www.iana.org/>.
[7] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and [7] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1999. 1998, <http://www.ietf.org/rfc/rfc2396.txt>.
[8] Crispin, M., "Internet Message Access Protocol - Version [8] Harrenstien, K., Stahl, M. and E. Feinler, "DoD Internet host
4rev1", RFC 2060, December 1996. table specification", RFC 952, October 1985.
[9] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD [9] Braden, R., "Requirements for Internet Hosts - Application and
53, RFC 1939, May 1996. Support", STD 3, RFC 1123, October 1989.
[10] Newman, C. and J. Myers, "ACAP -- Application Configuration [10] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile
Access Protocol", RFC 2244, November 1997. for Internationalized Domain Names (draft-ietf-idn-nameprep-11,
work in progress)", June 2002.
[11] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, [11] Hoffman, P. and M. Blanchet, "Preparation of Internationalized
June 1999. Strings ("stringprep")", RFC 3454, December 2002.
[12] Myers, J., "Simple Authentication and Security Layer (SASL)", [12] Saint-Andre, P. and J. Hildebrand, "Nodeprep: A Stringprep
Profile for Node Identifiers in XMPP (draft-ietf-xmpp-nodeprep-
00, work in progress)", February 2003.
[13] Saint-Andre, P. and J. Hildebrand, "Resourceprep: A Stringprep
Profile for Resource Identifiers in XMPP (draft-ietf-xmpp-
resourceprep-00, work in progress)", February 2003.
[14] World Wide Web Consortium, "Namespaces in XML", W3C xml-names,
January 1999, <http://www.w3.org/TR/1999/REC-xml-names-
19990114/>.
[15] Myers, J., "Simple Authentication and Security Layer (SASL)",
RFC 2222, October 1997. RFC 2222, October 1997.
[13] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform [16] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and
Resource Identifiers (URI): Generic Syntax", RFC 2396, August P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January
1998, <http://www.ietf.org/rfc/rfc2396.txt>. 1999.
[14] Harrenstien, K., Stahl, M. and E. Feinler, "DoD Internet host [17] Crispin, M., "Internet Message Access Protocol - Version
table specification", RFC 952, October 1985. 4rev1", RFC 2060, December 1996.
[15] Braden, R., "Requirements for Internet Hosts - Application and [18] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD
Support", STD 3, RFC 1123, October 1989. 53, RFC 1939, May 1996.
[16] World Wide Web Consortium, "Namespaces in XML", W3C xml-names, [19] Newman, C. and J. Myers, "ACAP -- Application Configuration
January 1999, <http://www.w3.org/TR/1999/REC-xml-names- Access Protocol", RFC 2244, November 1997.
19990114/>.
[17] Alvestrand, H., "Tags for the Identification of Languages", BCP [20] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595,
June 1999.
[21] Alvestrand, H., "Tags for the Identification of Languages", BCP
47, RFC 3066, January 2001. 47, RFC 3066, January 2001.
[18] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the [22] 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.
[19] Elkins, M., Del Torto, D., Levien, R. and T. Roessler, "MIME [23] Elkins, M., Del Torto, D., Levien, R. and T. Roessler, "MIME
Security with OpenPGP", RFC 3156, August 2001. Security with OpenPGP", RFC 3156, August 2001.
[20] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC [24] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998. 2279, January 1998.
[21] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", [25] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646",
RFC 2781, February 2000. RFC 2781, February 2000.
[22] International Organization for Standardization, "Information [26] 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.
[23] Linn, J., "Generic Security Service Application Program [27] Saint-Andre, P. and J. Hildebrand, "End-to-End Object
Interface, Version 2", RFC 2078, January 1997. Encryption in XMPP (draft-ietf-xmpp-e2e-00, work in progress)",
February 2003.
Authors' Addresses Authors' Addresses
Jeremie Miller
Jabber Software Foundation
1899 Wynkoop Street, Suite 600
Denver, CO 80202
US
EMail: jeremie@jabber.org
URI: http://www.jabber.org/people/jer.php
Peter Saint-Andre Peter Saint-Andre
Jabber Software Foundation Jabber Software Foundation
1899 Wynkoop Street, Suite 600
Denver, CO 80202
US
EMail: stpeter@jabber.org EMail: stpeter@jabber.org
URI: http://www.jabber.org/people/stpeter.php URI: http://www.jabber.org/people/stpeter.php
Jeremie Miller
Jabber Software Foundation
EMail: jeremie@jabber.org
URI: http://www.jabber.org/people/jer.php
Appendix A. Standard Error Codes Appendix A. Standard Error Codes
A standard error element is used for failed processing of XML A standard error element is used for failed processing of XML
stanzas. This element is a child of the failed stanza and MUST stanzas. This element is a child of the failed stanza and MUST
include a 'code' attribute corresponding to one of the following include a 'code' attribute corresponding to one of the following
error codes. error codes.
o 302 (Redirect) - Whereas HTTP contains eight different codes for o 302 (Redirect) - Whereas HTTP contains eight different codes for
redirection, XMPP contains only one (which is intended to stand redirection, XMPP contains only one (which is intended to stand
for any redirection error). However, code 302 is being reserved for any redirection error). However, code 302 is being reserved
for future functionality and is not implemented at this time. for future functionality and is not implemented at this time.
o 400 (Bad Request) - Code 400 is used to inform a sender that a o 400 (Bad Request) - Code 400 is used to inform a sender that a
request could not be understood by the recipient. This might be request could not be understood by the recipient. This might be
generated when, for example, an entity sends a message that does generated when, for example, an entity sends a message that does
not have a 'to' attribute. not have a 'to' attribute.
o 401 (Unauthorized) - Code 401 is used to inform clients that they o 401 (Unauthorized) - Code 401 is used to inform clients that they
have provided incorrect authorization information, e.g., an have provided incorrect authorization information, e.g., an
incorrect password or unknown username when attempting to incorrect password or unknown username when attempting to
authenticate with a server. authenticate with a service.
o 402 (Payment Required) - Code 402 is being reserved for future o 402 (Payment Required) - Code 402 is being reserved for future
use. use.
o 403 (Forbidden) - Code 403 is used to inform an entity that the o 403 (Forbidden) - Code 403 is used to inform an entity that its
its request was understood but that the recipient is refusing to request was understood but that the recipient is refusing to
fulfill it, e.g., if a user attempts to set information associated fulfill it, e.g., if a user attempts to set information associated
with another user. with another user.
o 404 (Not Found) - Code 404 is used to inform a sender that no o 404 (Not Found) - Code 404 is used to inform a sender that no
recipient was found matching the JID to which an XML stanza was recipient was found matching the JID to which an XML stanza was
sent, e.g., if a sender has attempted to send a message to a JID sent, e.g., if a sender has attempted to send a message to a JID
that does not exist. (Note: if the server of the intended that does not exist. (Note: if the server of the intended
recipient cannot be reached, an error code from the 500 series recipient cannot be reached, an error code from the 500 series
must be sent). must be sent.)
o 405 (Not Allowed) - Code 405 is used when the action requested is o 405 (Not Allowed) - Code 405 is used when the action requested is
not allowed for the JID identified by the 'from' address, e.g., if not allowed for the JID identified by the 'from' address, e.g., if
a client attempts to set the time or version of a server. a client attempts to set the time or version of a server.
o 406 (Not Acceptable) - Code 406 is used when an XML stanza is for o 406 (Not Acceptable) - Code 406 is used when an XML stanza is for
some reason not acceptable to a server or other entity. This some reason not acceptable to a server or other entity. This
might be generated when, for example, a user attempts to register might be generated when, for example, a user attempts to register
with a server using an empty password. with a service using an empty password.
o 407 (Registration Required) - Code 407 is used when a message or o 407 (Registration Required) - Code 407 is used when a message or
request is sent to a service that requires prior registration, request is sent to a service that requires prior registration,
e.g., if a user attempts to send a message through a gateway to a e.g., if a user attempts to send a message through a gateway to a
foreign messaging system without having first registered with that foreign messaging system without having first registered with that
gateway. gateway.
o 408 (Request Timeout) - Code 408 is returned when a recipient does o 408 (Request Timeout) - Code 408 is returned when a recipient does
not produce a response within the time that the sender was not produce a response within the time that the sender was
prepared to wait. prepared to wait.
skipping to change at page 51, line 6 skipping to change at page 49, line 6
B.3.2 Schema B.3.2 Schema
<?xml version='1.0' encoding='UTF-8'?> <?xml version='1.0' encoding='UTF-8'?>
<xsd:schema <xsd:schema
xmlns:xsd='http://www.w3.org/2001/XMLSchema' xmlns:xsd='http://www.w3.org/2001/XMLSchema'
targetNamespace='http://www.jabber.org/protocol' targetNamespace='http://www.jabber.org/protocol'
xmlns='http://www.jabber.org/protocol' xmlns='http://www.jabber.org/protocol'
elementFormDefault='qualified'> elementFormDefault='qualified'>
<xsd:element name='message'> <xsd:element name='message'>
<xsd:complexType mixed='true'> <xsd:complexType mixed='true'>
<xsd:choice> <xsd:choice maxOccurs='unbounded'>
<xsd:element ref='body' minOccurs='0' maxOccurs='unbounded'/> <xsd:element ref='body' minOccurs='0' maxOccurs='unbounded'/>
<xsd:element ref='subject' minOccurs='0' maxOccurs='unbounded'/> <xsd:element ref='subject' minOccurs='0' maxOccurs='unbounded'/>
<xsd:element ref='thread' minOccurs='0' maxOccurs='1'/> <xsd:element ref='thread' minOccurs='0' maxOccurs='1'/>
<xsd:element ref='error' minOccurs='0' maxOccurs='1'/> <xsd:element ref='error' minOccurs='0' maxOccurs='1'/>
<xsd:any <xsd:any
namespace='##other' namespace='##other'
minOccurs='0' minOccurs='0'
maxOccurs='unbounded'/> maxOccurs='unbounded'/>
</xsd:choice> </xsd:choice>
<xsd:attribute name='to' type='xsd:string' use='optional'/> <xsd:attribute name='to' type='xsd:string' use='optional'/>
skipping to change at page 51, line 49 skipping to change at page 49, line 49
<xsd:element name='subject' type='xsd:string'> <xsd:element name='subject' type='xsd:string'>
<xsd:complexType> <xsd:complexType>
<xsd:attribute name='xml:lang' type='xsd:NMTOKEN' use='optional'/> <xsd:attribute name='xml:lang' type='xsd:NMTOKEN' use='optional'/>
</xsd:complexType> </xsd:complexType>
</xsd:element> </xsd:element>
<xsd:element name='thread' type='xsd:string'/> <xsd:element name='thread' type='xsd:string'/>
<xsd:element name='presence'> <xsd:element name='presence'>
<xsd:complexType> <xsd:complexType>
<xsd:choice> <xsd:choice maxOccurs='unbounded'>
<xsd:element ref='show' minOccurs='0' maxOccurs='1'/> <xsd:element ref='show' minOccurs='0' maxOccurs='1'/>
<xsd:element ref='status' minOccurs='0' maxOccurs='unbounded'/> <xsd:element ref='status' minOccurs='0' maxOccurs='unbounded'/>
<xsd:element ref='priority' minOccurs='0' maxOccurs='1'/> <xsd:element ref='priority' minOccurs='0' maxOccurs='1'/>
<xsd:element ref='error' minOccurs='0' maxOccurs='1'/> <xsd:element ref='error' minOccurs='0' maxOccurs='1'/>
<xsd:any <xsd:any
namespace='##other' namespace='##other'
minOccurs='0' minOccurs='0'
maxOccurs='unbounded'/> maxOccurs='unbounded'/>
</xsd:choice> </xsd:choice>
<xsd:attribute name='to' type='xsd:string' use='optional'/> <xsd:attribute name='to' type='xsd:string' use='optional'/>
skipping to change at page 52, line 47 skipping to change at page 50, line 47
</xsd:restriction> </xsd:restriction>
</xsd:simpleType> </xsd:simpleType>
</xsd:element> </xsd:element>
<xsd:element name='status' type='xsd:string'> <xsd:element name='status' type='xsd:string'>
<xsd:complexType> <xsd:complexType>
<xsd:attribute name='xml:lang' type='xsd:NMTOKEN' use='optional'/> <xsd:attribute name='xml:lang' type='xsd:NMTOKEN' use='optional'/>
</xsd:complexType> </xsd:complexType>
</xsd:element> </xsd:element>
<xsd:element name='priority' type='xsd:nonNegativeInteger'/> <xsd:element name='priority' type='xsd:byte'/>
<xsd:element name='iq'> <xsd:element name='iq'>
<xsd:complexType mixed='true'> <xsd:complexType mixed='true'>
<xsd:choice> <xsd:choice maxOccurs='unbounded'>
<xsd:element ref='error' minOccurs='0' maxOccurs='1'/> <xsd:element ref='error' minOccurs='0' maxOccurs='1'/>
<xsd:any <xsd:any
namespace='##other' namespace='##other'
minOccurs='0' minOccurs='0'
maxOccurs='unbounded'/> maxOccurs='unbounded'/>
</xsd:choice> </xsd:choice>
<xsd:attribute name='to' type='xsd:string' use='optional'/> <xsd:attribute name='to' type='xsd:string' use='optional'/>
<xsd:attribute name='from' type='xsd:string' use='optional'/> <xsd:attribute name='from' type='xsd:string' use='optional'/>
<xsd:attribute name='id' type='xsd:ID' use='optional'/> <xsd:attribute name='id' type='xsd:ID' use='optional'/>
<xsd:attribute name='type' use='required'> <xsd:attribute name='type' use='required'>
skipping to change at page 58, line 10 skipping to change at page 56, line 10
</xsd:complexType> </xsd:complexType>
</xsd:element> </xsd:element>
</xsd:schema> </xsd:schema>
Appendix C. Revision History Appendix C. Revision History
Note to RFC editor: please remove this entire appendix, and the Note to RFC editor: please remove this entire appendix, and the
corresponding entries in the table of contents, prior to publication. corresponding entries in the table of contents, prior to publication.
C.1 Changes from draft-ietf-xmpp-core-00 C.1 Changes from draft-ietf-xmpp-core-01
o Updated the addressing restrictions per list discussion and added
references to the new nodeprep and resourceprep profiles.
o Corrected error in Stream Authentication regarding version='1.0'
flag.
o Made numerous small editorial changes.
C.2 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.2 Changes from draft-miller-xmpp-core-02 C.3 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. 126 change blocks. 
371 lines changed or deleted 365 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/