RFC3920(XMPP协议)中文版

《RFC3920(XMPP协议)中文版》由会员分享，可在线阅读，更多相关《RFC3920(XMPP协议)中文版（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 进行成功的格式化。在

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

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

17、包含了两个实体之间通过网络交换的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连接。 4.3. 流的安全

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

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

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

25、性以保证安全性）。不应该（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更低。号码前面 的“0”(比如XMPP

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

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

30、本实体交互,初始化实体应该(SHUOULD)生成一个的流错误信息并终止XML流和它的TCP连接。 4. 如果一个实体收到一个头信息中没有version属性的流，这个实体必须（MUST）把对方实体的version当成0.0并且在它发送的应答流的头中也不应该(SHOULD NOT)包含version属性. 4.5. 名字空间声明 流的元素必须(MUST)同时满足一个流名字空间声明和一个缺省名字空间声明(名字空间声明定义在 XML 名字空间定义 XML-NAMES中).关于流名字空间和缺省名字空间的详细信息,参考 名字空间的名字和前缀(第十一章第二节). 4.6. 流的特性 如果初始化的实体在初始化

31、流的头信息中设置version属性的信息为1.0,接收实体必须(MUST)向初始化实体发送一个 子元素以声明任何可供协商的流一级的特性(或者其他需要声明的能力).目前,这仅用于声明本文中定义的 TLS的使用(第五章),SASL的使用（第六章）和资源绑定(第七章),以及 XMPP-IM 中定义的会话的建立;无论如何,流特性这一功能将来可以用于声明任何可协商的特性.如果一个实体不理解或支持安全特性,它应该(SHOULD)忽略它.如果要在一个非安全相关的特性(比如资源绑定)被提议之前,完成一个或多个安全特性(比如TLS和SASL)的协商,这个非安全相关的特性不应该(SHOULD NOT)在相应的安全

32、特性协商完毕之前被声明. 4.7. 流错误 流的根元素可以（MAY）包含一个 子元素，由流的名字空间前缀作为它的前缀。这个错误子元素必须（MUST）由感知到发生了流级别错误的实体发送（通常是一个服务器而不是一个客户端）。 4.7.1. 规则 以下规则适用于流级别的错误: 它假定所有流级别的错误都是不可恢复的；所以，如果一个错误发生在流级别，发现这个错误的实体必须（MUST）发送一个流错误信息给另一个实体，发送一个关闭标签 ，并终止这个流所在的TCP连接。 如果这个错误发生在流刚开始设置的时候，接收实体必须（MUST）仍然发送一个开放标签 ，并在流元素中包含一个的子元素，然后发送一个关闭标签 ，

33、最后终止相应的TCP连接。在这种情况下，如果初始化实体在 to 属性中提供了一个未知的主机名，服务器应该（SHOULD）在终止之前,先在流的头信息的 from 属性中提供一个服务器认证的主机名. 4.7.2. 语法 流错误的语法如下: OPTIONAL descriptive text OPTIONAL application-specific condition element 元素: 必须(MUST)包含一个子元素以描述一个下文定义的节错误条件;这个子元素必须(MUST)符合urn:ietf:params:xml:ns:xmpp-streams名字空间. 可以(MAY)包含一个 子元素,用

34、XML字符数据描述错误的细节;这个元素必须(MUST)符合urn:ietf:params:xml:ns:xmpp-streams名字空间并且应该(SHOULD)拥有一个xml:lang属性表明XML字符数据的自然语言。 可以（MAY）包含一个子元素用于描述一个明确的应用程序错误条件；这个元素必须（MUST）符合一个应用程序定义的名字空间，并且它的结构是由那个名字空间定义的。 元素是可选的（OPTIONAL）。如果有这个元素，它应该（SHOULD）仅用于提供描述或调试信息以补充一个已定义的条件或应用程序定义的条件。它不应该（SHOULD NOT）被一个应用程序当成一个可编程的信息。它不应该（SH

35、OULD NOT）被用于向用户表达错误信息，但是可以（MAY）作为和条件元素相关的错误信息之外的附加说明。 4.7.3. 已定义的条件 以下流级别的错误条件是已定义的: - 实体已经发送XML但是不能被处理;这个错误可以（可以）被更多特定的XML相关的错误替换，比如 , , , , 以及 ,尽管更多特定的错误是首选的。 - 实体发送的名字空间前缀不被支持，或者在一个需要某种前缀的元素中没有发送一个名字空间前缀(参见 XML Namespace Names and Prefixes (第十一章第二节). - 服务器正在关闭为这个实体激活的流，因为一个和已经存在的流有冲突的新的流已经被初始化。 -

36、 实体已经很长时间没有通过这个流发生任何通信流量(可由一个本地服务策略来配置). - 初始化实体在流的头信息中提供的to属性的值所指定的主机已经不再由这台服务器提供 - 由初始化实体在流的头信息中提供的 to 属性的值和由服务器提供的主机名不一致. - 一个在两台服务器之间传送的节缺少 to 或 from 属性(或者这个属性没有值). - 服务器配置错误或者其他未定义的内部错误,使得服务器无法提供流服务. - 在from属性中提供的 JID 或 主机名地址，和认证的 JID不匹配 或服务器之间无法通过SASL（或回拨）协商出合法的域名，或客户端和服务器之间无法通过它进行认证和资源绑定。 - 流

37、 ID 或回拨 ID 是非法的或和以前提供的 ID 不一致. - 流名字空间和 http:/etherx.jabber.org/streams 不相同或回拨名字空间和 jabber:server:dialback 不相同.(参考 XML Namespace Names and Prefixes (第十一章第二节). - 实体通过流发送了一个非法的XML给执行验证的服务器 (参考 Validation (第十一章第三节). - 实体试图在流被验证之前发送数据或不被许可执行一个和流协商有关的动作，接收实体在发送错误信息之前不允许（MUST NOT）处理厌恶的节。 - 实体违反了某些本地服务策略；服

38、务器可以（MAY）选择在 元素或应用程序定义的错误条件（元素）中详细说明策略。 - 服务器无法正确连接到用于验证或授权的远程实体。 - 服务器缺乏必要的系统资源为流服务。 - 实体试图发送受限的XML特性，比如一个注释，处理指示，DTD，实体参考，或保留的字符(参考 Restrictions (第十一章第一节). - 服务器将不提供服务给初始化实体但是把它重定向到另一台主机；服务器应该（SHOULD）在元素的XML字符数据中指明替代服务器名或IP地址（它必须（必须）是合法的域名标识）。 - 服务器正在关机并且所有激活的流正在被关闭。 - 错误条件不在本文已定义的错误条件列表之中；这个错误条件应

39、该（SHOULD）仅用于应用程序定义条件元素. - 初始化实体以一个服务器不不支持的编码方式编码了一个流(参照 Character Encoding (第十一章第五节). - 初始化实体发送了一个流的一级子元素但是服务器不支持. - 由初始化实体在流的头信息中指定的version属性的值所指定的版本不被服务器支持;服务器可以(MAY)在元素中指定一个它支持的版本号. - 初始化实体发送了一个不规范的XML（参考XML）. 4.7.4. 应用程序定义条件 大家知道,应用程序可以(MAY)在error元素中包含一个适当名字空间的子元素来提供一个应用程序定义流错误信息.应用程序定义元素应该(SHOU

40、LD)补充或甚至限定一个已定义的元素.所以 元素将包含两个或三个子元素: Some special application diagnostic information! 4.8. 简化的流示例 这里包含两个简化的例子，描述了基于流的客户端在服务器上的“会话”(这里C表示从客户端发给服务器,S表示从服务器发给客户端);这些例子只是用于举例说明原理. 一个基本的 会话: C: S: encryption, authentication, and resource binding . C: C: Art thou not Romeo, and a Montague? C: S: S: Neithe

41、r, fair saint, if either thee dislike. S: C: S: 一个不成功的 会话 : C: S: encryption, authentication, and resource binding . C: Bad XML, no closing body tag! S: S: 5. TLS 的使用 5.1. 概览 XMPP包含的一个保证流安全的方法来防止篡改和偷听.这个传输层安全协议TLS的频道加密方法, 模拟了类似的其他STARTTLS(见RFC 2595 USINGTLS)的扩展,如 IMAP IMAP, POP3 POP3, and ACAP ACAP.

42、STARTTLS的扩展名字空间是urn:ietf:params:xml:ns:xmpp-tls. 一个给定域的管理员可以(MAY)要求客户端和服务器通信以及服务器之间通信时使用TLS，或者两者都要求。客户端应该（SHOULD）在尝试完成 SASL （第六章）握手之前使用 TLS，服务器应该（SHOULD）在两个域之间使用 TLS 以保证服务器间通信的安全。 以下是使用规则: 1. 一个遵守本协议的初始化实体必须（MUST）在初始化流的头信息中包含一个version属性并把值设为“1.0”。 2. 如果TLS握手发生在两个服务器之间，除非服务器声称的DNS主机名已经被解析(见第十四章第四节 Se

43、rver-to-Server Communications)，通信不能（MUST NOT）继续进行。 3. 当一个遵守本协议的接收实体接收了一个初始化流（它的头信息中包含一个version属性并且值设为“1.0”），在发送应答流的的头信息（其中包含版本标记）之后，它必须发送（MUST）元素（名字空间为 urn:ietf:params:xml:ns:xmpp-tls）以及其他它支持的流特性 。 4. 如果初始化实体选择使用TLS,TLS握手必须在SASL握手之前完成；这个顺序用于帮助保护SASL握手时发送的认证信息的安全，同时可以在必要的时候在TLS握手之前为SASL外部机制提供证书。 5. T

44、LS握手期间,一个实体不能（MUST NOT）在流的根元素中发送任何空格符号作为元素的分隔符（在下面的TLS示例中的任何空格符都仅仅是为了便于阅读）；这个禁令用来帮助确保安全层字节精度。 6. 接收实体必须（MUST）在发送 元素的关闭符号 之后立刻开始TLS协商。初始化实体必须（MUST）在从接收实体接收到 元素的关闭符号 之后立刻开始TLS协商。 7. 初始化实体必须（MUST）验证接收实体出示的证书；关于证书验证流程参见Certificate Validation ( 第十四章第二节)。 8. ？证书必须（MUST）检查初始化实体(比如一个用户)提供的主机名；而不是通过DNS系统解析出来

45、的主机名；例如，如果用户指定一个主机名而一个DNS SRV SRV查询返回，证书必须（MUST）检查.如果任何种类的XMPP实体（例如客户端或服务器）的JID出现在一个证书里，它必须（MUST）表现为一个别名实体里面的UTF8字符串，存在于subjectAltName之中。如何使用 ASN.1 对象标识符 id-on-xmppAddr 定义在本文的第五章第一节第一小节。 9. 如果 TLS 握手成功了，接收实体必须（MUST） 丢弃TLS 生效之前从初始化实体得到的任何不可靠的信息. 10. 如果 TLS 握手成功了，初始化实体必须（MUST） 丢弃TLS 生效之前从接收实体得到的任何不可靠的

46、信息. 11. 如果 TLS 握手成功了，接收实体不能(MUST NOT)在流重新开始的时候通过提供其他的流特性来向初始化实体提供 STARTTLS 扩展. 12. 如果 TLS 握手成功了，初始化实体必须(MUST)继续进行SASL握手。 13. 如果 TLS 握手失败了，接收实体必须（MUST）终止XML流和相应的TCP连接。 14. 关于必须（MUST）支持的机制，参照 Mandatory-to-Implement Technologies (第十四章第七节) 。 5.1.1. 用于 XMPP 地址的 ASN.1 对象标识符 上文提到的ASN.1 对象标识符 id-on-xmppAddr

47、定义如下: id-pkix OBJECT IDENTIFIER := iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-on OBJECT IDENTIFIER := id-pkix 8 - other name forms id-on-xmppAddr OBJECT IDENTIFIER := id-on 5 XmppAddr := UTF8String 对象标识符也可以(MAY)使用点分隔的格式,如 1.3.6.1.5.5.7.8.5. 5.2. 叙述 当一个初

48、始化实体用TLS保护一个和接收实体之间的流，其步骤如下: 1. 初始化实体打开一个TCP连接，发送一个打开的XML流头信息（其version属性设置为1.0）给接收实体以初始化一个流。 2. 接收实体打开一个TCP连接，发送一个XML流头信息（其version属性设置为1.0）给初始化实体作为应答。 3. 接收实体向初始化实体提议STARTTLS范围（包括其他支持的流特性），如果TLS对于和接收实体交互是必需的，它应该（SHOULD）在元素中包含子元素. 4. 初始化实体发出STARTTLS命令(例如, 一个符合urn:ietf:params:xml:ns:xmpp-tls名字空间的 元素)

49、以通知接收实体它希望开始一个TLS握手来保护流。 5. 接收实体必须（MUST）以urn:ietf:params:xml:ns:xmpp-tls名字空间中的元素或元素应答。如果失败，接收实体必须（MUST）终止XML流和相应的TCP连接。如果继续进行，接收实体必须（MUST）尝试通过TCP连接完成TLS握手并且在TLS握手完成之前不能（MUST NOT）发送任何其他XML数据。 6. 初始化实体和接收实体尝试完成TLS握手。（要符合TLS规范） 7. 如果 TLS 握手不成功, 接收实体必须（MUST）终止 TCP 连接. 如果 TLS 握手成功, 初始化实体必须（MUST）发送给接收实体一个

50、打开的XML流头信息来初始化一个新的流（先发送一个关闭标签是不必要的,因为接收实体和初始化实体必须(MUST)确保原来的流在TLS握手成功之后被关闭） 。 8. 在从初始化实体收到新的流头信息之后，接收实体必须（MUST）发送一个新的XML流头信息给初始化实体作为应答，其中应包含可用的特性但不包含STATRTTLS特性。 5.3. 客户端-服务器 示例 以下例子展示一个客户端使用STARTTLS保护数据流 (注意: 以下步骤举例说明协议中的失败案例；在这个例子中它们并不详尽并且也不是必须被数据传输触发的). 步骤 1: 客户端初始化流给服务器: 步骤 2: 服务器发送一个流标签给客户端作为应答: 步骤 3: 服务器发送 STARTTLS 范围给客户端（包括验证机制和任何其他流特性）: mechanisms xmlns=urn:ietf:par