《RFC3920XMPP协议中文版》由会员分享，可在线阅读，更多相关《RFC3920XMPP协议中文版（85页珍藏版）》请在金锄头文库上搜索。
1、RFC3920 可扩展的消息和出席信息协议 (XMPP): 核心协议 关于本文的说明 本文为互联网社区定义了一个互联网标准跟踪协议，并且申请讨论协议和提出了改进的建议。请参照“互联网官方协议标准”的最新版本（STD 1）获得这个协议的标准化进程和状态。本文可以不受限制的分发。 版权声明 本文版权属于互联网社区 (C) The Internet Society (2004). 摘要 本文定义了可扩展消息和出席信息协议（XMPP）的核心功能，这个协议采用XML流实现在任意两个网络终端接近实时的交换结构化信息。XMPP提供一个通用的可扩展的框架来交换XML数据，它主要用来建立即时消息和出席信息应用以
2、实现 RFC 2779 的需求。 目录 1. 绪论 2. 通用的架构 3. 地址空间 4. XML流 5. TLS的使用 6. SASL的使用 7. 资源绑定 8. 服务器回拨 9. XML节 10. 服务器处理XML节的规则 11. XMPP中的XML用法 12. 核心的兼容性要求 13. 国际化事项 14. 安全性事项 15. IANA事项 16. 参考 1. 绪论 1.1. 概览 XMPP是一个开放式的XML协议，设计用于准实时消息和出席信息以及请求-响应服务。其基本的语法和语义最初主要是由Jabber开放源代码社区于1999年开发的。2002年，XMPP工作组被授权接手开发和改编Jab
3、ber协议以适应IETF的消息和出席信息技术。作为XMPP工作组的成果，本文定义了 XMPP 1.0 的核心功能；在 RFC 2779 IMP-REQS 中指定的提供即时消息和出席信息功能的扩展，定义在 XMPP-IM 协议 the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence 中。 1.2. 术语 本文中大写的关键字 MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY
4、, 和 OPTIONAL 的确切含义符合 BCP 14, RFC 2119 TERMS. 2. 通用的架构 2.1. 概览 尽管XMPP没有结合任何特定的网络结构，通常认为它是 客户-服务器 架构的一种实现，在这里客户端用XMPP的方式访问服务器采用的是TCP连接，服务器之间的通信也是TCP连接。 以下是这一架构的抽象的示意图 (这里 - 表示使用 XMPP 通讯， = 表示可使用任何协议通讯)。 C1-S1-S2-C3|C2-+-G1=FN1=FC1 符号代表的意思如下: C1, C2, C3 = XMPP 客户端 S1, S2 = XMPP 服务器 G1 = 一个XMPP和外部（非XMPP
5、）消息网络之间进行“翻译”的网关 FN1 = 一个外部消息网络 FC1 = 外部消息网络上的一个客户端 2.2. 服务器 服务器充当XMPP通信的一个智能抽象层，它主要负责： 管理发出的连接或其他实体的会话，在XML流（第四章）的表单中接收和发送给授权的客户端，服务器和其他实体。 用XML流通过实体转发特定地址的XML消息（第九章） 大部分 XMPP 兼容的服务器也负责存储客户端使用的数据 (比如基于XMPP应用的联系人名单); 在这种情况下， XML 数据直接由服务器代替客户端处理而不需要转发到其他实体。 2.3. 客户端 大部分客户端通过 TCP 连接直接连到服务器，并通过XMPP获得由服
6、务器和任何相关的服务所提供的全部功能。多个不同资源（比如不同的设备和地点）的客户端可以同时登陆并且并发的连接到一个服务器，每个不同资源的客户端通过XMPP地址的资源标识符来区分（比如 和 ），参见地址空间（第三章）。_建议_的客户端和服务器连接的端口是 5222 ，这个端口已经在 IANA（在第十五章第九节查阅端口号码） 注册了。. 2.4. 网关 网关是一个特殊用途的服务器端的服务，主要功能是把 XMPP 翻译成外部(非XMPP)消息系统，并把返回的消息翻译成 XMPP 。例如到 email（参见 SMTP ），IRC（参见 IRC ），SIMPLE（参见 SIMPLE ），SMS 的网关；
7、还有和别的消息服务的网关，比如AIM，ICQ，MSN Messenger，Yahoo! Instant Messenger。网关和服务器之间的通信，网关和外部消息系统的通信，不在本文描述范围之内。 2.5. 网络 因为每个服务器都是由一个网络地址来标识的并且服务器之间的通信是 客户-服务器 协议的直接扩展，实际上整个系统是由很多互通的服务器构成的。例如， 可以和 交换消息,出席信息和其他信息。这种模式常见于那些需要使网络地址标准化的协议（比如 SMTP ）。任意两个服务器之间的通信是可选（OPTIONAL）的。如果被激活，那么这种通信应该（SHOULD）通过 XML 流绑定到 TCP 连接上进
8、行。建议的（RECOMMENDED）服务器之间的连接端口为 5269 ，这个端口号已经在 IANA （在第十五章第九节查阅端口号码）注册了。 3. 地址空间 3.1. 概览 一个实体可以是任何一个被认为是一个网络端点的东西(例如网络上的一个 ID )，而且它是通过XMPP进行通信的。所有这些实体都有一个具有唯一性的地址，并符合 RFC 2396 URI规范要求的格式。由于历史原因，一个 XMPP 实体的地址被称为 Jabber Identifier 或 JID 。一个合法的 JID 包括一组排列好的元素，包括域名（domain identifier），节点名（node identifier），
9、和资源名（resource identifier）。 JID的语法定义，使用 ABNF 中的 Augmented Backus-Naur 格式。（IPv4 地址和 IPv6地址规则在 附录B 中的 IPv6 中定义；确定节点规则的合法字符顺序由 附录A 的 STRINGPREP 的 Nodeprep 部分来定义；确定资源规则的合法字符顺序由 附录B 的 STRINGPREP 的Resourceprep 部分来定义；子域名规则参考 IDNA 中关于国际域名标签的描述。）。 jid = node domain / resource domain = fqdn / address-literalfq
10、dn = (sub-domain 1*(. sub-domain)sub-domain = (internationalized domain label)address-literal = IPv4address / IPv6address 所有 JID 都是基于上述的结构。类似 这种结构，最常用来标识一个即时消息用户，这个用户所连接的服务器，以及这个用户用于连接的资源（比如特定类型的客户端软件）。不过,节点类型不是客户端也是有可能的，比如一个用来提供多用户聊天服务的特定的聊天室，地址可以是 （这里 “room“ 是聊天室的名字而 ”service“ 是多用户聊天服务的主机名），而加入了这个
11、聊天室的某个特定的用户的地址则是 （这里 ”nick“ 是用户在聊天室的昵称）。许多其他的 JID 类型都是可能的（例如 可能是一个服务器端的脚本或服务）。 一个 JID 的每个合法部分（节点名，域名，资源名）的长度不能（MUST NOT）超过 1023 字节。也就是整体长度（包括 和 / ）不能超过 3071 字节。 3.2. 域名 域名是一个主要的ID并且是 JID 中唯一必需（REQUIRED）的元素（一个纯粹的域名也是一个合法的 JID）。它通常代表网络的网关或者“主”服务器，其他实体通过连接它来实现 XML 转发和数据管理功能。然而，由一个域名标识引用的实体，并非总是一个服务器，它也
12、可能是一个服务器的子域地址，提供额外的功能（比如多用户聊天服务，用户目录，或一个到外部消息系统的网关）。 每个服务器或者服务的域名，可以（MAY）是一个 IP 地址，但应该（SHOULD）是一个完全合法的域名(参见 DNS).一个域名ID必须(MUST)是 IANA 里定义的“国际化域名”，并且按 STRINGPREP中的 NAMEPREP profile进行成功的字符转换。在比较两个域名ID之前，服务器必须(MUST),客户端应该(SHOULD)首先按照 Nameprep profile(定义在IANA中) 来转换每个域名的字符。 3.3. 节点名 节点名是一个可选（OPTIONAL）的第二
13、 ID，放在域名之前并用符号分开.它通常表示一个向服务器或网关请求和使用网络服务的实体(比如一个客户端),当然它也能够表示其他的实体(比如在多用户聊天系统中的一个房间). 节点名所代表的实体，它的地址依赖于一个特定的域名;在 XMPP 的即时消息和出席信息应用系统中，这个地址是“纯 JID” 中的一部分。 一个节点名必须按 STRINGPREP 中的 Nodeprep profile 进行成功的字符转换。在比较两个节点ID之前，服务器必须（MUST）,客户端应该(SHOULD)首先按 Nodeprep profile 转换每个ID的字符。 3.4. 资源名 资源名是一个可选的第三 ID,它放在
14、域名的后面并由符号/分开。资源名可以跟在 后面也可以跟在 后面。它通常表示一个特定的会话，连接（比如设备或者所在位置），或者一个附属于某个节点ID实体相关实体的对象（比如多用户聊天室中的一个参加者）。对于服务器和和其他客户端来说，资源名是不透明的。当它提供必需的信息以完成资源绑定（参见第七章）的时候，通常是由客户端来实现的（尽管可以由客户端向服务器请求完成），然后显示为“已连接的资源”。一个实体可以(MAY)并发维护多个已连接的资源。每个已连接的资源由不同的资源ID来区分。 一个资源名必须（MUST）按 STRINGPREP 中的 Resourceprep profile 进行成功的格式化。在比较两个资源ID之前，服务器必须（MUST）,客户端应该(SHOULD)首先按 Resourceprep profile 转换每个ID的字符。 3.5. 地址的确认 在 SASL （见第六章）握手之后（如果必要的话，也在资源绑定（见第七章）之后），正在接收流信息的实体必须（MUST）确认初始实体的 ID 。 对于服务器间的通信，在 SASL 握手时，如果没有指明授权的ID，这个初始的实体应该（SHOULD）是经过认证实体（参见 简单认证和安全层协议 SASL 中的定义）授权的ID（见第六章）。 对于客户端和服务器的通信，在 SASL 握手时，如果没有指明授权的ID，“纯 JID” (nod
