tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6120

 Errata 
Proposed STD
Pages: 211
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: XMPP

Extensible Messaging and Presence Protocol (XMPP): Core

Part 1 of 9, p. 1 to 13
None       Next RFC Part

Obsoletes:    3920
Updated by:    7590


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                    P. Saint-Andre
Request for Comments: 6120                                         Cisco
Obsoletes: 3920                                               March 2011
Category: Standards Track
ISSN: 2070-1721


        Extensible Messaging and Presence Protocol (XMPP): Core

Abstract

   The Extensible Messaging and Presence Protocol (XMPP) is an
   application profile of the Extensible Markup Language (XML) that
   enables the near-real-time exchange of structured yet extensible data
   between any two or more network entities.  This document defines
   XMPP's core protocol methods: setup and teardown of XML streams,
   channel encryption, authentication, error handling, and communication
   primitives for messaging, network availability ("presence"), and
   request-response interactions.  This document obsoletes RFC 3920.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc6120.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Top       Page 2 
Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   8
     1.1.   Overview . . . . . . . . . . . . . . . . . . . . . . . .   8
     1.2.   History  . . . . . . . . . . . . . . . . . . . . . . . .   8
     1.3.   Functional Summary . . . . . . . . . . . . . . . . . . .   9
     1.4.   Terminology  . . . . . . . . . . . . . . . . . . . . . .  11
   2.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .  13
     2.1.   Global Addresses . . . . . . . . . . . . . . . . . . . .  13
     2.2.   Presence . . . . . . . . . . . . . . . . . . . . . . . .  14
     2.3.   Persistent Streams . . . . . . . . . . . . . . . . . . .  14
     2.4.   Structured Data  . . . . . . . . . . . . . . . . . . . .  14
     2.5.   Distributed Network of Clients and Servers . . . . . . .  14
   3.  TCP Binding . . . . . . . . . . . . . . . . . . . . . . . . .  16
     3.1.   Scope  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     3.2.   Resolution of Fully Qualified Domain Names . . . . . . .  17
       3.2.1.   Preferred Process: SRV Lookup  . . . . . . . . . . .  17
       3.2.2.   Fallback Processes . . . . . . . . . . . . . . . . .  18
       3.2.3.   When Not to Use SRV  . . . . . . . . . . . . . . . .  18
       3.2.4.   Use of SRV Records with Add-On Services  . . . . . .  19
     3.3.   Reconnection . . . . . . . . . . . . . . . . . . . . . .  19
     3.4.   Reliability  . . . . . . . . . . . . . . . . . . . . . .  20
   4.  XML Streams . . . . . . . . . . . . . . . . . . . . . . . . .  20
     4.1.   Stream Fundamentals  . . . . . . . . . . . . . . . . . .  20
     4.2.   Opening a Stream . . . . . . . . . . . . . . . . . . . .  23
     4.3.   Stream Negotiation . . . . . . . . . . . . . . . . . . .  24
       4.3.1.   Basic Concepts . . . . . . . . . . . . . . . . . . .  24
       4.3.2.   Stream Features Format . . . . . . . . . . . . . . .  25
       4.3.3.   Restarts . . . . . . . . . . . . . . . . . . . . . .  27
       4.3.4.   Resending Features . . . . . . . . . . . . . . . . .  27
       4.3.5.   Completion of Stream Negotiation . . . . . . . . . .  27
       4.3.6.   Determination of Addresses . . . . . . . . . . . . .  28
       4.3.7.   Flow Chart . . . . . . . . . . . . . . . . . . . . .  29
     4.4.   Closing a Stream . . . . . . . . . . . . . . . . . . . .  31
     4.5.   Directionality . . . . . . . . . . . . . . . . . . . . .  32
     4.6.   Handling of Silent Peers . . . . . . . . . . . . . . . .  33
       4.6.1.   Dead Connection  . . . . . . . . . . . . . . . . . .  34
       4.6.2.   Broken Stream  . . . . . . . . . . . . . . . . . . .  34
       4.6.3.   Idle Peer  . . . . . . . . . . . . . . . . . . . . .  34
       4.6.4.   Use of Checking Methods  . . . . . . . . . . . . . .  35
     4.7.   Stream Attributes  . . . . . . . . . . . . . . . . . . .  35
       4.7.1.   from . . . . . . . . . . . . . . . . . . . . . . . .  35
       4.7.2.   to . . . . . . . . . . . . . . . . . . . . . . . . .  37
       4.7.3.   id . . . . . . . . . . . . . . . . . . . . . . . . .  38
       4.7.4.   xml:lang . . . . . . . . . . . . . . . . . . . . . .  39
       4.7.5.   version  . . . . . . . . . . . . . . . . . . . . . .  41
       4.7.6.   Summary of Stream Attributes . . . . . . . . . . . .  43
     4.8.   XML Namespaces . . . . . . . . . . . . . . . . . . . . .  43

Top      ToC       Page 3 
       4.8.1.   Stream Namespace . . . . . . . . . . . . . . . . . .  43
       4.8.2.   Content Namespace  . . . . . . . . . . . . . . . . .  43
       4.8.3.   XMPP Content Namespaces  . . . . . . . . . . . . . .  44
       4.8.4.   Other Namespaces . . . . . . . . . . . . . . . . . .  46
       4.8.5.   Namespace Declarations and Prefixes  . . . . . . . .  47
     4.9.   Stream Errors  . . . . . . . . . . . . . . . . . . . . .  48
       4.9.1.   Rules  . . . . . . . . . . . . . . . . . . . . . . .  48
         4.9.1.1.  Stream Errors Are Unrecoverable . . . . . . . . .  48
         4.9.1.2.  Stream Errors Can Occur During Setup  . . . . . .  49
         4.9.1.3.  Stream Errors When the Host Is Unspecified or
                   Unknown . . . . . . . . . . . . . . . . . . . . .  50
         4.9.1.4.  Where Stream Errors Are Sent  . . . . . . . . . .  50
       4.9.2.   Syntax . . . . . . . . . . . . . . . . . . . . . . .  51
       4.9.3.   Defined Stream Error Conditions  . . . . . . . . . .  52
         4.9.3.1.  bad-format  . . . . . . . . . . . . . . . . . . .  52
         4.9.3.2.  bad-namespace-prefix  . . . . . . . . . . . . . .  52
         4.9.3.3.  conflict  . . . . . . . . . . . . . . . . . . . .  53
         4.9.3.4.  connection-timeout  . . . . . . . . . . . . . . .  54
         4.9.3.5.  host-gone . . . . . . . . . . . . . . . . . . . .  54
         4.9.3.6.  host-unknown  . . . . . . . . . . . . . . . . . .  55
         4.9.3.7.  improper-addressing . . . . . . . . . . . . . . .  56
         4.9.3.8.  internal-server-error . . . . . . . . . . . . . .  56
         4.9.3.9.  invalid-from  . . . . . . . . . . . . . . . . . .  56
         4.9.3.10. invalid-namespace . . . . . . . . . . . . . . . .  57
         4.9.3.11. invalid-xml . . . . . . . . . . . . . . . . . . .  57
         4.9.3.12. not-authorized  . . . . . . . . . . . . . . . . .  58
         4.9.3.13. not-well-formed . . . . . . . . . . . . . . . . .  59
         4.9.3.14. policy-violation  . . . . . . . . . . . . . . . .  59
         4.9.3.15. remote-connection-failed  . . . . . . . . . . . .  60
         4.9.3.16. reset . . . . . . . . . . . . . . . . . . . . . .  60
         4.9.3.17. resource-constraint . . . . . . . . . . . . . . .  61
         4.9.3.18. restricted-xml  . . . . . . . . . . . . . . . . .  61
         4.9.3.19. see-other-host  . . . . . . . . . . . . . . . . .  62
         4.9.3.20. system-shutdown . . . . . . . . . . . . . . . . .  64
         4.9.3.21. undefined-condition . . . . . . . . . . . . . . .  64
         4.9.3.22. unsupported-encoding  . . . . . . . . . . . . . .  64
         4.9.3.23. unsupported-feature . . . . . . . . . . . . . . .  65
         4.9.3.24. unsupported-stanza-type . . . . . . . . . . . . .  65
         4.9.3.25. unsupported-version . . . . . . . . . . . . . . .  66
       4.9.4.   Application-Specific Conditions  . . . . . . . . . .  67
     4.10.  Simplified Stream Examples . . . . . . . . . . . . . . .  68
   5.  STARTTLS Negotiation  . . . . . . . . . . . . . . . . . . . .  69
     5.1.   Fundamentals . . . . . . . . . . . . . . . . . . . . . .  69
     5.2.   Support  . . . . . . . . . . . . . . . . . . . . . . . .  70
     5.3.   Stream Negotiation Rules . . . . . . . . . . . . . . . .  70
       5.3.1.   Mandatory-to-Negotiate . . . . . . . . . . . . . . .  70
       5.3.2.   Restart  . . . . . . . . . . . . . . . . . . . . . .  70
       5.3.3.   Data Formatting  . . . . . . . . . . . . . . . . . .  70

Top      ToC       Page 4 
       5.3.4.   Order of TLS and SASL Negotiations . . . . . . . . .  71
       5.3.5.   TLS Renegotiation  . . . . . . . . . . . . . . . . .  71
       5.3.6.   TLS Extensions . . . . . . . . . . . . . . . . . . .  72
     5.4.   Process  . . . . . . . . . . . . . . . . . . . . . . . .  72
       5.4.1.   Exchange of Stream Headers and Stream Features . . .  72
       5.4.2.   Initiation of STARTTLS Negotiation . . . . . . . . .  73
         5.4.2.1.  STARTTLS Command  . . . . . . . . . . . . . . . .  73
         5.4.2.2.  Failure Case  . . . . . . . . . . . . . . . . . .  73
         5.4.2.3.  Proceed Case  . . . . . . . . . . . . . . . . . .  74
       5.4.3.   TLS Negotiation  . . . . . . . . . . . . . . . . . .  74
         5.4.3.1.  Rules . . . . . . . . . . . . . . . . . . . . . .  74
         5.4.3.2.  TLS Failure . . . . . . . . . . . . . . . . . . .  75
         5.4.3.3.  TLS Success . . . . . . . . . . . . . . . . . . .  76
   6.  SASL Negotiation  . . . . . . . . . . . . . . . . . . . . . .  77
     6.1.   Fundamentals . . . . . . . . . . . . . . . . . . . . . .  77
     6.2.   Support  . . . . . . . . . . . . . . . . . . . . . . . .  77
     6.3.   Stream Negotiation Rules . . . . . . . . . . . . . . . .  77
       6.3.1.   Mandatory-to-Negotiate . . . . . . . . . . . . . . .  77
       6.3.2.   Restart  . . . . . . . . . . . . . . . . . . . . . .  78
       6.3.3.   Mechanism Preferences  . . . . . . . . . . . . . . .  78
       6.3.4.   Mechanism Offers . . . . . . . . . . . . . . . . . .  78
       6.3.5.   Data Formatting  . . . . . . . . . . . . . . . . . .  79
       6.3.6.   Security Layers  . . . . . . . . . . . . . . . . . .  80
       6.3.7.   Simple User Name . . . . . . . . . . . . . . . . . .  80
       6.3.8.   Authorization Identity . . . . . . . . . . . . . . .  80
       6.3.9.   Realms . . . . . . . . . . . . . . . . . . . . . . .  81
       6.3.10.  Round Trips  . . . . . . . . . . . . . . . . . . . .  81
     6.4.   Process  . . . . . . . . . . . . . . . . . . . . . . . .  82
       6.4.1.   Exchange of Stream Headers and Stream Features . . .  82
       6.4.2.   Initiation . . . . . . . . . . . . . . . . . . . . .  83
       6.4.3.   Challenge-Response Sequence  . . . . . . . . . . . .  84
       6.4.4.   Abort  . . . . . . . . . . . . . . . . . . . . . . .  84
       6.4.5.   SASL Failure . . . . . . . . . . . . . . . . . . . .  85
       6.4.6.   SASL Success . . . . . . . . . . . . . . . . . . . .  86
     6.5.   SASL Errors  . . . . . . . . . . . . . . . . . . . . . .  87
       6.5.1.   aborted  . . . . . . . . . . . . . . . . . . . . . .  88
       6.5.2.   account-disabled . . . . . . . . . . . . . . . . . .  88
       6.5.3.   credentials-expired  . . . . . . . . . . . . . . . .  88
       6.5.4.   encryption-required  . . . . . . . . . . . . . . . .  89
       6.5.5.   incorrect-encoding . . . . . . . . . . . . . . . . .  89
       6.5.6.   invalid-authzid  . . . . . . . . . . . . . . . . . .  89
       6.5.7.   invalid-mechanism  . . . . . . . . . . . . . . . . .  90
       6.5.8.   malformed-request  . . . . . . . . . . . . . . . . .  90
       6.5.9.   mechanism-too-weak . . . . . . . . . . . . . . . . .  90
       6.5.10.  not-authorized . . . . . . . . . . . . . . . . . . .  91
       6.5.11.  temporary-auth-failure . . . . . . . . . . . . . . .  91
     6.6.   SASL Definition  . . . . . . . . . . . . . . . . . . . .  91
   7.  Resource Binding  . . . . . . . . . . . . . . . . . . . . . .  92

Top      ToC       Page 5 
     7.1.   Fundamentals . . . . . . . . . . . . . . . . . . . . . .  92
     7.2.   Support  . . . . . . . . . . . . . . . . . . . . . . . .  93
     7.3.   Stream Negotiation Rules . . . . . . . . . . . . . . . .  93
       7.3.1.   Mandatory-to-Negotiate . . . . . . . . . . . . . . .  93
       7.3.2.   Restart  . . . . . . . . . . . . . . . . . . . . . .  93
     7.4.   Advertising Support  . . . . . . . . . . . . . . . . . .  93
     7.5.   Generation of Resource Identifiers . . . . . . . . . . .  94
     7.6.   Server-Generated Resource Identifier . . . . . . . . . .  94
       7.6.1.   Success Case . . . . . . . . . . . . . . . . . . . .  94
       7.6.2.   Error Cases  . . . . . . . . . . . . . . . . . . . .  95
         7.6.2.1.  Resource Constraint . . . . . . . . . . . . . . .  95
         7.6.2.2.  Not Allowed . . . . . . . . . . . . . . . . . . .  96
     7.7.   Client-Submitted Resource Identifier . . . . . . . . . .  96
       7.7.1.   Success Case . . . . . . . . . . . . . . . . . . . .  96
       7.7.2.   Error Cases  . . . . . . . . . . . . . . . . . . . .  97
         7.7.2.1.  Bad Request . . . . . . . . . . . . . . . . . . .  97
         7.7.2.2.  Conflict  . . . . . . . . . . . . . . . . . . . .  97
       7.7.3.   Retries  . . . . . . . . . . . . . . . . . . . . . .  99
   8.  XML Stanzas . . . . . . . . . . . . . . . . . . . . . . . . .  99
     8.1.   Common Attributes  . . . . . . . . . . . . . . . . . . . 100
       8.1.1.   to . . . . . . . . . . . . . . . . . . . . . . . . . 100
         8.1.1.1.  Client-to-Server Streams  . . . . . . . . . . . . 100
         8.1.1.2.  Server-to-Server Streams  . . . . . . . . . . . . 101
       8.1.2.   from . . . . . . . . . . . . . . . . . . . . . . . . 101
         8.1.2.1.  Client-to-Server Streams  . . . . . . . . . . . . 101
         8.1.2.2.  Server-to-Server Streams  . . . . . . . . . . . . 102
       8.1.3.   id . . . . . . . . . . . . . . . . . . . . . . . . . 103
       8.1.4.   type . . . . . . . . . . . . . . . . . . . . . . . . 103
       8.1.5.   xml:lang . . . . . . . . . . . . . . . . . . . . . . 103
     8.2.   Basic Semantics  . . . . . . . . . . . . . . . . . . . . 105
       8.2.1.   Message Semantics  . . . . . . . . . . . . . . . . . 105
       8.2.2.   Presence Semantics . . . . . . . . . . . . . . . . . 105
       8.2.3.   IQ Semantics . . . . . . . . . . . . . . . . . . . . 105
     8.3.   Stanza Errors  . . . . . . . . . . . . . . . . . . . . . 107
       8.3.1.   Rules  . . . . . . . . . . . . . . . . . . . . . . . 108
       8.3.2.   Syntax . . . . . . . . . . . . . . . . . . . . . . . 109
       8.3.3.   Defined Conditions . . . . . . . . . . . . . . . . . 110
         8.3.3.1.  bad-request . . . . . . . . . . . . . . . . . . . 110
         8.3.3.2.  conflict  . . . . . . . . . . . . . . . . . . . . 111
         8.3.3.3.  feature-not-implemented . . . . . . . . . . . . . 111
         8.3.3.4.  forbidden . . . . . . . . . . . . . . . . . . . . 112
         8.3.3.5.  gone  . . . . . . . . . . . . . . . . . . . . . . 113
         8.3.3.6.  internal-server-error . . . . . . . . . . . . . . 113
         8.3.3.7.  item-not-found  . . . . . . . . . . . . . . . . . 114
         8.3.3.8.  jid-malformed . . . . . . . . . . . . . . . . . . 114
         8.3.3.9.  not-acceptable  . . . . . . . . . . . . . . . . . 115
         8.3.3.10. not-allowed . . . . . . . . . . . . . . . . . . . 116
         8.3.3.11. not-authorized  . . . . . . . . . . . . . . . . . 116

Top      ToC       Page 6 
         8.3.3.12. policy-violation  . . . . . . . . . . . . . . . . 117
         8.3.3.13. recipient-unavailable . . . . . . . . . . . . . . 117
         8.3.3.14. redirect  . . . . . . . . . . . . . . . . . . . . 118
         8.3.3.15. registration-required . . . . . . . . . . . . . . 119
         8.3.3.16. remote-server-not-found . . . . . . . . . . . . . 119
         8.3.3.17. remote-server-timeout . . . . . . . . . . . . . . 120
         8.3.3.18. resource-constraint . . . . . . . . . . . . . . . 121
         8.3.3.19. service-unavailable . . . . . . . . . . . . . . . 121
         8.3.3.20. subscription-required . . . . . . . . . . . . . . 122
         8.3.3.21. undefined-condition . . . . . . . . . . . . . . . 123
         8.3.3.22. unexpected-request  . . . . . . . . . . . . . . . 123
       8.3.4.   Application-Specific Conditions  . . . . . . . . . . 124
     8.4.   Extended Content . . . . . . . . . . . . . . . . . . . . 125
   9.  Detailed Examples . . . . . . . . . . . . . . . . . . . . . . 128
     9.1.   Client-to-Server Examples  . . . . . . . . . . . . . . . 128
       9.1.1.   TLS  . . . . . . . . . . . . . . . . . . . . . . . . 128
       9.1.2.   SASL . . . . . . . . . . . . . . . . . . . . . . . . 130
       9.1.3.   Resource Binding . . . . . . . . . . . . . . . . . . 132
       9.1.4.   Stanza Exchange  . . . . . . . . . . . . . . . . . . 133
       9.1.5.   Close  . . . . . . . . . . . . . . . . . . . . . . . 134
     9.2.   Server-to-Server Examples  . . . . . . . . . . . . . . . 134
       9.2.1.   TLS  . . . . . . . . . . . . . . . . . . . . . . . . 134
       9.2.2.   SASL . . . . . . . . . . . . . . . . . . . . . . . . 136
       9.2.3.   Stanza Exchange  . . . . . . . . . . . . . . . . . . 137
       9.2.4.   Close  . . . . . . . . . . . . . . . . . . . . . . . 137
   10. Server Rules for Processing XML Stanzas . . . . . . . . . . . 138
     10.1.  In-Order Processing  . . . . . . . . . . . . . . . . . . 138
     10.2.  General Considerations . . . . . . . . . . . . . . . . . 140
     10.3.  No 'to' Address  . . . . . . . . . . . . . . . . . . . . 141
       10.3.1.  Message  . . . . . . . . . . . . . . . . . . . . . . 141
       10.3.2.  Presence . . . . . . . . . . . . . . . . . . . . . . 141
       10.3.3.  IQ . . . . . . . . . . . . . . . . . . . . . . . . . 141
     10.4.  Remote Domain  . . . . . . . . . . . . . . . . . . . . . 142
       10.4.1.  Existing Stream  . . . . . . . . . . . . . . . . . . 142
       10.4.2.  No Existing Stream . . . . . . . . . . . . . . . . . 142
       10.4.3.  Error Handling . . . . . . . . . . . . . . . . . . . 143
     10.5.  Local Domain . . . . . . . . . . . . . . . . . . . . . . 143
       10.5.1.  domainpart . . . . . . . . . . . . . . . . . . . . . 143
       10.5.2.  domainpart/resourcepart  . . . . . . . . . . . . . . 143
       10.5.3.  localpart@domainpart . . . . . . . . . . . . . . . . 143
         10.5.3.1. No Such User  . . . . . . . . . . . . . . . . . . 144
         10.5.3.2. User Exists . . . . . . . . . . . . . . . . . . . 144
       10.5.4.  localpart@domainpart/resourcepart  . . . . . . . . . 144
   11. XML Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 145
     11.1.  XML Restrictions . . . . . . . . . . . . . . . . . . . . 145
     11.2.  XML Namespace Names and Prefixes . . . . . . . . . . . . 146
     11.3.  Well-Formedness  . . . . . . . . . . . . . . . . . . . . 146
     11.4.  Validation . . . . . . . . . . . . . . . . . . . . . . . 147

Top      ToC       Page 7 
     11.5.  Inclusion of XML Declaration . . . . . . . . . . . . . . 147
     11.6.  Character Encoding . . . . . . . . . . . . . . . . . . . 147
     11.7.  Whitespace . . . . . . . . . . . . . . . . . . . . . . . 148
     11.8.  XML Versions . . . . . . . . . . . . . . . . . . . . . . 148
   12. Internationalization Considerations . . . . . . . . . . . . . 148
   13. Security Considerations . . . . . . . . . . . . . . . . . . . 148
     13.1.  Fundamentals . . . . . . . . . . . . . . . . . . . . . . 148
     13.2.  Threat Model . . . . . . . . . . . . . . . . . . . . . . 149
     13.3.  Order of Layers  . . . . . . . . . . . . . . . . . . . . 150
     13.4.  Confidentiality and Integrity  . . . . . . . . . . . . . 150
     13.5.  Peer Entity Authentication . . . . . . . . . . . . . . . 151
     13.6.  Strong Security  . . . . . . . . . . . . . . . . . . . . 151
     13.7.  Certificates . . . . . . . . . . . . . . . . . . . . . . 152
       13.7.1.  Certificate Generation . . . . . . . . . . . . . . . 152
         13.7.1.1. General Considerations  . . . . . . . . . . . . . 152
         13.7.1.2. Server Certificates . . . . . . . . . . . . . . . 153
         13.7.1.3. Client Certificates . . . . . . . . . . . . . . . 156
         13.7.1.4. XmppAddr Identifier Type  . . . . . . . . . . . . 156
       13.7.2.  Certificate Validation . . . . . . . . . . . . . . . 157
         13.7.2.1. Server Certificates . . . . . . . . . . . . . . . 158
         13.7.2.2. Client Certificates . . . . . . . . . . . . . . . 158
         13.7.2.3. Checking of Certificates in Long-Lived Streams  . 160
         13.7.2.4. Use of Certificates in XMPP Extensions  . . . . . 160
     13.8.  Mandatory-to-Implement TLS and SASL Technologies . . . . 160
       13.8.1.  For Authentication Only  . . . . . . . . . . . . . . 161
       13.8.2.  For Confidentiality Only . . . . . . . . . . . . . . 161
       13.8.3.  For Confidentiality and Authentication with
                Passwords  . . . . . . . . . . . . . . . . . . . . . 162
       13.8.4.  For Confidentiality and Authentication without
                Passwords  . . . . . . . . . . . . . . . . . . . . . 163
     13.9.  Technology Reuse . . . . . . . . . . . . . . . . . . . . 163
       13.9.1.  Use of Base 64 in SASL . . . . . . . . . . . . . . . 163
       13.9.2.  Use of DNS . . . . . . . . . . . . . . . . . . . . . 163
       13.9.3.  Use of Hash Functions  . . . . . . . . . . . . . . . 164
       13.9.4.  Use of SASL  . . . . . . . . . . . . . . . . . . . . 164
       13.9.5.  Use of TLS . . . . . . . . . . . . . . . . . . . . . 165
       13.9.6.  Use of UTF-8 . . . . . . . . . . . . . . . . . . . . 165
       13.9.7.  Use of XML . . . . . . . . . . . . . . . . . . . . . 166
     13.10. Information Leaks  . . . . . . . . . . . . . . . . . . . 166
       13.10.1. IP Addresses . . . . . . . . . . . . . . . . . . . . 166
       13.10.2. Presence Information . . . . . . . . . . . . . . . . 166
     13.11. Directory Harvesting . . . . . . . . . . . . . . . . . . 166
     13.12. Denial of Service  . . . . . . . . . . . . . . . . . . . 167
     13.13. Firewalls  . . . . . . . . . . . . . . . . . . . . . . . 169
     13.14. Interdomain Federation . . . . . . . . . . . . . . . . . 169
     13.15. Non-Repudiation  . . . . . . . . . . . . . . . . . . . . 169
   14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 170
     14.1.  XML Namespace Name for TLS Data  . . . . . . . . . . . . 170

Top      ToC       Page 8 
     14.2.  XML Namespace Name for SASL Data . . . . . . . . . . . . 170
     14.3.  XML Namespace Name for Stream Errors . . . . . . . . . . 170
     14.4.  XML Namespace Name for Resource Binding  . . . . . . . . 171
     14.5.  XML Namespace Name for Stanza Errors . . . . . . . . . . 171
     14.6.  GSSAPI Service Name  . . . . . . . . . . . . . . . . . . 171
     14.7.  Port Numbers and Service Names . . . . . . . . . . . . . 171
   15. Conformance Requirements  . . . . . . . . . . . . . . . . . . 172
   16. References  . . . . . . . . . . . . . . . . . . . . . . . . . 181
     16.1.  Normative References . . . . . . . . . . . . . . . . . . 181
     16.2.  Informative References . . . . . . . . . . . . . . . . . 184
   Appendix A.  XML Schemas  . . . . . . . . . . . . . . . . . . . . 190
     A.1.   Stream Namespace . . . . . . . . . . . . . . . . . . . . 190
     A.2.   Stream Error Namespace . . . . . . . . . . . . . . . . . 192
     A.3.   STARTTLS Namespace . . . . . . . . . . . . . . . . . . . 193
     A.4.   SASL Namespace . . . . . . . . . . . . . . . . . . . . . 194
     A.5.   Client Namespace . . . . . . . . . . . . . . . . . . . . 196
     A.6.   Server Namespace . . . . . . . . . . . . . . . . . . . . 201
     A.7.   Resource Binding Namespace . . . . . . . . . . . . . . . 206
     A.8.   Stanza Error Namespace . . . . . . . . . . . . . . . . . 206
   Appendix B.  Contact Addresses  . . . . . . . . . . . . . . . . . 208
   Appendix C.  Account Provisioning . . . . . . . . . . . . . . . . 208
   Appendix D.  Differences from RFC 3920  . . . . . . . . . . . . . 208
   Appendix E.  Acknowledgements . . . . . . . . . . . . . . . . . . 210

1.  Introduction

1.1.  Overview

   The Extensible Messaging and Presence Protocol (XMPP) is an
   application profile of the Extensible Markup Language [XML] that
   enables the near-real-time exchange of structured yet extensible data
   between any two or more network entities.  This document defines
   XMPP's core protocol methods: setup and teardown of XML streams,
   channel encryption, authentication, error handling, and communication
   primitives for messaging, network availability ("presence"), and
   request-response interactions.

1.2.  History

   The basic syntax and semantics of XMPP were developed originally
   within the Jabber open-source community, mainly in 1999.  In late
   2002, the XMPP Working Group was chartered with developing an
   adaptation of the base Jabber protocol that would be suitable as an
   IETF instant messaging (IM) and presence technology in accordance
   with [IMP-REQS].  In October 2004, [RFC3920] and [RFC3921] were
   published, representing the most complete definition of XMPP at that
   time.

Top      ToC       Page 9 
   Since 2004 the Internet community has gained extensive implementation
   and deployment experience with XMPP, including formal
   interoperability testing carried out under the auspices of the XMPP
   Standards Foundation (XSF).  This document incorporates comprehensive
   feedback from software developers and XMPP service providers,
   including a number of backward-compatible modifications summarized
   under Appendix D.  As a result, this document reflects the rough
   consensus of the Internet community regarding the core features of
   XMPP 1.0, thus obsoleting RFC 3920.

1.3.  Functional Summary

   This non-normative section provides a developer-friendly, functional
   summary of XMPP; refer to the sections that follow for a normative
   definition of XMPP.

   The purpose of XMPP is to enable the exchange of relatively small
   pieces of structured data (called "XML stanzas") over a network
   between any two (or more) entities.  XMPP is typically implemented
   using a distributed client-server architecture, wherein a client
   needs to connect to a server in order to gain access to the network
   and thus be allowed to exchange XML stanzas with other entities
   (which can be associated with other servers).  The process whereby a
   client connects to a server, exchanges XML stanzas, and ends the
   connection is:

   1.  Determine the IP address and port at which to connect, typically
       based on resolution of a fully qualified domain name
       (Section 3.2)

   2.  Open a Transmission Control Protocol [TCP] connection

   3.  Open an XML stream over TCP (Section 4.2)

   4.  Preferably negotiate Transport Layer Security [TLS] for channel
       encryption (Section 5)

   5.  Authenticate using a Simple Authentication and Security Layer
       [SASL] mechanism (Section 6)

   6.  Bind a resource to the stream (Section 7)

   7.  Exchange an unbounded number of XML stanzas with other entities
       on the network (Section 8)

   8.  Close the XML stream (Section 4.4)

   9.  Close the TCP connection

Top      ToC       Page 10 
   Within XMPP, one server can optionally connect to another server to
   enable inter-domain or inter-server communication.  For this to
   happen, the two servers need to negotiate a connection between
   themselves and then exchange XML stanzas; the process for doing so
   is:

   1.  Determine the IP address and port at which to connect, typically
       based on resolution of a fully qualified domain name
       (Section 3.2)

   2.  Open a TCP connection

   3.  Open an XML stream (Section 4.2)

   4.  Preferably negotiate TLS for channel encryption (Section 5)

   5.  Authenticate using a Simple Authentication and Security Layer
       [SASL] mechanism (Section 6) *

   6.  Exchange an unbounded number of XML stanzas both directly for the
       servers and indirectly on behalf of entities associated with each
       server, such as connected clients (Section 8)

   7.  Close the XML stream (Section 4.4)

   8.  Close the TCP connection

      * Interoperability Note: At the time of writing, most deployed
      servers still use the Server Dialback protocol [XEP-0220] to
      provide weak identity verification instead of using SASL with PKIX
      certificates to provide strong authentication, especially in cases
      where SASL negotiation would not result in strong authentication
      anyway (e.g., because TLS negotiation was not mandated by the peer
      server, or because the PKIX certificate presented by the peer
      server during TLS negotiation is self-signed and has not been
      previously accepted); for details, see [XEP-0220].  The solutions
      specified in this document offer a significantly stronger level of
      security (see also Section 13.6).

   This document specifies how clients connect to servers and specifies
   the basic semantics of XML stanzas.  However, this document does not
   define the "payloads" of the XML stanzas that might be exchanged once
   a connection is successfully established; instead, those payloads are
   defined by various XMPP extensions.  For example, [XMPP-IM] defines
   extensions for basic instant messaging and presence functionality.
   In addition, various specifications produced in the XSF's XEP series
   [XEP-0001] define extensions for a wide range of applications.

Top      ToC       Page 11 
1.4.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in RFC
   2119 [KEYWORDS].

   Certain security-related terms are to be understood in the sense
   defined in [SEC-TERMS]; such terms include, but are not limited to,
   "assurance", "attack", "authentication", "authorization",
   "certificate", "certification authority", "certification path",
   "confidentiality", "credential", "downgrade", "encryption", "hash
   value", "identity", "integrity", "signature", "self-signed
   certificate", "sign", "spoof", "tamper", "trust", "trust anchor",
   "validate", and "verify".

   Certain terms related to certificates, domains, and application
   service identity are to be understood in the sense defined in
   [TLS-CERTS]; these include, but are not limited to, "PKIX
   certificate", "source domain", "derived domain", and the identifier
   types "CN-ID", "DNS-ID", and "SRV-ID".

   Other security-related terms are to be understood in the sense
   defined in the referenced specifications (for example, "denial of
   service" as described in [DOS] or "end entity certificate" as
   described in [PKIX]).

   The term "whitespace" is used to refer to any character or characters
   matching the "S" production from [XML], i.e., one or more instances
   of the SP, HTAB, CR, or LF rules defined in [ABNF].

   The terms "localpart", "domainpart", and "resourcepart" are defined
   in [XMPP-ADDR].

   The term "bare JID" refers to an XMPP address of the form
   <localpart@domainpart> (for an account at a server) or of the form
   <domainpart> (for a server).

   The term "full JID" refers to an XMPP address of the form
   <localpart@domainpart/resourcepart> (for a particular authorized
   client or device associated with an account) or of the form
   <domainpart/resourcepart> (for a particular resource or script
   associated with a server).

   The term "XML stream" (also "stream") is defined under Section 4.1.

Top      ToC       Page 12 
   The term "XML stanza" (also "stanza") is defined under Section 4.1.
   There are three kinds of stanzas: message, presence, and IQ (short
   for "Info/Query").  These communication primitives are defined under
   Sections 8.2.1, 8.2.2, and 8.2.3, respectively.

   The term "originating entity" refers to the entity that first
   generates a stanza that is sent over an XMPP network (e.g., a
   connected client, an add-on service, or a server).  The term
   "generated stanza" refers to the stanza so generated.

   The term "input stream" designates an XML stream over which a server
   receives data from a connected client or remote server, and the term
   "output stream" designates an XML stream over which a server sends
   data to a connected client or remote server.  The following terms
   designate some of the actions that a server can perform when
   processing data received over an input stream:

      route:  pass the data to a remote server for direct processing by
         the remote server or eventual delivery to a client associated
         with the remote server

      deliver:  pass the data to a connected client

      ignore:  discard the data without acting upon it or returning an
         error to the sender

   When the term "ignore" is used with regard to client processing of
   data it receives, the phrase "without acting upon it" explicitly
   includes not presenting the data to a human user.

   Following the "XML Notation" used in [IRI] to represent characters
   that cannot be rendered in ASCII-only documents, some examples in
   this document use the form "&#x...." as a notational device to
   represent [UNICODE] characters (e.g., the string "&#x0159;" stands
   for the Unicode character LATIN SMALL LETTER R WITH CARON); this form
   is definitely not to be sent over the wire in XMPP systems.

   Consistent with the convention used in [URI] to represent Uniform
   Resource Identifiers, XMPP addresses in running text are enclosed
   between '<' and '>' (although natively they are not URIs).

   In examples, lines have been wrapped for improved readability,
   "[...]" means elision, and the following prepended strings are used
   (these prepended strings are not to be sent over the wire):

   o  C: = a client

   o  E: = any XMPP entity

Top      ToC       Page 13 
   o  I: = an initiating entity

   o  P: = a peer server

   o  R: = a receiving entity

   o  S: = a server

   o  S1: = server1

   o  S2: = server2

   Readers need to be aware that the examples are not exhaustive and
   that, in examples for some protocol flows, the alternate steps shown
   would not necessarily be triggered by the exact data sent in the
   previous step; in all cases the protocol definitions specified in
   this document or in normatively referenced documents rule over any
   examples provided here.  All examples are fictional and the
   information exchanged (e.g., usernames and passwords) does not
   represent any existing users or servers.



(page 13 continued on part 2)

Next RFC Part