RFC6120

"本文的英文原文来自RFC 6120

互联网工程任务组(IETF)	P. Saint-Andre
申请讨论: 6120	Cisco
取代: 3920	2011年3月
类别: 标准跟踪
ISSN: 2070-1721

可扩展的消息和出席信息协议 (XMPP): 核心协议

摘要

可扩展的消息和出席信息协议(XMPP)是一个XML应用，让任何两个或多个网络实体之间进行结构化和可扩展的准实时信息交流. 本文定义了XMPP的核心协议方法: XML流的配置和解除, 通道加密, 验证, 错误处理, 以及消息通讯基础, 网络可用性 ("presence"), 和 请求-应答 交互. 本文取代了 RFC 3920.

本文的状态

这是一个互联网标准跟踪文档.

本文是互联网工程工作组(IETF)的一个成果. 它代表了IETF社区的一致意见. 它已经公开审核并由互联网工程控制组(IESG)批准发布了. 更多关于互联网标准的信息请参见RFC 5741第2章.

关于本文当前状态的信息, 任何错误, 以及如何对它提出反馈，请到 http://www.rfc-editor.org/info/rfc6120 .

版权通知

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.

序论

概述

可扩展的消息和出席信息协议(XMPP)是一个可扩展标记语言XML应用，让任何两个或多个网络实体之间进行结构化和可扩展的准实时信息交流. 本文定义了XMPP的核心协议方法: XML流的配置和解除, 通道加密, 验证, 错误处理, 以及消息通讯基础, 网络可用性 ("presence"), 和 请求-应答 交互.

历史

XMPP的基本语法和语义最开始是由Jabber开源社区开发的, 主要是在1999年. 2002年, 根据 IMP‑REQS ，XMPP工作组被允许基于Jabber协议开发一个适合IETF的即时消息和出席信息技术. 到了2004年10月, 发布了 RFC3920 和 RFC3921 , 意味着那时候XMPP的主要定义完成了.

从2004年开始，互联网社区已经获得了广泛的XMPP实现和布署经验, 包括XMPP标准基金会(XSF)主持下开展的正式的互操作性测试. 本文全面整合了从软件开发者和XMPP服务提供者得到的反馈, 包含了一系列向后兼容的修改，见 附录D . 结果是, 本文反映了互联网社区对于XMPP1.0核心功能的初步共识, 因此废止了RFC 3920.

功能汇总

这个不规范的章节提供了一个方便开发者的XMPP功能汇总; 接下来的其他章节则是XMPP的规范定义.

XMPP的目标是允许两个(或多个)实体通过网络来交换相关的小件结构化数据(所谓"XML节"). XMPP典型地使用分布式的 客户端-服务器 体系结构来实现, 这里客户端需要连接到一个服务器以获得对网络的访问，从而被允许和其他实体(可能在其他服务器上)交换XML节. 一个客户端连接到一个服务器，交换XML节，以及结束连接，这样的流程如下:

1. 确定要连接的IP地址和端口号, 典型的做法是对一个合格的域名做出解析( 3.2 )
2. 打开一个传输控制协议 TCP 连接
3. 通过TCP打开一个XML流 4.2
4. 握手最好使用传输层安全性 TLS 来进行通道加密( 5 )
5. 使用简单验证和安全层 SASL 机制来验证 ( 6 )
6. 绑定一个资源到这个留上 ( 7 )
7. 和其他网络上的实体交换不限数量的XML节( 8 )
8. 关闭XML流 ( 4.4 )
9. 关闭TCP连接

在XMPP中, 一个服务器可以选择性地连接到另一个服务器以激活域间或服务器间的通讯. 这种情形下, 两个服务器需要在他们自身之间建立一个连接然后交换XML节; 这个过程所做的事情如下:

1. 确定要连接的IP地址和端口号, 典型的做法是对一个合格的域名做出解析( 3.2 )
2. 打开一个TCP连接
3. 打开一个XML流 4.2
4. 握手最好使用TLS来进行通道加密( 5 )
5. 使用简单验证和安全层 SASL 机制来验证 ( 6 ) *
6. 交换不限数量的XML节，可以服务器之间直接交换，也可以代表每台服务器上的相关实体来交换，例如那些连到服务器上的客户端 ( 8 )
7. 关闭XML流 ( 4.4 )
8. 关闭TCP连接

• 互操作性提示: 在本文写就的时候, 大多数已布署的服务器仍使用服务器回拨协议 XEP‑0220 来提供弱身份验证，而不是使用SASL的 PKIX证书来提供强验证, 特别在这些情况下，SASL握手无论如何将不会得到强验证 (例如, 因为TLS握手没有被对方服务器强制要求, 或因为当TLS握手时对方服务器提供的PKIX证书是自签名的并且之前没有被接受过); 细节请见 XEP‑0220 . 本文的解决方案显然提供了一个更高级别的安全性 (参见 13.6 ).

本文指定了客户端如何连接到服务器以及基本的XML节语义. 然而, 本文不定义一个连接成功建立之后可能用来交换的XML节的"载荷"; 反之, 那些载荷被定义在各种XMPP扩展之中. 例如, XMPP‑IM 定义了基本的即时消息和出席信息功能的扩展. 另外, XSF创造了各种扩展协议，即XEP系列 XEP‑0001 ,也为广泛的应用程序定义了扩展.

术语

本文中的关键字 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 和 "OPTIONAL" 的解释参见RFC 2119 关键字 .

特定的安全相关的术语的含义参见 安全术语 ; 这些术语包括但不限于, "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".

特定的和证书，域名，应用服务身份相关的术语参见 TLS‑证书 ; 这包括但不限于, "PKIX certificate", "source domain", "derived domain", 以及身份类型 "CN-ID", "DNS-ID", 和 "SRV-ID".

其他安全相关的术语定义于参考协议中 (例如, "denial of service" 定义于 DOS 或 "end entity certificate" 定义于 PKIX ).

术语 "whitespace" 用于指代 XML 中任何匹配"S"的字符或字符串, 也就是说, 一个或多个满足 ABNF 定义的SP, HTAB, CR, 或 LF 规则的实例.

术语 "localpart", "domainpart", 以及 "resourcepart" 定义于 XMPP地址 .

术语 "bare JID" 指代一个格式为 <localpart@domainpart> (对于一个位于某个服务器上的帐户而言) 或 <domainpart> (对于一个服务器而言) 的XMPP地址.

术语 "full JID" 指代一个格式为 <localpart@domainpart/resourcepart> (对一个典型的已授权客户端或和某个帐号相关的设备而言) 或 <domainpart/resourcepart> (对于一个典型的资源或和某个服务器相关的文字)的XMPP地址.

术语 "XML stream" (也称为 "stream") 定义于 4.1 .

The term "XML stanza" (also "stanza") is defined under Section 4.1 (Stream Fundamentals). There are three kinds of stanzas: message, presence, and IQ (short for "Info/Query"). These communication primitives are defined under Sections 8.2.1 (Message Semantics), 8.2.2 (Presence Semantics), and 8.2.3 (IQ Semantics), 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] (Duerst, M. and M. Suignard, “Internationalized Resource Identifiers (IRIs),” January 2005.) 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] (The Unicode Consortium, “The Unicode Standard, Version 6.0,” 2010.) characters (e.g., the string "ř" 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] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) 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):

   * C: = a client
   * E: = any XMPP entity
   * I: = an initiating entity
   * P: = a peer server
   * R: = a receiving entity
   * S: = a server
   * S1: = server1
   * 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.