draft-ietf-xmpp-core-16.txt   draft-ietf-xmpp-core-17.txt 
Network Working Group P. Saint-Andre Network Working Group P. Saint-Andre
Internet-Draft J. Miller Internet-Draft J. Miller
Expires: January 26, 2004 Jabber Software Foundation Expires: February 20, 2004 Jabber Software Foundation
July 28, 2003 August 22, 2003
XMPP Core XMPP Core
draft-ietf-xmpp-core-16 draft-ietf-xmpp-core-17
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 other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 31 skipping to change at page 1, line 31
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 January 26, 2004. This Internet-Draft will expire on February 20, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This document describes the core features of the Extensible Messaging This document describes the core features of the Extensible Messaging
and Presence Protocol (XMPP), a protocol for streaming XML elements and Presence Protocol (XMPP), a protocol for streaming XML elements
in order to exchange messages and presence information in close to in order to exchange messages and presence information in close to
skipping to change at page 2, line 29 skipping to change at page 2, line 29
3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Domain Identifier . . . . . . . . . . . . . . . . . . . . . 8 3.2 Domain Identifier . . . . . . . . . . . . . . . . . . . . . 8
3.3 Node Identifier . . . . . . . . . . . . . . . . . . . . . . 9 3.3 Node Identifier . . . . . . . . . . . . . . . . . . . . . . 9
3.4 Resource Identifier . . . . . . . . . . . . . . . . . . . . 9 3.4 Resource Identifier . . . . . . . . . . . . . . . . . . . . 9
4. XML Streams . . . . . . . . . . . . . . . . . . . . . . . . 10 4. XML Streams . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2 Stream Attributes . . . . . . . . . . . . . . . . . . . . . 11 4.2 Stream Attributes . . . . . . . . . . . . . . . . . . . . . 11
4.2.1 Version Support . . . . . . . . . . . . . . . . . . . . . . 12 4.2.1 Version Support . . . . . . . . . . . . . . . . . . . . . . 12
4.3 Namespace Declarations . . . . . . . . . . . . . . . . . . . 13 4.3 Namespace Declarations . . . . . . . . . . . . . . . . . . . 13
4.4 Stream Features . . . . . . . . . . . . . . . . . . . . . . 13 4.4 Stream Features . . . . . . . . . . . . . . . . . . . . . . 13
4.5 Stream Encryption and Authentication . . . . . . . . . . . . 13 4.5 Stream Encryption and Authentication . . . . . . . . . . . . 14
4.6 Stream Errors . . . . . . . . . . . . . . . . . . . . . . . 14 4.6 Stream Errors . . . . . . . . . . . . . . . . . . . . . . . 14
4.6.1 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.6.1 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.6.2 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.6.2 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.6.3 Defined Conditions . . . . . . . . . . . . . . . . . . . . . 15 4.6.3 Defined Conditions . . . . . . . . . . . . . . . . . . . . . 15
4.6.4 Application-Specific Conditions . . . . . . . . . . . . . . 17 4.6.4 Application-Specific Conditions . . . . . . . . . . . . . . 17
4.7 Simple Streams Example . . . . . . . . . . . . . . . . . . . 17 4.7 Simple Streams Example . . . . . . . . . . . . . . . . . . . 17
5. Stream Encryption . . . . . . . . . . . . . . . . . . . . . 20 5. Stream Encryption . . . . . . . . . . . . . . . . . . . . . 20
5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.2 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.2 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.3 Client-to-Server Example . . . . . . . . . . . . . . . . . . 23 5.3 Client-to-Server Example . . . . . . . . . . . . . . . . . . 23
skipping to change at page 3, line 19 skipping to change at page 3, line 19
8.2.5 xml:lang . . . . . . . . . . . . . . . . . . . . . . . . . . 46 8.2.5 xml:lang . . . . . . . . . . . . . . . . . . . . . . . . . . 46
8.3 Message Stanzas . . . . . . . . . . . . . . . . . . . . . . 47 8.3 Message Stanzas . . . . . . . . . . . . . . . . . . . . . . 47
8.3.1 Types of Message . . . . . . . . . . . . . . . . . . . . . . 47 8.3.1 Types of Message . . . . . . . . . . . . . . . . . . . . . . 47
8.3.2 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 47 8.3.2 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 47
8.4 Presence Stanzas . . . . . . . . . . . . . . . . . . . . . . 49 8.4 Presence Stanzas . . . . . . . . . . . . . . . . . . . . . . 49
8.4.1 Types of Presence . . . . . . . . . . . . . . . . . . . . . 49 8.4.1 Types of Presence . . . . . . . . . . . . . . . . . . . . . 49
8.4.2 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 50 8.4.2 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 50
8.5 IQ Stanzas . . . . . . . . . . . . . . . . . . . . . . . . . 51 8.5 IQ Stanzas . . . . . . . . . . . . . . . . . . . . . . . . . 51
8.5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 51 8.5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 51
8.5.2 Types of IQ . . . . . . . . . . . . . . . . . . . . . . . . 52 8.5.2 Types of IQ . . . . . . . . . . . . . . . . . . . . . . . . 52
8.5.3 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 53 8.5.3 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 52
8.6 Extended Namespaces . . . . . . . . . . . . . . . . . . . . 53 8.6 Extended Namespaces . . . . . . . . . . . . . . . . . . . . 52
8.7 Stanza Errors . . . . . . . . . . . . . . . . . . . . . . . 54 8.7 Stanza Errors . . . . . . . . . . . . . . . . . . . . . . . 53
8.7.1 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 8.7.1 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
8.7.2 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 8.7.2 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
8.7.3 Defined Conditions . . . . . . . . . . . . . . . . . . . . . 56 8.7.3 Defined Conditions . . . . . . . . . . . . . . . . . . . . . 55
8.7.4 Application-Specific Conditions . . . . . . . . . . . . . . 57 8.7.4 Application-Specific Conditions . . . . . . . . . . . . . . 57
9. XML Usage within XMPP . . . . . . . . . . . . . . . . . . . 59 9. XML Usage within XMPP . . . . . . . . . . . . . . . . . . . 58
9.1 Restrictions . . . . . . . . . . . . . . . . . . . . . . . . 59 9.1 Restrictions . . . . . . . . . . . . . . . . . . . . . . . . 58
9.2 XML Namespace Names and Prefixes . . . . . . . . . . . . . . 59 9.2 XML Namespace Names and Prefixes . . . . . . . . . . . . . . 58
9.2.1 Stream Namespace . . . . . . . . . . . . . . . . . . . . . . 59 9.2.1 Stream Namespace . . . . . . . . . . . . . . . . . . . . . . 58
9.2.2 Default Namespace . . . . . . . . . . . . . . . . . . . . . 60 9.2.2 Default Namespace . . . . . . . . . . . . . . . . . . . . . 59
9.2.3 Dialback Namespace . . . . . . . . . . . . . . . . . . . . . 60 9.2.3 Dialback Namespace . . . . . . . . . . . . . . . . . . . . . 59
9.3 Validation . . . . . . . . . . . . . . . . . . . . . . . . . 61 9.3 Validation . . . . . . . . . . . . . . . . . . . . . . . . . 60
9.4 Character Encodings . . . . . . . . . . . . . . . . . . . . 61 9.4 Inclusion of Text Declaration . . . . . . . . . . . . . . . 60
9.5 Inclusion of Text Declaration . . . . . . . . . . . . . . . 61 9.5 Character Encodings . . . . . . . . . . . . . . . . . . . . 60
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 62 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 61
10.1 XML Namespace Name for TLS Data . . . . . . . . . . . . . . 62 10.1 XML Namespace Name for TLS Data . . . . . . . . . . . . . . 61
10.2 XML Namespace Name for SASL Data . . . . . . . . . . . . . . 62 10.2 XML Namespace Name for SASL Data . . . . . . . . . . . . . . 61
10.3 XML Namespace Name for Stream Errors . . . . . . . . . . . . 62 10.3 XML Namespace Name for Stream Errors . . . . . . . . . . . . 61
10.4 XML Namespace Name for Stanza Errors . . . . . . . . . . . . 63 10.4 XML Namespace Name for Stanza Errors . . . . . . . . . . . . 62
10.5 Existing Registrations . . . . . . . . . . . . . . . . . . . 63 10.5 Existing Registrations . . . . . . . . . . . . . . . . . . . 62
11. Internationalization Considerations . . . . . . . . . . . . 64 11. Internationalization Considerations . . . . . . . . . . . . 63
12. Security Considerations . . . . . . . . . . . . . . . . . . 65 12. Security Considerations . . . . . . . . . . . . . . . . . . 64
12.1 High Security . . . . . . . . . . . . . . . . . . . . . . . 65 12.1 High Security . . . . . . . . . . . . . . . . . . . . . . . 64
12.2 Client-to-Server Communications . . . . . . . . . . . . . . 65 12.2 Client-to-Server Communications . . . . . . . . . . . . . . 64
12.3 Server-to-Server Communications . . . . . . . . . . . . . . 66 12.3 Server-to-Server Communications . . . . . . . . . . . . . . 65
12.4 Order of Layers . . . . . . . . . . . . . . . . . . . . . . 67 12.4 Order of Layers . . . . . . . . . . . . . . . . . . . . . . 66
12.5 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . 67 12.5 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . 66
12.6 Mandatory to Implement Technologies . . . . . . . . . . . . 67 12.6 Mandatory to Implement Technologies . . . . . . . . . . . . 66
Normative References . . . . . . . . . . . . . . . . . . . . 68 13. Compliance Requirements . . . . . . . . . . . . . . . . . . 67
Informative References . . . . . . . . . . . . . . . . . . . 70 13.1 Servers . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 70 13.2 Clients . . . . . . . . . . . . . . . . . . . . . . . . . . 67
A. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . 71 14. Differences Between Jabber and XMPP . . . . . . . . . . . . 69
A.1 Stream namespace . . . . . . . . . . . . . . . . . . . . . . 71 14.1 Authentication . . . . . . . . . . . . . . . . . . . . . . . 69
A.2 Stream error namespace . . . . . . . . . . . . . . . . . . . 72 14.2 Channel Encryption . . . . . . . . . . . . . . . . . . . . . 69
A.3 TLS namespace . . . . . . . . . . . . . . . . . . . . . . . 74 14.3 JID Processing . . . . . . . . . . . . . . . . . . . . . . . 69
A.4 SASL namespace . . . . . . . . . . . . . . . . . . . . . . . 74 14.4 Error Handling . . . . . . . . . . . . . . . . . . . . . . . 69
A.5 Dialback namespace . . . . . . . . . . . . . . . . . . . . . 76 14.5 Internationalization . . . . . . . . . . . . . . . . . . . . 70
A.6 Client namespace . . . . . . . . . . . . . . . . . . . . . . 77 14.6 Stream Version Attribute . . . . . . . . . . . . . . . . . . 70
A.7 Server namespace . . . . . . . . . . . . . . . . . . . . . . 81 Normative References . . . . . . . . . . . . . . . . . . . . 71
A.8 Stanza error namespace . . . . . . . . . . . . . . . . . . . 85 Informative References . . . . . . . . . . . . . . . . . . . 73
B. Revision History . . . . . . . . . . . . . . . . . . . . . . 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 73
B.1 Changes from draft-ietf-xmpp-core-15 . . . . . . . . . . . . 87 A. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . 74
B.2 Changes from draft-ietf-xmpp-core-14 . . . . . . . . . . . . 87 A.1 Stream namespace . . . . . . . . . . . . . . . . . . . . . . 74
B.3 Changes from draft-ietf-xmpp-core-13 . . . . . . . . . . . . 87 A.2 Stream error namespace . . . . . . . . . . . . . . . . . . . 75
B.4 Changes from draft-ietf-xmpp-core-12 . . . . . . . . . . . . 87 A.3 TLS namespace . . . . . . . . . . . . . . . . . . . . . . . 76
B.5 Changes from draft-ietf-xmpp-core-11 . . . . . . . . . . . . 88 A.4 SASL namespace . . . . . . . . . . . . . . . . . . . . . . . 77
B.6 Changes from draft-ietf-xmpp-core-10 . . . . . . . . . . . . 88 A.5 Dialback namespace . . . . . . . . . . . . . . . . . . . . . 78
B.7 Changes from draft-ietf-xmpp-core-09 . . . . . . . . . . . . 88 A.6 Client namespace . . . . . . . . . . . . . . . . . . . . . . 79
B.8 Changes from draft-ietf-xmpp-core-08 . . . . . . . . . . . . 89 A.7 Server namespace . . . . . . . . . . . . . . . . . . . . . . 83
B.9 Changes from draft-ietf-xmpp-core-07 . . . . . . . . . . . . 89 A.8 Stanza error namespace . . . . . . . . . . . . . . . . . . . 87
B.10 Changes from draft-ietf-xmpp-core-06 . . . . . . . . . . . . 89 B. Revision History . . . . . . . . . . . . . . . . . . . . . . 89
B.11 Changes from draft-ietf-xmpp-core-05 . . . . . . . . . . . . 89 B.1 Changes from draft-ietf-xmpp-core-16 . . . . . . . . . . . . 89
B.12 Changes from draft-ietf-xmpp-core-04 . . . . . . . . . . . . 89 B.2 Changes from draft-ietf-xmpp-core-15 . . . . . . . . . . . . 89
B.13 Changes from draft-ietf-xmpp-core-03 . . . . . . . . . . . . 90 B.3 Changes from draft-ietf-xmpp-core-14 . . . . . . . . . . . . 89
B.14 Changes from draft-ietf-xmpp-core-02 . . . . . . . . . . . . 90 B.4 Changes from draft-ietf-xmpp-core-13 . . . . . . . . . . . . 90
B.15 Changes from draft-ietf-xmpp-core-01 . . . . . . . . . . . . 90 B.5 Changes from draft-ietf-xmpp-core-12 . . . . . . . . . . . . 90
B.16 Changes from draft-ietf-xmpp-core-00 . . . . . . . . . . . . 90 B.6 Changes from draft-ietf-xmpp-core-11 . . . . . . . . . . . . 90
B.17 Changes from draft-miller-xmpp-core-02 . . . . . . . . . . . 91 B.7 Changes from draft-ietf-xmpp-core-10 . . . . . . . . . . . . 90
Intellectual Property and Copyright Statements . . . . . . . 93 B.8 Changes from draft-ietf-xmpp-core-09 . . . . . . . . . . . . 91
B.9 Changes from draft-ietf-xmpp-core-08 . . . . . . . . . . . . 91
B.10 Changes from draft-ietf-xmpp-core-07 . . . . . . . . . . . . 91
B.11 Changes from draft-ietf-xmpp-core-06 . . . . . . . . . . . . 91
B.12 Changes from draft-ietf-xmpp-core-05 . . . . . . . . . . . . 92
B.13 Changes from draft-ietf-xmpp-core-04 . . . . . . . . . . . . 92
B.14 Changes from draft-ietf-xmpp-core-03 . . . . . . . . . . . . 92
B.15 Changes from draft-ietf-xmpp-core-02 . . . . . . . . . . . . 92
B.16 Changes from draft-ietf-xmpp-core-01 . . . . . . . . . . . . 93
B.17 Changes from draft-ietf-xmpp-core-00 . . . . . . . . . . . . 93
B.18 Changes from draft-miller-xmpp-core-02 . . . . . . . . . . . 93
Intellectual Property and Copyright Statements . . . . . . . 95
1. Introduction 1. Introduction
1.1 Overview 1.1 Overview
The Extensible Messaging and Presence Protocol (XMPP) is an open XML The Extensible Messaging and Presence Protocol (XMPP) is an open XML
[1] protocol for near-real-time messaging, presence, and [1] protocol for near-real-time messaging, presence, and
request-response services. The basic syntax and semantics were request-response services. The basic syntax and semantics were
developed originally within the Jabber open-source community, mainly developed originally within the Jabber open-source community, mainly
in 1999. In 2002, the XMPP WG was chartered with developing an in 1999. In 2002, the XMPP WG was chartered with developing an
adaptation of the Jabber protocol that would be suitable as an IETF adaptation of the Jabber protocol that would be suitable as an IETF
instant messaging (IM) and presence technology. As a result of work instant messaging (IM) and presence technology. As a result of work
by the XMPP WG, the current document defines the core features of by the XMPP WG, the current document defines the core features of
XMPP; XMPP IM [23] defines the extensions required to provide the XMPP; XMPP IM [24] defines the extensions required to provide the
instant messaging and presence functionality defined in RFC 2779 [2]. instant messaging and presence functionality defined in RFC 2779 [2].
1.2 Terminology 1.2 Terminology
The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [3]. 2119 [3].
1.3 Discussion Venue 1.3 Discussion Venue
skipping to change at page 8, line 12 skipping to change at page 8, line 12
sockets, using port 5269 as registered with the IANA (see IANA sockets, using port 5269 as registered with the IANA (see IANA
Considerations (Section 10)). Considerations (Section 10)).
3. Addressing Scheme 3. Addressing Scheme
3.1 Overview 3.1 Overview
An entity is anything that can be considered a network endpoint An entity is anything that can be considered a network endpoint
(i.e., an ID on the network) and that can communicate using XMPP. All (i.e., an ID on the network) and that can communicate using XMPP. All
such entities are uniquely addressable in a form that is consistent such entities are uniquely addressable in a form that is consistent
with RFC 2396 [24]. For historical reasons, the address of such an with RFC 2396 [25]. For historical reasons, the address of such an
entity is called a Jabber Identifier or JID. A valid JID contains a entity is called a Jabber Identifier or JID. A valid JID contains a
set of ordered elements formed of a domain identifier, node set of ordered elements formed of a domain identifier, node
identifier, and resource identifier in the following format: identifier, and resource identifier in the following format:
[node@]domain[/resource]. Each allowable portion of a JID (node [node@]domain[/resource]. Each allowable portion of a JID (node
identifier, domain identifier, and resource identifier) may be up to identifier, domain identifier, and resource identifier) may be up to
1023 bytes in length, resulting in a maximum total size (including 1023 bytes in length, resulting in a maximum total size (including
the '@' and '/' separators) of 3071 bytes. the '@' and '/' separators) of 3071 bytes.
All JIDs are based on the foregoing structure. The most common use of All JIDs are based on the foregoing structure. The most common use of
this structure is to identify an instant messaging user, the server this structure is to identify an instant messaging user, the server
skipping to change at page 10, line 25 skipping to change at page 10, line 25
exchange of XML elements between any two entities over a network. exchange of XML elements between any two entities over a network.
An XML stream is negotiated from an initiating entity (usually a An XML stream is negotiated from an initiating entity (usually a
client or server) to a receiving entity (usually a server), client or server) to a receiving entity (usually a server),
normally over a TCP socket, and corresponds to the initiating normally over a TCP socket, and corresponds to the initiating
entity's "session" with the receiving entity. The start of the XML entity's "session" with the receiving entity. The start of the XML
stream is denoted unambiguously by an opening XML <stream> tag stream is denoted unambiguously by an opening XML <stream> tag
with appropriate attributes and namespace declarations, and the with appropriate attributes and namespace declarations, and the
end of the XML stream is denoted unambiguously by a closing XML </ end of the XML stream is denoted unambiguously by a closing XML </
stream> tag. An XML stream is unidirectional; in order to enable stream> tag. An XML stream is unidirectional; in order to enable
bidirectional information exchange, the initiating entity and bidirectional information exchange, the initiating entity and
receiving entity MUST negotiate one stream in each direction, receiving entity MUST negotiate one stream in each direction (the
normally over the same TCP connection. "initial stream" and the "response stream"), normally over the
same TCP connection.
Definition of XML Stanza: An XML stanza is a discrete semantic unit Definition of XML Stanza: An XML stanza is a discrete semantic unit
of structured information that is sent from one entity to another of structured information that is sent from one entity to another
over an XML stream. An XML stanza exists at the direct child level over an XML stream. An XML stanza exists at the direct child level
of the root <stream/> element and is said to be well-balanced if of the root <stream/> element and is said to be well-balanced if
it matches production [43] content of the XML specification [1]). it matches production [43] content of the XML specification [1]).
The start of any XML stanza is denoted unambiguously by the The start of any XML stanza is denoted unambiguously by the
element start tag at depth=1 of the XML stream (e.g., <presence>), element start tag at depth=1 of the XML stream (e.g., <presence>),
and the end of any XML stanza is denoted unambiguously by the and the end of any XML stanza is denoted unambiguously by the
corresponding close tag at depth=1 (e.g., </presence>). An XML corresponding close tag at depth=1 (e.g., </presence>). An XML
stanza MAY contain child elements (with accompanying attributes, stanza MAY contain child elements (with accompanying attributes,
elements, and CDATA) as necessary in order to convey the desired elements, and CDATA) as necessary in order to convey the desired
information. An XML element sent for the purpose of stream information. An XML element sent for the purpose of stream
encryption, stream authentication, or server dialback is not encryption, stream authentication, or server dialback is not
considered to be an XML stanza. considered to be an XML stanza.
Consider the example of a client's session with a server. In order to Consider the example of a client's session with a server. In order to
connect to a server, a client MUST initiate an XML stream by sending connect to a server, a client MUST initiate an XML stream by sending
an opening <stream> tag to the server, optionally preceded by a text an opening <stream> tag to the server, optionally preceded by a text
declaration specifying the XML version supported and the character declaration specifying the XML version supported and the character
encoding (see also Character Encodings (Section 9.4)). The server encoding (see also Character Encodings (Section 9.5)). The server
SHOULD then reply with a second XML stream back to the client, again SHOULD then reply with a second XML stream back to the client, again
optionally preceded by a text declaration. Once the client has optionally preceded by a text declaration. Once the client has
authenticated with the server (see Section 6), the client MAY send an authenticated with the server (see Section 6), the client MAY send an
unlimited number of XML stanzas over the stream to any recipient on unlimited number of XML stanzas over the stream to any recipient on
the network. When the client desires to close the stream, it simply the network. When the client desires to close the stream, it simply
sends a closing </stream> tag to the server (alternatively, the sends a closing </stream> tag to the server (alternatively, the
stream may be closed by the server), after which both the client and stream may be closed by the server), after which both the client and
server SHOULD close the underlying TCP connection as well. server SHOULD close the underlying TCP connection as well.
Those who are accustomed to thinking of XML in a document-centric Those who are accustomed to thinking of XML in a document-centric
skipping to change at page 12, line 26 skipping to change at page 12, line 27
header from the receiving entity to the initiating entity. This header from the receiving entity to the initiating entity. This
attribute is a unique identifier created by the receiving entity attribute is a unique identifier created by the receiving entity
to function as a session key for the initiating entity's streams to function as a session key for the initiating entity's streams
with the receiving entity, and MUST be unique within the receiving with the receiving entity, and MUST be unique within the receiving
application (normally a server). There SHOULD be no 'id' attribute application (normally a server). There SHOULD be no 'id' attribute
on the XML stream header sent from the initiating entity to the on the XML stream header sent from the initiating entity to the
receiving entity; however, if an 'id' attribute is included, it receiving entity; however, if an 'id' attribute is included, it
SHOULD be silently ignored by the receiving entity. SHOULD be silently ignored by the receiving entity.
o version -- The presence of the version attribute set to a value of o version -- The presence of the version attribute set to a value of
"1.0" indicates compliance with this specification. Detailed rules "1.0" signals support for the stream features defined in this
regarding generation and handling of this attribute are defined specification. Detailed rules regarding generation and handling of
below. this attribute are defined below.
We can summarize as follows: We can summarize as follows:
| initiating to receiving | receiving to initiating | initiating to receiving | receiving to initiating
------------------------------------------------------------ ------------------------------------------------------------
to | hostname of receiver | silently ignored to | hostname of receiver | silently ignored
from | silently ignored | hostname of receiver from | silently ignored | hostname of receiver
id | silently ignored | session key id | silently 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.2.1 Version Support 4.2.1 Version Support
The following rules apply to the generation and handling of the The following rules apply to the generation and handling of the
'version' attribute: 'version' attribute:
1. If the initiating entity complies with the protocol defined 1. If the initiating entity complies with the XML streams protocol
herein, it MUST include the 'version' attribute in the XML stream defined herein (including Stream Encryption (Section 5), Stream
header it sends to the receiving entity, and it MUST set the Authentication (Section 6), and Stream Errors (Section 4.6)), it
value of the 'version' attribute to "1.0". MUST include the 'version' attribute in the XML stream header it
sends to the receiving entity, and it MUST set the value of the
'version' attribute to "1.0".
2. If the initiating entity includes the 'version' attribute set to 2. If the initiating entity includes the 'version' attribute set to
a value of "1.0" in its stream header and the receiving entity a value of "1.0" in its stream header and the receiving entity
supports XMPP 1.0, the receiving entity MUST reciprocate by supports XMPP 1.0, the receiving entity MUST reciprocate by
including the 'version' attribute set to a value of "1.0" in its including the 'version' attribute set to a value of "1.0" in its
stream header response. stream header response.
3. If the initiating entity does not include the 'version' attribute 3. If the initiating entity does not include the 'version' attribute
in its stream header, the receiving entity still SHOULD include in its stream header, the receiving entity still SHOULD include
the 'version' attribute set to a value of "1.0" in its stream the 'version' attribute set to a value of "1.0" in its stream
skipping to change at page 15, line 30 skipping to change at page 15, line 33
The <text/> element is OPTIONAL. If included, it SHOULD be used only The <text/> element is OPTIONAL. If included, it SHOULD be used only
to provide descriptive or diagnostic information that supplements the to provide descriptive or diagnostic information that supplements the
meaning of a defined condition or application-specific condition. It meaning of a defined condition or application-specific condition. It
SHOULD NOT be interpreted programmatically by an application. It SHOULD NOT be interpreted programmatically by an application. It
SHOULD NOT be used as the error message presented to user, but MAY be SHOULD NOT be used as the error message presented to user, but MAY be
shown in addition to the error message associated with the included shown in addition to the error message associated with the included
condition element (or elements). condition element (or elements).
Note: the XML namespace name 'urn:ietf:params:xml:ns:xmpp-streams' Note: the XML namespace name 'urn:ietf:params:xml:ns:xmpp-streams'
that qualifies the descriptive element adheres to the format defined that qualifies the descriptive element adheres to the format defined
in The IETF XML Registry [25]. in The IETF XML Registry [26].
4.6.3 Defined Conditions 4.6.3 Defined Conditions
The following stream-level error conditions are defined: The following stream-level error conditions are defined:
o <conflict/> -- the server is closing the active stream for this
entity because a new stream has been initiated that conflicts with
the existing stream.
o <connection-timeout/> -- the entity has not generated any traffic o <connection-timeout/> -- the entity has not generated any traffic
over the stream for some period of time (configurable according to over the stream for some period of time (configurable according to
a local service policy). a local service policy).
o <host-gone/> -- the value of the 'to' attribute provided by the o <host-gone/> -- the value of the 'to' attribute provided by the
initiating entity in the stream header corresponds to a hostname initiating entity in the stream header corresponds to a hostname
that is no longer hosted by the server. that is no longer hosted by the server.
o <host-unknown/> -- the value of the 'to' attribute provided by the o <host-unknown/> -- the value of the 'to' attribute provided by the
initiating entity in the stream header does not correspond to a initiating entity in the stream header does not correspond to a
skipping to change at page 16, line 24 skipping to change at page 16, line 32
does not match the hostname (or other validated domain) negotiated does not match the hostname (or other validated domain) negotiated
via SASL or dialback. via SASL or dialback.
o <not-authorized/> -- the entity has attempted to send data before o <not-authorized/> -- the entity has attempted to send data before
authenticating, or otherwise is not authorized to perform an authenticating, or otherwise is not authorized to perform an
action related to stream negotiation; the receiving entity SHOULD action related to stream negotiation; the receiving entity SHOULD
silently drop the offending stanza and MUST NOT process it before silently drop the offending stanza and MUST NOT process it before
sending the stream error. sending the stream error.
o <policy-violation/> -- the entity has violated some local service o <policy-violation/> -- the entity has violated some local service
policy. policy; the server MAY choose to specify the policy in the <text/>
element.
o <remote-connection-failed/> -- the server is unable to properly o <remote-connection-failed/> -- the server is unable to properly
connect to a remote resource that is required for authentication connect to a remote resource that is required for authentication
or authorization. or authorization.
o <resource-constraint/> -- the server is resource-contrained and is o <resource-constraint/> -- the server is resource-contrained and is
unable to service the stream. unable to service the stream.
o <see-other-host/> -- the server will not provide service to the o <see-other-host/> -- the server will not provide service to the
initiating entity but is redirecting traffic to another host; this initiating entity but is redirecting traffic to another host; the
element SHOULD contain CDATA specifying the alternate hostname or server SHOULD specify the alternate hostname or IP address in the
IP address to which the initiating entity MAY attempt to connect. <text/> element.
o <system-shutdown/> -- the server is being shut down and all active o <system-shutdown/> -- the server is being shut down and all active
streams are being closed. streams are being closed.
o <undefined-condition/> -- the error condition is not one of those o <undefined-condition/> -- the error condition is not one of those
defined by the other conditions in this list; this error condition defined by the other conditions in this list; this error condition
SHOULD be used only in conjuction with an application-specific SHOULD be used only in conjuction with an application-specific
condition. condition.
o <unsupported-encoding/> -- the initiating entity has encoded the
stream in an encoding that is not supported by the server.
o <unsupported-stanza-type/> -- the initiating entity has sent a o <unsupported-stanza-type/> -- the initiating entity has sent a
first-level child of the stream that is not supported by the first-level child of the stream that is not supported by the
server. server.
o <unsupported-version/> -- the value of the 'version' attribute o <unsupported-version/> -- the value of the 'version' attribute
provided by the initiating entity in the stream header specifies a provided by the initiating entity in the stream header specifies a
version of XMPP that is not supported by the server; this element version of XMPP that is not supported by the server; the server
MAY contain CDATA specifying the XMPP version(s) supported by the MAY specify the version(s) it supports in the <text/> element.
server.
o <xml-not-well-formed/> -- the initiating entity has sent XML that o <xml-not-well-formed/> -- the initiating entity has sent XML that
is not well-formed as defined by the XML specification [1]. is not well-formed as defined by the XML specification [1].
4.6.4 Application-Specific Conditions 4.6.4 Application-Specific Conditions
As noted, an application MAY provide application-specific stream As noted, an application MAY provide application-specific stream
error information by including a properly-namespaced child in the error information by including a properly-namespaced child in the
error element. The application-specific element SHOULD supplement or error element. The application-specific element SHOULD supplement or
further qualify a defined element. Thus the <error/> element will further qualify a defined element. Thus the <error/> element will
skipping to change at page 20, line 13 skipping to change at page 20, line 13
S: </stream:stream> S: </stream:stream>
5. Stream Encryption 5. Stream Encryption
5.1 Overview 5.1 Overview
XMPP includes a method for securing the stream from tampering and XMPP includes a method for securing the stream from tampering and
eavesdropping. This channel encryption method makes use of the eavesdropping. This channel encryption method makes use of the
Transport Layer Security (TLS) [13] protocol, along with a "STARTTLS" Transport Layer Security (TLS) [13] protocol, along with a "STARTTLS"
extension that is modelled after similar extensions for the IMAP extension that is modelled after similar extensions for the IMAP
[26], POP3 [27], and ACAP [28] protocols as described in RFC 2595 [27], POP3 [28], and ACAP [29] protocols as described in RFC 2595
[29]. The namespace name for the STARTTLS extension is [30]. The namespace name for the STARTTLS extension is
'urn:ietf:params:xml:ns:xmpp-tls', which adheres to the format 'urn:ietf:params:xml:ns:xmpp-tls', which adheres to the format
defined in The IETF XML Registry [25]. defined in The IETF XML Registry [26].
An administrator of a given domain MAY require the use of TLS for An administrator of a given domain MAY require the use of TLS for
client-to-server communications, server-to-server communications, or client-to-server communications, server-to-server communications, or
both. Servers SHOULD use TLS betweeen two domains for the purpose of both. Servers SHOULD use TLS betweeen two domains for the purpose of
securing server-to-server communications. See Mandatory to Implement securing server-to-server communications. See Mandatory to Implement
Technologies (Section 12.6) regarding mechanisms that MUST be Technologies (Section 12.6) regarding mechanisms that MUST be
supported. supported.
The following rules apply: The following rules apply:
skipping to change at page 27, line 16 skipping to change at page 27, line 16
6.1 Overview 6.1 Overview
XMPP includes a method for authenticating a stream using an XMPP XMPP includes a method for authenticating a stream using an XMPP
adaptation of the Simple Authentication and Security Layer (SASL) adaptation of the Simple Authentication and Security Layer (SASL)
[15]. SASL provides a generalized method for adding authentication [15]. SASL provides a generalized method for adding authentication
support to connection-based protocols, and XMPP uses a generic XML support to connection-based protocols, and XMPP uses a generic XML
namespace profile for SASL that conforms to section 4 ("Profiling namespace profile for SASL that conforms to section 4 ("Profiling
Requirements") of RFC 2222 [15] (the XMPP-specific namespace name is Requirements") of RFC 2222 [15] (the XMPP-specific namespace name is
'urn:ietf:params:xml:ns:xmpp-sasl', which adheres to the format 'urn:ietf:params:xml:ns:xmpp-sasl', which adheres to the format
defined in The IETF XML Registry [25]). Finally, see Mandatory to defined in The IETF XML Registry [26]). Finally, see Mandatory to
Implement Technologies (Section 12.6) regarding mechanisms that MUST Implement Technologies (Section 12.6) regarding mechanisms that MUST
be supported. be supported.
The following rules apply: The following rules apply:
1. If the SASL negotiation occurs between two servers, 1. If the SASL negotiation occurs between two servers,
communications MUST NOT proceed until the DNS hostnames asserted communications MUST NOT proceed until the DNS hostnames asserted
by the servers have been resolved (see Server-to-Server by the servers have been resolved (see Server-to-Server
Communications (Section 12.3)). Communications (Section 12.3)).
skipping to change at page 28, line 12 skipping to change at page 28, line 12
obtained from the receiving entity which was not obtained from obtained from the receiving entity which was not obtained from
the SASL negotiation itself. the SASL negotiation itself.
7. The initiating entity MUST provide an authzid during SASL 7. The initiating entity MUST provide an authzid during SASL
negotiation. The authzid-value MUST be a valid JID of the form negotiation. The authzid-value MUST be a valid JID of the form
<domain> (i.e., a domain identifier only) for servers and of the <domain> (i.e., a domain identifier only) for servers and of the
form <user@domain/resource> (i.e., node identifier, domain form <user@domain/resource> (i.e., node identifier, domain
identifier, and resource identifier) for clients. The initiating identifier, and resource identifier) for clients. The initiating
entity MAY process the authzid-value in accordance with the rules entity MAY process the authzid-value in accordance with the rules
defined in Addressing Scheme (Section 3) before providing it to defined in Addressing Scheme (Section 3) before providing it to
the receiving entity, but is NOT REQUIRED to do so. the receiving entity, but is NOT REQUIRED to do so; however, the
receiving entity MUST verify that the authzid-value provided by
the initiating entity conforms to the rules defined therein.
8. Any character data contained within the XML elements used during 8. Any character data contained within the XML elements used during
SASL negotiation MUST be encoded using base64. SASL negotiation MUST be encoded using base64.
6.2 Narrative 6.2 Narrative
When an initiating entity authenticates with a receiving entity, the When an initiating entity authenticates with a receiving entity, the
steps involved are as follows: steps involved are as follows:
1. The initiating entity requests SASL authentication by including 1. The initiating entity requests SASL authentication by including
skipping to change at page 29, line 34 skipping to change at page 29, line 36
element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl'
namespace to the receiving entity. Upon receiving the <abort/> namespace to the receiving entity. Upon receiving the <abort/>
element, the receiving entity MUST terminate the TCP connection. element, the receiving entity MUST terminate the TCP connection.
2. The receiving entity reports failure of the handshake by sending 2. The receiving entity reports failure of the handshake by sending
a <failure/> element qualified by the a <failure/> element qualified by the
'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating
entity (the particular cause of failure SHOULD be communicated in entity (the particular cause of failure SHOULD be communicated in
an appropriate child element of the <failure/> element as defined an appropriate child element of the <failure/> element as defined
under SASL Errors (Section 6.3)). Immediately after sending the under SASL Errors (Section 6.3)). Immediately after sending the
<failure/> element, the receiving entity MUST terminate the TCP <failure/> element, the receiving entity MUST terminate both the
connection. XML stream and the underlying TCP connection.
3. The receiving entity reports success of the handshake by sending 3. The receiving entity reports success of the handshake by sending
a <success/> element qualified by the a <success/> element qualified by the
'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating
entity; this element MAY optionally contain character data (in entity; this element MAY optionally contain character data (in
SASL terminology "additional data with success"). Upon receiving SASL terminology "additional data with success"). Upon receiving
the <success/> element, the initiating entity MUST initiate a new the <success/> element, the initiating entity MUST initiate a new
stream by sending an opening XML stream header to the receiving stream by sending an opening XML stream header to the receiving
entity (it is not necessary to send a closing </stream:stream> entity (it is not necessary to send a closing </stream:stream>
element first, since the receiving entity and initiating entity element first, since the receiving entity and initiating entity
skipping to change at page 33, line 4 skipping to change at page 32, line 48
<challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
cmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIi cmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIi
xxb3A9ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNz xxb3A9ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNz
</challenge> </challenge>
The decoded challenge is: The decoded challenge is:
realm="cataclysm.cx",nonce="OA6MG9tEQGm2hh",\ realm="cataclysm.cx",nonce="OA6MG9tEQGm2hh",\
qop="auth",charset=utf-8,algorithm=md5-sess qop="auth",charset=utf-8,algorithm=md5-sess
Step 5 (alt): Server returns error to client: Step 5 (alt): Server returns error to client:
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism-too-weak/> <mechanism-too-weak/>
</failure> </failure>
</stream:stream>
Step 6: Client responds to the challenge: Step 6: Client responds to the challenge:
<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
dXNlcm5hbWU9InJvYiIscmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik dXNlcm5hbWU9InJvYiIscmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik
9BNk1HOXRFUUdtMmhoIixjbm9uY2U9Ik9BNk1IWGg2VnFUclJrIixuYz0w 9BNk1HOXRFUUdtMmhoIixjbm9uY2U9Ik9BNk1IWGg2VnFUclJrIixuYz0w
MDAwMDAwMSxxb3A9YXV0aCxkaWdlc3QtdXJpPSJ4bXBwL2NhdGFjbHlzbS MDAwMDAwMSxxb3A9YXV0aCxkaWdlc3QtdXJpPSJ4bXBwL2NhdGFjbHlzbS
5jeCIscmVzcG9uc2U9ZDM4OGRhZDkwZDRiYmQ3NjBhMTUyMzIxZjIxNDNh 5jeCIscmVzcG9uc2U9ZDM4OGRhZDkwZDRiYmQ3NjBhMTUyMzIxZjIxNDNh
ZjcsY2hhcnNldD11dGYtOCxhdXRoemlkPSJyb2JAY2F0YWNseXNtLmN4L2 ZjcsY2hhcnNldD11dGYtOCxhdXRoemlkPSJyb2JAY2F0YWNseXNtLmN4L2
15UmVzb3VyY2Ui 15UmVzb3VyY2Ui
skipping to change at page 33, line 44 skipping to change at page 33, line 41
The decoded challenge is: The decoded challenge is:
rspauth=ea40f60335c427b5527b84dbabcdfffd rspauth=ea40f60335c427b5527b84dbabcdfffd
Step 7 (alt): Server returns error to client: Step 7 (alt): Server returns error to client:
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<invalid-realm/> <invalid-realm/>
</failure> </failure>
</stream:stream>
Step 8: Client responds to the challenge: Step 8: Client responds to the challenge:
<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/> <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
Step 9: Server informs client of successful authentication: Step 9: Server informs client of successful authentication:
<success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/> <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
Step 9 (alt): Server informs client of failed authentication: Step 9 (alt): Server informs client of failed authentication:
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<temporary-auth-failure/> <temporary-auth-failure/>
</failure> </failure>
</stream:stream>
Step 10: Client initiates a new stream to server: Step 10: Client initiates a new 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'
version='1.0'> version='1.0'>
Step 11: Server responds by sending a stream header to client along Step 11: Server responds by sending a stream header to client along
skipping to change at page 36, line 4 skipping to change at page 35, line 39
The decoded challenge is: The decoded challenge is:
realm="cataclysm.cx",nonce="OA6MG9tEQGm2hh",\ realm="cataclysm.cx",nonce="OA6MG9tEQGm2hh",\
qop="auth",charset=utf-8,algorithm=md5-sess qop="auth",charset=utf-8,algorithm=md5-sess
Step 5 (alt): Server2 returns error to Server1: Step 5 (alt): Server2 returns error to Server1:
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<encryption-required/> <encryption-required/>
</failure> </failure>
</stream:stream>
Step 6: Server1 responds to the challenge: Step 6: Server1 responds to the challenge:
<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
cmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIi cmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIi
xjbm9uY2U9Ik9BNk1IWGg2VnFUclJrIixuYz0wMDAwMDAwMSxxb3A9YXV0 xjbm9uY2U9Ik9BNk1IWGg2VnFUclJrIixuYz0wMDAwMDAwMSxxb3A9YXV0
aCxkaWdlc3QtdXJpPSJ4bXBwL2NhdGFjbHlzbS5jeCIscmVzcG9uc2U9ZD aCxkaWdlc3QtdXJpPSJ4bXBwL2NhdGFjbHlzbS5jeCIscmVzcG9uc2U9ZD
M4OGRhZDkwZDRiYmQ3NjBhMTUyMzIxZjIxNDNhZjcsY2hhcnNldD11dGYt M4OGRhZDkwZDRiYmQ3NjBhMTUyMzIxZjIxNDNhZjcsY2hhcnNldD11dGYt
OAo= OAo=
</response> </response>
skipping to change at page 36, line 35 skipping to change at page 36, line 24
The decoded challenge is: The decoded challenge is:
rspauth=ea40f60335c427b5527b84dbabcdfffd rspauth=ea40f60335c427b5527b84dbabcdfffd
Step 5 (alt): Server2 returns error to Server1: Step 5 (alt): Server2 returns error to Server1:
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<invalid-authzid/> <invalid-authzid/>
</failure> </failure>
</stream:stream>
Step 8: Server1 responds to the challenge: Step 8: Server1 responds to the challenge:
<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/> <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
Step 9: Server2 informs Server1 of successful authentication: Step 9: Server2 informs Server1 of successful authentication:
<success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/> <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
Step 9 (alt): Server2 informs Server1 of failed authentication: Step 9 (alt): Server2 informs Server1 of failed authentication:
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<temporary-auth-failure/> <temporary-auth-failure/>
</failure> </failure>
</stream:stream>
Step 10: Server1 initiates a new stream to Server2: Step 10: Server1 initiates a new stream to Server2:
<stream:stream <stream:stream
xmlns='jabber:server' xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams' xmlns:stream='http://etherx.jabber.org/streams'
to='montague.net' to='montague.net'
version='1.0'> version='1.0'>
Step 11: Server2 responds by sending a stream header to Server1 along Step 11: Server2 responds by sending a stream header to Server1 along
with any additional features (or an empty features element): with any additional features (or an empty features element):
skipping to change at page 47, line 6 skipping to change at page 47, line 6
or context of the message, presence, or IQ stanza. The particular or context of the message, presence, or IQ stanza. The particular
allowable values for the 'type' attribute vary depending on whether allowable values for the 'type' attribute vary depending on whether
the stanza is a message, presence, or IQ, and thus are defined in the the stanza is a message, presence, or IQ, and thus are defined in the
following sections. following sections.
8.2.5 xml:lang 8.2.5 xml:lang
A stanza SHOULD possess an 'xml:lang' attribute (as defined in A stanza SHOULD possess an 'xml:lang' attribute (as defined in
Section 2.12 of the XML specification [1]) if the stanza contains XML Section 2.12 of the XML specification [1]) if the stanza contains XML
character data that is intended to be presented to a human user (as character data that is intended to be presented to a human user (as
explained in RFC 2277 [31], "internationalization is for humans"). explained in RFC 2277 [20], "internationalization is for humans").
The value of the 'xml:lang' attribute specifies the default language The value of the 'xml:lang' attribute specifies the default language
of any such XML character data, which MAY be overridden by the of any such XML character data, which MAY be overridden by the
'xml:lang' attribute of a specific child element. The value of the 'xml:lang' attribute of a specific child element. The value of the
attribute MUST be an NMTOKEN and MUST conform to the format defined attribute MUST be an NMTOKEN and MUST conform to the format defined
in RFC 3066 [17]. in RFC 3066 [17].
8.3 Message Stanzas 8.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
skipping to change at page 47, line 42 skipping to change at page 47, line 42
o headline o headline
o normal o normal
A message stanza with a different value, or without a 'type' A message stanza with a different value, or without a 'type'
attribute, SHOULD be handled as if the 'type' were "normal". attribute, SHOULD be handled as if the 'type' were "normal".
For information regarding the meaning of these message types in the For information regarding the meaning of these message types in the
context of XMPP-based instant messaging and presence applications, context of XMPP-based instant messaging and presence applications,
refer to XMPP IM [23]. refer to XMPP IM [24].
8.3.2 Children 8.3.2 Children
As described under extended namespaces (Section 8.6), a message As described under extended namespaces (Section 8.6), a message
stanza MAY contain any properly-namespaced child element. stanza MAY contain any properly-namespaced child element.
In accordance with the default namespace declaration, by default a In accordance with the default namespace declaration, by default a
message stanza is in the 'jabber:client' or 'jabber:server' message stanza is in the 'jabber:client' or 'jabber:server'
namespace, which defines certain allowable children of message namespace, which defines certain allowable children of message
stanzas. If the message stanza is of type "error", it MUST include an stanzas. If the message stanza is of type "error", it MUST include an
skipping to change at page 49, line 50 skipping to change at page 49, line 50
previously-granted subscription has been cancelled. previously-granted subscription has been cancelled.
o probe -- A request for an entity's current presence; in general, o probe -- A request for an entity's current presence; in general,
SHOULD NOT be sent by a client. SHOULD NOT be sent by a client.
o error -- An error has occurred regarding processing or delivery of o error -- An error has occurred regarding processing or delivery of
a previously-sent presence stanza. a previously-sent presence stanza.
For information regarding presence semantics and the subscription For information regarding presence semantics and the subscription
model used in the context of XMPP-based instant messaging and model used in the context of XMPP-based instant messaging and
presence applications, refer to XMPP IM [23]. presence applications, refer to XMPP IM [24].
8.4.2 Children 8.4.2 Children
As described under extended namespaces (Section 8.6), a presence As described under extended namespaces (Section 8.6), a presence
stanza MAY contain any properly-namespaced child element. stanza MAY contain any properly-namespaced child element.
In accordance with the default namespace declaration, by default a In accordance with the default namespace declaration, by default a
presence stanza is in the 'jabber:client' or 'jabber:server' presence stanza is in the 'jabber:client' or 'jabber:server'
namespace, which defines certain allowable children of presence namespace, which defines certain allowable children of presence
stanzas. If the presence stanza is of type "error", it MUST include stanzas. If the presence stanza is of type "error", it MUST include
skipping to change at page 50, line 47 skipping to change at page 50, line 47
o away o away
o chat o chat
o dnd o dnd
o xa o xa
For information regarding the meaning of these values in the context For information regarding the meaning of these values in the context
of XMPP-based instant messaging and presence applications, refer to of XMPP-based instant messaging and presence applications, refer to
XMPP IM [23]. XMPP IM [24].
8.4.2.2 Status 8.4.2.2 Status
The OPTIONAL <status/> element contains a natural-language The OPTIONAL <status/> element contains a natural-language
description of availability status. It is normally used in description of availability status. It is normally used in
conjunction with the show element to provide a detailed description conjunction with the show element to provide a detailed description
of an availability state (e.g., "In a meeting"). The <status/> of an availability state (e.g., "In a meeting"). The <status/>
element SHOULD NOT possess any attributes, with the exception of the element SHOULD NOT possess any attributes, with the exception of the
'xml:lang' attribute. Multiple instances of the <status/> element MAY 'xml:lang' attribute. Multiple instances of the <status/> element MAY
be included but only if each instance possesses an 'xml:lang' be included but only if each instance possesses an 'xml:lang'
attribute with a distinct language value. attribute with a distinct language value.
8.4.2.3 Priority 8.4.2.3 Priority
The OPTIONAL <priority/> element specifies the priority level of the The OPTIONAL <priority/> element specifies the priority level of the
connected resource. The value may be any integer between -128 and connected resource. The value may be any integer between -128 and
+127. Only one <priority/> element MAY be included in a presence +127. Only one <priority/> element MAY be included in a presence
stanza, and it MUST NOT possess any attributes. If no priority is stanza, and it MUST NOT possess any attributes. If no priority is
provided, a server SHOULD consider the priority to be zero. For provided, a server SHOULD consider the priority to be zero. For
information regarding the semantics of priority values in stanza information regarding the semantics of priority values in stanza
routing within instant messaging applications, refer to XMPP IM [23]. routing within instant messaging applications, refer to XMPP IM [24].
8.5 IQ Stanzas 8.5 IQ Stanzas
8.5.1 Overview 8.5.1 Overview
Info/Query, or IQ, is a request-response mechanism, similar in some Info/Query, or IQ, is a request-response mechanism, similar in some
ways to HTTP [32]. IQ stanzas in the 'jabber:client' or ways to HTTP [32]. IQ stanzas in the 'jabber:client' or
'jabber:server' namespace enable an entity to make a request of, and 'jabber:server' namespace enable an entity to make a request of, and
receive a response from, another entity. The data content of the receive a response from, another entity. The data content of the
request and response is defined by the namespace declaration of a request and response is defined by the namespace declaration of a
skipping to change at page 56, line 8 skipping to change at page 55, line 34
The <text/> element is OPTIONAL. If included, it SHOULD be used only The <text/> element is OPTIONAL. If included, it SHOULD be used only
to provide descriptive or diagnostic information that supplements the to provide descriptive or diagnostic information that supplements the
meaning of a defined condition or application-specific condition. It meaning of a defined condition or application-specific condition. It
SHOULD NOT be interpreted programmatically by an application. It SHOULD NOT be interpreted programmatically by an application. It
SHOULD NOT be used as the error message presented to user, but MAY be SHOULD NOT be used as the error message presented to user, but MAY be
shown in addition to the error message associated with the included shown in addition to the error message associated with the included
condition element (or elements). condition element (or elements).
Note: the XML namespace name 'urn:ietf:params:xml:ns:xmpp-stanzas' Note: the XML namespace name 'urn:ietf:params:xml:ns:xmpp-stanzas'
that qualifies the descriptive element adheres to the format defined that qualifies the descriptive element adheres to the format defined
in The IETF XML Registry [25]. in The IETF XML Registry [26].
8.7.3 Defined Conditions 8.7.3 Defined Conditions
The following stanza-related error conditions are defined for use in The following stanza-related error conditions are defined for use in
stanza errors. stanza errors.
o <bad-request/> -- the sender has sent XML that is malformed or o <bad-request/> -- the sender has sent XML that is malformed or
that cannot be processed (e.g., a client-generated stanza includes that cannot be processed (e.g., a client-generated stanza includes
a 'from' address, or an IQ stanza includes an unrecognized value a 'from' address, or an IQ stanza includes an unrecognized value
of the 'type' attribute); the associated error type SHOULD be of the 'type' attribute); the associated error type SHOULD be
skipping to change at page 56, line 48 skipping to change at page 56, line 26
found; the associated error type SHOULD be "cancel". found; the associated error type SHOULD be "cancel".
o <jid-malformed/> -- the value of the 'to' attribute in the o <jid-malformed/> -- the value of the 'to' attribute in the
sender's stanza does not adhere to the syntax defined in sender's stanza does not adhere to the syntax defined in
Addressing Scheme (Section 3); the associated error type SHOULD be Addressing Scheme (Section 3); the associated error type SHOULD be
"modify". "modify".
o <not-allowed/> -- the recipient does not allow any entity to o <not-allowed/> -- the recipient does not allow any entity to
perform the action; the associated error type SHOULD be "cancel". perform the action; the associated error type SHOULD be "cancel".
o <payment-required/> -- the user is not authorized to access the
requested service because payment is required; the associated
error type SHOULD be "auth".
o <recipient-unavailable/> -- the specific recipient requested is o <recipient-unavailable/> -- the specific recipient requested is
currently unavailable; the associated error type SHOULD be "wait". currently unavailable; the associated error type SHOULD be "wait".
o <registration-required/> -- the user is not authorized to access o <registration-required/> -- the user is not authorized to access
the requested service because registration is required; the the requested service because registration is required; the
associated error type SHOULD be "auth". associated error type SHOULD be "auth".
o <remote-server-not-found/> -- a remote server or service specified o <remote-server-not-found/> -- a remote server or service specified
as part or all of the JID of the intended recipient does not as part or all of the JID of the intended recipient does not
exist; the associated error type SHOULD be "cancel". exist; the associated error type SHOULD be "cancel".
skipping to change at page 61, line 22 skipping to change at page 60, line 22
validating the XML elements forwarded to a client or another server; validating the XML elements forwarded to a client or another server;
an implementation MAY choose to provide only validated data elements an implementation MAY choose to provide only validated data elements
but is NOT REQUIRED to do so (although an implementation MUST NOT but is NOT REQUIRED to do so (although an implementation MUST NOT
accept XML that is not well-formed). Clients SHOULD NOT rely on the accept XML that is not well-formed). Clients SHOULD NOT rely on the
ability to send data which does not conform to the schemas, and ability to send data which does not conform to the schemas, and
SHOULD ignore any non-conformant elements or attributes on the 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 schemas are included herein for REQUIRED or recommended, and schemas are included herein for
descriptive purposes only. descriptive purposes only.
9.4 Character Encodings 9.4 Inclusion of Text Declaration
Software implementing XML streams MUST support the UTF-8 (RFC 2279 Implementations SHOULD send a text declaration before sending a
[19]) and UTF-16 (RFC 2781 [20]) transformations of Universal stream header. Applications MUST follow the rules in the XML
Character Set (ISO/IEC 10646-1 [21]) characters. Implementations MUST specification [1] regarding the circumstances under which a text
NOT attempt to use any other encoding for transmitted data. The declaration is included.
encodings of the transmitted and received streams are independent.
Implementations MAY select either UTF-8 or UTF-16 for the transmitted
stream, and SHOULD deduce the encoding of the received stream as
described in the XML specification [1]. For historical reasons,
existing implementations MAY support UTF-8 only.
9.5 Inclusion of Text Declaration 9.5 Character Encodings
An application MAY send a text declaration. Applications MUST follow Implementations MUST support UTF-8 (RFC 2279 [19]) as required by RFC
the rules in the XML specification [1] regarding the circumstances 2277 [20], and SHOULD support UTF-16 (RFC 2781 [21]) for the sake of
under which a text declaration is included. efficiency in encoding certain writing systems. If the character
encoding is not specified in a text declaration sent before the
stream header, implementations SHOULD deduce the encoding as
described in Appendix F of the XML specification [1]. If an
initiating entity attempts to use an encoding that the receiving
entity does not understand, the receiving entity MUST reply with an
<unsupported-encoding/> stream error. Note well that the encodings of
the initial stream and response stream are independent, and MAY be
different.
10. IANA Considerations 10. IANA Considerations
10.1 XML Namespace Name for TLS Data 10.1 XML Namespace Name for TLS Data
A URN sub-namespace for TLS-related data in the Extensible Messaging A URN sub-namespace for TLS-related data in the Extensible Messaging
and Presence Protocol (XMPP) is defined as follows. and Presence Protocol (XMPP) is defined as follows.
URI: urn:ietf:params:xml:ns:xmpp-tls URI: urn:ietf:params:xml:ns:xmpp-tls
skipping to change at page 63, line 24 skipping to change at page 62, line 24
Specification: [RFCXXXX] Specification: [RFCXXXX]
Description: This is the XML namespace name for stanza-related error Description: This is the XML namespace name for stanza-related error
data in the Extensible Messaging and Presence Protocol (XMPP) as data in the Extensible Messaging and Presence Protocol (XMPP) as
defined by [RFCXXXX]. defined by [RFCXXXX].
Registrant Contact: IETF, XMPP Working Group, <xmppwg@jabber.org> Registrant Contact: IETF, XMPP Working Group, <xmppwg@jabber.org>
10.5 Existing Registrations 10.5 Existing Registrations
The IANA registers "xmpp" as a GSSAPI [22] service name, as specified The IANA registers "xmpp" as a GSSAPI [23] service name, as specified
in SASL Definition (Section 6.4). in SASL Definition (Section 6.4).
Additionally, the IANA registers "jabber-client" and "jabber-server" Additionally, the IANA registers "jabber-client" and "jabber-server"
as keywords for TCP ports 5222 and 5269 respectively. These ports as keywords for TCP ports 5222 and 5269 respectively. These ports
SHOULD be used for client-to-server and server-to-server SHOULD be used for client-to-server and server-to-server
communications respectively, but their use is NOT REQUIRED. The use communications respectively, but their use is NOT REQUIRED. The use
of the string "jabber" in these keywords is historical. of the string "jabber" in these keywords is historical.
11. Internationalization Considerations 11. Internationalization Considerations
skipping to change at page 66, line 49 skipping to change at page 65, line 49
service identifier supersedes the earlier use of a "jabber" service service identifier supersedes the earlier use of a "jabber" service
identifier, since the earlier usage did not conform to RFC 2782 identifier, since the earlier usage did not conform to RFC 2782
[18]). If the SRV lookup fails, the fallback is a normal A lookup to [18]). If the SRV lookup fails, the fallback is a normal A lookup to
determine the IP address, using the "jabber-server" port of 5269 determine the IP address, using the "jabber-server" port of 5269
assigned by the Internet Assigned Numbers Authority [5]. assigned by the Internet Assigned Numbers Authority [5].
Server dialback helps protect against domain spoofing, thus making it Server dialback helps protect against domain spoofing, thus making it
more difficult to spoof XML stanzas. It is not a mechanism for more difficult to spoof XML stanzas. It is not a mechanism for
authenticating, securing, or encrypting streams between servers as is authenticating, securing, or encrypting streams between servers as is
done via SASL and TLS. Furthermore, it is susceptible to DNS done via SASL and TLS. Furthermore, it is susceptible to DNS
poisoning attacks unless DNSSec [30] is used, and even if the DNS poisoning attacks unless DNSSec [31] is used, and even if the DNS
information is accurate, dialback cannot protect from attacks where information is accurate, dialback cannot protect from attacks where
the attacker is capable of hijacking the IP address of the remote the attacker is capable of hijacking the IP address of the remote
domain. Domains requiring robust security SHOULD use TLS and SASL. If domain. Domains requiring robust security SHOULD use TLS and SASL. If
SASL is used for server-to-server authentication, dialback SHOULD NOT SASL is used for server-to-server authentication, dialback SHOULD NOT
be used since it is unnecessary. be used since it is unnecessary.
12.4 Order of Layers 12.4 Order of Layers
The order of layers in which protocols MUST be stacked is as follows: The order of layers in which protocols MUST be stacked is as follows:
skipping to change at page 68, line 5 skipping to change at page 67, line 5
for authentication: the SASL DIGEST-MD5 mechanism for authentication: the SASL DIGEST-MD5 mechanism
for confidentiality: TLS (using the TLS_RSA_WITH_3DES_EDE_CBC_SHA for confidentiality: TLS (using the TLS_RSA_WITH_3DES_EDE_CBC_SHA
cipher) cipher)
for both: TLS plus SASL EXTERNAL(using the for both: TLS plus SASL EXTERNAL(using the
TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher supporting client-side TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher supporting client-side
certificates) certificates)
13. Compliance Requirements
This section summarizes the specific aspects of the Extensible
Messaging and Presence Protocol that MUST be supported by servers and
clients in order to be considered compliant implementations, as well
as additional protocol aspects that SHOULD be supported. For
compliance purposes, we draw a distinction between core protocols
(which MUST be supported by any server or client, regardless of the
specific application) and instant messaging protocols (which MUST be
supported only by instant messaging applications built on top of the
core protocols). Compliance requirements that apply to all servers
and clients are specified in this section; compliance requirements
for instant messaging servers and clients are specified in the
corresponding section of XMPP IM [24].
13.1 Servers
A server MUST support the following core protocols in order to be
considered compliant:
o Enforcement of the nodeprep [10] and resourceprep [11] profiles of
stringprep
o XML streams (Section 4) as defined in this document, including
stream encryption (Section 5) using TLS and stream authentication
(Section 6) using SASL
o The basic semantics of the three defined XML stanzas (Section 8)
(i.e., <message/>, <presence/>, and <iq/>)
o Generation (and, where appropriate, handling) of error syntax and
semantics related to streams, TLS, SASL, and XML stanzas
In addition, a server SHOULD support the following core protocol:
o Server dialback (Section 7)
13.2 Clients
A client MUST support the following core protocols in order to be
considered compliant:
o XML streams (Section 4) as defined in this document, including
stream encryption (Section 5) using TLS and stream authentication
(Section 6) using SASL
o The basic semantics of the three defined XML stanzas (Section 8)
(i.e., <message/>, <presence/>, and <iq/>)
o Handling (and, where appropriate, generation) of error syntax and
semantics related to streams, TLS, SASL, and XML stanzas
In addition, a client SHOULD support the following core protocols:
o Generation of addresses in accordance with the nodeprep [10] and
resourceprep [11] profiles of stringprep
14. Differences Between Jabber and XMPP
This section is non-normative.
XMPP has been adapted from the protocols originally developed in the
Jabber open-source community, which can be thought of as "XMPP 0.9".
Because there exists a large installed base of Jabber implementations
and deployments, it may be helpful to specify the key differences
between Jabber and XMPP in order to expedite and encourage upgrades
of those implementations and deployments to XMPP. This section
summarizes the core differences, and the corresponding section of
XMPP IM [24] summarizes the differences that relate specifically to
instant messaging applications.
14.1 Authentication
The client-server authentication protocol developed in Jabber
community uses a basic IQ interaction scoped by the 'jabber:iq:auth'
namespace (documention of this protocol is contained in "JEP-0078:
Non-SASL Authentication", published by the Jabber Software Foundation
[33]). XMPP uses SASL for authentication, as defined in the Stream
Authentication (Section 6) section of this document.
The Jabber community does not currently possess an authentication
protocol for server-to-server communications, only the Server
Dialback (Section 7) protocol to prevent server spoofing. XMPP
augments Server Dialback with a true server-to-server authentication
protocol, as defined in the Stream Authentication (Section 6) section
of this document.
14.2 Channel Encryption
It is common practice in the Jabber community to use SSL for channel
encryption on ports other than 5222 and 5269 (the convention is to
use ports 5223 and 5270). XMPP uses TLS over the IANA-registered
ports for channel encryption, as defined in the Stream Encryption
(Section 5) section of this document.
14.3 JID Processing
JID processing was somewhat loosely defined by the Jabber community
(documentation of forbidden characters and case handling is contained
in "JEP-0029: Definition of Jabber Identifiers", published by the
Jabber Software Foundation [33]). XMPP defines two stringprep [9]
profiles for JID processing: nodeprep [10] and resourceprep [11].
14.4 Error Handling
Stream-related errors are handled in the Jabber community via simple
CDATA text in a <stream:error/> element. In XMPP, stream-related
errors are handled via an extensible mechanism defined in the Stream
Errors (Section 4.6) section of this document.
Stanza-related errors are handled in the Jabber community via
HTTP-style error codes. In XMPP, stanza-related errors are handled
via an extensible mechanism defined in the Stanza Errors (Section
8.7) section of this document. (Documentation of a mapping between
Jabber and XMPP error handling mechanisms is contained in "JEP-0086:
Legacy Errors", published by the Jabber Software Foundation [33].)
14.5 Internationalization
Although use of UTF-8 has always been standard practice within the
Jabber community, the community did not define mechanisms for
specifying the language of human-readable text provided in CDATA
sections. XMPP specifies the use of the 'xml:lang' attribute in such
contexts, as defined in the xml:lang (Section 8.2.5) section of this
document.
14.6 Stream Version Attribute
The Jabber community does not include a 'version' attribute in stream
headers. XMPP specifies inclusion of that attribute, with a value of
'1.0', as a way to signal support for the stream features
(authentication, encryption, etc.) defined in the Version Support
(Section 4.2.1) section of this document.
Normative References Normative 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] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / [2] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging /
Presence Protocol Requirements", RFC 2779, February 2000. Presence Protocol Requirements", RFC 2779, February 2000.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
skipping to change at page 69, line 23 skipping to change at page 72, line 23
[17] Alvestrand, H., "Tags for the Identification of Languages", BCP [17] Alvestrand, H., "Tags for the Identification of Languages", BCP
47, RFC 3066, January 2001. 47, RFC 3066, January 2001.
[18] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for [18] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
February 2000. February 2000.
[19] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC [19] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998. 2279, January 1998.
[20] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", [20] Alvestrand, H., "IETF Policy on Character Sets and Languages",
BCP 18, RFC 2277, January 1998.
[21] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646",
RFC 2781, February 2000. RFC 2781, February 2000.
[21] International Organization for Standardization, "Information [22] 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.
[22] Linn, J., "Generic Security Service Application Program [23] Linn, J., "Generic Security Service Application Program
Interface, Version 2", RFC 2078, January 1997. Interface, Version 2", RFC 2078, January 1997.
Informative References Informative References
[23] Saint-Andre, P. and J. Miller, "XMPP Instant Messaging", [24] Saint-Andre, P. and J. Miller, "XMPP Instant Messaging",
draft-ietf-xmpp-im-14 (work in progress), June 2003. draft-ietf-xmpp-im-16 (work in progress), August 2003.
[24] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform [25] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998, <http://www.ietf.org/rfc/rfc2396.txt>. 1998, <http://www.ietf.org/rfc/rfc2396.txt>.
[25] Mealling, M., "The IANA XML Registry", [26] Mealling, M., "The IANA XML Registry",
draft-mealling-iana-xmlns-registry-05 (work in progress), June draft-mealling-iana-xmlns-registry-05 (work in progress), June
2003. 2003.
[26] Crispin, M., "Internet Message Access Protocol - Version [27] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 2060, December 1996. 4rev1", RFC 2060, December 1996.
[27] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD [28] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD
53, RFC 1939, May 1996. 53, RFC 1939, May 1996.
[28] Newman, C. and J. Myers, "ACAP -- Application Configuration [29] Newman, C. and J. Myers, "ACAP -- Application Configuration
Access Protocol", RFC 2244, November 1997. Access Protocol", RFC 2244, November 1997.
[29] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, [30] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595,
June 1999. June 1999.
[30] Eastlake, D., "Domain Name System Security Extensions", RFC [31] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999. 2535, March 1999.
[31] Alvestrand, H., "IETF Policy on Character Sets and Languages",
BCP 18, RFC 2277, January 1998.
[32] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., [32] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999. HTTP/1.1", RFC 2616, June 1999.
[33] Jabber Software Foundation, "Jabber Software Foundation",
<http://www.jabber.org/>.
Authors' Addresses Authors' Addresses
Peter Saint-Andre Peter Saint-Andre
Jabber Software Foundation Jabber Software Foundation
EMail: stpeter@jabber.org EMail: stpeter@jabber.org
Jeremie Miller Jeremie Miller
Jabber Software Foundation Jabber Software Foundation
skipping to change at page 72, line 31 skipping to change at page 75, line 31
<xs:schema <xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema' xmlns:xs='http://www.w3.org/2001/XMLSchema'
xmlns:xml='http://www.w3.org/XML/1998/namespace' xmlns:xml='http://www.w3.org/XML/1998/namespace'
targetNamespace='urn:ietf:params:xml:ns:xmpp-streams' targetNamespace='urn:ietf:params:xml:ns:xmpp-streams'
xmlns='urn:ietf:params:xml:ns:xmpp-streams' xmlns='urn:ietf:params:xml:ns:xmpp-streams'
elementFormDefault='qualified'> elementFormDefault='qualified'>
<xs:import namespace='http://www.w3.org/XML/1998/namespace' <xs:import namespace='http://www.w3.org/XML/1998/namespace'
schemaLocation='http://www.w3.org/2001/xml.xsd'/> schemaLocation='http://www.w3.org/2001/xml.xsd'/>
<xs:element name='conflict' type='empty'/>
<xs:element name='connection-timeout' type='empty'/> <xs:element name='connection-timeout' type='empty'/>
<xs:element name='host-gone' type='empty'/> <xs:element name='host-gone' type='empty'/>
<xs:element name='host-unknown' type='empty'/> <xs:element name='host-unknown' type='empty'/>
<xs:element name='improper-addressing' type='empty'/> <xs:element name='improper-addressing' type='empty'/>
<xs:element name='internal-server-error' type='empty'/> <xs:element name='internal-server-error' type='empty'/>
<xs:element name='invalid-id' type='empty'/> <xs:element name='invalid-id' type='empty'/>
<xs:element name='invalid-namespace' type='empty'/> <xs:element name='invalid-namespace' type='empty'/>
<xs:element name='nonmatching-hosts' type='empty'/> <xs:element name='nonmatching-hosts' type='empty'/>
<xs:element name='not-authorized' type='empty'/> <xs:element name='not-authorized' type='empty'/>
<xs:element name='policy-violation' type='xs:string'/> <xs:element name='policy-violation' type='empty'/>
<xs:element name='remote-connection-failed' type='empty'/> <xs:element name='remote-connection-failed' type='empty'/>
<xs:element name='resource-constraint' type='empty'/> <xs:element name='resource-constraint' type='empty'/>
<xs:element name='see-other-host' type='xs:string'/> <xs:element name='see-other-host' type='empty'/>
<xs:element name='system-shutdown' type='empty'/> <xs:element name='system-shutdown' type='empty'/>
<xs:element name='undefined-condition' type='empty'/> <xs:element name='undefined-condition' type='empty'/>
<xs:element name='unsupported-encoding' type='empty'/>
<xs:element name='unsupported-stanza-type' type='empty'/> <xs:element name='unsupported-stanza-type' type='empty'/>
<xs:element name='unsupported-version' type='xs:string'/> <xs:element name='unsupported-version' type='empty'/>
<xs:element name='xml-not-well-formed' type='empty'/> <xs:element name='xml-not-well-formed' type='empty'/>
<xs:element name='text' type='xs:string'> <xs:element name='text' type='xs:string'>
<xs:complexType> <xs:complexType>
<xs:attribute ref='xml:lang' use='optional'/> <xs:attribute ref='xml:lang' use='optional'/>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:simpleType name='empty'> <xs:simpleType name='empty'>
<xs:restriction base='xs:string'> <xs:restriction base='xs:string'>
<xs:enumeration value=''/> <xs:enumeration value=''/>
</xs:restriction> </xs:restriction>
skipping to change at page 85, line 45 skipping to change at page 88, line 10
schemaLocation='http://www.w3.org/2001/xml.xsd'/> schemaLocation='http://www.w3.org/2001/xml.xsd'/>
<xs:element name='bad-request' type='empty'/> <xs:element name='bad-request' type='empty'/>
<xs:element name='conflict' type='empty'/> <xs:element name='conflict' type='empty'/>
<xs:element name='feature-not-implemented' type='empty'/> <xs:element name='feature-not-implemented' type='empty'/>
<xs:element name='forbidden' type='empty'/> <xs:element name='forbidden' type='empty'/>
<xs:element name='internal-server-error' type='empty'/> <xs:element name='internal-server-error' type='empty'/>
<xs:element name='item-not-found' type='empty'/> <xs:element name='item-not-found' type='empty'/>
<xs:element name='jid-malformed' type='empty'/> <xs:element name='jid-malformed' type='empty'/>
<xs:element name='not-allowed' type='empty'/> <xs:element name='not-allowed' type='empty'/>
<xs:element name='payment-required' type='empty'/>
<xs:element name='recipient-unavailable' type='empty'/> <xs:element name='recipient-unavailable' type='empty'/>
<xs:element name='registration-required' type='empty'/> <xs:element name='registration-required' type='empty'/>
<xs:element name='remote-server-not-found' type='empty'/> <xs:element name='remote-server-not-found' type='empty'/>
<xs:element name='remote-server-timeout' type='empty'/> <xs:element name='remote-server-timeout' type='empty'/>
<xs:element name='resource-constraint' type='empty'/> <xs:element name='resource-constraint' type='empty'/>
<xs:element name='service-unavailable' type='empty'/> <xs:element name='service-unavailable' type='empty'/>
<xs:element name='subscription-required' type='empty'/> <xs:element name='subscription-required' type='empty'/>
<xs:element name='undefined-condition' type='empty'/> <xs:element name='undefined-condition' type='empty'/>
<xs:element name='unexpected-request' type='empty'/> <xs:element name='unexpected-request' type='empty'/>
skipping to change at page 87, line 10 skipping to change at page 89, line 10
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
Appendix B. Revision History Appendix B. 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.
B.1 Changes from draft-ietf-xmpp-core-15 B.1 Changes from draft-ietf-xmpp-core-16
o Added <conflict/> and <unsupported-encoding/> stream errors.
o Changed the datatype for the <see-other-host/> and
<unsupported-version/> stream errors from 'xs:string' to 'empty'.
o Further clarified server handling of the basic stanza types.
o Further clarified character encoding rules per list discussion.
o Specified meaning of version='1.0' flag in stream headers.
o Added stream closure to SASL failure cases in order to mirror
handling of TLS failures.
o Added section on compliance requirements for server and client
implementations.
o Added non-normative section on differences between Jabber usage
and XMPP specifications.
B.2 Changes from draft-ietf-xmpp-core-15
o Added <connection-timeout/> and <policy-violation/> stream errors. o Added <connection-timeout/> and <policy-violation/> stream errors.
o Added <aborted/> SASL error and clarified <bad-protocol/> error. o Added <aborted/> SASL error and clarified <bad-protocol/> error.
o Made 'id' required for IQ stanzas. o Made 'id' required for IQ stanzas.
B.2 Changes from draft-ietf-xmpp-core-14 B.3 Changes from draft-ietf-xmpp-core-14
o Added SRV lookup for client-to-server communications. o Added SRV lookup for client-to-server communications.
o Changed server SRV record to conform to RFC 2782; specifically, o Changed server SRV record to conform to RFC 2782; specifically,
the service identifier was changed from 'jabber' to the service identifier was changed from 'jabber' to
'jabber-server'. 'jabber-server'.
B.3 Changes from draft-ietf-xmpp-core-13 B.4 Changes from draft-ietf-xmpp-core-13
o Clarified stream restart after successful TLS and SASL o Clarified stream restart after successful TLS and SASL
negotiation. negotiation.
o Clarified requirement for resolution of DNS hostnames. o Clarified requirement for resolution of DNS hostnames.
o Clarified text regarding namespaces. o Clarified text regarding namespaces.
o Clarified examples regarding empty <stream:features/> element. o Clarified examples regarding empty <stream:features/> element.
o Added several more SASL error conditions. o Added several more SASL error conditions.
o Changed <invalid-xml/> stream error to <improper-addressing/> and o Changed <invalid-xml/> stream error to <improper-addressing/> and
added to schema. added to schema.
o Made small editorial changes and fixed several schema errors. o Made small editorial changes and fixed several schema errors.
B.4 Changes from draft-ietf-xmpp-core-12 B.5 Changes from draft-ietf-xmpp-core-12
o Moved server dialback to a separate section; clarified its o Moved server dialback to a separate section; clarified its
security characteristics and its role in the protocol. security characteristics and its role in the protocol.
o Adjusted error handling syntax and semantics per list discussion. o Adjusted error handling syntax and semantics per list discussion.
o Further clarified length of node identifiers and total length of o Further clarified length of node identifiers and total length of
JIDs. JIDs.
o Documented message type='normal'. o Documented message type='normal'.
o Corrected several small errors in the TLS and SASL sections. o Corrected several small errors in the TLS and SASL sections.
o Corrected several errors in the schemas. o Corrected several errors in the schemas.
B.5 Changes from draft-ietf-xmpp-core-11 B.6 Changes from draft-ietf-xmpp-core-11
o Corrected several small errors in the TLS and SASL sections. o Corrected several small errors in the TLS and SASL sections.
o Made small editorial changes and fixed several schema errors. o Made small editorial changes and fixed several schema errors.
B.6 Changes from draft-ietf-xmpp-core-10 B.7 Changes from draft-ietf-xmpp-core-10
o Adjusted TLS content regarding certificate validation process. o Adjusted TLS content regarding certificate validation process.
o Specified that stanza error extensions for specific applications o Specified that stanza error extensions for specific applications
are to be properly namespaced children of the relevant descriptive are to be properly namespaced children of the relevant descriptive
element. element.
o Clarified rules for inclusion of the 'id' attribute. o Clarified rules for inclusion of the 'id' attribute.
o Specified that the 'xml:lang' attribute SHOULD be included (per o Specified that the 'xml:lang' attribute SHOULD be included (per
list discussion). list discussion).
o Made small editorial changes and fixed several schema errors. o Made small editorial changes and fixed several schema errors.
B.7 Changes from draft-ietf-xmpp-core-09 B.8 Changes from draft-ietf-xmpp-core-09
o Fixed several dialback error conditions. o Fixed several dialback error conditions.
o Cleaned up rules regarding TLS and certificate processing based on o Cleaned up rules regarding TLS and certificate processing based on
off-list feedback. off-list feedback.
o Changed <stream-condition/> and <stanza-condition/> elements to o Changed <stream-condition/> and <stanza-condition/> elements to
<condition/>. <condition/>.
o Added or modified several stream and stanza error conditions. o Added or modified several stream and stanza error conditions.
o Specified only one child allowed for IQ, or two if type="error". o Specified only one child allowed for IQ, or two if type="error".
o Fixed several errors in the schemas. o Fixed several errors in the schemas.
B.8 Changes from draft-ietf-xmpp-core-08 B.9 Changes from draft-ietf-xmpp-core-08
o Incorporated list discussion regarding addressing, SASL, TLS, TCP, o Incorporated list discussion regarding addressing, SASL, TLS, TCP,
dialback, namespaces, extensibility, and the meaning of 'ignore' dialback, namespaces, extensibility, and the meaning of 'ignore'
for routers and recipients. for routers and recipients.
o Specified dialback error conditions. o Specified dialback error conditions.
o Made small editorial changes to address RFC Editor requirements. o Made small editorial changes to address RFC Editor requirements.
B.9 Changes from draft-ietf-xmpp-core-07 B.10 Changes from draft-ietf-xmpp-core-07
o Made several small editorial changes. o Made several small editorial changes.
B.10 Changes from draft-ietf-xmpp-core-06 B.11 Changes from draft-ietf-xmpp-core-06
o Added text regarding certificate validation in TLS negotiation per o Added text regarding certificate validation in TLS negotiation per
list discussion. list discussion.
o Clarified nature of XML restrictions per discussion with W3C, and o Clarified nature of XML restrictions per discussion with W3C, and
moved XML Restrictions subsection under "XML Usage within XMPP". moved XML Restrictions subsection under "XML Usage within XMPP".
o Further clarified that XML streams are unidirectional. o Further clarified that XML streams are unidirectional.
o Changed stream error and stanza error namespace names to conform o Changed stream error and stanza error namespace names to conform
to the format defined in The IETF XML Registry [25]. to the format defined in The IETF XML Registry [26].
o Removed note to RFC Editor regarding provisional namespace names. o Removed note to RFC Editor regarding provisional namespace names.
B.11 Changes from draft-ietf-xmpp-core-05 B.12 Changes from draft-ietf-xmpp-core-05
o Added <invalid-namespace/> as a stream error condition. o Added <invalid-namespace/> as a stream error condition.
o Adjusted security considerations per discussion at IETF 56 and on o Adjusted security considerations per discussion at IETF 56 and on
list. list.
B.12 Changes from draft-ietf-xmpp-core-04 B.13 Changes from draft-ietf-xmpp-core-04
o Added server-to-server examples for TLS and SASL. o Added server-to-server examples for TLS and SASL.
o Changed error syntax, rules, and examples based on list o Changed error syntax, rules, and examples based on list
discussion. discussion.
o Added schemas for the TLS, stream error, and stanza error o Added schemas for the TLS, stream error, and stanza error
namespaces. namespaces.
o Added note to RFC Editor regarding provisional namespace names. o Added note to RFC Editor regarding provisional namespace names.
o Made numerous small editorial changes and clarified text o Made numerous small editorial changes and clarified text
throughout. throughout.
B.13 Changes from draft-ietf-xmpp-core-03 B.14 Changes from draft-ietf-xmpp-core-03
o Clarified rules and procedures for TLS and SASL. o Clarified rules and procedures for TLS and SASL.
o Amplified stream error code syntax per list discussion. o Amplified stream error code syntax per list discussion.
o Made numerous small editorial changes. o Made numerous small editorial changes.
B.14 Changes from draft-ietf-xmpp-core-02 B.15 Changes from draft-ietf-xmpp-core-02
o Added dialback schema. o Added dialback schema.
o Removed all DTDs since schemas provide more complete definitions. o Removed all DTDs since schemas provide more complete definitions.
o Added stream error codes. o Added stream error codes.
o Clarified error code "philosophy". o Clarified error code "philosophy".
B.15 Changes from draft-ietf-xmpp-core-01 B.16 Changes from draft-ietf-xmpp-core-01
o Updated the addressing restrictions per list discussion and added o Updated the addressing restrictions per list discussion and added
references to the new nodeprep and resourceprep profiles. references to the new nodeprep and resourceprep profiles.
o Corrected error in Stream Authentication regarding 'version' o Corrected error in Stream Authentication regarding 'version'
attribute. attribute.
o Made numerous small editorial changes. o Made numerous small editorial changes.
B.16 Changes from draft-ietf-xmpp-core-00 B.17 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.
B.17 Changes from draft-miller-xmpp-core-02 B.18 Changes from draft-miller-xmpp-core-02
o Brought Streams Authentication section into line with discussion o Brought Streams Authentication section into line with discussion
on list and at IETF 55 meeting. on list and at IETF 55 meeting.
o Added information about the optional 'xml:lang' attribute per o Added information about the optional 'xml:lang' attribute per
discussion on list and at IETF 55 meeting. discussion on list and at IETF 55 meeting.
o Specified that validation is neither required nor recommended, and o Specified that validation is neither required nor recommended, and
that the formal definitions (DTDs and schemas) are included for that the formal definitions (DTDs and schemas) are included for
descriptive purposes only. descriptive purposes only.
skipping to change at page 94, line 7 skipping to change at page 96, line 7
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees. revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 86 change blocks. 
151 lines changed or deleted 350 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/