查看源代码

[[Category:XMPP相关RFC]]
[[Category:XMPP核心RFC]]
[[Category:翻译中]]

"本文的英文原文来自[http://xmpp.org/rfcs/rfc6120.html RFC 6120]

{|border="1" cellspacing="0" width="65%"
|互联网工程任务组(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)是一个可扩展标记语言[[RFC6120#XML|XML]]应用，让任何两个或多个网络实体之间进行结构化和可扩展的准实时信息交流. 本文定义了XMPP的核心协议方法: XML流的配置和解除, 通道加密, 验证, 错误处理, 以及消息通讯基础, 网络可用性 ("presence"), 和 请求-应答 交互.

===历史===

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

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

===功能汇总===

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

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

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

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

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

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

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

===术语===

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

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

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

其他安全相关的术语定义于参考协议中 (例如, "denial of service" (拒绝服务)定义于 [[RFC6120#DOS|DOS]] 或 "end entity certificate" (终端实体证书)定义于 [[RFC6120#PKIX|PKIX]] ).

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

术语 "localpart" (本地部分), "domainpart" (域部分), 以及 "resourcepart" (资源部分)定义于 [[RFC6120#XMPP地址|XMPP地址]] .

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

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

术语 "XML stream" (也称为 "stream" (流)) 定义于 [[RFC6120#流的基本原理|4.1]] .

术语 "XML stanza" (也称为 "stanza" (节)) 定义于 [[RFC6120#流的基本原理|4.1]] . 有三种 stanzas（节）: message, presence, 和 IQ ("Info/Query"的简称). 这些通讯原语分别定义于 [[RFC6120#Message语义|8.2.1]] , [[RFC6120#Presence语义|8.2.2]] , 和 [[RFC6120#IQ语义|8.2.3]] .

术语 "originating entity" (原实体)指的是第一次生成一个发送到XMPP网络的stanza(节)的实体(例如, 一个已连接的客户端, 一个附加的服务, 或一个服务器). 术语 "generated stanza" (生成的节)值的是生成的节那个节.

术语 "input stream" (输入流)指定这样一个XML流，服务器通过这个流从一个已连接的客户端或远端服务器接收数据, 而术语 "output stream" (输出流)指定这样一个流，服务器通过这个流发送数据到一个已连接的客户端或远程服务器. 以下术语指定一些动作，处理从输入流收到的数据时服务器可以执行这些动作:

        route(路由):
            传递数据到一个远端服务器让它自行处理或最终递送到一个和远端服务器关联的客户端
        deliver(递送):
            传递数据到一个已连接的客户端
        ignore(忽略):
            丢弃数据不做任何处理或返回一个错误给发送者sender 

当术语 "ignore" (忽略)用于客户端处理收到的数据时, 短语 "without acting upon it" (不做任何处理)明确的包括不展示任何数据给使用者(人).

接下来的 "XML符号" 被 [[RFC6120#IRI|IRI]] 用于展示无法用仅用ASCII码呈现的字符, 本文的一些例子使用了类似 "&#x...." 的格式来表现 [[RFC6120#UNICODE|UNICODE]] 字符串 (例如, 字符串 "&#x0159;" 表示Unicode字符 LATIN SMALL LETTER R WITH CARON); 这种形式是绝对不会在XMPP系统将通过网络发送的.

和 [[RFC6120#URI|URI]] 展现统一资源定位符的规则一样, XMPP地址文本也是用 '<' 和 '>' 括起来的(尽管基本上它们不属于 URIs).

例如, 被括起来的行是用来提高可读性的, "[...]" 表示省略, 并且还是用了以下预定义字符串 (这些预定义的字符串不会通过网络发送出去):

* C: = 客户端
* E: = 任何XMPP实体
* I: = 发起实体
* P: = 对端服务器
* R: = 接收实体
* S: = 服务器
* S1: = 服务器1
* S2: = 服务器2

读者需要注意这些例子不包括细节, 并且例子里的一些协议流程中, 展示的备用步骤不一定是由前一个步骤发送的确切的数据触发的; 本文或常用参考文档中的协议规范所用到的所有用例里面提供的例子都遵从上述规则. 所有例子都是虚构的并且交换的信息 (例如, 用户名和密码) 不代表任何现存的用户和服务器.

==体系结构==

XMPP提供一种异步的端到端的结构化数据交换技术，在一个分布式的可全球寻址和出席信息感知的客户端和服务器的网络中使用直接的持久XML流。这种体系结构形式包含了普遍的网络可用性的知识，以及在给定的客户端-服务器和服务器-服务器会话的时候，不限数量的并发信息交易的概念，所以我们把它称为 "并发交易可用性" ("Availability for Concurrent Transactions") (简称ACT) 来把它和来自WWW的 "Representational State Transfer" [[RFC6120#REST|REST]] 体系结构形式区别开. 尽管XMPP的体系结构很大程度上类似于 email (参见 [[RFC6120#EMAIL‑ARCH|EMAIL‑ARCH]], 它引入了一些变化以便于准实时通讯.  ACT体系结构形式的独特特性如下. 

===全局地址===

和email一样, 为了通过网络路由和递送消息,XMPP使用全球唯一地址(基于DNS). 所有XMPP实体可以在网络上被寻址, 大部分客户端和服务器以及很多外部服务可以被客户端和服务器访问. 通常, 服务器地址的格式为 <域部分> (例如, <im.example.com>), 属于某台服务器的帐号的格式为 <本地部分@域部分> (例如, <juliet@im.example.com>, 称为 "纯JID"), 而连接到一个特定的设备或资源并且已经被(服务器)授权可以和外部交互的客户端的格式为 <本地部分@域部分/资源部分> (例如, <juliet@im.example.com/balcony>, 称为 "全JID"). 因为历史原因, XMPP地址常被称为Jabber IDs 或 JIDs. 因为XMPP地址格式的正式规范依赖于国际化技术（本文撰写时正在制定中），这个格式定义于 [[RFC6120#XMPP‑ADDR|XMPP‑ADDR]] 而非本文之中. 术语 "localpart"(本地部分), "domainpart"（域部分）, 和 "resourcepart"（资源部分） 正式定义于  [[RFC6120#XMPP‑ADDR|XMPP‑ADDR]] .

===出席信息===

XMPP让一个实体能够向其他实体声明它的网络可用性或者 "presence"（出席信息） . 在XMPP中, 这种可通讯状态是用端到端的专用通讯元素来标识的: 即 <presence/> 节. 尽管网络可用性对于XMPP消息交换并不是必需的, 它还是可以促进实时交互，因为消息发起者可以在发消息之前知道接收者在线并处于可通讯状态. 端到端的出席信息定义于 [[RFC6120#XMPP‑IM|XMPP‑IM]] .

===持久流===

每个点对点的一"跳"都建立了基于TCP长连接的持久XML流来保持可通讯状态. 这些 "always-on" 客户端-服务器 和 服务器-服务器 流使得任何时间每方都能够推送数据到另一方并且立即路由和递送. XML流定义于 [[RFC6120#XML流|4]] .

===结构化数据===

XMPP中基本的协议数据单元不是一个XML流 (它只是为点对点通讯提供传输层) 而是一个 XML 节（"stanza"), 它是一个通过流发送的XML片段. 一个节的根元素包括路由属性 (类似 "from" 和 "to" 地址), 而节的子元素包含了递送给目标接收者的载荷. XML节定义于 [[RFC6120#XML节|8]] .

===客户端和服务器的分布式网络===

在实践之中, XMPP是一个包含了很多互相通讯的客户端和服务器的网络(当然, 任何两个给定的布署服务器之间的通讯都是严格谨慎的并且也和本地服务策略有关). 因此, 例如, 与服务器 <im.example.com> 关联的用户 <juliet@im.example.com> 能够和服务器 <example.net> 关联的用户 <romeo@example.net> 交换消息，出席信息和其他结构化数据. 这个模式对使用全局地址的消息协议是很常见的, 例如email网络 (见 [[RFC6120#SMTP|SMTP]] 和 [[RFC6120#EMAIL‑ARCH|EMAIL‑ARCH]] . 结果, 在XMPP中端到端的通讯是逻辑上的点对点，而物理结构则是 客户端-服务器-服务器-客户端, 如下图所示. 

'''图1: 分布式客户端-服务器 体系结构'''

  example.net <--------------> im.example.com
      ^                                ^
      |                                |
      v                                v
 romeo@example.net           juliet@im.example.com


:提示性备注: 体系结构使用 [[RFC6120#XML流|XML流]] 和 [[RFC6120#XML节|XML节]] ，但是两个客户端之间直接建立端到端的连接则使用基于 [[RFC6120#LINKLOCAL|LINKLOCAL]] 的技术, 不过那个体系结构没有定义在本协议之中，它只能说是 "类XMPP"; 详见 [[RFC6120#XEP‑0174|XEP‑0174]] . 另外, XML流可以在任何可靠的传输层上简历端到端的连接, 包括XMPP本真的扩展; 无论如何, 这些方法没有包含在本文之中.

以下段落描述客户端和服务器们各自在网络中负责什么.

一个客户端就是一个实体，它先和它的注册帐号所在服务器建立XML流 (通过 [[RFC6120#SASL握手|SASL握手]] ) , 然后完成 [[RFC6120#资源绑定|资源绑定]] , 这样就能通过建好的流在客户端和服务器之间递送XML节. 客户端使用 XMPP 来和它的服务器, 其他客户端以及任何其他网络上的实体通讯, 这里服务器负责递送节到同一台服务器上其他已连接的客户端，或把它们路由到远程服务器上. 一个服务器上的注册帐号可以同时使用多个客户端连接到一台服务器上, 这里每个客户端的XMPP地址的 ''资源部分'' 是不同的 (例如, <juliet@im.example.com/balcony> 和 <juliet@im.example.com/chamber>), 定义于 [[RFC6120#常规引用|XMPP‑ADDR]] 和 [[RFC6120#资源绑定|7]]

一个服务器是一个实体，主要负责以下事项: 

:* 管理已连接客户端的 [[RFC6120#XML流|XML流]] 并通过建好的流递送 [[RFC6120#XML节|XML节]] 到那些通过客户端; 这也包括负责确保客户端在被授权访问XMPP网络之前的客户端身份验证工作.
:* 遵循本地服务对服务器之间通讯的策略, 管理和远程服务器之间的 [[RFC6120#XML流|XML流]] 并通过建好的流路由 [[RFC6120#XML节|XML节]] 到那些服务器.

取决于服务器的不同, 一个XMPP服务器的次要责任可能包括: 

:* 存储客户端使用的数据 (例如, 用户的基于 [[RFC6120#常规引用|XMPP-IM]] 的联系人; 在这种情况下, 相关的XML节直接由服务器本身代替客户端来处理而不用路由到远程服务器或递送到一个已连接的客户端.
:* 托管的额外服务也使用XMPP作为通讯的基础，但是提供超出本文范围的额外的或 [[RFC6120#常规引用|XMPP-IM]] 定义的功能; 例子包括多用户会议服务(定义于 [[RFC6120#常规引用|XEP‑0045]] ) 和 发布-订阅 服务 (定义于 [[RFC6120#常规引用|XEP‑0060]] ).

==TCP绑定==
===范围===

如本文定义的XMPP所述, 一个发起方实体在 (客户端或服务器) 和接收方实体协商XML流之前必须(MUST) 打开一个到接收方实体 (服务器) 的 [[RFC6120#常规引用|TCP]] 连接. 然后在使用XML流期间双方一直保持那个TCP连接. 这个规则在下面章节中的TCP绑定要用到.

:提示性备注: 不一定要把XML流建立在TCP上, 其他传输协议也是可以的. 例如, 两个实体可以通过 [[RFC6120#提示性引用|HTTP]] 互相连接（定义于 [[RFC6120#提示性引用|XEP‑0124]] 和 [[RFC6120#提示性引用|XEP‑0206]] . 无论如何, 本协议只定义把XMPP绑定到TCP.

===合格的全域名解析===

因为XML流是是通过TCP发送的, 发起方实体在尝试打开一个XML流之前需要确定接收方实体的IPv4或IPv6地址(以及端口). 一般来说这是通过解析接收方实体的合格的全域名(简称FQDN,参见 [[RFC6120#常规引用|DNS概念]] )来实现的. 

====首选流程:SRV查询====

FQDN解析的首选流程是如下使用 [[RFC6120#常规引用|DNS‑SRV]] 记录: 

# 发起方实体构造一个 DNS SRV 查询，参数如下:
## 一个 "xmpp-client" (用于 客户端-服务器 连接) 或 "xmpp-server" (用于 服务器-服务器 连接)服务
## 一个 "tcp" 协议
## 一个对应发起方实体希望连接的XMPP服务的 "原有域"（ [[RFC6120#常规引用|TLS‑CERTS]] ）的名字 (例如, "example.net" 或 "im.example.com")
# 得到一个类似 "_xmpp-client._tcp.example.net." 或 "_xmpp-server._tcp.im.example.com." 的查询.
# 如果收到应答, 它将包含一个或多个FDQN和端口的组合, 每个都拥有权重和优先级 (如 [[RFC6120#常规引用|DNS‑SRV]] 所述). (无论如何, 如果SRV查询的结果是一个单独的资源记录 ".", 即根域名, 那么发起方实体必须(MUST)在这时终止SRV处理，因为根据 [[RFC6120#常规引用|DNS‑SRV]] ,这样一个结果意味着那个服务在本域中是不可用的)
# 发起方实体至少选择返回的FQDNs记录中的一个来解决 (根据 [[RFC6120#常规引用|DNS‑SRV]] 规则,对FDQN执行 DNS "A" 或 "AAAA" 查询; 这将返回一个 IPv4 或 IPv6 的地址.
# 成功解析FDQN(包括SRV查询返回的相应的端口号)之后,发起方实体就使用IP地址来连接接收方实体.
# 如果发起方实体使用那个IP地址连接失败，而的 "A" 或 "AAAA" 记录查询返回了不止一个IP地址, 那么发起方实体使用那个FDQN的下一个解析好的IP地址作为连接地址.
# 如果发起方实体用给定的FDQN的所有解析出来的IP地址都无法连接, 那么它重复解析过程并使用基于优先级和权重的SRV查询(定义于 [[RFC6120#常规引用|DNS SRV]] )返回的下一个FQDN来连接.
# 如果发起方实体接收到它的SRV应答但是无法使用接收到的应答数据来建立一个XMPP连接, 它不应该(SHOULD NOT)尝试下面描述的备用流程(这有助于防止入站和出站连接状态不匹配).
# 如果发起方实体不能从它的SRV查询接收到应答, 它应该(SHOULD)尝试下一节描述的备用流程.

====后备流程====
====什么时候不用SRV====
====附加服务使用SRV记录====

===重连===
===可靠性===