RFC3920中文版.docx

1、RFC3920中文版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工作组被授权

3、接手开发和改编Jabber协议以适应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, RECOMM

4、ENDED, MAY, 和 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 = 一个XMP

5、P和外部（非XMPP）消息网络之间进行“翻译”的网关 FN1 = 一个外部消息网络 FC1 = 外部消息网络上的一个客户端 2.2. 服务器 服务器充当XMPP通信的一个智能抽象层，它主要负责： 管理发出的连接或其他实体的会话，在XML流（第四章）的表单中接收和发送给授权的客户端，服务器和其他实体。 用XML流通过实体转发特定地址的XML消息（第九章） 大部分 XMPP 兼容的服务器也负责存储客户端使用的数据 (比如基于XMPP应用的联系人名单); 在这种情况下， XML 数据直接由服务器代替客户端处理而不需要转发到其他实体。 2.3. 客户端 大部分客户端通过 TCP 连接直接连到服务器，并

6、通过XMPP获得由服务器和任何相关的服务所提供的全部功能。多个不同资源（比如不同的设备和地点）的客户端可以同时登陆并且并发的连接到一个服务器，每个不同资源的客户端通过XMPP地址的资源标识符来区分（比如 和 ），参见地址空间（第三章）。_建议_的客户端和服务器连接的端口是 5222 ，这个端口已经在 IANA（在第十五章第九节查阅端口号码） 注册了。. 2.4. 网关 网关是一个特殊用途的服务器端的服务，主要功能是把 XMPP 翻译成外部(非XMPP)消息系统，并把返回的消息翻译成 XMPP 。例如到 email（参见 SMTP ），IRC（参见 IRC ），SIMPLE（参见 SIMPLE

7、），SMS 的网关；还有和别的消息服务的网关，比如AIM，ICQ，MSN Messenger，Yahoo! Instant Messenger。网关和服务器之间的通信，网关和外部消息系统的通信，不在本文描述范围之内。 2.5. 网络 因为每个服务器都是由一个网络地址来标识的并且服务器之间的通信是 客户-服务器 协议的直接扩展，实际上整个系统是由很多互通的服务器构成的。例如， 可以和 交换消息,出席信息和其他信息。这种模式常见于那些需要使网络地址标准化的协议（比如 SMTP ）。任意两个服务器之间的通信是可选（OPTIONAL）的。如果被激活，那么这种通信应该（SHOULD）通过 XML 流绑定

8、到 TCP 连接上进行。建议的（RECOMMENDED）服务器之间的连接端口为 5269 ，这个端口号已经在 IANA （在第十五章第九节查阅端口号码）注册了。 3. 地址空间 3.1. 概览 一个实体可以是任何一个被认为是一个网络端点的东西(例如网络上的一个 ID )，而且它是通过XMPP进行通信的。所有这些实体都有一个具有唯一性的地址，并符合 RFC 2396 URI规范要求的格式。由于历史原因，一个 XMPP 实体的地址被称为 Jabber Identifier 或 JID 。一个合法的 JID 包括一组排列好的元素，包括域名（domain identifier），节点名（node id

9、entifier），和资源名（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

10、-literalfqdn = (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. 节点名 节点名是一个可选（OP

13、TIONAL）的第二 ID，放在域名之前并用符号分开.它通常表示一个向服务器或网关请求和使用网络服务的实体(比如一个客户端),当然它也能够表示其他的实体(比如在多用户聊天系统中的一个房间). 节点名所代表的实体，它的地址依赖于一个特定的域名;在 XMPP 的即时消息和出席信息应用系统中，这个地址是“纯 JID” 中的一部分。 一个节点名必须按 STRINGPREP 中的 Nodeprep profile 进行成功的字符转换。在比较两个节点ID之前，服务器必须（MUST）,客户端应该(SHOULD)首先按 Nodeprep profile 转换每个ID的字符。 3.4. 资源名 资源名是一个可选

14、的第三 ID,它放在域名的后面并由符号/分开。资源名可以跟在 后面也可以跟在 后面。它通常表示一个特定的会话，连接（比如设备或者所在位置），或者一个附属于某个节点ID实体相关实体的对象（比如多用户聊天室中的一个参加者）。对于服务器和和其他客户端来说，资源名是不透明的。当它提供必需的信息以完成资源绑定（参见第七章）的时候，通常是由客户端来实现的（尽管可以由客户端向服务器请求完成），然后显示为“已连接的资源”。一个实体可以(MAY)并发维护多个已连接的资源。每个已连接的资源由不同的资源ID来区分。 一个资源名必须（MUST）按 STRINGPREP 中的 Resourceprep profile

15、进行成功的格式化。在比较两个资源ID之前，服务器必须（MUST）,客户端应该(SHOULD)首先按 Resourceprep profile 转换每个ID的字符。 3.5. 地址的确认 在 SASL （见第六章）握手之后（如果必要的话，也在资源绑定（见第七章）之后），正在接收流信息的实体必须（MUST）确认初始实体的 ID 。 对于服务器间的通信，在 SASL 握手时，如果没有指明授权的ID，这个初始的实体应该（SHOULD）是经过认证实体（参见 简单认证和安全层协议 SASL 中的定义）授权的ID（见第六章）。 对于客户端和服务器的通信，在 SASL 握手时，如果没有指明授权的ID，“纯 J

16、ID” ()应该（SHOULD）是经过认证实体（参见 SASL 中的定义）授权的ID，“全 JID” ()的资源ID部分应该（SHOULD）是由客户端和服务器在资源绑定的时候商定的（参见第七章）。 接收的实体必须（MUST）确保结果JID（包括节点名，域名，资源名以及分隔符）与本章前面部分描述的规则和格式相一致；为了满足这些约束条件，接收实体可能（MAY）需要把初始实体的发送方 JID 替换成接收实体认可的规范 JID。 4. XML流 4.1. 概览 两个基本概念，XML流和XML节，使得在出席信息已知的实体之间，异步交换低负载的结构化信息成为可能。这两个术语定义如下： XML流的定义：一个

17、XML流是一个容器，包含了两个实体之间通过网络交换的XML元素。一个XML流是由一个XML打开标签 (包含适当的属性和名字空间声明)开始的,流的结尾则是一个XML关闭L标签 。在流的整个生命周期，初始化它的实体可以通过流发送大量的XML元素，用于流的握手(例如 TLS 握手(第五章) 或 SASL 握手(第六章)或XML节（在这里指符合缺省名字空间的元素,包括, 或 元素）。“初始的流”由初始化实体（通常是一个客户端或服务器）和接收实体（通常是一个服务器）握手，从接收实体来看，它就是那个初始实体的会话.初始化流允许从初始化实体到接收实体的单向通信;为了使接收实体能够和初始实体交换信息,接收实体

18、必须发起一个反向的握手(应答流). XML节的定义: 一个XML节是一个实体通过 XML 流向另一个实体发送的结构化信息中的一个离散的语义单位。一个XML直接存在于根元素的下一级，并且如果这样就能够满足XML内容的production 43,那么它被认为是均衡的.任何XML节都是从一个XML流的下一级的某个打开标签（如 ）开始，到相应的关闭标签（如 ）。一个XML节可以（MAY）包含子元素(相关的属性,元素, 和 XML 字符数据等) 以表达完整的信息.在这里定义的XML节仅限于, , 和 元素，具体描述见 XML Stanzas（第九章）；为TLS握手（第五章）、SASL握手（第六章）、服务

19、器回拨（第八章）的需要而发送的XML元素，不被认为是一个XML节。 设想一个客户端和服务器会话的例子。为了连接一个服务器，一个客户端必须（MUST）发送一个打开标签给服务器，初始化一个XML流，也可选择（OPTIONAL）在这之前发送一段文本声明XML版本和支持的字符集（参见文本声明的内容(第十一章第四节); 也可看字符编码(第十一章第五节)）。视本地化策略和提供的服务而定，服务器应该（SHOULD）回复一个XML流给客户端，同样的，也可选择在这之前发 送一段文本声明。一旦客户端完成了SASL握手（第六章），客户端可以（MAY）通过流发送不限量的XML节给网络中的任何接收者。当客户端想关闭这个

20、流，它只需要简单的发送一个关闭标签给服务器（或者作为另一个选择，可能由服务器关闭这个流）。然后，客户端和服务器都应该（SHOULD）彻底地终止这个连接（通常是一个TCP连接）。 那些习惯认为XML是一个以文本为中心风格的人可能希望看看一个与服务器连接的客户端会话，包含两个 打开-关闭 XML文档：一个是从客户端到服务器，一个是从服务器到客户端。下图中，根元素 可以被认为是每个“文档”的文档实体，这两个“文档”通过累积那些在XML上传输的XML节来搭建的。无论如何，下图只是方便理解；实际上XMPP并不处理文档而是处理XML流和XML节。 基本上，一个XML流相当于一个会话期间所有XML节的一个信

21、封。我们可以简单的把它描述成下图： |-| |-| | | |-| | | |-| | | |-| |-| |-4.2. 绑定到TCP 虽然有很多非必需的连接使用XML流来绑定TCP连接（两个实体可以通过别的机制来互联，比如通过HTPP连接轮询），本规范只定义了 XMPP 到 TCP 的绑定。在客户和服务器通信的过程中，服务器必须（MUST）允许客户端共享一个TCP连接来传输XML节，包括从客户端传到服务器和从服务器传到客户端。在服务器之间的通信过程中，服务器必须（MUST）用一个 TCP连接 向对方发送 XML节，另一个 TCP连接（由对方初始化）接收对方的XML节，一共两个 TCP连接。

22、4.3. 流的安全 在XMPP 1.0中，当XML流开始握手时，TLS应该（SHOULD）按 第五章：TLS的使用 中的规定来使用，SASL必须（MUST）按 第六章：SASL的使用 中的规定来使用。尽管可能（MAY）存在某种共有的机制能够保证双向安全，但是“初始化流”（比如从初始化实体发给接收实体的流）和“应答流”（比如从接收实体发给初始化实体的流）还是必须（MUST）安全的分开。在流被验证之间，实体不应该（SHOULD NOT） 尝试通过流发送XML节（第九章）；就算它这样做了，对方的实体也不能（MUST NOT）接受这些XML节，并且应该（SHOULD）返回一个 的流错误信息并且终止当前

23、TCP连接上双方的XML流；注意，这仅仅是针对XML节（包含在缺省命名空间中的 , , 和 元素），而不是指那些用于 TLS握手（第五章）、SASL握手（第六章）握手的流。 4.4. 流属性 流元素的属性如下: to - to属性应该（SHOULD）仅用于从初始化实体到接收实体的 XML流的头，并且必须（MUST）设成为接收实体提供服务的主机名。注意，不应该（SHOULD NOT）有 to属性出现在接收实体应答初始实体的 XML流的头中；无论如何，如果to属性出现在应答流中，初始化实体应该（SHOULD）忽略它。 from - from属性应该（SHOULD）仅用于接收实体应答初始化实体的 X

24、ML流的头，并且必须（MUST）设成为接收实体（正在给初始实体授权）提供服务的主机名。注意，不应该（SHOULD NOT）有 from属性出现在初始实体发送给接收实体的 XML流的头中；无论如何，如果from属性出现在初始化流中，接收实体应该（SHOULD）忽略它。 id - id属性应该（SHOULD）仅用于接收实体发送给初始化实体 XML流的头。这个属性是一个由接收实体创建的具有唯一性的ID,一个初始实体和接收实体之间的会话ID，并且它在接收方的应用程序中（通常是一个服务器）必须（MUST）是唯一的。注意，这个流 ID 必须是足够安全的，所以它必须是不可预知的和不可重复的（参见 RANDO

25、M 了解如何获得随机性以保证安全性）。不应该（SHOULD NOT）有 id属性出现在初始实体发送给接收实体的 XML流的头中；无论如何，如果id属性出现在初始化流中，接收实体应该（SHOULD）忽略它。 xml:lang - xml:lang属性（定义在XML中的第二章第十二节）应该（SHOULD）包含在初始化实体发给接收实体的 XML流的头中，以指定在流中传输的可读XML字符所使用的缺省语言。如果这个属性出现了，接收实体应该（SHOULD）记住它的值，作为初始化流和应答流的缺省属性；如果这个属性没有出现，接收实体应该（SHOULD）用一个可配置的缺省值用于双方的流，这个属性值必须（MUST

26、）在应答流的头中传达。对于所有初始化流中传输的节，如果初始实体没有提供xml:lang属性，接收实体应该（SHOULD）应用缺省值；如果初始实体提供了xml:lang属性，接收实体不能（MUST NOT）修改或删除它（参见第九章第一节第五小节 xml:lang）。xml:lang属性的值必须（MUST）是一个 NMTOKEN (定义在XML的第二章第三节) 并且必须（MUST）遵守 RFC 3066 LANGTAGS 规定的格式。 version - version属性（最少需要1.0）为本规范中和流相关的协议提供了支持。关于这个属性的生成和处理的详细规则将在下文中定义。 我们现在可以总结如下

27、: 初始化方发给接收方接收方发给初始化方to接收方的主机名忽略from忽略接收方的主机名id忽略会话键值xml:lang缺省语言缺省语言version支持XMPP 1.0支持XMPP 1.04.4.1. 版本支持 在这里XMPP的版本是1.0；准确地说，这里囊括了和流相关的所有协议(TLS的使用 (第五章),SASL的使用(第六章), 和流错误(第四章第七节)，以及三个定义好的XML节类型(,和 )。XMPP版本号的编号顺序是“.”。主版本和副版本号必须（MUST）是独立的整数并且每个号码可以（MAY）单独以阿拉伯数字增长。这样，XMPP 2.4的版本将比XMPP 2.13更低。号码前面 的“

28、0”(比如XMPP 6.01)必须(MUST)被接收方忽略并且不能(MUST NOT)被发送出去. 如果流和节的格式或者必需的处理方式有了显著的改变，以至于老版本的实体如果只是简单的忽略它不理解的节和属性并且继续像老版本一样的处理方式，会使得老版本的实体不能够和新版本的实体交互，只有在这时候主版本号才应该（SHOULD）增加。副版本号显示新的性能，它必须（MUST）被副版本号更低的实体忽略，但被高（副）版本号的实体用于了解信息。例如，一个副版本号显示处理某种新定义的type属性的值（用于message,presence或IQ节）的能力；副版本号高的实体将会了解到与之通信的对方不能够理解这个ty

29、pe属性的值，所以将不会发送它。 以下规则是用于版本属性在实现流的头信息时如何生成和处理: 1. 初始化实体必须（MUST）在初始化流的头信息中把版本的值设置成它所支持的最高版本。（比如，如果最高版本支持就是本规范，那么它必须(MUST)设置成1.0）. 2. 接收实体必须（MUST）在应答流的头信息中把版本的值设置成初始化实体所提供的版本或它所支持的最高版本,取其中版本号较低的那一个。接收实体必须(MUST)把主版本号和副版本号作为数字来比较,而不是对主版本号.副版本号这个字符串进行比较. 3. 如果在应答流的头信息的版本号中至少有一个主版本号低于初始化流的头信息的版本号,并且如前所述,新版本的实体不能够和旧版本实体交互,初始化实体应该(SHUOULD)生成一个