draft-ietf-xmpp-core-13.txt   draft-ietf-xmpp-core-14.txt 
Network Working Group P. Saint-Andre Network Working Group P. Saint-Andre
Internet-Draft J. Miller Internet-Draft J. Miller
Expires: December 3, 2003 Jabber Software Foundation Expires: December 22, 2003 Jabber Software Foundation
June 04, 2003 June 23, 2003
XMPP Core XMPP Core
draft-ietf-xmpp-core-13 draft-ietf-xmpp-core-14
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 December 3, 2003. This Internet-Draft will expire on December 22, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This document describes the core features of the Extensible Messaging This document describes the core features of the Extensible Messaging
and Presence Protocol (XMPP), a protocol for streaming XML 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 26 skipping to change at page 2, line 26
2.4 Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.4 Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5 Network . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.5 Network . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Addressing Scheme . . . . . . . . . . . . . . . . . . . . . 8 3. Addressing Scheme . . . . . . . . . . . . . . . . . . . . . 8
3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Domain Identifier . . . . . . . . . . . . . . . . . . . . . 8 3.2 Domain Identifier . . . . . . . . . . . . . . . . . . . . . 8
3.3 Node Identifier . . . . . . . . . . . . . . . . . . . . . . 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.3 Namespace Declarations . . . . . . . . . . . . . . . . . . . 12 4.2.1 Version Support . . . . . . . . . . . . . . . . . . . . . . 12
4.3.1 Stream Namespace Declaration . . . . . . . . . . . . . . . . 12 4.3 Namespace Declarations . . . . . . . . . . . . . . . . . . . 13
4.3.2 Default Namespace Declaration . . . . . . . . . . . . . . . 13
4.4 Stream Features . . . . . . . . . . . . . . . . . . . . . . 13 4.4 Stream Features . . . . . . . . . . . . . . . . . . . . . . 13
4.5 Stream Errors . . . . . . . . . . . . . . . . . . . . . . . 14 4.5 Stream Encryption and Authentication . . . . . . . . . . . . 13
4.5.1 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.6 Stream Errors . . . . . . . . . . . . . . . . . . . . . . . 14
4.5.2 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.6.1 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.5.3 Defined Conditions . . . . . . . . . . . . . . . . . . . . . 15 4.6.2 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.5.4 Application-Specific Conditions . . . . . . . . . . . . . . 16 4.6.3 Defined Conditions . . . . . . . . . . . . . . . . . . . . . 15
4.6 Simple Streams Example . . . . . . . . . . . . . . . . . . . 16 4.6.4 Application-Specific Conditions . . . . . . . . . . . . . . 16
4.7 Simple Streams Example . . . . . . . . . . . . . . . . . . . 17
5. Stream Encryption . . . . . . . . . . . . . . . . . . . . . 19 5. Stream Encryption . . . . . . . . . . . . . . . . . . . . . 19
5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.2 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.2 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.3 Client-to-Server Example . . . . . . . . . . . . . . . . . . 22 5.3 Client-to-Server Example . . . . . . . . . . . . . . . . . . 22
5.4 Server-to-Server Example . . . . . . . . . . . . . . . . . . 23 5.4 Server-to-Server Example . . . . . . . . . . . . . . . . . . 23
6. Stream Authentication . . . . . . . . . . . . . . . . . . . 26 6. Stream Authentication . . . . . . . . . . . . . . . . . . . 26
6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 26 6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.2 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.2 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.3 SASL Errors . . . . . . . . . . . . . . . . . . . . . . . . 28 6.3 SASL Errors . . . . . . . . . . . . . . . . . . . . . . . . 29
6.4 SASL Definition . . . . . . . . . . . . . . . . . . . . . . 29 6.4 SASL Definition . . . . . . . . . . . . . . . . . . . . . . 30
6.5 Client-to-Server Example . . . . . . . . . . . . . . . . . . 29 6.5 Client-to-Server Example . . . . . . . . . . . . . . . . . . 30
6.6 Server-to-Server Example . . . . . . . . . . . . . . . . . . 32 6.6 Server-to-Server Example . . . . . . . . . . . . . . . . . . 33
7. Server Dialback . . . . . . . . . . . . . . . . . . . . . . 36 7. Server Dialback . . . . . . . . . . . . . . . . . . . . . . 37
7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 36 7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 37
7.2 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 38 7.2 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 39
8. XML Stanzas . . . . . . . . . . . . . . . . . . . . . . . . 43 8. XML Stanzas . . . . . . . . . . . . . . . . . . . . . . . . 44
8.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 43 8.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 44
8.2 Common Attributes . . . . . . . . . . . . . . . . . . . . . 43 8.2 Common Attributes . . . . . . . . . . . . . . . . . . . . . 44
8.2.1 to . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 8.2.1 to . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
8.2.2 from . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 8.2.2 from . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
8.2.3 id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 8.2.3 id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
8.2.4 type . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 8.2.4 type . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
8.2.5 xml:lang . . . . . . . . . . . . . . . . . . . . . . . . . . 44 8.2.5 xml:lang . . . . . . . . . . . . . . . . . . . . . . . . . . 45
8.3 Message Stanzas . . . . . . . . . . . . . . . . . . . . . . 45 8.3 Message Stanzas . . . . . . . . . . . . . . . . . . . . . . 46
8.3.1 Types of Message . . . . . . . . . . . . . . . . . . . . . . 45 8.3.1 Types of Message . . . . . . . . . . . . . . . . . . . . . . 46
8.3.2 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 45 8.3.2 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 46
8.4 Presence Stanzas . . . . . . . . . . . . . . . . . . . . . . 46 8.4 Presence Stanzas . . . . . . . . . . . . . . . . . . . . . . 48
8.4.1 Types of Presence . . . . . . . . . . . . . . . . . . . . . 47 8.4.1 Types of Presence . . . . . . . . . . . . . . . . . . . . . 48
8.4.2 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 47 8.4.2 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 48
8.5 IQ Stanzas . . . . . . . . . . . . . . . . . . . . . . . . . 49 8.5 IQ Stanzas . . . . . . . . . . . . . . . . . . . . . . . . . 50
8.5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 49 8.5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 50
8.5.2 Types of IQ . . . . . . . . . . . . . . . . . . . . . . . . 50 8.5.2 Types of IQ . . . . . . . . . . . . . . . . . . . . . . . . 51
8.5.3 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 50 8.5.3 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 51
8.6 Extended Namespaces . . . . . . . . . . . . . . . . . . . . 50 8.6 Extended Namespaces . . . . . . . . . . . . . . . . . . . . 51
8.7 Stanza Errors . . . . . . . . . . . . . . . . . . . . . . . 51 8.7 Stanza Errors . . . . . . . . . . . . . . . . . . . . . . . 52
8.7.1 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 8.7.1 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
8.7.2 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 8.7.2 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
8.7.3 Defined Conditions . . . . . . . . . . . . . . . . . . . . . 53 8.7.3 Defined Conditions . . . . . . . . . . . . . . . . . . . . . 54
8.7.4 Application-Specific Conditions . . . . . . . . . . . . . . 54 8.7.4 Application-Specific Conditions . . . . . . . . . . . . . . 56
9. XML Usage within XMPP . . . . . . . . . . . . . . . . . . . 55 9. XML Usage within XMPP . . . . . . . . . . . . . . . . . . . 57
9.1 Restrictions . . . . . . . . . . . . . . . . . . . . . . . . 55 9.1 Restrictions . . . . . . . . . . . . . . . . . . . . . . . . 57
9.2 Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . 55 9.2 XML Namespace Names and Prefixes . . . . . . . . . . . . . . 57
9.3 Validation . . . . . . . . . . . . . . . . . . . . . . . . . 55 9.2.1 Stream Namespace . . . . . . . . . . . . . . . . . . . . . . 57
9.4 Character Encodings . . . . . . . . . . . . . . . . . . . . 56 9.2.2 Default Namespace . . . . . . . . . . . . . . . . . . . . . 58
9.5 Inclusion of Text Declaration . . . . . . . . . . . . . . . 56 9.2.3 Dialback Namespace . . . . . . . . . . . . . . . . . . . . . 58
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 57 9.3 Validation . . . . . . . . . . . . . . . . . . . . . . . . . 59
10.1 XML Namespace Name for TLS Data . . . . . . . . . . . . . . 57 9.4 Character Encodings . . . . . . . . . . . . . . . . . . . . 59
10.2 XML Namespace Name for SASL Data . . . . . . . . . . . . . . 57 9.5 Inclusion of Text Declaration . . . . . . . . . . . . . . . 59
10.3 XML Namespace Name for Stream Errors . . . . . . . . . . . . 57 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 60
10.4 XML Namespace Name for Stanza Errors . . . . . . . . . . . . 58 10.1 XML Namespace Name for TLS Data . . . . . . . . . . . . . . 60
10.5 Existing Registrations . . . . . . . . . . . . . . . . . . . 58 10.2 XML Namespace Name for SASL Data . . . . . . . . . . . . . . 60
11. Internationalization Considerations . . . . . . . . . . . . 59 10.3 XML Namespace Name for Stream Errors . . . . . . . . . . . . 60
12. Security Considerations . . . . . . . . . . . . . . . . . . 60 10.4 XML Namespace Name for Stanza Errors . . . . . . . . . . . . 61
12.1 High Security . . . . . . . . . . . . . . . . . . . . . . . 60 10.5 Existing Registrations . . . . . . . . . . . . . . . . . . . 61
12.2 Client-to-Server Communications . . . . . . . . . . . . . . 60 11. Internationalization Considerations . . . . . . . . . . . . 62
12.3 Server-to-Server Communications . . . . . . . . . . . . . . 61 12. Security Considerations . . . . . . . . . . . . . . . . . . 63
12.4 Order of Layers . . . . . . . . . . . . . . . . . . . . . . 61 12.1 High Security . . . . . . . . . . . . . . . . . . . . . . . 63
12.5 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . 61 12.2 Client-to-Server Communications . . . . . . . . . . . . . . 63
12.6 Mandatory to Implement Technologies . . . . . . . . . . . . 62 12.3 Server-to-Server Communications . . . . . . . . . . . . . . 64
Normative References . . . . . . . . . . . . . . . . . . . . 63 12.4 Order of Layers . . . . . . . . . . . . . . . . . . . . . . 64
Informative References . . . . . . . . . . . . . . . . . . . 65 12.5 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . 65
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 65 12.6 Mandatory to Implement Technologies . . . . . . . . . . . . 65
A. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . 67 Normative References . . . . . . . . . . . . . . . . . . . . 66
A.1 Stream namespace . . . . . . . . . . . . . . . . . . . . . . 67 Informative References . . . . . . . . . . . . . . . . . . . 68
A.2 Stream error namespace . . . . . . . . . . . . . . . . . . . 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 68
A.3 TLS namespace . . . . . . . . . . . . . . . . . . . . . . . 70 A. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . 69
A.4 SASL namespace . . . . . . . . . . . . . . . . . . . . . . . 70 A.1 Stream namespace . . . . . . . . . . . . . . . . . . . . . . 69
A.5 Dialback namespace . . . . . . . . . . . . . . . . . . . . . 71 A.2 Stream error namespace . . . . . . . . . . . . . . . . . . . 70
A.6 Client namespace . . . . . . . . . . . . . . . . . . . . . . 73 A.3 TLS namespace . . . . . . . . . . . . . . . . . . . . . . . 71
A.7 Server namespace . . . . . . . . . . . . . . . . . . . . . . 77 A.4 SASL namespace . . . . . . . . . . . . . . . . . . . . . . . 71
A.8 Stanza error namespace . . . . . . . . . . . . . . . . . . . 81 A.5 Dialback namespace . . . . . . . . . . . . . . . . . . . . . 73
B. Revision History . . . . . . . . . . . . . . . . . . . . . . 82 A.6 Client namespace . . . . . . . . . . . . . . . . . . . . . . 74
B.1 Changes from draft-ietf-xmpp-core-12 . . . . . . . . . . . . 82 A.7 Server namespace . . . . . . . . . . . . . . . . . . . . . . 78
B.2 Changes from draft-ietf-xmpp-core-11 . . . . . . . . . . . . 82 A.8 Stanza error namespace . . . . . . . . . . . . . . . . . . . 82
B.3 Changes from draft-ietf-xmpp-core-10 . . . . . . . . . . . . 82 B. Revision History . . . . . . . . . . . . . . . . . . . . . . 84
B.4 Changes from draft-ietf-xmpp-core-09 . . . . . . . . . . . . 82 B.1 Changes from draft-ietf-xmpp-core-13 . . . . . . . . . . . . 84
B.5 Changes from draft-ietf-xmpp-core-08 . . . . . . . . . . . . 83 B.2 Changes from draft-ietf-xmpp-core-12 . . . . . . . . . . . . 84
B.6 Changes from draft-ietf-xmpp-core-07 . . . . . . . . . . . . 83 B.3 Changes from draft-ietf-xmpp-core-11 . . . . . . . . . . . . 84
B.7 Changes from draft-ietf-xmpp-core-06 . . . . . . . . . . . . 83 B.4 Changes from draft-ietf-xmpp-core-10 . . . . . . . . . . . . 85
B.8 Changes from draft-ietf-xmpp-core-05 . . . . . . . . . . . . 83 B.5 Changes from draft-ietf-xmpp-core-09 . . . . . . . . . . . . 85
B.9 Changes from draft-ietf-xmpp-core-04 . . . . . . . . . . . . 84 B.6 Changes from draft-ietf-xmpp-core-08 . . . . . . . . . . . . 85
B.10 Changes from draft-ietf-xmpp-core-03 . . . . . . . . . . . . 84 B.7 Changes from draft-ietf-xmpp-core-07 . . . . . . . . . . . . 85
B.11 Changes from draft-ietf-xmpp-core-02 . . . . . . . . . . . . 84 B.8 Changes from draft-ietf-xmpp-core-06 . . . . . . . . . . . . 86
B.12 Changes from draft-ietf-xmpp-core-01 . . . . . . . . . . . . 84 B.9 Changes from draft-ietf-xmpp-core-05 . . . . . . . . . . . . 86
B.13 Changes from draft-ietf-xmpp-core-00 . . . . . . . . . . . . 85 B.10 Changes from draft-ietf-xmpp-core-04 . . . . . . . . . . . . 86
B.14 Changes from draft-miller-xmpp-core-02 . . . . . . . . . . . 85 B.11 Changes from draft-ietf-xmpp-core-03 . . . . . . . . . . . . 86
Intellectual Property and Copyright Statements . . . . . . . 87 B.12 Changes from draft-ietf-xmpp-core-02 . . . . . . . . . . . . 87
B.13 Changes from draft-ietf-xmpp-core-01 . . . . . . . . . . . . 87
B.14 Changes from draft-ietf-xmpp-core-00 . . . . . . . . . . . . 87
B.15 Changes from draft-miller-xmpp-core-02 . . . . . . . . . . . 87
Intellectual Property and Copyright Statements . . . . . . . 89
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
skipping to change at page 7, line 13 skipping to change at page 7, line 13
2.3 Client 2.3 Client
Most clients connect directly to a server over a TCP socket and use Most clients connect directly to a server over a TCP socket and use
XMPP to take full advantage of the functionality provided by a server XMPP to take full advantage of the functionality provided by a server
and any associated services. Although there is no necessary coupling and any associated services. Although there is no necessary coupling
of an XML stream to a TCP socket (e.g., a client COULD connect via of an XML stream to a TCP socket (e.g., a client COULD connect via
HTTP polling or some other mechanism), this specification defines a HTTP polling or some other mechanism), this specification defines a
binding for XMPP to TCP only. Multiple resources (e.g., devices or binding for XMPP to TCP only. Multiple resources (e.g., devices or
locations) MAY connect simultaneously to a server on behalf of each locations) MAY connect simultaneously to a server on behalf of each
authorized client, with each resource connecting over a discrete TCP authorized client, with each resource connecting over a discrete TCP
socket and differentiated by the resource identifier of a JID (e.g., socket and differentiated by the resource identifier of a JID (e.g.,
<user@domain/home> vs. <user@domain/work>) as defined under Section <user@domain/home> vs. <user@domain/work>) as defined under
3. The port registered with the IANA for connections between a client Addressing Scheme (Section 3). The port registered with the IANA for
and a server is 5222 (see Section 10). connections between a client and a server is 5222 (see IANA
Considerations (Section 10)).
2.4 Gateway 2.4 Gateway
A gateway is a special-purpose server-side service whose primary A gateway is a special-purpose server-side service whose primary
function is to translate XMPP into the protocol used by a foreign function is to translate XMPP into the protocol used by a foreign
(non-XMPP) messaging system, as well as to translate the return data (non-XMPP) messaging system, as well as to translate the return data
back into XMPP. Examples are gateways to Internet Relay Chat (IRC), back into XMPP. Examples are gateways to Internet Relay Chat (IRC),
Short Message Service (SMS), SMTP, and legacy instant messaging Short Message Service (SMS), SMTP, and legacy instant messaging
networks such as AIM, ICQ, MSN Messenger, and Yahoo! Instant networks such as AIM, ICQ, MSN Messenger, and Yahoo! Instant
Messenger. Communications between gateways and servers, and between Messenger. Communications between gateways and servers, and between
skipping to change at page 7, line 40 skipping to change at page 7, line 41
Because each server is identified by a network address and because Because each server is identified by a network address and because
server-to-server communications are a straightforward extension of server-to-server communications are a straightforward extension of
the client-to-server protocol, in practice the system consists of a the client-to-server protocol, in practice the system consists of a
network of servers that inter-communicate. Thus user-a@domain1 is network of servers that inter-communicate. Thus user-a@domain1 is
able to exchange messages, presence, and other information with able to exchange messages, presence, and other information with
user-b@domain2. This pattern is familiar from messaging protocols user-b@domain2. This pattern is familiar from messaging protocols
(such as SMTP) that make use of network addressing standards. (such as SMTP) that make use of network addressing standards.
Communications between any two servers are OPTIONAL; if enabled, such Communications between any two servers are OPTIONAL; if enabled, such
communications occur over XML streams that are normally bound to TCP communications occur over XML streams that are normally bound to TCP
sockets, using port 5269 as registered with the IANA (see Section sockets, using port 5269 as registered with the IANA (see IANA
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 [24]. 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
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,
normally over the same TCP connection. 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. information. An XML element sent for the purpose of stream
encryption, stream authentication, or server dialback is not
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 Section 9.4). The server SHOULD then reply with a encoding (see also Character Encodings (Section 9.4)). The server
second XML stream back to the client, again optionally preceded by a SHOULD then reply with a second XML stream back to the client, again
text declaration. Once the client has authenticated with the server optionally preceded by a text declaration. Once the client has
(see Section 6), the client MAY send an unlimited number of XML authenticated with the server (see Section 6), the client MAY send an
stanzas over the stream to any recipient on the network. When the unlimited number of XML stanzas over the stream to any recipient on
client desires to close the stream, it simply sends a closing </ the network. When the client desires to close the stream, it simply
stream> tag to the server (alternatively, the stream may be closed by sends a closing </stream> tag to the server (alternatively, the
the server), after which both the client and server SHOULD close the stream may be closed by the server), after which both the client and
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
manner may wish to view a client's session with a server as manner may wish to view a client's session with a server as
consisting of two open-ended XML documents: one from the client to consisting of two open-ended XML documents: one from the client to
the server and one from the server to the client. From this the server and one from the server to the client. From this
perspective, the root <stream/> element can be considered the perspective, the root <stream/> element can be considered the
document entity for each "document", and the two "documents" are document entity for each "document", and the two "documents" are
built up through the accumulation of XML stanzas sent over the two built up through the accumulation of XML stanzas sent over the two
XML streams. However, this perspective is a convenience only, and XML streams. However, this perspective is a convenience only, and
XMPP does not deal in documents but in XML streams and XML stanzas. XMPP does not deal in documents but in XML streams and XML stanzas.
skipping to change at page 12, line 23 skipping to change at page 12, line 25
o id -- The 'id' attribute SHOULD be used only in the XML stream o id -- The 'id' attribute SHOULD be used only in the XML stream
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 -- If the initiating entity complies with the protocol o version -- The presence of the version attribute set to a value of
defined herein, it MUST include a 'version' attribute in the XML "1.0" indicates compliance with this specification. Detailed rules
stream header it sends to the receiving entity, and it MUST set regarding generation and handling of this attribute are defined
the value of the 'version' attribute to "1.0". If the initiating below.
entity includes the version attribute and the receiving entity
supports XMPP 1.0, the receiving entity MUST reciprocate by
including the attribute in its response.
We can summarize these values 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.3 Namespace Declarations 4.2.1 Version Support
The stream element MUST possess both a stream namespace declaration
and a default namespace declaration (as "namespace declaration" is
defined in the XML namespaces specification [12]).
4.3.1 Stream Namespace Declaration The following rules apply to the generation and handling of the
'version' attribute:
A stream namespace declaration (e.g., 'xmlns:stream') is REQUIRED in 1. If the initiating entity complies with the protocol defined
both XML streams. A compliant entity SHOULD accept any namespace herein, it MUST include the 'version' attribute in the XML stream
prefix on the <stream/> element; however, for historical reasons some header it sends to the receiving entity, and it MUST set the
entities MAY accept only a 'stream' prefix, resulting in the use of a value of the 'version' attribute to "1.0".
<stream:stream/> element as the stream root. The name of the stream
namespace MUST be "http://etherx.jabber.org/streams". The element
names of the <stream/> element and its <features/> and <error/>
children MUST be qualified by the stream namespace prefix in all
instances.
4.3.2 Default Namespace Declaration 2. If the initiating entity includes the 'version' attribute set to
a value of "1.0" in its stream header and the receiving entity
supports XMPP 1.0, the receiving entity MUST reciprocate by
including the 'version' attribute set to a value of "1.0" in its
stream header response.
A default namespace declaration ('xmlns') is REQUIRED and is used in 3. If the initiating entity does not include the 'version' attribute
both XML streams in order to define the allowable first-level in its stream header, the receiving entity still SHOULD include
children of the root stream element. This namespace declaration MUST the 'version' attribute set to a value of "1.0" in its stream
be the same for the initiating stream and the responding stream so header response.
that both streams are qualified consistently. The default namespace
declaration applies to the stream and all stanzas sent within a
stream (unless explicitly qualified by another namespace or the
stream namespace prefix).
Since XML streams function as containers for any XML stanzas sent 4. If the initiating entity includes the 'version' attribute set to
asynchronously between network endpoints, it should be possible to a value other than "1.0", the receiving entity SHOULD include the
qualify an XML stream with any default namespace declaration. At a 'version' attribute set to a value of "1.0" in its stream header
minimum, a compliant implementation MUST support the following two response, but MAY at its discretion generate an
namespaces (for historical reasons, some implementations MAY support <unsupported-version/> stream error and terminate the XML stream
only these two default namespaces): and underlying TCP connection.
o jabber:client -- this default namespace is declared when the 5. If the receiving entity includes the 'version' attribute set to a
stream is used for communications between a client and a server value other than "1.0" in its stream header response, the
initiating entity SHOULD generate an <unsupported-version/>
stream error and terminate the XML stream and underlying TCP
connection.
o jabber:server -- this default namespace is declared when the 4.3 Namespace Declarations
stream is used for communications between two servers
The 'jabber:client' and 'jabber:server' namespaces are nearly The stream element MUST possess both a stream namespace declaration
identical but are used in different contexts (client-to-server and a default namespace declaration (as "namespace declaration" is
communications for 'jabber:client' and server-to-server defined in the XML namespaces specification [12]). For detailed
communications for 'jabber:server'). The only difference between the information regarding the stream namespace and default namespace, see
two is that the 'to' and 'from' attributes are OPTIONAL on stanzas Namespace Names and Prefixes (Section 9.2).
sent within 'jabber:client', whereas they are REQUIRED on stanzas
sent within 'jabber:server'. If a compliant implementation accepts a
stream that is qualified by the 'jabber:client' or 'jabber:server'
namespace, it MUST support all three core stanza types (message,
presence, and IQ) as described herein and defined in the schema.
4.4 Stream Features 4.4 Stream Features
If the initiating entity includes a 'version' attribute set to a If the initiating entity includes the 'version' attribute set to a
value of "1.0" in its initiating stream element, the receiving entity value of "1.0" in its initiating stream element, the receiving entity
MUST send a <features/> child element (prefixed by the stream MUST send a <features/> child element (prefixed by the stream
namespace prefix) to the initiating entity in order to announce any namespace prefix) to the initiating entity in order to announce any
stream-level features that can be negotiated (or capabilities that stream-level features that can be negotiated (or capabilities that
otherwise need to be advertised). Currently this is used for TLS and otherwise need to be advertised). Currently this is used for TLS and
SASL negotiation only, but it could be used for other negotiable SASL negotiation only, but it could be used for other negotiable
features in the future (usage is defined under Stream Encryption features in the future (usage is defined under Stream Encryption
(Section 5) and Section 6 below). If an entity does not understand or (Section 5) and Stream Authentication (Section 6) below). If an
support some features, it SHOULD silently ignore them. entity does not understand or support some features, it SHOULD
silently ignore them.
4.5 Stream Errors 4.5 Stream Encryption and Authentication
XML streams in XMPP 1.0 SHOULD be encrypted as defined under Stream
Encryption (Section 5) and MUST be authenticated as defined under
Stream Authentication (Section 6). If the initiating entity attempts
to send an XML stanza before the stream is authenticated, the
receiving entity SHOULD return a <not-authorized/> stream error to
the initiating entity and then terminate both the XML stream and the
underlying TCP connection.
4.6 Stream Errors
The root stream element MAY contain an <error/> child element that is The root stream element MAY contain an <error/> child element that is
prefixed by the stream namespace prefix. The error child MUST be sent prefixed by the stream namespace prefix. The error child MUST be sent
by a compliant entity (usually a server rather than a client) if it by a compliant entity (usually a server rather than a client) if it
perceives that a stream-level error has occurred. perceives that a stream-level error has occurred.
4.5.1 Rules 4.6.1 Rules
The following rules apply to stream-level errors: The following rules apply to stream-level errors:
o It is assumed that all stream-level errors are unrecoverable; o It is assumed that all stream-level errors are unrecoverable;
therefore, if an error occurs at the level of the stream, the therefore, if an error occurs at the level of the stream, the
entity that detects the error MUST send a stream error to the entity that detects the error MUST send a stream error to the
other entity, send a closing </stream> tag, and terminate the other entity, send a closing </stream> tag, and terminate the
underlying TCP connection. underlying TCP connection.
o If the error occurs while the stream is being set up, the o If the error occurs while the stream is being set up, the
receiving entity MUST still send the opening <stream> tag, include receiving entity MUST still send the opening <stream> tag, include
the <error/> element as a child of the stream element, send the the <error/> element as a child of the stream element, send the
closing </stream> tag, and terminate the underlying TCP closing </stream> tag, and terminate the underlying TCP
connection. In this case, if the initiating entity provides an connection. In this case, if the initiating entity provides an
unknown host in the 'to' attribute (or provides no 'to' attribute unknown host in the 'to' attribute (or provides no 'to' attribute
at all), the server SHOULD provide the server's authoritative at all), the server SHOULD provide the server's authoritative
hostname in the 'from' attribute of the stream header sent before hostname in the 'from' attribute of the stream header sent before
termination. termination.
4.5.2 Syntax 4.6.2 Syntax
The syntax for stream errors is as follows: The syntax for stream errors is as follows:
<stream:error> <stream:error>
<descriptive-element-name <defined-condition xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> <text xmlns='urn:ietf:params:xml:ns:xmpp-streams'>
OPTIONAL descriptive text
</text>
[OPTIONAL application-specific condition element]
</stream:error> </stream:error>
The error element MUST contain a child element that specifies a The <error/> element:
particular stream-level error condition, as defined in the next
section. (Note: the XML namespace name
'urn:ietf:params:xml:ns:xmpp-streams' that qualifies the descriptive
element adheres to the format defined in The IETF XML Registry [25].)
4.5.3 Defined Conditions o MUST contain a child element corresponding to one of the defined
stanza error conditions defined below; this element MUST be
qualified by the 'urn:ietf:params:xml:ns:xmpp-streamstreams'
namespace
o MAY contain a <text/> child containing CDATA that describes the
error in more detail; this element MUST be qualified by the
'urn:ietf:params:xml:ns:xmpp-streams' namespace and SHOULD possess
an 'xml:lang' attribute
o MAY contain a child element for an application-specific error
condition; this element MUST be qualified by an
application-defined namespace, and its structure is defined by
that namespace
The <text/> element is OPTIONAL. If included, it SHOULD be used only
to provide descriptive or diagnostic information that supplements the
meaning of a defined condition or application-specific condition. It
SHOULD NOT be interpreted programmatically by an application. It
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
condition element (or elements).
Note: the XML namespace name 'urn:ietf:params:xml:ns:xmpp-streams'
that qualifies the descriptive element adheres to the format defined
in The IETF XML Registry [25].
4.6.3 Defined Conditions
The following stream-level error conditions are defined: The following stream-level error conditions are defined:
o <host-gone/> -- the value of the 'to' attribute provided by the o <host-gone/> -- the value of the 'to' attribute provided by the
initiating entity in the stream header corresponds to a hostname initiating entity in the stream header corresponds to a hostname
that is no longer hosted by the server. 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
hostname that is hosted by the server. hostname that is hosted by the server.
o <improper-addressing/> -- a stanza sent between two servers lacks
a 'to' or 'from' attribute (or the attribute has no value).
o <internal-server-error/> -- the server has experienced a o <internal-server-error/> -- the server has experienced a
misconfiguration or an otherwise-undefined internal error that misconfiguration or an otherwise-undefined internal error that
prevents it from servicing the stream. prevents it from servicing the stream.
o <invalid-id/> -- the stream ID or dialback ID is invalid or does o <invalid-id/> -- the stream ID or dialback ID is invalid or does
not match an ID previously provided. not match an ID previously provided.
o <invalid-namespace/> -- the stream namespace name is something o <invalid-namespace/> -- the stream namespace name is something
other than "http://etherx.jabber.org/streams" or the dialback other than "http://etherx.jabber.org/streams" or the dialback
namespace name is something other than "jabber:server:dialback". namespace name is something other than "jabber:server:dialback".
skipping to change at page 16, line 18 skipping to change at page 16, line 47
o <unsupported-version/> -- the value of the 'version' attribute o <unsupported-version/> -- the value of the 'version' attribute
provided by the initiating entity in the stream header specifies a provided by the initiating entity in the stream header specifies a
version of XMPP that is not supported by the server; this element version of XMPP that is not supported by the server; this element
MAY contain CDATA specifying the XMPP version(s) supported by the MAY contain CDATA specifying the XMPP version(s) supported by the
server. 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.5.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
contain two child elements, for example: contain two or three child elements:
<stream:error> <stream:error>
<xml-not-well-formed <xml-not-well-formed
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
<text xml:lang='en' xmlns='urn:ietf:params:xml:ns:xmpp-streams'>
Some special application diagnostic information!
</text>
<escape-your-data xmlns='application-ns'/> <escape-your-data xmlns='application-ns'/>
</stream:error> </stream:error>
</stream:stream> </stream:stream>
4.6 Simple Streams Example 4.7 Simple Streams Example
The following is a stream-based session of a client on a server The following is a stream-based session of a client on a server
(where the "C" lines are sent from the client to the server, and the (where the "C" lines are sent from the client to the server, and the
"S" lines are sent from the server to the client): "S" lines are sent from the server to the client):
A basic session: A basic session:
C: <?xml version='1.0'?> C: <?xml version='1.0'?>
<stream:stream <stream:stream
to='shakespeare.lit' to='shakespeare.lit'
skipping to change at page 19, line 19 skipping to change at page 19, line 19
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 [26], POP3 [27], and ACAP [28] protocols as described in RFC 2595
[29]. The namespace name for the STARTTLS extension is [29]. 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 [25].
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
either or both client-to-server communications and server-to-server client-to-server communications, server-to-server communications, or
communications. Servers SHOULD use TLS betweeen two domains for the both. Servers SHOULD use TLS betweeen two domains for the purpose of
purpose of securing server-to-server communications. When the remote securing server-to-server communications. See Mandatory to Implement
domain is already known, the server can verify the credentials of the Technologies (Section 12.6) regarding mechanisms that MUST be
known domain by comparing known keys or certificates. When the remote supported.
domain is not recognized, it may still be possible to verify a
certificate if it is signed by a common trusted authority. Even if
there is no way to verify certificates (e.g., an unknown domain with
a self-signed certificate, or a certificate signed by an unrecognized
authority), if the servers choose to communicate despite the lack of
verified credentials, TLS still SHOULD be used to provide channel
encryption. Finally, see Section 12.6 regarding mechanisms that MUST
be supported.
The following rules apply: The following rules apply:
1. An initiating entity that complies with this specification MUST 1. An initiating entity that complies with this specification MUST
include a 'version' attribute set to a value of "1.0" in the include the 'version' attribute set to a value of "1.0" in the
initiating stream header. initiating stream header.
2. When a receiving entity that complies with this specification 2. If the TLS negotiation occurs between two servers,
receives an initiating stream header that includes a 'version' communications MUST NOT proceed until the DNS hostnames asserted
by the servers have been resolved (see Server-to-Server
Communications (Section 12.3)).
3. When a receiving entity that complies with this specification
receives an initiating stream header that includes the 'version'
attribute set to a value of "1.0", after sending a stream header attribute set to a value of "1.0", after sending a stream header
in reply (including the version flag) it MUST include a in reply (including the version flag) it MUST include a
<starttls/> element (qualified by the <starttls/> element (qualified by the
'urn:ietf:params:xml:ns:xmpp-tls' namespace) along with the list 'urn:ietf:params:xml:ns:xmpp-tls' namespace) along with the list
of other stream features it supports. of other stream features it supports.
3. If the initiating entity chooses to use TLS for stream 4. If the initiating entity chooses to use TLS for stream
encryption, TLS negotiation MUST be completed before proceeding encryption, TLS negotiation MUST be completed before proceeding
to SASL negotiation. to SASL negotiation.
4. The receiving entity MUST consider the TLS negotiation to have 5. The receiving entity MUST consider the TLS negotiation to have
begun immediately after sending the closing ">" of the <proceed/ begun immediately after sending the closing ">" of the <proceed/
> element. The initiating entity MUST consider the TLS > element. The initiating entity MUST consider the TLS
negotiation to have begun immediately after receiving the negotiation to have begun immediately after receiving the
closing ">" of the <proceed/> element from the receiving entity. closing ">" of the <proceed/> element from the receiving entity.
5. The initiating entity MUST validate the certificate presented by 6. The initiating entity MUST validate the certificate presented by
the receiving entity; there are two cases: the receiving entity; there are two cases:
Case 1 -- The initiating entity has been configured with a set Case 1 -- The initiating entity has been configured with a set
of trusted root certificates: Normal certificate validation of trusted root certificates: Normal certificate validation
processing is appropriate, and SHOULD follow the rules processing is appropriate, and SHOULD follow the rules
defined for HTTP over TLS [14]. The trusted roots may be defined for HTTP over TLS [14]. The trusted roots may be
either a well-known public set or a manually configured Root either a well-known public set or a manually configured Root
CA (e.g., an organization's own Certificate Authority or a CA (e.g., an organization's own Certificate Authority or a
self-signed Root CA for the service as described under High self-signed Root CA for the service as described under High
Security (Section 12.1)). This case is RECOMMENDED. Security (Section 12.1)). This case is RECOMMENDED.
Case 2 -- The initiating entity has been configured with the Case 2 -- The initiating entity has been configured with the
receiving entity's self-signed service certificate: Simple receiving entity's self-signed service certificate: Simple
comparison of public keys is appropriate. This case is NOT comparison of public keys is appropriate. This case is NOT
RECOMMENDED (see High Security (Section 12.1) for details). RECOMMENDED (see High Security (Section 12.1) for details).
If the above methods fail, the certificate SHOULD be presented If the above methods fail, the certificate SHOULD be presented
to a user for approval; if presented, the receiver MUST deliver to a human (e.g., an end user or server administrator) for
the entire certificate chain to the user, who SHOULD be given approval; if presented, the receiver MUST deliver the entire
the option to store the Root CA certificate (not the service or certificate chain to the human, who SHOULD be given the option
End Entity certificate) and to not be queried again regarding to store the Root CA certificate (not the service or End Entity
acceptance of the certificate for some reasonable period of certificate) and to not be queried again regarding acceptance of
time. the certificate for some reasonable period of time.
6. If the TLS negotiation is successful, the receiving entity MUST 7. If the TLS negotiation is successful, the receiving entity MUST
discard any knowledge obtained from the initiating entity before discard any knowledge obtained from the initiating entity before
TLS takes effect. TLS takes effect.
7. If the TLS negotiation is successful, the initiating entity MUST 8. If the TLS negotiation is successful, the initiating entity MUST
discard any knowledge obtained from the receiving entity before discard any knowledge obtained from the receiving entity before
TLS takes effect. TLS takes effect.
8. If the TLS negotiation is successful, the receiving entity MUST 9. If the TLS negotiation is successful, the receiving entity MUST
NOT offer the STARTTLS extension to the initiating entity along NOT offer the STARTTLS extension to the initiating entity along
with the other stream features that are offered when the stream with the other stream features that are offered when the stream
is restarted. is restarted.
9. If the TLS negotiation is successful, the initiating entity 10. If the TLS negotiation is successful, the initiating entity
SHOULD continue with SASL negotiation. SHOULD continue with SASL negotiation.
10. If the TLS negotiation results in failure, the receiving entity 11. If the TLS negotiation results in failure, the receiving entity
MUST terminate both the XML stream and the underlying TCP MUST terminate both the XML stream and the underlying TCP
connection. connection.
5.2 Narrative 5.2 Narrative
When an initiating entity secures a stream with a receiving entity, When an initiating entity secures a stream with a receiving entity,
the steps involved are as follows: the steps involved are as follows:
1. The initiating entity opens a TCP connection and initiates the 1. The initiating entity opens a TCP connection and initiates the
stream by sending the opening XML stream header to the receiving stream by sending the opening XML stream header to the receiving
entity, including a 'version' attribute set to a value of "1.0". entity, including the 'version' attribute set to a value of
"1.0".
2. The receiving entity responds by opening a TCP connection and 2. The receiving entity responds by opening a TCP connection and
sending an XML stream header to the initiating entity, including sending an XML stream header to the initiating entity, including
a 'version' attribute set to a value of "1.0". the 'version' attribute set to a value of "1.0".
3. The receiving entity offers the STARTTLS extension to the 3. The receiving entity offers the STARTTLS extension to the
initiating entity by including it with the list of other initiating entity by including it with the list of other
supported stream features (if TLS is required for interaction supported stream features (if TLS is required for interaction
with the receiving entity, it SHOULD signal that fact by with the receiving entity, it SHOULD signal that fact by
including a <required/> element as a child of the <starttls/> including a <required/> element as a child of the <starttls/>
element). element).
4. The initiating entity issues the STARTTLS command (i.e., a 4. The initiating entity issues the STARTTLS command (i.e., a
<starttls/> element qualified by the <starttls/> element qualified by the
skipping to change at page 21, line 45 skipping to change at page 21, line 46
and the underlying TCP connection. If the proceed case occurs, and the underlying TCP connection. If the proceed case occurs,
the receiving entity MUST ignore any further XML data sent over the receiving entity MUST ignore any further XML data sent over
the XML stream but keep the underlying TCP connection open for the XML stream but keep the underlying TCP connection open for
the purpose of completing the TLS negotiation. the purpose of completing the TLS negotiation.
6. The initiating entity and receiving entity attempt to complete a 6. The initiating entity and receiving entity attempt to complete a
TLS negotiation in accordance with RFC 2246 [13]. TLS negotiation in accordance with RFC 2246 [13].
7. If the TLS negotiation is unsuccessful, the receiving entity MUST 7. If the TLS negotiation is unsuccessful, the receiving entity MUST
terminate the TCP connection. If the TLS negotiation is terminate the TCP connection. If the TLS negotiation is
successful, the initiating entity SHOULD initiate a new stream by successful, the initiating entity MUST initiate a new stream by
sending an opening XML stream header to the receiving entity. sending an opening XML stream header to the receiving entity.
8. Upon receiving the new stream header from the initiating entity, 8. Upon receiving the new stream header from the initiating entity,
the receiving entity SHOULD respond by sending a new XML stream the receiving entity MUST respond by sending a new XML stream
header to the initiating entity along with the remaining header to the initiating entity along with the remaining
available features (but NOT including the STARTTLS feature). available features (but NOT including the STARTTLS feature).
5.3 Client-to-Server Example 5.3 Client-to-Server Example
The following example shows the data flow for a client securing a The following example shows the data flow for a client securing a
stream using STARTTLS (the IANA-registered port 5222 SHOULD be used; stream using STARTTLS (the IANA-registered port 5222 SHOULD be used;
see Section 10). see IANA Considerations (Section 10)).
Step 1: Client initiates stream to server: Step 1: Client initiates stream to server:
<stream:stream <stream:stream
xmlns='jabber:client' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams' xmlns:stream='http://etherx.jabber.org/streams'
to='capulet.com' to='capulet.com'
version='1.0'> version='1.0'>
Step 2: Server responds by sending a stream tag to client: Step 2: Server responds by sending a stream tag to client:
skipping to change at page 23, line 42 skipping to change at page 23, line 42
id='12345678' id='12345678'
version='1.0'> version='1.0'>
<stream:features> <stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>DIGEST-MD5</mechanism> <mechanism>DIGEST-MD5</mechanism>
<mechanism>PLAIN</mechanism> <mechanism>PLAIN</mechanism>
<mechanism>EXTERNAL</mechanism> <mechanism>EXTERNAL</mechanism>
</mechanisms> </mechanisms>
</stream:features> </stream:features>
Step 9: Client SHOULD continue with Section 6. Step 9: Client SHOULD continue with Stream Authentication (Section
6).
5.4 Server-to-Server Example 5.4 Server-to-Server Example
The following example shows the data flow for two servers securing a The following example shows the data flow for two servers securing a
stream using STARTTLS (the IANA-registered port 5269 SHOULD be used; stream using STARTTLS (the IANA-registered port 5269 SHOULD be used;
see Section 10). see IANA Considerations (Section 10)).
Step 1: Server1 initiates stream to Server2: Step 1: Server1 initiates 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 2: Server2 responds by sending a stream tag to Server1: Step 2: Server2 responds by sending a stream tag to Server1:
skipping to change at page 25, line 34 skipping to change at page 25, line 34
id='12345678' id='12345678'
version='1.0'> version='1.0'>
<stream:features> <stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>DIGEST-MD5</mechanism> <mechanism>DIGEST-MD5</mechanism>
<mechanism>KERBEROS_V4</mechanism> <mechanism>KERBEROS_V4</mechanism>
<mechanism>EXTERNAL</mechanism> <mechanism>EXTERNAL</mechanism>
</mechanisms> </mechanisms>
</stream:features> </stream:features>
Step 9: Server1 SHOULD continue with Section 6. Step 9: Server1 SHOULD continue with Stream Authentication (Section
6).
6. Stream Authentication 6. Stream Authentication
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 Section 12.6 defined in The IETF XML Registry [25]). Finally, see Mandatory to
regarding mechanisms that MUST be supported. Implement Technologies (Section 12.6) regarding mechanisms that MUST
be supported.
The following rules apply: The following rules apply:
1. If TLS is used for stream encryption, SASL SHOULD NOT be used for 1. If the SASL negotiation occurs between two servers,
communications MUST NOT proceed until the DNS hostnames asserted
by the servers have been resolved (see Server-to-Server
Communications (Section 12.3)).
2. If TLS is used for stream encryption, SASL SHOULD NOT be used for
anything except stream authentication (i.e., a security layer anything except stream authentication (i.e., a security layer
SHOULD NOT be negotiated using SASL). Conversely, if a security SHOULD NOT be negotiated using SASL). Conversely, if a security
layer is to be negotiated via SASL, TLS SHOULD NOT be used. layer is to be negotiated via SASL, TLS SHOULD NOT be used.
2. If the initiating entity is capable of authenticating via SASL, 3. If the initiating entity is capable of authenticating via SASL,
it MUST include a 'version' attribute set to a value of "1.0" in it MUST include the 'version' attribute set to a value of "1.0"
the initiating stream header. in the initiating stream header.
3. If the receiving entity is capable of negotiating authentication 4. If the receiving entity is capable of negotiating authentication
via SASL, it MUST send one or more authentication mechanisms via SASL, it MUST send one or more authentication mechanisms
within a <mechanisms/> element qualified by the within a <mechanisms/> element qualified by the
'urn:ietf:params:xml:ns:xmpp-sasl' namespace in response to the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace in response to the
opening stream tag received from the initiating entity (if the opening stream tag received from the initiating entity (if the
opening stream tag included a 'version' attribute set to a value opening stream tag included the 'version' attribute set to a
of "1.0"). value of "1.0").
4. If the SASL negotiation involves negotiation of a security layer, 5. Upon successful SASL negotiation that involves negotiation of a
the receiving entity MUST discard any knowledge obtained from the security layer, the receiving entity MUST discard any knowledge
initiating entity which was not obtained from the SASL obtained from the initiating entity which was not obtained from
negotiation itself. the SASL negotiation itself.
5. If the SASL negotiation involves negotiation of a security layer, 6. Upon successful SASL negotiation that involves negotiation of a
the initiating entity MUST discard any knowledge obtained from security layer, the initiating entity MUST discard any knowledge
the receiving entity which was not obtained from the SASL obtained from the receiving entity which was not obtained from
negotiation itself. the SASL negotiation itself.
6. The SASL negotiation MUST include an authzid, and the 7. The initiating entity MUST provide an authzid during SASL
authzid-value MUST be a valid JID of the form <domain> (i.e., a negotiation. The authzid-value MUST be a valid JID of the form
domain identifier only) for servers and of the form <user@domain/ <domain> (i.e., a domain identifier only) for servers and of the
resource> (i.e., node identifier, domain identifier, and resource form <user@domain/resource> (i.e., node identifier, domain
identifier) for clients. identifier, and resource identifier) for clients. The initiating
entity MAY process the authzid-value in accordance with the rules
defined in Addressing Scheme (Section 3) before providing it to
the receiving entity, but is NOT REQUIRED to do so.
8. Any character data contained within the XML elements used during
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 a 1. The initiating entity requests SASL authentication by including
'version' attribute in the opening XML stream header sent to the the 'version' attribute in the opening XML stream header sent to
receiving entity, with the value set to "1.0". the receiving entity, with the value set to "1.0".
2. After sending an XML stream header in response, the receiving 2. After sending an XML stream header in response, the receiving
entity sends a list of available SASL authentication mechanisms; entity sends a list of available SASL authentication mechanisms;
each of these is a <mechanism/> element included as a child each of these is a <mechanism/> element included as a child
within a <mechanisms/> container element qualified by the within a <mechanisms/> container element qualified by the
'urn:ietf:params:xml:ns:xmpp-sasl' namespace, which in turn is a 'urn:ietf:params:xml:ns:xmpp-sasl' namespace, which in turn is a
child of a <features/> element in the streams namespace. If child of a <features/> element in the streams namespace. If
channel encryption must be established before a particular channel encryption needs to be established before a particular
authentication mechanism may be used, the receiving entity MUST authentication mechanism may be used, the receiving entity MUST
NOT provide that mechanism in the list of available SASL NOT provide that mechanism in the list of available SASL
authentication methods prior to channel encryption. If the authentication methods prior to channel encryption. If the
initiating entity presents a valid certificate during prior TLS initiating entity presents a valid certificate during prior TLS
negotiation, the receiving entity MAY offer the SASL EXTERNAL negotiation, the receiving entity MAY offer the SASL EXTERNAL
mechanism to the initiating entity during stream authentication mechanism to the initiating entity during stream authentication
(see RFC 2222 [15]). (refer to RFC 2222 [15]).
3. The initiating entity selects a mechanism by sending an <auth/> 3. The initiating entity selects a mechanism by sending an <auth/>
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 and including an appropriate namespace to the receiving entity and including an appropriate
value for the 'mechanism' attribute; this element MAY optionally value for the 'mechanism' attribute; this element MAY optionally
contain character data (in SASL terminology the "initial contain character data (in SASL terminology the "initial
response") if the mechanism supports or requires it. If the response") if the mechanism supports or requires it. If the
initiating entity selects the EXTERNAL mechanism for initiating entity selects the EXTERNAL mechanism for
authentication, the authentication credentials shall be taken authentication, the authentication credentials shall be taken
from the certificate presented during prior TLS negotiation. from the certificate presented during prior TLS negotiation.
skipping to change at page 28, line 12 skipping to change at page 28, line 24
MUST be computed in accordance with the SASL mechanism chosen by MUST be computed in accordance with the SASL mechanism chosen by
the initiating entity). the initiating entity).
6. If necessary, the receiving entity sends more challenges and the 6. If necessary, the receiving entity sends more challenges and the
initiating entity sends more responses. initiating entity sends more responses.
This series of challenge/response pairs continues until one of three This series of challenge/response pairs continues until one of three
things happens: things happens:
1. The initiating entity aborts the handshake by sending an <abort/> 1. The initiating entity aborts the handshake by sending an <abort/>
element to the receiving entity. element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl'
namespace to the receiving entity. Upon receiving the <abort/>
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 Section 6.3. under SASL Errors (Section 6.3)). Immediately after sending the
<failure/> element, the receiving entity MUST terminate the 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"). SASL terminology "additional data with success"). Upon receiving
the <success/> element, the initiating entity MUST initiate a new
Any character data contained within these elements MUST be encoded stream by sending an opening XML stream header to the receiving
using base64. entity (it is not necessary to send a closing </stream:stream>
element first, since the receiving entity and initiating entity
MUST consider the original stream to be closed upon sending or
receiving the <success/> element). Upon receiving the new stream
header from the initiating entity, the receiving entity MUST
respond by sending a new XML stream header to the initiating
entity, along with any remaining available features (but NOT
including the STARTTLS feature or any authentication mechanisms)
or an empty features element (to signify that no additional
features are available); note that any such additional features
are not defined herein, and MUST be defined by the relevant
extension to XMPP.
6.3 SASL Errors 6.3 SASL Errors
The following SASL-related error conditions are defined: The following SASL-related error conditions are defined:
o <bad-protocol/> -- The data provided by the initiating entity does
not adhere to the protocol for the requested mechanism; sent in
response to the <response/> element.
o <encryption-required/> -- The mechanism chosen by the initiating o <encryption-required/> -- The mechanism chosen by the initiating
entity may be used only if the stream is already encrypted; entity may be used only if the stream is already encrypted; sent
provided in response to the <auth/> element. in response to the <auth/> element.
o <invalid-authzid/> -- The authzid provided by the initiating o <invalid-authzid/> -- The authzid provided by the initiating
entity is invalid, either because it is incorrectly formatted or entity is invalid, either because it is incorrectly formatted or
because the initiating entity does not have permissions to because the initiating entity does not have permissions to
authorize that ID; provided in response to a <response/> element. authorize that ID; sent in response to a <response/> element.
o <invalid-mechanism/> -- The initiating entity did not provide a
mechanism or requested a mechanism that is not supported by the
receiving entity; sent in response to the <auth/> element.
o <invalid-realm/> -- The realm provided by the initiating entity o <invalid-realm/> -- The realm provided by the initiating entity
(in mechanisms that support the concept of a realm) does not match (in mechanisms that support the concept of a realm) does not match
one of the hostnames served by the receiving entity; provided in one of the hostnames served by the receiving entity; sent in
response to a <response/> element. response to a <response/> element.
o <mechanism-too-weak/> -- The mechanism chosen by the initiating o <mechanism-too-weak/> -- The mechanism requested by the initiating
entity is weaker than server policy permits for that initiating entity is weaker than server policy permits for that initiating
entity; provided in response to the <auth/> element. entity; sent in response to the <response/> element.
o <not-authorized/> -- The authentication failed because the
initiating entity did not provide valid credentials (this includes
the case of an unknown username); sent in response to a <response/
> element.
o <temporary-auth-failure/> -- The authentication failed because of o <temporary-auth-failure/> -- The authentication failed because of
a temporary error condition within the receiving entity; provided a temporary error condition within the receiving entity; sent in
in response to an <auth/> element or <response/> element. response to an <auth/> element or <response/> element.
6.4 SASL Definition 6.4 SASL Definition
Section 4 of the SASL specification [15] requires that the following Section 4 of the SASL specification [15] requires that the following
information be supplied by a protocol definition: information be supplied by a protocol definition:
service name: "xmpp" service name: "xmpp"
initiation sequence: After the initiating entity provides an opening initiation sequence: After the initiating entity provides an opening
XML stream header and the receiving entity replies in kind, the XML stream header and the receiving entity replies in kind, the
skipping to change at page 29, line 29 skipping to change at page 30, line 27
'mechanism' attribute possessed by an <auth/> element, optionally 'mechanism' attribute possessed by an <auth/> element, optionally
including an initial response to avoid a round trip. including an initial response to avoid a round trip.
exchange sequence: Challenges and responses are carried through the exchange sequence: Challenges and responses are carried through the
exchange of <challenge/> elements from receiving entity to exchange of <challenge/> elements from receiving entity to
initiating entity and <response/> elements from initiating entity initiating entity and <response/> elements from initiating entity
to receiving entity. The receiving entity reports failure by to receiving entity. The receiving entity reports failure by
sending a <failure/> element and success by sending a <success/> sending a <failure/> element and success by sending a <success/>
element; the initiating entity aborts the exchange by sending an element; the initiating entity aborts the exchange by sending an
<abort/> element. (All of these elements are qualified by the <abort/> element. (All of these elements are qualified by the
'urn:ietf:params:xml:ns:xmpp-sasl' namespace.) 'urn:ietf:params:xml:ns:xmpp-sasl' namespace.) Upon successful
negotiation, both sides consider the original XML stream closed
and new <stream> headers are sent by both entities.
security layer negotiation: If a security layer is negotiated, both security layer negotiation: The security layer takes effect
sides consider the original stream closed and new <stream> headers immediately after sending the closing ">" character of the
are sent by both entities. The security layer takes effect <success/> element for the server, and immediately after receiving
immediately following the ">" character of the <response/> element the closing ">" character of the <success/> element for the client
for the client and immediately following the closing ">" character (this element is qualified by the
of the <succeed/> element for the server. (Both of these elements 'urn:ietf:params:xml:ns:xmpp-sasl' namespace).
are qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl'
namespace.)
use of the authorization identity: The authorization identity is used use of the authorization identity: The authorization identity is used
by xmpp to denote the "full JID" (<user@domain/resource>) of a by xmpp to denote the "full JID" (<user@domain/resource>) of a
client or the sending domain of a server. client or the sending domain of a server.
6.5 Client-to-Server Example 6.5 Client-to-Server Example
The following example shows the data flow for a client authenticating The following example shows the data flow for a client authenticating
with a server using SASL (the IANA-registered port 5222 SHOULD be with a server using SASL (the IANA-registered port 5222 SHOULD be
used; see Section 10). used; see IANA Considerations (Section 10)).
Step 1: Client initiates stream to server: Step 1: Client initiates stream to server:
<stream:stream <stream:stream
xmlns='jabber:client' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams' xmlns:stream='http://etherx.jabber.org/streams'
to='capulet.com' to='capulet.com'
version='1.0'> version='1.0'>
Step 2: Server responds with a stream tag sent to client: Step 2: Server responds with a stream tag sent to client:
skipping to change at page 30, line 26 skipping to change at page 31, line 26
xmlns='jabber:client' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams' xmlns:stream='http://etherx.jabber.org/streams'
id='12345678' id='12345678'
from='capulet.com' from='capulet.com'
version='1.0'> version='1.0'>
Step 3: Server informs client of available authentication mechanisms: Step 3: Server informs client of available authentication mechanisms:
<stream:features> <stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>PLAIN</mechanism>
<mechanism>OTP</mechanism>
<mechanism>DIGEST-MD5</mechanism> <mechanism>DIGEST-MD5</mechanism>
<mechanism>CRAM-MD5</mechanism> <mechanism>PLAIN</mechanism>
<mechanism>ANONYMOUS</mechanism>
</mechanisms> </mechanisms>
</stream:features> </stream:features>
Step 4: Client selects an authentication mechanism: Step 4: Client selects an authentication mechanism:
<auth <auth
xmlns='urn:ietf:params:xml:ns:xmpp-sasl' xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
mechanism='DIGEST-MD5'/> mechanism='DIGEST-MD5'/>
Step 5: Server sends a base64-encoded challenge to client: Step 5: Server sends a base64-encoded challenge to client:
<challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
bm9uY2U9Imd4MFAwMVJSVm9PZkpWcklKNmFOa0ZsaW5oOW5NL1VwOWRhel cmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIi
ZURlRxMWM9IixyZWFsbT0iY2FwdWxldC5jb20iLHFvcD0iYXV0aCxhdXRo xxb3A9ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNz
LWludCxhdXRoLWNvbmYiLGNpcGhlcj0icmM0LTQwLHJjNC01NixyYzQsZG
VzLDNkZXMiLG1heGJ1Zj0yMDQ4LGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGht
PW1kNS1zZXNz
</challenge> </challenge>
The decoded challenge is: The decoded challenge is:
nonce="gx0P01RRVoOfJVrIJ6aNkFlinh9nM/Up9dazVTFTq1c=",\ realm="cataclysm.cx",nonce="OA6MG9tEQGm2hh",\
realm="capulet.com",qop="auth,auth-int,auth-conf",\ qop="auth",charset=utf-8,algorithm=md5-sess
cipher="rc4-40,rc4-56,rc4,des,3des",maxbuf=2048,\
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>
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'>
dXNlcm5hbWU9Imp1bGlldCIscmVhbG09ImNhcHVsZXQuY29tIixhdXRoem dXNlcm5hbWU9InJvYiIscmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik
lkPSJqdWxpZXRAY2FwdWxldC5jb20vYmFsY29ueSIsbm9uY2U9Imd4MFAw 9BNk1HOXRFUUdtMmhoIixjbm9uY2U9Ik9BNk1IWGg2VnFUclJrIixuYz0w
MVJSVm9PZkpWcklKNmFOa0ZsaW5oOW5NL1VwOWRhelZURlRxMWM9Iixjbm MDAwMDAwMSxxb3A9YXV0aCxkaWdlc3QtdXJpPSJ4bXBwL2NhdGFjbHlzbS
9uY2U9ImJkaTdVL0R1aGQ5N2ZmWHBTOW1OaGhLM2NpWTBGR085eHVxSWxh 5jeCIscmVzcG9uc2U9ZDM4OGRhZDkwZDRiYmQ3NjBhMTUyMzIxZjIxNDNh
cEJLNG89IixuYz0wMDAwMDAwMSxxb3A9YXV0aC1jb25mLGNpcGhlcj0icm ZjcsY2hhcnNldD11dGYtOCxhdXRoemlkPSJyb2JAY2F0YWNseXNtLmN4L2
M0IixtYXhidWY9MjA0OCxkaWdlc3QtdXJpPSJ4bXBwL2NhcHVsZXQuY29t 15UmVzb3VyY2Ui
IixyZXNwb25zZT04ZTBhYzYwMTA4MzNiMTIyNGZjYzQ3NDJhZmJkYjM1Mg
==
</response> </response>
The decoded response is: The decoded response is:
username="juliet",realm="capulet.com",\ username="rob",realm="cataclysm.cx",\
authzid="juliet@capulet.com/balcony",\ nonce="OA6MG9tEQGm2hh",cnonce="OA6MHXh6VqTrRk",\
nonce="gx0P01RRVoOfJVrIJ6aNkFlinh9nM/Up9dazVTFTq1c=",\ nc=00000001,qop=auth,digest-uri="xmpp/cataclysm.cx",\
cnonce="bdi7U/Duhd97ffXpS9mNhhK3ciY0FGO9xuqIlapBK4o=",\ response=d388dad90d4bbd760a152321f2143af7,charset=utf-8,\
nc=00000001,qop=auth-conf,cipher="rc4",maxbuf=2048,\ authzid="rob@cataclysm.cx/myResource"
digest-uri="xmpp/capulet.com",\
response=8e0ac6010833b1224fcc4742afbdb352
Step 7: Server sends another challenge to client: Step 7: Server sends another challenge to client:
<challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
cnNwYXV0aD1mMTBjYjIzNTYwY2NmZTVjNDQxNzQ4OGEzZWRkZjc3NA== cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA==
</challenge> </challenge>
The decoded challenge is: The decoded challenge is:
rspauth=f10cb23560ccfe5c4417488a3eddf774 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>
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>
skipping to change at page 32, line 32 skipping to change at page 33, line 22
</failure> </failure>
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, with Step 11: Server responds by sending a stream header to client along
the stream already authenticated (not followed by further stream with any additional features (or an empty features element):
features):
<stream:stream <stream:stream
xmlns='jabber:client' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams' xmlns:stream='http://etherx.jabber.org/streams'
id='12345678' id='12345678'
from='capulet.com' from='capulet.com'
version='1.0'> version='1.0'>
<stream:features/>
6.6 Server-to-Server Example 6.6 Server-to-Server Example
The following example shows the data flow for a server authenticating The following example shows the data flow for a server authenticating
with another server using SASL (the IANA-registered port 5269 SHOULD with another server using SASL (the IANA-registered port 5269 SHOULD
be used; see Section 10). be used; see IANA Considerations (Section 10)).
Step 1: Server1 initiates stream to Server2: Step 1: Server1 initiates 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 2: Server2 responds with a stream tag sent to Server1: Step 2: Server2 responds with a stream tag sent to Server1:
<stream:stream <stream:stream
xmlns='jabber:server' xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams' xmlns:stream='http://etherx.jabber.org/streams'
from='montague.net' from='montague.net'
id='12345678' id='12345678'
version='1.0'> version='1.0'>
Step 3: Server2 informs Server1 of available authentication Step 3: Server2 informs Server1 of available authentication
skipping to change at page 35, line 4 skipping to change at page 35, line 43
<invalid-authzid/> <invalid-authzid/>
</failure> </failure>
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>
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, with Step 11: Server2 responds by sending a stream header to Server1 along
the stream already authenticated (not followed by further stream with any additional features (or an empty features element):
features):
<stream:stream <stream:stream
xmlns='jabber:client' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams' xmlns:stream='http://etherx.jabber.org/streams'
from='montague.net' from='montague.net'
id='12345678' id='12345678'
version='1.0'> version='1.0'>
<stream:features/>
7. Server Dialback 7. Server Dialback
7.1 Overview 7.1 Overview
The Jabber protocol from which XMPP was adapted includes a "server The Jabber protocol from which XMPP was adapted includes a "server
dialback" method for protecting against domain spoofing, thus making dialback" method for protecting against domain spoofing, thus making
it more difficult to spoof XML stanzas (see Section 12.3 regarding it more difficult to spoof XML stanzas (see Server-to-Server
this method's security characteristics). Server dialback also makes Communications (Section 12.3) regarding this method's security
it easier to deploy systems in which outbound messages and inbound characteristics). Server dialback also makes it easier to deploy
messages are handled by different machines for the same domain. The systems in which outbound messages and inbound messages are handled
server dialback method is made possible by the existence of DNS, by different machines for the same domain. The server dialback method
since one server can (normally) discover the authoritative server for is made possible by the existence of DNS, since one server can
a given domain. All DNS hostname resolutions MUST first resolve the (normally) discover the authoritative server for a given domain.
hostname using an SRV [18] record of _jabber._tcp.server (the use of
the string "jabber" for SRV purposes is historical). If the SRV Because dialback depends on the Domain Name System, inter-domain
lookup fails, the fallback is a normal A lookup to determine the IP communications MUST NOT proceed until the DNS hostnames asserted by
address, using the jabber-server port of 5269 assigned by the the servers have been resolved (see Server-to-Server Communications
Internet Assigned Numbers Authority [5]. (Section 12.3)).
The method for generating and verifying the keys used in server The method for generating and verifying the keys used in server
dialback MUST take into account the hostnames being used, the random dialback MUST take into account the hostnames being used, the random
ID generated for the stream, and a secret known by the authoritative ID generated for the stream, and a secret known by the authoritative
server's network. server's network.
Any error that occurs during dialback negotiation MUST be considered Any error that occurs during dialback negotiation MUST be considered
a stream error, resulting in termination of the stream and of the a stream error, resulting in termination of the stream and of the
underlying TCP connection. The possible error conditions are underlying TCP connection. The possible error conditions are
specified in the protocol description below. specified in the protocol description below.
skipping to change at page 39, line 47 skipping to change at page 40, line 47
<db:result <db:result
to='Receiving Server' to='Receiving Server'
from='Originating Server'> from='Originating Server'>
98AF014EDC0... 98AF014EDC0...
</db:result> </db:result>
Note: this key is not examined by Receiving Server, since Note: this key is not examined by Receiving Server, since
Receiving Server does not keep information about Originating Receiving Server does not keep information about Originating
Server between sessions. The key generated by Originating Server Server between sessions. The key generated by Originating Server
must be based in part on the value of the ID provided by MUST be based in part on the value of the ID provided by
Receiving Server in the previous step, and in part on a secret Receiving Server in the previous step, and in part on a secret
shared by Originating Server and Authoritative Server. If the shared by Originating Server and Authoritative Server. If the
value of the 'to' address does not match a hostname recognized value of the 'to' address does not match a hostname recognized
by Receiving Server, then Receiving Server MUST generate a by Receiving Server, then Receiving Server MUST generate a
<host-unknown/> stream error condition and terminate both the <host-unknown/> stream error condition and terminate both the
XML stream and the underlying TCP connection. If the value of XML stream and the underlying TCP connection. If the value of
the 'from' address matches a domain with which Receiving Server the 'from' address matches a domain with which Receiving Server
already has an established connection, then Receiving Server already has an established connection, then Receiving Server
SHOULD generate a <not-authorized/> stream error condition and MUST maintain the existing connection until it validates whether
terminate both the XML stream and the underlying TCP connection. the new connection is legitimate; additionally, Receiving Server
MAY choose to generate a <not-authorized/> stream error
condition for the new connection and then terminate both the XML
stream and the underlying TCP connection related to the new
request.
5. Receiving Server establishes a TCP connection back to the domain 5. Receiving Server establishes a TCP connection back to the domain
name asserted by Originating Server, as a result of which it name asserted by Originating Server, as a result of which it
connects to Authoritative Server. (Note: as an optimization, an connects to Authoritative Server. (Note: as an optimization, an
implementation MAY reuse an existing trusted connection here implementation MAY reuse an existing trusted connection here
rather than opening a new TCP connection.) rather than opening a new TCP connection.)
6. Receiving Server sends Authoritative Server a stream header: 6. Receiving Server sends Authoritative Server a stream header:
<stream:stream <stream:stream
skipping to change at page 42, line 32 skipping to change at page 43, line 36
invalid, then Receiving Server MUST terminate both the XML invalid, then Receiving Server MUST terminate both the XML
stream and the underlying TCP connection. If the connection is stream and the underlying TCP connection. If the connection is
validated, data can be sent by Originating Server and read by validated, data can be sent by Originating Server and read by
Receiving Server; before that, all data stanzas sent to Receiving Server; before that, all data stanzas sent to
Receiving Server SHOULD be silently dropped. Receiving Server SHOULD be silently dropped.
Even if dialback negotiation is successful, a server MUST verify that Even if dialback negotiation is successful, a server MUST verify that
all XML stanzas received from the other server include a 'from' all XML stanzas received from the other server include a 'from'
attribute and a 'to' attribute; if a stanza does not meet this attribute and a 'to' attribute; if a stanza does not meet this
restriction, the server that receives the stanza MUST generate an restriction, the server that receives the stanza MUST generate an
<invalid-xml/> stream error condition and terminate both the XML <improper-addressing/> stream error condition and terminate both the
stream and the underlying TCP connection. Furthermore, a server MUST XML stream and the underlying TCP connection. Furthermore, a server
verify that the 'from' attribute of stanzas received from the other MUST verify that the 'from' attribute of stanzas received from the
server includes a validated domain for the stream; if a stanza does other server includes a validated domain for the stream; if a stanza
not meet this restriction, the server that receives the stanza MUST does not meet this restriction, the server that receives the stanza
generate a <nonmatching-hosts/> stream error condition and terminate MUST generate a <nonmatching-hosts/> stream error condition and
both the XML stream and the underlying TCP connection. Both of these terminate both the XML stream and the underlying TCP connection. Both
checks help to prevent spoofing related to particular stanzas. of these checks help to prevent spoofing related to particular
stanzas.
8. XML Stanzas 8. XML Stanzas
8.1 Overview 8.1 Overview
Once XML streams in both directions have been authenticated and (if Once XML streams in both directions have been authenticated and (if
desired) encrypted, XML stanzas can be sent over the streams. Three desired) encrypted, XML stanzas can be sent over the streams. Three
XML stanza types are defined for the 'jabber:client' and XML stanza types are defined for the 'jabber:client' and
'jabber:server' namespaces: <message/>, <presence/>, and <iq/>. 'jabber:server' namespaces: <message/>, <presence/>, and <iq/>.
skipping to change at page 43, line 42 skipping to change at page 44, line 42
The 'to' attribute specifies the JID of the intended recipient for The 'to' attribute specifies the JID of the intended recipient for
the stanza. the stanza.
In the 'jabber:client' namespace, a stanza SHOULD possess a 'to' In the 'jabber:client' namespace, a stanza SHOULD possess a 'to'
attribute, although a stanza sent from a client to a server for attribute, although a stanza sent from a client to a server for
handling by that server (e.g., presence sent to the server for handling by that server (e.g., presence sent to the server for
broadcasting to other entities) SHOULD NOT possess a 'to' attribute. broadcasting to other entities) SHOULD NOT possess a 'to' attribute.
In the 'jabber:server' namespace, a stanza MUST possess a 'to' In the 'jabber:server' namespace, a stanza MUST possess a 'to'
attribute; if a server receives a stanza that does not meet this attribute; if a server receives a stanza that does not meet this
restriction, it MUST generate an <invalid-xml/> stream error restriction, it MUST generate an <improper-addressing/> stream error
condition and terminate both the XML stream and the underlying TCP condition and terminate both the XML stream and the underlying TCP
connection with the offending server. connection with the offending server.
If the value of the 'to' attribute is invalid or cannot be contacted, If the value of the 'to' attribute is invalid or cannot be contacted,
the entity discovering that fact (usually the sender's or recipient's the entity discovering that fact (usually the sender's or recipient's
server) MUST return an appropriate error to the sender. server) MUST return an appropriate error to the sender.
8.2.2 from 8.2.2 from
The 'from' attribute specifies the JID of the sender. The 'from' attribute specifies the JID of the sender.
In the 'jabber:client' namespace, a client MUST NOT include a 'from' In the 'jabber:client' namespace, a client MUST NOT include a 'from'
attribute on the stanzas it sends to a server; if a server receives a attribute on the stanzas it sends to a server; if a server receives
stanza from a client and the stanza possesses a 'from' attribute, it an XML stanza from a client and the stanza possesses a 'from'
MUST ignore the value of the 'from' attribute and MAY return an error attribute, it MUST ignore the value of the 'from' attribute and MAY
to the sender. In addition, a server MUST stamp stanzas received from return an error to the sender. When a client sends an XML stanza
a client with the full JID (<user@domain/resource>) of the connected within the context of an authenticated stream, the server MUST stamp
resource that generated the stanza as defined by the authzid provided the stanza with the full JID (<user@domain/resource>) of the
in the SASL negotiation. connected resource that generated the stanza as defined by the
authzid provided in the SASL negotiation. If a client attempts to
send an XML stanza before the stream is authenticated, the server
SHOULD return a <not-authorized/> stream error to the client and then
terminate both the XML stream and the underlying TCP connection.
In the 'jabber:server' namespace, a stanza MUST possess a 'from' In the 'jabber:server' namespace, a stanza MUST possess a 'from'
attribute; if a server receives a stanza that does not meet this attribute; if a server receives a stanza that does not meet this
restriction, it MUST generate an <invalid-xml/> stream error restriction, it MUST generate an <improper-addressing/> stream error
condition. Furthermore, the domain identifier portion of the JID condition. Furthermore, the domain identifier portion of the JID
contained in the 'from' attribute MUST match the hostname of the contained in the 'from' attribute MUST match the hostname of the
sending server (or any validated domain) as communicated in the SASL sending server (or any validated domain) as communicated in the SASL
negotiation or dialback negotiation; if a server receives a stanza negotiation or dialback negotiation; if a server receives a stanza
that does not meet this restriction, it MUST generate a that does not meet this restriction, it MUST generate a
<nonmatching-hosts/> stream error condition. Both of these conditions <nonmatching-hosts/> stream error condition. Both of these conditions
MUST result in closing of the stream and termination of the MUST result in closing of the stream and termination of the
underlying TCP connection. underlying TCP connection.
8.2.3 id 8.2.3 id
skipping to change at page 45, line 4 skipping to change at page 46, line 8
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 [31], "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 attribute MUST 'xml:lang' attribute of a specific child element. The value of the
be an NMTOKEN and MUST conform to the format defined in RFC 3066 attribute MUST be an NMTOKEN and MUST conform to the format defined
[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
context of instant messaging include single messages, messages sent context of instant messaging include single messages, messages sent
in the context of a chat conversation, messages sent in the context in the context of a chat conversation, messages sent in the context
of a multi-user chat room, headlines, and errors. of a multi-user chat room, headlines, and errors.
8.3.1 Types of Message 8.3.1 Types of Message
skipping to change at page 45, line 48 skipping to change at page 47, line 4
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
<error/> child; for details, see Section 8.7. Otherwise, the message <error/> child; for details, see Stanza Errors (Section 8.7).
stanza MAY contain any of the following child elements without an Otherwise, the message stanza MAY contain any of the following child
explicit namespace declaration: elements without an explicit namespace declaration:
1. <subject/> 1. <subject/>
2. <body/> 2. <body/>
3. <thread/> 3. <thread/>
8.3.2.1 Subject 8.3.2.1 Subject
The <subject/> element specifies the topic of the message. The The <subject/> element specifies the topic of the message. The
skipping to change at page 47, line 36 skipping to change at page 48, line 40
o subscribed -- The sender has allowed the recipient to receive o subscribed -- The sender has allowed the recipient to receive
their presence. their presence.
o unsubscribe -- A notification that an entity is unsubscribing from o unsubscribe -- A notification that an entity is unsubscribing from
another entity's presence. another entity's presence.
o unsubscribed -- The subscription request has been denied or a o unsubscribed -- The subscription request has been denied or a
previously-granted subscription has been cancelled. previously-granted subscription has been cancelled.
o probe -- A request for an entity's current presence. 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 [23].
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
an <error/> child; for details, see Section 8.7. If the presence an <error/> child; for details, see Stanza Errors (Section 8.7). If
stanza possesses no 'type' attribute, it MAY contain any of the the presence stanza possesses no 'type' attribute, it MAY contain any
following child elements (note that the <status/> child MAY be sent of the following child elements (note that the <status/> child MAY be
in a presence stanza of type "unavailable" or, for historical sent in a presence stanza of type "unavailable" or, for historical
reasons, "subscribe"): reasons, "subscribe"):
1. <show/> 1. <show/>
2. <status/> 2. <status/>
3. <priority/> 3. <priority/>
8.4.2.1 Show 8.4.2.1 Show
skipping to change at page 48, line 34 skipping to change at page 49, line 37
MAY be included in a presence stanza, and it SHOULD NOT possess any MAY be included in a presence stanza, and it SHOULD NOT possess any
attributes. The CDATA value SHOULD be one of the following (values attributes. The CDATA value SHOULD be one of the following (values
other than these four SHOULD be ignored; additional availability other than these four SHOULD be ignored; additional availability
types could be defined through a properly-namespaced child element of types could be defined through a properly-namespaced child element of
the presence stanza): the presence stanza):
o away o away
o chat o chat
o xa
o dnd o dnd
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 [23].
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 the priority to be zero. For information provided, a server SHOULD consider the priority to be zero. For
regarding the semantics of priority values in stanza routing within information regarding the semantics of priority values in stanza
instant messaging applications, see XMPP IM [23]. routing within instant messaging applications, refer to XMPP IM [23].
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 49, line 48 skipping to change at page 51, line 4
| | | |
| <iq type='result' id='1'> | | <iq type='result' id='1'> |
| <------------------------ | | <------------------------ |
| | | |
| <iq type='set' id='2'> | | <iq type='set' id='2'> |
| ------------------------> | | ------------------------> |
| | | |
| <iq type='error' id='2'> | | <iq type='error' id='2'> |
| <------------------------ | | <------------------------ |
| | | |
An entity that receives an IQ request of type "get" or "set" MUST An entity that receives an IQ request of type "get" or "set" MUST
reply with an IQ response of type "result" or "error" (which response reply with an IQ response of type "result" or "error" (which response
MUST preserve the 'id' attribute of the request). An entity that MUST preserve the 'id' attribute of the request, if provided). An
receives a stanza of type "result" or "error" MUST NOT respond to the entity that receives a stanza of type "result" or "error" MUST NOT
stanza by sending a further IQ response of type "result" or "error"; respond to the stanza by sending a further IQ response of type
however, as shown above, the requesting entity MAY send another "result" or "error"; however, as shown above, the requesting entity
request (e.g., an IQ of type "set" in order to provide required MAY send another request (e.g., an IQ of type "set" in order to
information discovered through a get/result pair). provide required information discovered through a get/result pair).
8.5.2 Types of IQ 8.5.2 Types of IQ
The 'type' attribute of an IQ stanza is REQUIRED. The 'type' The 'type' attribute of an IQ stanza is REQUIRED. The 'type'
attribute specifies a distinct step within a request-response attribute specifies a distinct step within a request-response
interaction. The value SHOULD be one of the following (all other interaction. The value SHOULD be one of the following (all other
values SHOULD be ignored): values SHOULD be ignored):
o get -- The stanza is a request for information or requirements. o get -- The stanza is a request for information or requirements.
skipping to change at page 50, line 32 skipping to change at page 51, line 35
o result -- The stanza is a response to a successful get or set o result -- The stanza is a response to a successful get or set
request. request.
o error -- An error has occurred regarding processing or delivery of o error -- An error has occurred regarding processing or delivery of
a previously-sent get or set. a previously-sent get or set.
8.5.3 Children 8.5.3 Children
As described under extended namespaces (Section 8.6), an IQ stanza As described under extended namespaces (Section 8.6), an IQ stanza
MAY contain any properly-namespaced child element. Note that an IQ MAY contain any properly-namespaced child element. Note that an IQ
stanza contains no children in the 'jabber:client' or 'jabber:server' stanza of type "get", "set", or "result" contains no children in the
namespace since it is a vessel for XML in another namespace. 'jabber:client' or 'jabber:server' namespace since it is a vessel for
XML in another namespace.
An IQ stanza of type "get" or "set" MUST include one and only one An IQ stanza of type "get" or "set" MUST include one and only one
child element. An IQ stanza of type "result" MUST include zero or one child element. An IQ stanza of type "result" MUST include zero or one
child elements. An IQ stanza of type "error" SHOULD include the child child elements. An IQ stanza of type "error" SHOULD include the child
element contained in the associated "get" or "set" and MUST include element contained in the associated "get" or "set" and MUST include
an <error/> child; for details, see Section 8.7. an <error/> child; for details, see Stanza Errors (Section 8.7).
8.6 Extended Namespaces 8.6 Extended Namespaces
While the core data elements in the "jabber:client" or While the three XML stanza types defined in the "jabber:client" or
"jabber:server" namespace (along with their attributes and child "jabber:server" namespace (along with their attributes and child
elements) provide a basic level of functionality for messaging and elements) provide a basic level of functionality for messaging and
presence, XMPP uses XML namespaces to extend the core data elements presence, XMPP uses XML namespaces to extend the stanzas for the
for the purpose of providing additional functionality. Thus a purpose of providing additional functionality. Thus a message,
message, presence, or IQ stanza MAY house one or more optional child presence, or IQ stanza MAY house one or more optional child elements
elements containing content that extends the meaning of the message containing content that extends the meaning of the message (e.g., an
(e.g., an XHTML-formatted version of the message body). This child XHTML-formatted version of the message body). This child element MAY
element MAY have any name and MUST possess an 'xmlns' namespace have any name and MUST possess an 'xmlns' namespace declaration
declaration (other than "jabber:client", "jabber:server", or "http:// (other than "jabber:client", "jabber:server", or "http://
etherx.jabber.org/streams") that defines all data contained within etherx.jabber.org/streams") that defines all data contained within
the child element. the child element.
Support for any given extended namespace is OPTIONAL on the part of Support for any given extended namespace is OPTIONAL on the part of
any implementation. If an entity does not understand such a any implementation. If an entity does not understand such a
namespace, the entity's expected behavior depends on whether the namespace, the entity's expected behavior depends on whether the
entity is (1) the recipient or (2) an entity that is routing the entity is (1) the recipient or (2) an entity that is routing the
stanza to the recipient: stanza to the recipient:
Recipient: If a recipient receives a stanza that contains a child Recipient: If a recipient receives a stanza that contains a child
skipping to change at page 51, line 42 skipping to change at page 52, line 46
"error" with an error condition of <feature-not-implemented/>. "error" with an error condition of <feature-not-implemented/>.
Router: If a routing entity (usually a server) handles a stanza that Router: If a routing entity (usually a server) handles a stanza that
contains a child element it does not understand, it SHOULD ignore contains a child element it does not understand, it SHOULD ignore
the associated XML data by passing it on untouched to the the associated XML data by passing it on untouched to the
recipient. recipient.
8.7 Stanza Errors 8.7 Stanza Errors
Stanza-related errors are handled in a manner similar to stream Stanza-related errors are handled in a manner similar to stream
errors (Section 4.5), except that hints are also provided to the errors (Section 4.6), except that hints are also provided to the
receiving application regarding actions to take in reponse to the receiving application regarding actions to take in reponse to the
error. error.
8.7.1 Rules 8.7.1 Rules
The following rules apply to stanza-related errors: The following rules apply to stanza-related errors:
o A stanza whose 'type' attribute has a value of "error" MUST o A stanza whose 'type' attribute has a value of "error" MUST
contain an <error/> child element. contain an <error/> child element.
skipping to change at page 52, line 23 skipping to change at page 53, line 29
stanza of type "error"; this helps to prevent looping. stanza of type "error"; this helps to prevent looping.
o An <error/> child MUST NOT be included if the 'type' attribute has o An <error/> child MUST NOT be included if the 'type' attribute has
a value other than "error" (or if there is no 'type' attribute). a value other than "error" (or if there is no 'type' attribute).
8.7.2 Syntax 8.7.2 Syntax
The syntax for stanza-related errors is as follows: The syntax for stanza-related errors is as follows:
<stanza-name to='sender' type='error'> <stanza-name to='sender' type='error'>
[include sender XML here] [RECOMMENDED to include sender XML here]
<error type='error-type'> <error type='error-type'>
<descriptive-element-name <defined-condition xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>
OPTIONAL descriptive text
</text>
[OPTIONAL application-specific condition element]
</error> </error>
</stanza-name> </stanza-name>
The stanza-name is one of message, presence, or iq. The stanza-name is one of message, presence, or iq.
The value of the <error/> element's 'type' attribute MUST be one of The value of the <error/> element's 'type' attribute MUST be one of
the following: the following:
o cancel -- do not retry (the error is unrecoverable) o cancel -- do not retry (the error is unrecoverable)
skipping to change at page 52, line 42 skipping to change at page 54, line 4
The value of the <error/> element's 'type' attribute MUST be one of The value of the <error/> element's 'type' attribute MUST be one of
the following: the following:
o cancel -- do not retry (the error is unrecoverable) o cancel -- do not retry (the error is unrecoverable)
o continue -- proceed (the condition was only a warning) o continue -- proceed (the condition was only a warning)
o modify -- retry after changing the data sent o modify -- retry after changing the data sent
o auth -- retry after providing credentials o auth -- retry after providing credentials
o wait -- retry after waiting (the error is temporary) o wait -- retry after waiting (the error is temporary)
The <error/> element MUST contain a child element that specifies a The <error/> element:
particular stanza-related error condition. This descriptive element
SHOULD be one of those defined in the next section. However, an o MUST contain a child element corresponding to one of the defined
application MAY supplement or further qualify a defined descriptive stanza error conditions defined below; this element MUST be
element with an application-specific element, resulting in the qualified by the 'urn:ietf:params:xml:ns:xmpp-stanzas' namespace
inclusion of two descriptive elements; in this case, the
application-specific element MUST further explain or qualify the o MAY contain a <text/> child containing CDATA that describes the
defined element. error in more detail; this element MUST be qualified by the
'urn:ietf:params:xml:ns:xmpp-stanzas' namespace and SHOULD possess
an 'xml:lang' attribute
o MAY contain a child element for an application-specific error
condition; this element MUST be qualified by an
application-defined namespace, and its structure is defined by
that namespace
The <text/> element is OPTIONAL. If included, it SHOULD be used only
to provide descriptive or diagnostic information that supplements the
meaning of a defined condition or application-specific condition. It
SHOULD NOT be interpreted programmatically by an application. It
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
condition element (or elements).
Note: the XML namespace name 'urn:ietf:params:xml:ns:xmpp-stanzas'
that qualifies the descriptive element adheres to the format defined
in The IETF XML Registry [25].
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 (the namespace name for these elements is stanza errors.
'urn:ietf:params:xml:ns:xmpp-stanzas', which adheres to the format
defined in The IETF XML Registry [25]).
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 is "modify". of the 'type' attribute); the associated error type SHOULD be
"modify".
o <conflict/> -- access cannot be granted because an existing o <conflict/> -- access cannot be granted because an existing
resource or session exists with the same name or address; the resource or session exists with the same name or address; the
associated error type is "cancel". associated error type SHOULD be "cancel".
o <feature-not-implemented/> -- the feature requested is not o <feature-not-implemented/> -- the feature requested is not
implemented by the recipient or server and therefore cannot be implemented by the recipient or server and therefore cannot be
processed; the associated error type is "cancel". processed; the associated error type SHOULD be "cancel".
o <forbidden/> -- the requesting entity does not possess the o <forbidden/> -- the requesting entity does not possess the
required permissions to perform the action; the associated error required permissions to perform the action; the associated error
type is "auth". type SHOULD be "auth".
o <internal-server-error/> -- the server could not process the o <internal-server-error/> -- the server could not process the
stanza because of a misconfiguration or an otherwise-undefined stanza because of a misconfiguration or an otherwise-undefined
internal server error; the associated error type is "wait". internal server error; the associated error type SHOULD be "wait".
o <item-not-found/> -- the addressed JID or item requested cannot be o <item-not-found/> -- the addressed JID or item requested cannot be
found; the associated error type is "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 (Section 3); the associated error type is "modify". Addressing Scheme (Section 3); the associated error type SHOULD be
"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 is "cancel". perform the action; the associated error type SHOULD be "cancel".
o <recipient-unavailable/> -- the specific recipient requested is o <recipient-unavailable/> -- the specific recipient requested is
currently unavailable; the associated error type is "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 is "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 is "cancel". exist; the associated error type SHOULD be "cancel".
o <remote-server-timeout/> -- a remote server or service specified o <remote-server-timeout/> -- a remote server or service specified
as part or all of the JID of the intended recipient could not be as part or all of the JID of the intended recipient could not be
contacted within a reasonable amount of time; the associated error contacted within a reasonable amount of time; the associated error
type is "wait". type SHOULD be "wait".
o <resource-constraint/> -- the server is resource-contrained and is o <resource-constraint/> -- the server is resource-contrained and is
unable to service the request; the associated error type is unable to service the request; the associated error type SHOULD be
"wait". "wait".
o <service-unavailable/> -- the service requested is currently o <service-unavailable/> -- the service requested is currently
unavailable on the server; the associated error type is "cancel". unavailable on the server; the associated error type SHOULD be
"cancel".
o <subscription-required/> -- the user is not authorized to access o <subscription-required/> -- the user is not authorized to access
the requested service because a subscription is required; the the requested service because a subscription is required; the
associated error type is "auth". associated error type SHOULD be "auth".
o <undefined-condition/> -- the error condition is not one of those
defined by the other conditions in this list; any error type may
be associated with this condition, and it SHOULD be used only in
conjuction with an application-specific condition.
o <unexpected-request/> -- the recipient understood the request but o <unexpected-request/> -- the recipient understood the request but
was not expecting it at this time (e.g., the request was out of was not expecting it at this time (e.g., the request was out of
order); the associated error type is "wait". order); the associated error type SHOULD be "wait".
8.7.4 Application-Specific Conditions 8.7.4 Application-Specific Conditions
As noted, an application MAY provide application-specific stanza As noted, an application MAY provide application-specific stanza
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
contain two child elements, for example: contain two or three child elements:
<iq type='error' id='some-id'> <iq type='error' id='some-id'>
<error type='modify'> <error type='modify'>
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<too-many-parameters xmlns='application-ns'/> <too-many-parameters xmlns='application-ns'/>
</error> </error>
</iq> </iq>
<message type='error' id='another-id'>
<error type='modify'>
<undefined-condition xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<text xml:lang='en' xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>
Some special application diagnostic information!
</text>
<special-application-condition xmlns='application-ns'/>
</error>
</message>
9. XML Usage within XMPP 9. XML Usage within XMPP
9.1 Restrictions 9.1 Restrictions
XMPP is a simplified and specialized protocol for streaming XML XMPP is a simplified and specialized protocol for streaming XML
elements in order to exchange messages and presence information in elements in order to exchange messages and presence information in
close to real time. Because XMPP does not require the parsing of close to real time. Because XMPP does not require the parsing of
arbitrary and complete XML documents, there is no requirement that arbitrary and complete XML documents, there is no requirement that
XMPP must support the full XML specification [1]. In particular, the XMPP needs to support the full XML specification [1]. In particular,
following restrictions apply. the following restrictions apply.
With regard to XML generation, an XMPP implementation MUST NOT inject With regard to XML generation, an XMPP implementation MUST NOT inject
into an XML stream any of the following: into an XML stream any of the following:
o comments (as defined in Section 2.5 of the XML specification [1]) o comments (as defined in Section 2.5 of the XML specification [1])
o processing instructions (Section 2.6) o processing instructions (Section 2.6)
o internal or external DTD subsets (Section 2.8) o internal or external DTD subsets (Section 2.8)
o internal or external entity references (Section 4.2) with the o internal or external entity references (Section 4.2) with the
exception of predefined entities (Section 4.6) exception of predefined entities (Section 4.6)
o character data or attribute values containing unescaped characters
that map to the predefined entities (Section 4.6); such characters
MUST be escaped
With regard to XML processing, if an XMPP implementation receives With regard to XML processing, if an XMPP implementation receives
such restricted XML data, it MUST ignore the data. such restricted XML data, it MUST ignore the data.
9.2 Namespaces 9.2 XML Namespace Names and Prefixes
XML Namespaces [12] are used within all XMPP-compliant XML to create XML Namespaces [12] are used within all XMPP-compliant XML to create
strict boundaries of data ownership. The basic function of namespaces strict boundaries of data ownership. The basic function of namespaces
is to separate different vocabularies of XML elements that are is to separate different vocabularies of XML elements that are
structurally mixed together. Ensuring that XMPP-compliant XML is structurally mixed together. Ensuring that XMPP-compliant XML is
namespace-aware enables any XML to be structurally mixed with any namespace-aware enables any XML to be structurally mixed with any
data element within XMPP. data element within XMPP. Rules for XML namespace names and prefixes
are defined below.
Additionally, an XMPP implementation MAY be more strict about 9.2.1 Stream Namespace
namespace prefixes than the XML namespace specification requires.
A stream namespace declaration is REQUIRED in both XML stream
headers. The name of the stream namespace MUST be 'http://
etherx.jabber.org/streams'. The element names of the <stream/>
element and its <features/> and <error/> children MUST be qualified
by the stream namespace prefix in all instances. An implementation
SHOULD generate only the 'stream:' prefix for these elements, and for
historical reasons MAY accept only the 'stream:' prefix.
9.2.2 Default Namespace
A default namespace declaration is REQUIRED and is used in both XML
streams in order to define the allowable first-level children of the
root stream element. This namespace declaration MUST be the same for
the initiating stream and the responding stream so that both streams
are qualified consistently. The default namespace declaration applies
to the stream and all stanzas sent within a stream (unless explicitly
qualified by another namespace, or by the prefix of the stream
namespace or the dialback namespace).
A server implementation MUST support the following two default
namespaces (for historical reasons, some implementations MAY support
only these two default namespaces):
o jabber:client -- this default namespace is declared when the
stream is used for communications between a client and a server
o jabber:server -- this default namespace is declared when the
stream is used for communications between two servers
A client implementation MUST support the 'jabber:client' default
namespace, and for historical reasons MAY support only that default
namespace.
An implementation MUST NOT generate namespace prefixes for elements
in the default namespace if the default namespace is 'jabber:client'
or 'jabber:server'. An implementation SHOULD NOT generate namespace
prefixes for elements qualified by "extended" namespaces as described
under Extended Namespaces (Section 8.6).
Note: the 'jabber:client' and 'jabber:server' namespaces are nearly
identical but are used in different contexts (client-to-server
communications for 'jabber:client' and server-to-server
communications for 'jabber:server'). The only difference between the
two is that the 'to' and 'from' attributes are OPTIONAL on stanzas
sent within 'jabber:client', whereas they are REQUIRED on stanzas
sent within 'jabber:server'. If a compliant implementation accepts a
stream that is qualified by the 'jabber:client' or 'jabber:server'
namespace, it MUST support all three core stanza types (message,
presence, and IQ) as described herein and defined in the schema.
9.2.3 Dialback Namespace
A dialback namespace declaration is REQUIRED for all elements used in
server dialback. The name of the dialback namespace MUST be
'jabber:server:dialback'. All elements qualified by this namespace
MUST be prefixed. An implementation SHOULD generate only the 'db:'
prefix for such elements and MAY accept only the 'db:' prefix.
9.3 Validation 9.3 Validation
Except as noted with regard to 'to' and 'from' addresses for stanzas Except as noted with regard to 'to' and 'from' addresses for stanzas
within the 'jabber:server' namespace, a server is not responsible for within the 'jabber:server' namespace, a server is not responsible for
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. Clients SHOULD NOT rely on the ability but is NOT REQUIRED to do so (although an implementation MUST NOT
to send data which does not conform to the schemas, and SHOULD ignore accept XML that is not well-formed). Clients SHOULD NOT rely on the
any non-conformant elements or attributes on the incoming XML stream. ability to send data which does not conform to the schemas, and
Validation of XML streams and stanzas is NOT REQUIRED or recommended, SHOULD ignore any non-conformant elements or attributes on the
and schemas are included herein for descriptive purposes only. incoming XML stream. Validation of XML streams and stanzas is NOT
REQUIRED or recommended, and schemas are included herein for
descriptive purposes only.
9.4 Character Encodings 9.4 Character Encodings
Software implementing XML streams MUST support the UTF-8 (RFC 2279 Software implementing XML streams MUST support the UTF-8 (RFC 2279
[19]) and UTF-16 (RFC 2781 [20]) transformations of Universal [19]) and UTF-16 (RFC 2781 [20]) transformations of Universal
Character Set (ISO/IEC 10646-1 [21]) characters. Software MUST NOT Character Set (ISO/IEC 10646-1 [21]) characters. Implementations MUST
attempt to use any other encoding for transmitted data. The encodings NOT attempt to use any other encoding for transmitted data. The
of the transmitted and received streams are independent. Software MAY encodings of the transmitted and received streams are independent.
select either UTF-8 or UTF-16 for the transmitted stream, and SHOULD Implementations MAY select either UTF-8 or UTF-16 for the transmitted
deduce the encoding of the received stream as described in the XML stream, and SHOULD deduce the encoding of the received stream as
specification [1]. For historical reasons, existing implementations described in the XML specification [1]. For historical reasons,
MAY support UTF-8 only. existing implementations MAY support UTF-8 only.
9.5 Inclusion of Text Declaration 9.5 Inclusion of Text Declaration
An application MAY send a text declaration. Applications MUST follow An application MAY send a text declaration. Applications MUST follow
the rules in the XML specification [1] regarding the circumstances the rules in the XML specification [1] regarding the circumstances
under which a text declaration is included. under which a text declaration is included.
10. IANA Considerations 10. IANA Considerations
10.1 XML Namespace Name for TLS Data 10.1 XML Namespace Name for TLS Data
skipping to change at page 58, line 25 skipping to change at page 61, line 25
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 [22] service name, as specified
in 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
Each XML stanza SHOULD include an 'xml:lang' attribute. Servers MUST Each XML stanza SHOULD include an 'xml:lang' attribute. Servers MUST
skipping to change at page 60, line 37 skipping to change at page 63, line 37
certificate signed by an unrecognized authority. certificate signed by an unrecognized authority.
Implementations MUST support high security. Service provisioning Implementations MUST support high security. Service provisioning
SHOULD use high security, subject to local security policies. SHOULD use high security, subject to local security policies.
12.2 Client-to-Server Communications 12.2 Client-to-Server Communications
A compliant implementation MUST support both TLS and SASL for A compliant implementation MUST support both TLS and SASL for
connections to a server. connections to a server.
The TLS protocol for encrypting XML streams (defined under Section 5) The TLS protocol for encrypting XML streams (defined under Stream
provides a reliable mechanism for helping to ensure the Encryption (Section 5)) provides a reliable mechanism for helping to
confidentiality and data integrity of data exchanged between two ensure the confidentiality and data integrity of data exchanged
entities. between two entities.
The SASL protocol for authenticating XML streams (defined under The SASL protocol for authenticating XML streams (defined under
Section 6) provides a reliable mechanism for validating that a client Stream Authentication (Section 6)) provides a reliable mechanism for
connecting to a server is who it claims to be. validating that a client connecting to a server is who it claims to
be.
The IP address and method of access of clients MUST NOT be made The IP address and method of access of clients MUST NOT be made
available by a server, nor are any connections other than the available by a server, nor are any connections other than the
original server connection required. This helps to protect the original server connection required. This helps to protect the
client's server from direct attack or identification by third client's server from direct attack or identification by third
parties. parties.
12.3 Server-to-Server Communications 12.3 Server-to-Server Communications
A compliant implementation MUST support both TLS and SASL for A compliant implementation MUST support both TLS and SASL for
inter-domain communications. For historical reasons, a compliant inter-domain communications. For historical reasons, a compliant
implementation SHOULD also support Section 7. implementation SHOULD also support Server Dialback (Section 7).
Because service provisioning is a matter of policy, it is OPTIONAL Because service provisioning is a matter of policy, it is OPTIONAL
for any given domain to communicate with other domains, and for any given domain to communicate with other domains, and
server-to-server communications MAY be disabled by the administrator server-to-server communications MAY be disabled by the administrator
of any given deployment. If a particular domain enables inter-domain of any given deployment. If a particular domain enables inter-domain
communications, it SHOULD enable high security. communications, it SHOULD enable high security.
Administrators may want to require use of SASL for server-to-server Administrators may want to require use of SASL for server-to-server
communications in order to ensure both authentication and communications in order to ensure both authentication and
confidentiality (e.g., on an organization's private network). confidentiality (e.g., on an organization's private network).
Compliant implementations SHOULD support SASL for this purpose. Compliant implementations SHOULD support SASL for this purpose.
Inter-domain connections MUST NOT proceed until the DNS hostnames
asserted by the servers have been resolved. Such resolutions MUST
first attempt to resolve the hostname using an SRV [18] record of
_jabber._tcp.server (the use of the string "jabber" for SRV purposes
is historical). If the SRV lookup fails, the fallback is a normal A
lookup to determine the IP address, using the jabber-server port of
5269 assigned by the Internet Assigned Numbers 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 [30] 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.
skipping to change at page 61, line 44 skipping to change at page 65, line 4
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:
1. TCP 1. TCP
2. TLS 2. TLS
3. SASL 3. SASL
4. XMPP 4. XMPP
The rationale for this order is that TCP is the base connection layer The rationale for this order is that TCP is the base connection layer
used by all of the protocols stacked on top of TCP, TLS is often used by all of the protocols stacked on top of TCP, TLS is often
provided at the operating system layer, SASL is often provided at the provided at the operating system layer, SASL is often provided at the
application layer, and XMPP is the application itself. application layer, and XMPP is the application itself.
12.5 Firewalls 12.5 Firewalls
Communications using XMPP normally occur over TCP sockets on port Communications using XMPP normally occur over TCP sockets on port
5222 (client-to-server) or port 5269 (server-to-server), as 5222 (client-to-server) or port 5269 (server-to-server), as
registered with the IANA [5] (see Section 10). Use of these registered with the IANA [5] (see IANA Considerations (Section 10)).
well-known ports allows administrators to easily enable or disable Use of these well-known ports allows administrators to easily enable
XMPP activity through existing and commonly-deployed firewalls. or disable XMPP activity through existing and commonly-deployed
firewalls.
12.6 Mandatory to Implement Technologies 12.6 Mandatory to Implement Technologies
At a minimum, all implementations MUST support the following At a minimum, all implementations MUST support the following
mechanisms: mechanisms:
for authentication: the SASL DIGEST-MD5 mechanism for authentication: the SASL DIGEST-MD5 mechanism
for confidentiality: TLS (using the TLS_RSA_WITH_3DES_EDE_CBC_SHA for confidentiality: TLS (using the TLS_RSA_WITH_3DES_EDE_CBC_SHA
cipher) cipher)
for both: TLS (using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher for both: TLS plus SASL EXTERNAL(using the
supporting client-side certificates) TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher supporting client-side
certificates)
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.
skipping to change at page 65, line 46 skipping to change at page 68, line 46
[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.
Authors' Addresses Authors' Addresses
Peter Saint-Andre Peter Saint-Andre
Jabber Software Foundation Jabber Software Foundation
EMail: stpeter@jabber.org EMail: stpeter@jabber.org
URI: http://www.jabber.org/people/stpeter.php
Jeremie Miller Jeremie Miller
Jabber Software Foundation Jabber Software Foundation
EMail: jeremie@jabber.org EMail: jeremie@jabber.org
URI: http://www.jabber.org/people/jer.php
Appendix A. XML Schemas Appendix A. XML Schemas
The following XML schemas are descriptive, not normative. The following XML schemas are descriptive, not normative.
A.1 Stream namespace A.1 Stream namespace
<?xml version='1.0' encoding='UTF-8'?> <?xml version='1.0' encoding='UTF-8'?>
<xs:schema <xs:schema
skipping to change at page 69, line 11 skipping to change at page 70, line 23
</xs:element> </xs:element>
</xs:schema> </xs:schema>
A.2 Stream error namespace A.2 Stream error namespace
<?xml version='1.0' encoding='UTF-8'?> <?xml version='1.0' encoding='UTF-8'?>
<xs:schema <xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema' xmlns:xs='http://www.w3.org/2001/XMLSchema'
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'
schemaLocation='http://www.w3.org/2001/xml.xsd'/>
<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='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='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='xs:string'/>
<xs:element name='system-shutdown' type='empty'/> <xs:element name='system-shutdown' 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='xs:string'/>
<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:complexType>
<xs:attribute ref='xml:lang' use='optional'/>
</xs:complexType>
</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>
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
A.3 TLS namespace A.3 TLS namespace
skipping to change at page 71, line 26 skipping to change at page 72, line 36
</xs:element> </xs:element>
<xs:element name='challenge' type='xs:NMTOKEN'/> <xs:element name='challenge' type='xs:NMTOKEN'/>
<xs:element name='response' type='xs:NMTOKEN'/> <xs:element name='response' type='xs:NMTOKEN'/>
<xs:element name='abort' type='empty'/> <xs:element name='abort' type='empty'/>
<xs:element name='success' type='empty'/> <xs:element name='success' type='empty'/>
<xs:element name='failure'> <xs:element name='failure'>
<xs:complexType> <xs:complexType>
<xs:choice maxOccurs='1'> <xs:choice maxOccurs='1'>
<xs:element ref='bad-protocol'/>
<xs:element ref='encryption-required'/> <xs:element ref='encryption-required'/>
<xs:element ref='invalid-authzid'/> <xs:element ref='invalid-authzid'/>
<xs:element ref='invalid-mechanism'/>
<xs:element ref='invalid-realm'/> <xs:element ref='invalid-realm'/>
<xs:element ref='mechanism-too-weak'/> <xs:element ref='mechanism-too-weak'/>
<xs:element ref='not-authorized'/>
<xs:element ref='temporary-auth-failure'/> <xs:element ref='temporary-auth-failure'/>
</xs:choice> </xs:choice>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:element name='bad-protocol' type='empty'/>
<xs:element name='encryption-required' type='empty'/> <xs:element name='encryption-required' type='empty'/>
<xs:element name='invalid-authzid' type='empty'/> <xs:element name='invalid-authzid' type='empty'/>
<xs:element name='invalid-mechanism' type='empty'/>
<xs:element name='invalid-realm' type='empty'/> <xs:element name='invalid-realm' type='empty'/>
<xs:element name='mechanism-too-weak' type='empty'/> <xs:element name='mechanism-too-weak' type='empty'/>
<xs:element name='not-authorized' type='empty'/>
<xs:element name='temporary-auth-failure' type='empty'/> <xs:element name='temporary-auth-failure' type='empty'/>
<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>
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
skipping to change at page 73, line 47 skipping to change at page 75, line 16
</xs:sequence> </xs:sequence>
<xs:attribute name='to' <xs:attribute name='to'
type='xs:string' type='xs:string'
use='optional'/> use='optional'/>
<xs:attribute name='from' <xs:attribute name='from'
type='xs:string' type='xs:string'
use='optional'/> use='optional'/>
<xs:attribute name='id' <xs:attribute name='id'
type='xs:NMTOKEN' type='xs:NMTOKEN'
use='optional'/> use='optional'/>
<xs:attribute ref='xml:lang'/> <xs:attribute ref='xml:lang' use='optional'/>
<xs:attribute name='type' use='optional'> <xs:attribute name='type' use='optional'>
<xs:simpleType> <xs:simpleType>
<xs:restriction base='xs:NCName'> <xs:restriction base='xs:NCName'>
<xs:enumeration value='chat'/> <xs:enumeration value='chat'/>
<xs:enumeration value='error'/> <xs:enumeration value='error'/>
<xs:enumeration value='groupchat'/> <xs:enumeration value='groupchat'/>
<xs:enumeration value='headline'/> <xs:enumeration value='headline'/>
<xs:enumeration value='normal'/> <xs:enumeration value='normal'/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
skipping to change at page 75, line 7 skipping to change at page 76, line 25
</xs:sequence> </xs:sequence>
<xs:attribute name='to' <xs:attribute name='to'
type='xs:string' type='xs:string'
use='optional'/> use='optional'/>
<xs:attribute name='from' <xs:attribute name='from'
type='xs:string' type='xs:string'
use='optional'/> use='optional'/>
<xs:attribute name='id' <xs:attribute name='id'
type='xs:NMTOKEN' type='xs:NMTOKEN'
use='optional'/> use='optional'/>
<xs:attribute ref='xml:lang'/> <xs:attribute ref='xml:lang' use='optional'/>
<xs:attribute name='type' use='optional'> <xs:attribute name='type' use='optional'>
<xs:simpleType> <xs:simpleType>
<xs:restriction base='xs:NCName'> <xs:restriction base='xs:NCName'>
<xs:enumeration value='subscribe'/> <xs:enumeration value='subscribe'/>
<xs:enumeration value='subscribed'/> <xs:enumeration value='subscribed'/>
<xs:enumeration value='unsubscribe'/> <xs:enumeration value='unsubscribe'/>
<xs:enumeration value='unsubscribed'/> <xs:enumeration value='unsubscribed'/>
<xs:enumeration value='unavailable'/> <xs:enumeration value='unavailable'/>
<xs:enumeration value='error'/> <xs:enumeration value='error'/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:attribute> </xs:attribute>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:element name='show'> <xs:element name='show'>
<xs:simpleType> <xs:simpleType>
<xs:restriction base='xs:NCName'> <xs:restriction base='xs:NCName'>
<xs:enumeration value='away'/> <xs:enumeration value='away'/>
<xs:enumeration value='chat'/> <xs:enumeration value='chat'/>
<xs:enumeration value='xa'/>
<xs:enumeration value='dnd'/> <xs:enumeration value='dnd'/>
<xs:enumeration value='xa'/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:element> </xs:element>
<xs:element name='status' type='xs:string'> <xs:element name='status' 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:element name='priority' type='xs:byte'/> <xs:element name='priority' type='xs:byte'/>
<xs:element name='iq'> <xs:element name='iq'>
<xs:complexType> <xs:complexType>
skipping to change at page 76, line 13 skipping to change at page 77, line 31
</xs:sequence> </xs:sequence>
<xs:attribute name='to' <xs:attribute name='to'
type='xs:string' type='xs:string'
use='optional'/> use='optional'/>
<xs:attribute name='from' <xs:attribute name='from'
type='xs:string' type='xs:string'
use='optional'/> use='optional'/>
<xs:attribute name='id' <xs:attribute name='id'
type='xs:NMTOKEN' type='xs:NMTOKEN'
use='optional'/> use='optional'/>
<xs:attribute ref='xml:lang'/> <xs:attribute ref='xml:lang' use='optional'/>
<xs:attribute name='type' use='required'> <xs:attribute name='type' use='required'>
<xs:simpleType> <xs:simpleType>
<xs:restriction base='xs:NCName'> <xs:restriction base='xs:NCName'>
<xs:enumeration value='get'/> <xs:enumeration value='get'/>
<xs:enumeration value='set'/> <xs:enumeration value='set'/>
<xs:enumeration value='result'/> <xs:enumeration value='result'/>
<xs:enumeration value='error'/> <xs:enumeration value='error'/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:attribute> </xs:attribute>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:element name='error'> <xs:element name='error'>
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<xs:any namespace='urn:ietf:params:xml:ns:xmpp-stanzas' <xs:any namespace='urn:ietf:params:xml:ns:xmpp-stanzas'
maxOccurs='1'/> maxOccurs='1'/>
<text namespace='urn:ietf:params:xml:ns:xmpp-stanzas'
minOccurs='0'
maxOccurs='1'/>
<xs:any <xs:any
namespace='##other' namespace='##other'
minOccurs='0' minOccurs='0'
maxOccurs='1'/> maxOccurs='1'/>
</xs:sequence> </xs:sequence>
<xs:attribute name='type' use='required'/> <xs:attribute name='type' use='required'/>
<xs:simpleType> <xs:simpleType>
<xs:restriction base='xs:NCName'> <xs:restriction base='xs:NCName'>
<xs:enumeration value='cancel'/> <xs:enumeration value='cancel'/>
<xs:enumeration value='continue'/> <xs:enumeration value='continue'/>
skipping to change at page 77, line 47 skipping to change at page 79, line 21
</xs:sequence> </xs:sequence>
<xs:attribute name='to' <xs:attribute name='to'
type='xs:string' type='xs:string'
use='required'/> use='required'/>
<xs:attribute name='from' <xs:attribute name='from'
type='xs:string' type='xs:string'
use='required'/> use='required'/>
<xs:attribute name='id' <xs:attribute name='id'
type='xs:NMTOKEN' type='xs:NMTOKEN'
use='optional'/> use='optional'/>
<xs:attribute ref='xml:lang'/> <xs:attribute ref='xml:lang' use='optional'/>
<xs:attribute name='type' use='optional'> <xs:attribute name='type' use='optional'>
<xs:simpleType> <xs:simpleType>
<xs:restriction base='xs:NCName'> <xs:restriction base='xs:NCName'>
<xs:enumeration value='chat'/> <xs:enumeration value='chat'/>
<xs:enumeration value='error'/> <xs:enumeration value='error'/>
<xs:enumeration value='groupchat'/> <xs:enumeration value='groupchat'/>
<xs:enumeration value='headline'/> <xs:enumeration value='headline'/>
<xs:enumeration value='normal'/> <xs:enumeration value='normal'/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
skipping to change at page 79, line 7 skipping to change at page 80, line 30
</xs:sequence> </xs:sequence>
<xs:attribute name='to' <xs:attribute name='to'
type='xs:string' type='xs:string'
use='required'/> use='required'/>
<xs:attribute name='from' <xs:attribute name='from'
type='xs:string' type='xs:string'
use='required'/> use='required'/>
<xs:attribute name='id' <xs:attribute name='id'
type='xs:NMTOKEN' type='xs:NMTOKEN'
use='optional'/> use='optional'/>
<xs:attribute ref='xml:lang'/> <xs:attribute ref='xml:lang' use='optional'/>
<xs:attribute name='type' use='optional'> <xs:attribute name='type' use='optional'>
<xs:simpleType> <xs:simpleType>
<xs:restriction base='xs:NCName'> <xs:restriction base='xs:NCName'>
<xs:enumeration value='subscribe'/> <xs:enumeration value='subscribe'/>
<xs:enumeration value='subscribed'/> <xs:enumeration value='subscribed'/>
<xs:enumeration value='unsubscribe'/> <xs:enumeration value='unsubscribe'/>
<xs:enumeration value='unsubscribed'/> <xs:enumeration value='unsubscribed'/>
<xs:enumeration value='unavailable'/> <xs:enumeration value='unavailable'/>
<xs:enumeration value='error'/> <xs:enumeration value='error'/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:attribute> </xs:attribute>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:element name='show'> <xs:element name='show'>
<xs:simpleType> <xs:simpleType>
<xs:restriction base='xs:NCName'> <xs:restriction base='xs:NCName'>
<xs:enumeration value='away'/> <xs:enumeration value='away'/>
<xs:enumeration value='chat'/> <xs:enumeration value='chat'/>
<xs:enumeration value='xa'/>
<xs:enumeration value='dnd'/> <xs:enumeration value='dnd'/>
<xs:enumeration value='xa'/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:element> </xs:element>
<xs:element name='status' type='xs:string'> <xs:element name='status' 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>
skipping to change at page 80, line 13 skipping to change at page 81, line 36
</xs:sequence> </xs:sequence>
<xs:attribute name='to' <xs:attribute name='to'
type='xs:string' type='xs:string'
use='required'/> use='required'/>
<xs:attribute name='from' <xs:attribute name='from'
type='xs:string' type='xs:string'
use='required'/> use='required'/>
<xs:attribute name='id' <xs:attribute name='id'
type='xs:NMTOKEN' type='xs:NMTOKEN'
use='optional'/> use='optional'/>
<xs:attribute ref='xml:lang'/> <xs:attribute ref='xml:lang' use='optional'/>
<xs:attribute name='type' use='required'> <xs:attribute name='type' use='required'>
<xs:simpleType> <xs:simpleType>
<xs:restriction base='xs:NCName'> <xs:restriction base='xs:NCName'>
<xs:enumeration value='get'/> <xs:enumeration value='get'/>
<xs:enumeration value='set'/> <xs:enumeration value='set'/>
<xs:enumeration value='result'/> <xs:enumeration value='result'/>
<xs:enumeration value='error'/> <xs:enumeration value='error'/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:attribute> </xs:attribute>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:element name='error'> <xs:element name='error'>
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<xs:any namespace='urn:ietf:params:xml:ns:xmpp-stanzas' <xs:any namespace='urn:ietf:params:xml:ns:xmpp-stanzas'
maxOccurs='1'/> maxOccurs='1'/>
<text namespace='urn:ietf:params:xml:ns:xmpp-stanzas'
minOccurs='0'
maxOccurs='1'/>
<xs:any <xs:any
namespace='##other' namespace='##other'
minOccurs='0' minOccurs='0'
maxOccurs='1'/> maxOccurs='1'/>
</xs:sequence> </xs:sequence>
<xs:attribute name='type' use='required'/> <xs:attribute name='type' use='required'/>
<xs:simpleType> <xs:simpleType>
<xs:restriction base='xs:NCName'> <xs:restriction base='xs:NCName'>
<xs:enumeration value='cancel'/> <xs:enumeration value='cancel'/>
<xs:enumeration value='continue'/> <xs:enumeration value='continue'/>
skipping to change at page 81, line 11 skipping to change at page 82, line 37
</xs:element> </xs:element>
</xs:schema> </xs:schema>
A.8 Stanza error namespace A.8 Stanza error namespace
<?xml version='1.0' encoding='UTF-8'?> <?xml version='1.0' encoding='UTF-8'?>
<xs:schema <xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema' xmlns:xs='http://www.w3.org/2001/XMLSchema'
xmlns:xml='http://www.w3.org/XML/1998/namespace'
targetNamespace='urn:ietf:params:xml:ns:xmpp-stanzas' targetNamespace='urn:ietf:params:xml:ns:xmpp-stanzas'
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas' xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'
elementFormDefault='qualified'> elementFormDefault='qualified'>
<xs:import namespace='http://www.w3.org/XML/1998/namespace'
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='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='unexpected-request' type='empty'/> <xs:element name='unexpected-request' type='empty'/>
<xs:element name='text' type='xs:string'>
<xs:complexType>
<xs:attribute ref='xml:lang' use='optional'/>
</xs:complexType>
</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>
</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-12 B.1 Changes from draft-ietf-xmpp-core-13
o Clarified stream restart after successful TLS and SASL
negotiation.
o Clarified requirement for resolution of DNS hostnames.
o Clarified text regarding namespaces.
o Clarified examples regarding empty <stream:features/> element.
o Added several more SASL error conditions.
o Changed <invalid-xml/> stream error to <improper-addressing/> and
added to schema.
o Made small editorial changes and fixed several schema errors.
B.2 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.2 Changes from draft-ietf-xmpp-core-11 B.3 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.3 Changes from draft-ietf-xmpp-core-10 B.4 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.4 Changes from draft-ietf-xmpp-core-09 B.5 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.5 Changes from draft-ietf-xmpp-core-08 B.6 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.6 Changes from draft-ietf-xmpp-core-07 B.7 Changes from draft-ietf-xmpp-core-07
o Made several small editorial changes. o Made several small editorial changes.
B.7 Changes from draft-ietf-xmpp-core-06 B.8 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 [25].
o Removed note to RFC Editor regarding provisional namespace names. o Removed note to RFC Editor regarding provisional namespace names.
B.8 Changes from draft-ietf-xmpp-core-05 B.9 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.9 Changes from draft-ietf-xmpp-core-04 B.10 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.10 Changes from draft-ietf-xmpp-core-03 B.11 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.11 Changes from draft-ietf-xmpp-core-02 B.12 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.12 Changes from draft-ietf-xmpp-core-01 B.13 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.13 Changes from draft-ietf-xmpp-core-00 B.14 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.14 Changes from draft-miller-xmpp-core-02 B.15 Changes from draft-miller-xmpp-core-02
o Brought Streams Authentication section into line with discussion o Brought Streams Authentication section into line with discussion
on list and at IETF 55 meeting. on list and at IETF 55 meeting.
o Added information about the optional 'xml:lang' attribute per o Added information about the optional 'xml:lang' attribute per
discussion on list and at IETF 55 meeting. discussion on list and at IETF 55 meeting.
o Specified that validation is neither required nor recommended, and o Specified that validation is neither required nor recommended, and
that the formal definitions (DTDs and schemas) are included for that the formal definitions (DTDs and schemas) are included for
descriptive purposes only. descriptive purposes only.
 End of changes. 201 change blocks. 
466 lines changed or deleted 698 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/