Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6120

Extensible Messaging and Presence Protocol (XMPP): Core

Pages: 211
Proposed Standard
Errata
Obsoletes:  3920
Updated by:  75908553
Part 1 of 9 – Pages 1 to 13
None   None   Next

Top   ToC   RFC6120 - 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   ToC   RFC6120 - 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   RFC6120 - 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   RFC6120 - 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   RFC6120 - 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   RFC6120 - 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   RFC6120 - 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   RFC6120 - 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   RFC6120 - 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   RFC6120 - 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   RFC6120 - 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   RFC6120 - 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   RFC6120 - 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 Section