本文详细介绍了XMPP协议的基础知识，包括XML流的建立、TLS和SASL的安全机制、资源绑定及服务器回拨等关键概念。通过深入探讨地址空间、流错误处理和国际化事项，揭示了XMPP协议在即时通讯中的应用和技术要求。
1.简介
- XMPP是一个开放式的XML协议，设计用于准实时消息和出席信息以及请求-响应服务。其基本的语法和语义最初主要是由Jabber开放 源代码社区于1999年开发的。2002年，XMPP工作组被授权接手开发和改编Jabber协议以适应IETF的即时消息和出席信息技术。作为XMPP 工作组的成果，本文定义了 XMPP 1.0 的核心功能；在 RFC 2779 [IMP-REQS] 中指定的提供即时消息和出席信息功能的扩展，定义在 XMPP-IM 协议 [the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence] 中。
2.通用的架构
概述
- 尽管XMPP没有指定任何特定的网络结构，但它通常是采用客户-服务器 架构进行实现，其中客户端通过TCP方式使用XMPP访问服务器，服务器之间也采用TCP方式进行通信。
- 以下是这一架构的抽象的示意图 (这里 "-" 表示使用 XMPP 通讯， "=" 表示可使用任何协议通讯)。
C1----S1---S2---C3
|
C2----+--G1===FN1===FC1
- 符号的含义如下:
-
-
- C1, C2, C3 = XMPP 客户端
-
-
-
- S1, S2 = XMPP 服务器
-
-
-
- G1 = 一个XMPP和外部（非XMPP）消息网络之间进行“翻译”的网关
-
-
-
- FN1 = 一个外部消息网络
-
-
-
- FC1 = 外部消息网络上的一个客户端
-
服务器
- 服务器充当XMPP通信的一个智能抽象层，它主要负责:
-
- 对受验证的客户端，服务器以及其他实体之间以XML流形式的连接和会话进行管理。
-
- 在这些实体间使用XML流对合理编址的XML节（第九章）进行路由
- 大部分 XMPP 兼容的服务器也负责存储客户端使用的数据 (比如基于XMPP协议的及时消息应用中的联系人名单); 在这种情况下， XML 数据直接服务器来处理，而不需要转发到其他实体。
客户端
- 大部分客户端通过 TCP 连接直接连到服务器，并通过XMPP获得由服务器以及联合服务器所提供的全部功能。多个不同资源（比如不同的设备和地点）的客户端 可以 同时登陆并且并发的连接到一个服务器，每个不同资源的客户端通过XMPP地址的资源标识符来区分（比如<node@domain/ home> 和 <node@domain/work>），参见地址空间（第三章）。 建议 的客户端和服务器连接的端口是 5222 ，这个端口已经在 IANA（在第十五章第九节查阅端口号码） 注册了。
网关
- 网关是一个特殊用途的服务器端的服务，主要功能是把 XMPP 翻译成外部(非XMPP)消息系统，并把返回的消息翻译成 XMPP 。例如到 email（参见 [SMTP] ），IRC（参见 [IRC] ），SIMPLE（参见 [SIMPLE] ），SMS 的网关；还有和别的消息服务的网关，比如AIM，ICQ，MSN Messenger，Yahoo! Instant Messenger。网关和服务器之间的通信，网关和外部消息系统的通信，不在本文描述范围之内。
网络
- 因为每个服务器都是由一个网络地址来标识的并且服务器之间的通信是 客户-服务器 协议的直接扩展，实际上整个系统是由很多互通的服务器构成的。例如，<juliet@example.com> 可以和 <romeo@example.net> 交换消息,出席信息和其他信息。这种模式常见于那些需要使网络地址标准化的协议（比如 SMTP ）。任意两个服务器之间的通信是可选（OPTIONAL）的。如果被激活，那么这种通信应该（SHOULD）通过 XML 流绑定到 TCP 连接上进行。建议的（RECOMMENDED）服务器之间的连接端口为 5269 ，这个端口号已经在 IANA （在第十五章第九节查阅端口号码）注册了。
3.地址空间
概览
- 一个实体可以是任何一个被认为是一个网络端点的东西(例如网络上的一个 ID )，而且它是通过XMPP进行通信的。
- 一个 XMPP 实体的地址被称为 Jabber Identifier 或 JID，包括一组排列好的元素：域名（domain identifier），节点名（node identifier），和资源名（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-literal
-
- fqdn = (sub-domain 1*("." sub-domain))
-
- sub-domain = (internationalized domain label)
-
- address-literal = IPv4address / IPv6address
- 所有 JID 都是基于上述的结构。类似 <user@host/resource> 这种结构，最常用来标识一个即时消息用户，这个用户所连接的服务器，以及这个用户用于连接的资源（比如特定类型的客户端软件）。不过,节点类型不是客户端 也是有可能的，比如一个用来提供多用户聊天服务的特定的聊天室，地址可以是 <room@service> （这里 “room“ 是聊天室的名字而 ”service“ 是多用户聊天服务的主机名），而加入了这个聊天室的某个特定的用户的地址则是 <room@service/nick> （这里 ”nick“ 是用户在聊天室的昵称）。许多其他的 JID 类型都是可能的（例如 <domain/resource> 可能是一个服务器端的脚本或服务）。
- 一个 JID 的每个合法部分（节点名，域名，资源名）的长度不能（MUST NOT）超过 1023 字节。也就是整体长度（包括 '@' 和 '/' ）不能超过 3071 字节。
域名
- 域名是一个主要的ID并且是 JID 中唯一必需（REQUIRED）的元素（一个纯粹的域名也是一个合法的 JID）。它通常代表网络的网关或者“主”服务器，其他实体通过连接它来实现 XML 转发和数据管理功能。然而，由一个域名标识引用的实体，并非总是一个服务器，它也可能是一个服务器的子域地址，提供额外的功能（比如多用户聊天服务，用户 目录，或一个到外部消息系统的网关）。
- 每个服务器或者服务的域名，可以（MAY）是一个 IP 地址，但应该（SHOULD）是一个完全合法的域名(参见 [DNS]).一个域名ID必须(MUST)是 [IANA] 里定义的“国际化域名”，并且按 [STRINGPREP]中的 [NAMEPREP] profile进行成功的字符转换。在比较两个域名ID之前，服务器必须(MUST),客户端应该(SHOULD)首先按照Nameprep profile(定义在[IANA]中) 来转换每个域名的字符。
节点名
- 节点名是一个可选（OPTIONAL）的第二 ID，放在域名之前并用符号"@"分开.它通常表示一个向服务器或网关请求和使用网络服务的实体(比如一个客户端),当然它也能够表示其他的实体(比如在 多用户聊天系统中的一个房间). 节点名所代表的实体，它的地址依赖于一个特定的域名;在 XMPP 的即时消息和出席信息应用系统中，这个地址是“纯 JID” <node@domain> 中的一部分。
- 一个节点名必须按 [STRINGPREP] 中的 Nodeprep profile 进行成功的字符转换。在比较两个节点ID之前，服务器必须（MUST）,客户端应该(SHOULD)首先按 Nodeprep profile 转换每个ID的字符。
资源名
- 资源名是一个可选的第三 ID,它放在域名的后面并由符号"/"分开。资源名可以跟在 <node@domain>后面也可以跟在 <domain> 后面。它通常表示一个特定的会话，连接（比如设备或者所在位置），或者一个附属于某个节点ID实体相关实体的对象（比如多用户聊天室中的一个参加者）。对 于服务器和和其他客户端来说，资源名是不透明的。当它提供必需的信息以完成资源绑定（参见第七章）的时候，通常是由客户端来实现的（尽管可以由客户端向服 务器请求完成），然后显示为“已连接的资源”。一个实体可以(MAY)并发维护多个已连接的资源。每个已连接的资源由不同的资源ID来区分。
- 一个资源名必须（MUST）按 [STRINGPREP] 中的 Resourceprep profile 进行成功的格式化。在比较两个资源ID之前，服务器必须（MUST）,客户端应该(SHOULD)首先按 Resourceprep profile 转换每个ID的字符。
地址的确认
- 在 SASL （见第六章）握手之后（如果必要的话，也在资源绑定（见第七章）之后），正在接收流信息的实体必须（MUST）确认初始实体的 ID 。
- 对于服务器间的通信，在 SASL 握手时，如果没有指明授权的ID，这个初始的实体应该（SHOULD）是经过认证实体（参见 简单认证和安全层协议 [SASL] 中的定义）授权的ID（见第六章）。
- 对于客户端和服务器的通信，在 SASL 握手时，如果没有指明授权的ID，“纯 JID” (<node@domain>)应该（SHOULD）是经过认证实体（参见 [SASL] 中的定义）授权的ID，“全 JID” (<node@domain/resource>)的资源ID部分应该（SHOULD）是由客户端和服务器在资源绑定的时候商定的（参见第七 章）。
- 接收的实体必须（MUST）确保结果JID（包括节点名，域名，资源名以及分隔符）与本章前面部分描述的规则和格式相一致；为了满足这些约束条件，接收实体可能（MAY）需要把初始实体的发送方 JID 替换成接收实体认可的规范 JID。
4.XML流
概览
- 两个基本概念，XML流和XML节，使得在出席信息已知的实体之间，异步交换低负载的结构化信息成为可能。这两个术语定义如下：
- XML流的定义：一个XML流是一个容器，包含了两个实体之间通过网络交换的XML元素 。一个XML流是由一个XML打开标签 <stream> (包含适当的属性和名字空间声明)开始的,流的结尾则是一个XML关闭L标签 </stream> 。
- 在流的整个生命周期，初始化它的实体可以通过流发送大量的XML元素，用于流的握手(例如 TLS 握手(第五章) 或 SASL 握手(第六章))或XML节（在这里指符合缺省名字空间的元素,包括<message/>,<presence/>, 或 <iq/> 元素）。“初始的流”由初始化实体（通常是一个客户端或服务器）和接收实体（通常是一个服务器）握手，从接收实体来看，它就是那个初始实体的"会话".初 始化流允许从初始化实体到接收实体的单向通信;为了使接收实体能够和初始实体交换信息,接收实体必须发起一个反向的握手(应答流).
- XML节的定义: 一个XML节是一个实体通过 XML 流向另一个实体发送的结构化信息中的一个离散的语义单位。 一个XML节直接存在于根元素<stream/>的下一级，这样可以说是很好的匹配 了[XML](译者注:在标准参考一节)的第43条.任何XML节都是从一个XML流的下一级的某个打开标签（如 <presence>）开始，到相应的关闭标签（如 </presence>）。一个XML节可以（MAY）包含子元素(相关的属性,元素, 和 XML 字符数据等) 以表达完整的信息.在这里定义的XML节仅限于<message/>, <presence/>, 和 <iq/> 元素，具体描述间见 XML Stanzas（第九章）；为TLS握手（第五章）、SASL握手（第六章）、服务器回拨（第八章）的需要而发送的XML元素，不被认为是一个XML节。
- 设想一个客户端和服务器会话的例子。 为了连接一个服务器，一个客户端必须（MUST）发送一个打开标签<stream>给服 务器，初始化一个XML流， 也可选择（OPTIONAL）在这之前发送一段文本声明XML版本和支持的字符集（参见文本声明的内容(第十一章第四节); 也可看字符编码(第十一章第五节)）。视本地化策略和提供的服务而定 ，服务器应该（SHOULD）回复一个XML流给客户端，同样的，也可选择在这之前发 送一段文本声明。一旦客户端完成了SASL握手（第六章），客户端可以（MAY）通过流发送不限量的XML节给网络中的任何接收者。当客户端想关闭这个 流，它只需要简单的发送一个关闭标签</stream>给服务器（或者作为另一个选择，可能由服务器关闭这个流）。然后，客户端和服务器都应 该（SHOULD）彻底地终止这个连接（通常是一个TCP连接）。
- 那些习惯认为XML是一个以文本为中心风格的人可能希望看看一个与服务器连接的客户端会话，包含两个 打开-关闭 XML文档：一个是从客户端到服务器，一个是从服务器到客户端。下图中，根元素<stream/> 可以被认为是每个“文档”的文档实体，这两个“文档”通过累积那些在XML上传输的XML节来搭建的。无论如何，下图只是方便理解；实际上XMPP并不处 理文档而是处理XML流和XML节。
- 基本上，一个XML流相当于一个会话期间所有XML节的一个信封。我们可以简单的把它描述成下图：
|--------------------| | <stream> |--------------------| | <presence> | <show/> | </presence> |--------------------| | <message to='foo'> | <body/> | </message> |--------------------| | <iq to='bar'> | <query/> | </iq> |--------------------| | ... |--------------------| | </stream> |--------------------|
绑定到TCP
- 虽然有很多非必需的连接使用XML流来绑定[TCP]连接（两个实体可以通过别的机制来互联，比如通过[HTPP]连接轮询），本规范只 定义了 XMPP 到 TCP 的绑定。 在客户和服务器通信的过程中，服务器必须（MUST）允许客户端共享一个TCP连接来传输XML节，包括从客户端传到服务器和从服务器传到客户 端。在服务器之间的通信过程中，服务器必须（MUST）用一个 TCP连接 向对方发送 XML节，另一个 TCP连接（由对方初始化）接收对方的XML节，一共两个 TCP连接。
流的安全
- 在XMPP 1.0中，当XML流开始握手时，TLS( 安全传输层协议 )应该（SHOULD）按 第五章：TLS的使用 中的规定来使用，SASL必须（MUST）按 第六章：SASL的使用 中的规定来使用。尽管可能（MAY）存在某种共有的机制能够保证双向安全，但是“初始化流”（比如从初始化实体发给接收实体的流）和“应答流”（比如从接 收实体发给初始化实体的流）还是必须（MUST）安全的分开。在流被验证之间，实体不应该（SHOULD NOT） 尝试通过流发送XML节（第九章）；就算它这样做了，对方的实体也不能（MUST NOT）接受这些XML节，并且应该（SHOULD）返回一个 <not-authorized/> 的流错误信息并且终止当前TCP连接上双方的XML流；注意，这仅仅是针对XML节（包含在缺省命名空间中的 <message/>, <presence/>, 和 <iq/> 元素），而不是指那些用于 TLS握手（第五章）、SASL握手（第六章）握手的流。
stream 属性
- stream 元素的属性如下:
-
- to -- 'to' 属性应（SHOULD）仅出现在初始化实体发给接收实体的 XML 流的头当中，并且它的值必须（MUST）是接收实体所在的主机名。 在接收实体发送给初始化实体的 XML 流的头中不应该（SHOULD NOT）出现 'to' 属性。若 'to' 属性出现在应答流中，则初始化实体应（SHOULD）忽略它。
-
- from -- 'from' 属性应（SHOULD）仅出现在接收实体发给初始化实体的 XML 流的头当中，并且它的值必须（MUST）是为当前初始化实体授权的接收实体所在的主机名。 注意，不应该（SHOULD NOT）有 'from'属性出现在初始实体发送给接收实体的 XML流的头中；无论如何，如果'from'属性出现在初始化流中，接收实体应该（SHOULD）忽略它。
-
- id -- 'id'属性应该（SHOULD）仅用于接收实体发送给初始化实体 XML流的头。这个属性是一个由接收实体创建的具有唯一性的ID,一个初始实体和接收实体之间的会话ID，并且它在接收方的应用程序中（通常是一个服务 器）必须（MUST）是唯一的。 注意，这个流 ID 必须是足够安全的，所以它必须是不可预知的和不可重复的（参见[RANDOM] 了解如何获得随机性以保证安全性）。不应该（SHOULD NOT）有 'id'属性出现在初始实体发送给接收实体的 XML流的头中；无论如何，如果'id'属性出现在初始化流中，接收实体应该（SHOULD）忽略它。
-
- xml:lang -- 'xml:lang'属性（定义在[XML]中的第二章第十二节）应该（SHOULD）包含在初始化实体发给接收实体的 XML流的头中，以指定在流中传输的可读XML字符所使用的缺省语言。如果这个属性出现了，接收实体应该（SHOULD）记住它的值，作为初始化流和应答 流的缺省属性；如果这个属性没有出现，接收实体应该（SHOULD）用一个可配置的缺省值用于双方的流，这个属性值必须（MUST）在应答流的头中传达。 对于所有初始化流中传输的节，如果初始实体没有提供'xml:lang'属性，接收实体应该（SHOULD）应用缺省值；如果初始实体提供了 'xml:lang'属性，接收实体不能（MUST NOT）修改或删除它（参见第九章第一节第五小节 xml:lang）。'xml:lang'属性的值必须（MUST）是一个 NMTOKEN (定义在[XML]的第二章第三节) 并且必须（MUST）遵守 RFC 3066 [LANGTAGS] 规定的格式。
-
- version -- version属性（最少需要"1.0"）为本规范中和流相关的协议提供了支持。关于这个属性的生成和处理的详细规则将在下文中定义。
- 我们现在可以总结如下:
| 初始化方发给接收方 | 接收方发给初始化方 | |
|---|---|---|
| to | 接收方的主机名 | 忽略 |
| from | 忽略 | 接收方的主机名 |
| id | 忽略 | 会话键值 |
| xml:lang | 缺省语言 | 缺省语言 |
| version | 支持XMPP 1.0 | 支持XMPP 1.0 |
版本支持
- 在这里XMPP的版本是"1.0"；准确地说，这里囊括了和流相关的所有协议(TLS的使用 (第五章),SASL的使用(第六章), 和流错误(第四章第七节))，以及三个定义好的XML节类型(<message/>,<presence/>,和 <iq/>)。 XMPP版本号的编号顺序是“<主版本号>.<副版本号>”。主版本和副版本号必须（MUST）是独 立的整数并且每个号码可以（MAY）单独以阿拉伯数字增长。 这样，"XMPP 2.4"的版本将比"XMPP 2.13"更低。号码前面 的“0”(比如XMPP 6.01)必须(MUST)被接收方忽略并且不能(MUST NOT)被发送出去.
- 如果 流和节的格式或者必需的处理方式有了显著的改变，以至于老版本的实体如果只是简单的忽略它不理解的节和属性并且继续像老版本一样的处 理方式，会使得老版本的实体不能够和新版本的实体交互，只有在这时候主版本号才应该（SHOULD）增加。副版本号显示新的性能，它必须（MUST）被副 版本号更低的实体忽略，但被高（副）版本号的实体用于了解信息。 例如，一个副版本号显示处理某种新定义的"type"属性的值（用于 message,presence或IQ节）的能力；副版本号高的实体将会了解到与之通信的对方不能够理解这个"type"属性的值，所以将不会发送它。
- 以下规则是用于'版本'属性在实现流的头信息时如何生成和处理:
-
- 初始化实体必须（MUST）在初始化流的头信息中把'版本'的值设置成它所支持的最高版本 。（比如，如果最高版本支持就是本规范，那么它必须(MUST)设置成"1.0"）.
- 接收实体必须（MUST）在应答流的头信息中把'版本'的值设置成初始化实体所提供的版本或它所支持的最高版本,取其中版本号较低的那一个 。接收实体必须(MUST)把主版本号和副版本号作为数字来比较,而不是对"主版本号.副版本号"这个字符串进行比较.
- 如果在应答流的头信息的版本号中至少有一个主版本号低于初始化流的头信息的版本号,并且如前所述,新版本的实体不能够和旧版本实体交互,初始化实体应该 (SHUOULD)生成一个<unsupported-version/>的流错误信息并终止XML流和它的TCP连接。
- 如果一个实体收到一个头信息中没有'version'属性的流，这个实体必须（MUST）把对方实体的'version'当成'0.0'并且在它发送的应答流的头中也不应该(SHOULD NOT)包含'version'属性.
名字空间声明
- 流的元素必须(MUST)同时满足一个流名字空间声明和一个缺省名字空间声明("名字空间声明"定义在 XML 名字空间定义 [XML-NAMES]中).关于流名字空间和缺省名字空间的详细信息,参考 名字空间的名字和前缀(第十一章第二节).
流的特性
- 如果初始化的实体在初始化流的头信息中设置'version'属性的信息为"1.0",接收实体必须(MUST)向初始化实体发送一个 <features/> 子元素以声明任何可供协商的流一级的特性(或者其他需要声明的能力).目前,这仅用于声明本文中定义的 TLS的使用(第五章),SASL的使用（第六章）和资源绑定(第七章),以及 XMPP-IM 中定义的会话的建立;无论如何,流特性这一功能将来可以用于声明任何可协商的特性.如果一个实体不理解或支持安全特性,它应该(SHOULD)忽略它.如 果要在一个非安全相关的特性(比如资源绑定)被提议之前,完成一个或多个安全特性(比如TLS和SASL)的协商,这个非安全相关的特性不应该 (SHOULD NOT)在相应的安全特性协商完毕之前被声明.
流错误
- 流的根元素可以（MAY）包含一个 <error/> 子元素，由流的名字空间前缀作为它的前缀。这个"错误"子元素必须（MUST）由感知到发生了流级别错误的实体发送（通常是一个服务器而不是一个客户端）。
规则
- 以下规则适用于流级别的错误:
-
- 它假定所有流级别的错误都是不可恢复的；所以，如果一个错误发生在流级别，发现这个错误的实体必须（MUST）发送一个流错误信息给另一个实体，发送一个关闭标签 </stream>，并终止这个流所在的TCP连接。
-
- 如果这个错误发生在流刚开始设置的时候，接收实体必须（MUST）仍然发送一个开放标签 <stream> ，并在流元素中包含一个<error/>的子元素，然后发送一个关闭标签 </stream>，最后终止相应的TCP连接。在这种情况下，如果初始化实体在 'to' 属性中提供了一个未知的主机名，服务器应该（SHOULD）在终止之前,先在流的头信息的 'from' 属性中提供一个服务器认证的主机名.
语法
- 流错误的语法如下:
<stream:error> <defined-condition xmlns ='urn:ietf:params:xml:ns:xmpp-streams' /> <text xmlns ='urn:ietf:params:xml:ns:xmpp-streams' xml:lang ='langcode' > OPTIONAL descriptive text </text> [OPTIONAL application-specific condition element] </stream:error>
-
<error/>元素:
- 必须(MUST)包含一个子元素以描述一个下文定义的节错误条件;这个子元素必须(MUST)符合'urn:ietf:params:xml:ns:xmpp-streams'名字空间.
-
- 可以(MAY)包含一个 <text/> 子元素,用XML字符数据描述错误的细节;这个元素必须(MUST)符合'urn:ietf:params:xml:ns:xmpp-streams'名 字空间并且应该(SHOULD)拥有一个'xml:lang'属性表明XML字符数据的自然语言。
-
- 可以（MAY）包含一个子元素用于描述一个明确的应用程序错误条件；这个元素必须（MUST）符合一个应用程序定义的名字空间，并且它的结构是由那个名字空间定义的。
- <text/> 元素是可选的（OPTIONAL）。如果有这个元素，它应该（SHOULD）仅用于提供描述或调试信息以补充一个已定义的条件或应用程序定义的条件。它不 应该（SHOULD NOT）被一个应用程序当成一个可编程的信息。它不应该（SHOULD NOT）被用于向用户表达错误信息，但是可以（MAY）作为和条件元素相关的错误信息之外的附加说明。
已定义的条件
- 以下流级别的错误条件是已定义的:
-
- <bad-format/> -- 实体已经发送XML但是不能被处理;这个错误可以（可以）被更多特定的XML相关的错误替换，比如 <bad-namespace-prefix/>, <invalid-xml/>, <restricted-xml/>, <unsupported-encoding/>, 以及 <xml-not-well-formed/>,尽管更多特定的错误是首选的。
-
- <bad-namespace-prefix/> -- 实体发送的名字空间前缀不被支持，或者在一个需要某种前缀的元素中没有发送一个名字空间前缀(参见 XML Namespace Names and Prefixes (第十一章第二节)).
-
- <conflict/> -- 服务器正在关闭为这个实体激活的流，因为一个和已经存在的流有冲突的新的流已经被初始化。
-
- <connection-timeout/> -- 实体已经很长时间没有通过这个流发生任何通信流量(可由一个本地服务策略来配置).
-
- <host-gone/> -- 初始化实体在流的头信息中提供的'to'属性的值所指定的主机已经不再由这台服务器提供
-
- <host-unknown/> -- 由初始化实体在流的头信息中提供的 'to' 属性的值和由服务器提供的主机名不一致.
-
- <improper-addressing/> -- 一个在两台服务器之间传送的节缺少 'to' 或 'from' 属性(或者这个属性没有值).
-
- <internal-server-error/> -- 服务器配置错误或者其他未定义的内部错误,使得服务器无法提供流服务.
-
- <invalid-from/> -- 在'from'属性中提供的 JID 或 主机名地址，和认证的 JID不匹配 或服务器之间无法通过SASL（或回拨）协商出合法的域名，或客户端和服务器之间无法通过它进行认证和资源绑定。
-
- <invalid-id/> -- 流 ID 或回拨 ID 是非法的或和以前提供的 ID 不一致.
-
- <invalid-namespace/> -- 流名字空间和 "http://etherx.jabber.org/streams " 不相同或回拨名字空间和 "jabber:server:dialback" 不相同.(参考 XML Namespace Names and Prefixes (第十一章第二节)).
-
- <invalid-xml/> -- 实体通过流发送了一个非法的XML给执行验证的服务器 (参考 Validation (第十一章第三节)).
-
- <not-authorized/> -- 实体试图在流被验证之前发送数据或不被许可执行一个和流协商有关的动作，接收实体在发送错误信息之前不允许（MUST NOT）处理厌恶的节。
-
- <policy-violation/> -- 实体违反了某些本地服务策略；服务器可以（MAY）选择在 <text/> 元素或应用程序定义的错误条件（元素）中详细说明策略。
-
- <remote-connection-failed/> -- 服务器无法正确连接到用于验证或授权的远程实体。
-
- <resource-constraint/> -- 服务器缺乏必要的系统资源为流服务。
-
- <restricted-xml/> -- 实体试图发送受限的XML特性，比如一个注释，处理指示，DTD，实体参考，或保留的字符(参考 Restrictions (第十一章第一节)).
-
- <see-other-host/> -- 服务器将不提供服务给初始化实体但是把它重定向到另一台主机；服务器应该（SHOULD）在<see-other-host/>元素的XML 字符数据中指明替代服务器名或IP地址（它必须（必须）是合法的域名标识）。
-
- <system-shutdown/> -- 服务器正在关机并且所有激活的流正在被关闭。
-
- <undefined-condition/> -- 错误条件不在本文已定义的错误条件列表之中；这个错误条件应该（SHOULD）仅用于"应用程序定义条件"元素.
-
- <unsupported-encoding/> -- 初始化实体以一个服务器不不支持的编码方式编码了一个流(参照Character Encoding (第十一章第五节)).
-
- <unsupported-stanza-type/> -- 初始化实体发送了一个流的一级子元素但是服务器不支持.
-
- <unsupported-version/> -- 由初始化实体在流的头信息中指定的'version'属性的值所指定的版本不被服务器支持;服务器可以(MAY)在<text/>元素中指定一个它支持的版本号.
-
- <xml-not-well-formed/> -- 初始化实体发送了一个不规范的XML(参考[XML]）.
应用程序定义条件
- 大家知道,应用程序可以(MAY)在error元素中包含一个适当名字空间的子元素来提供一个应用程序定义流错误信息."应用程序定义"元素应该(SHOULD)补充或甚至限定一个已定义的元素.所以 <error/> 元素将包含两个或三个子元素:
<stream:error> <xml-not-well-formed xmlns ='urn:ietf:params:xml:ns:xmpp-streams' /> <text xml:lang ='en' xmlns ='urn:ietf:params:xml:ns:xmpp-streams' > Some special application diagnostic information! </text> <escape-your-data xmlns ='application-ns' /> </stream:error> </stream:stream>
简化的流示例
- 这里包含两个简化的例子，描述了基于流的客户端在服务器上的“会话”(这里"C"表示从客户端发给服务器,"S"表示从服务器发给客户端);这些例子只是用于举例说明原理.
- 一个基本的 "会话":
C: <?xml version ='1.0' ?> <stream:stream to ='example.com' xmlns ='jabber:client' xmlns:stream ='http://etherx.jabber.org/streams' version ='1.0' > S: <?xml version ='1.0' ?> <stream:stream from ='example.com' id ='someid' xmlns ='jabber:client' xmlns:stream ='http://etherx.jabber.org/streams' version ='1.0' > ... encryption, authentication, and resource binding ... C: <message from ='juliet@example.com' to ='romeo@example.net' xml:lang ='en' > C: <body> Art thou not Romeo, and a Montague? </body> C: </message> S: <message from ='romeo@example.net' to ='juliet@example.com' xml:lang ='en' > S: <body> Neither, fair saint, if either thee dislike. </body> S: </message> C: </stream:stream> S: </stream:stream>
- 一个不成功的 "会话" :
C: <?xml version ='1.0' ?> <stream:stream to ='example.com' xmlns ='jabber:client' xmlns:stream ='http://etherx.jabber.org/streams' version ='1.0' > S: <?xml version ='1.0' ?> <stream:stream from ='example.com' id ='someid' xmlns ='jabber:client' xmlns:stream ='http://etherx.jabber.org/streams' version ='1.0' > ... encryption, authentication, and resource binding ... C: <message xml:lang ='en' > <body> Bad XML, no closing body tag! </message> S: <stream:error> <xml-not-well-formed xmlns ='urn:ietf:params:xml:ns:xmpp-streams' /> </stream:error> S: </stream:stream>
TLS 的使用
概览
- XMPP包含的一个保证流安全的方法来防止篡改和偷听.这个传输层安全协议[TLS]的频道加密方法, 模拟了类似的其他"STARTTLS"(见 RFC 2595 [USINGTLS])的扩展,如 IMAP [IMAP], POP3 [POP3], and ACAP [ACAP]."STARTTLS"的扩展名字空间是'urn:ietf:params:xml:ns:xmpp-tls'.
- 一个给定域的管理员可以(MAY)要求客户端和服务器通信以及服务器之间通信时使用TLS，或者两者都要求。客户端应该（SHOULD） 在尝试完成 SASL （第六章）握手之前使用 TLS，服务器应该（SHOULD）在两个域之间使用 TLS 以保证服务器间通信的安全。
- 以下是使用规则:
-
-
- 一个遵守本协议的初始化实体必须（MUST）在初始化流的头信息中包含一个'version'属性并把值设为“1.0”。
- 如果TLS握手发生在两个服务器之间，除非服务器声称的DNS主机名已经被解析(见第十四章第四节 Server-to-Server Communications)，通信不能（MUST NOT）继续进行。
- 当一个遵守本协议的接收实体接收了一个初始化流（它的头信息中包含一个'version'属性并且值设为“1.0”），在发送应答流的的头信息（其中包含 版本标记）之后，它必须发送（MUST）<starttls/>元素（名字空间为 'urn:ietf:params:xml:ns:xmpp-tls'）以及其他它支持的流特性 。
- 如果初始化实体选择使用TLS,TLS握手必须在SASL握手之前完成；这个顺序用于帮助保护SASL握手时发送的认证信息的安全，同时可以在必要的时候在TLS握手之前为SASL外部机制提供证书。
- TLS握手期间,一个实体不能（MUST NOT）在流的根元素中发送任何空格符号作为元素的分隔符（在下面的TLS示例中的任何空格符都仅仅是为了便于阅读）；这个禁令用来帮助确保安全层字节精度。
- 接收实体必须（MUST）在发送<proceed/> 元素的关闭符号">" 之后立刻开始TLS协商。初始化实体必须（MUST）在从接收实体接收到<proceed/> 元素的关闭符号">" 之后立刻开始TLS协商。
- 初始化实体必须（MUST）验证接收实体出示的证书；关于证书验证流程参见Certificate Validation ( 第十四章第二节)。
- 证书必须（MUST）检查初始化实体(比如一个用户)提供的主机名；而不是通过DNS系统解析出来的主机名；例如，如果用户指定一个主机 名"example.com"而一个DNS SRV [SRV]查询返回"im.example.com"，证书必须（MUST）检查"example.com".如果任何种类的XMPP实体（例如客户端或 服务器）的JID出现在一个证书里，它必须（MUST）表现为一个别名实体里面的UTF8字符串，存在于subjectAltName之中。如何使用 [ASN.1] 对象标识符 "id-on-xmppAddr" 定义在本文的第五章第一节第一小节。
- 如果 TLS 握手成功了，接收实体必须（MUST） 丢弃TLS 生效之前从初始化实体得到的任何不可靠的信息.
- 如果 TLS 握手成功了，初始化实体必须（MUST） 丢弃TLS 生效之前从接收实体得到的任何不可靠的信息.
- 如果 TLS 握手成功了，接收实体不能(MUST NOT)在流重新开始的时候通过提供其他的流特性来向初始化实体提供 STARTTLS 扩展.
- 如果 TLS 握手成功了，初始化实体必须(MUST)继续进行SASL握手。
- 如果 TLS 握手失败了，接收实体必须（MUST）终止XML流和相应的TCP连接。
- 关于必须（MUST）支持的机制，参照 Mandatory-to-Implement Technologies (第十四章第七节) 。
-
用于 XMPP 地址的 ASN.1 对象标识符
- 上文提到的[ASN.1] 对象标识符 "id-on-xmppAddr"定义如下:
-
- 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".
叙述
- 当一个初始化实体用TLS保护一个和接收实体之间的流，其步骤如下:
-
-
- 初始化实体打开一个TCP连接，发送一个打开的XML流头信息（其'version'属性设置为"1.0"）给接收实体以初始化一个流。
- 接收实体打开一个TCP连接，发送一个XML流头信息（其'version'属性设置为"1.0"）给初始化实体作为应答。
- 接收实体向初始化实体提议STARTTLS范围（包括其他支持的流特性），如果TLS对于和接收实体交互是必需的，它应该（SHOULD）在<starttls/>元素中包含子元素<required/>.
- 初始化实体发出STARTTLS命令(例如, 一个符合'urn:ietf:params:xml:ns:xmpp-tls'名字空间的 <starttls/> 元素) 以通知接收实体它希望开始一个TLS握手来保护流。
- 接收实体必须（MUST）以'urn:ietf:params:xml:ns:xmpp-tls'名字空间中的<proceed/>元素 或<failure/>元素应答。如果失败，接收实体必须（MUST）终止XML流和相应的TCP连接。如果继续进行，接收实体必须 （MUST）尝试通过TCP连接完成TLS握手并且在TLS握手完成之前不能（MUST NOT）发送任何其他XML数据。
- 初始化实体和接收实体尝试完成TLS握手。（要符合[TLS]规范）
- 如果 TLS 握手不成功, 接收实体必须（MUST）终止 TCP 连接. 如果 TLS 握手成功, 初始化实体必须（MUST）发送给接收实体一个打开的XML流头信息来初始化一个新的流（先发送一个关闭标签</stream>是不必要的, 因为接收实体和初始化实体必须(MUST)确保原来的流在TLS握手成功之后被关闭） 。
- 在从初始化实体收到新的流头信息之后，接收实体必须（MUST）发送一个新的XML流头信息给初始化实体作为应答，其中应包含可用的特性但不包含STATRTTLS特性。
-
客户端-服务器 示例
- 以下例子展示一个客户端使用STARTTLS保护数据流 (注意: 以下步骤举例说明协议中的失败案例；在这个例子中它们并不详尽并且也不是必须被数据传输触发的).
- 步骤 1: 客户端初始化流给服务器:
<stream:stream xmlns ='jabber:client' xmlns:stream ='http://etherx.jabber.org/streams' to ='example.com' version ='1.0' >
- 步骤 2: 服务器发送一个流标签给客户端作为应答:
<stream:stream xmlns ='jabber:client' xmlns:stream ='http://etherx.jabber.org/streams' id ='c2s_123' from ='example.com' version ='1.0' >
- 步骤 3: 服务器发送 STARTTLS 范围给客户端（包括验证机制和任何其他流特性）:
<stream:features> <starttls xmlns ='urn:ietf:params:xml:ns:xmpp-tls' > <required /> </starttls> <mechanisms xmlns ='urn:ietf:params:xml:ns:xmpp-sasl' > <mechanism> DIGEST-MD5 </mechanism> <mechanism> PLAIN </mechanism> </mechanisms> </stream:features>
- 步骤 4: 客户端发送 STARTTLS 命令给服务器:
<starttls xmlns ='urn:ietf:params:xml:ns:xmpp-tls' />
- 步骤 5: 服务器通知客户端可以继续进行:
<proceed xmlns ='urn:ietf:params:xml:ns:xmpp-tls' />
- 步骤 5 (或者): 服务器通知客户端 TLS 握手失败并关闭流和TCP连接:
<failure xmlns ='urn:ietf:params:xml:ns:xmpp-tls' /> </stream:stream>
- 步骤 6: 客户端和服务器尝试通过已有的TCP连接完成 TLS 握手.
- 步骤 7: 如果 TLS 握手成功, 客户端初始化一个新的流给服务器:
<stream:stream xmlns ='jabber:client' xmlns:stream ='http://etherx.jabber.org/streams' to ='example.com' version ='1.0' >
- 步骤 7 (或者): 如果 TLS 握手不成功, 服务器关闭 TCP 连接.
- 步骤 8: 服务器发送一个流头信息应答客户端，其中包括任何可用的流特性:
<stream:stream xmlns ='jabber:client' xmlns:stream ='http://etherx.jabber.org/streams' from ='example.com' id ='c2s_234' version ='1.0' > <stream:features> <mechanisms xmlns ='urn:ietf:params:xml:ns:xmpp-sasl' > <mechanism> DIGEST-MD5 </mechanism> <mechanism> PLAIN </mechanism> <mechanism> EXTERNAL </mechanism> </mechanisms> </stream:features>
- 步骤 9: 客户端继续 SASL 握手 (第六章).
服务器-服务器示例
- 以下例子展示两个服务器之间使用STARTTLS保护数据流 (注意: 以下步骤举例说明协议中的失败案例；在这个例子中它们并不详尽并且也不是必须被数据传输触发的).
- 步骤 1: Server1 初始化流给 Server2:
<stream:stream xmlns ='jabber:server' xmlns:stream ='http://etherx.jabber.org/streams' to ='example.com' version ='1.0' >
- 步骤 2: Server2 发送一个流标签给 Server1 作为应答:
<stream:stream xmlns ='jabber:server' xmlns:stream ='http://etherx.jabber.org/streams' from ='example.com' id ='s2s_123' version ='1.0' >
- 步骤 3: Server2 发送 STARTTLS 范围给 Server1 ，包括验证机制和任何其他流特性:
<stream:features> <starttls xmlns ='urn:ietf:params:xml:ns:xmpp-tls' > <required /> </starttls> <mechanisms xmlns ='urn:ietf:params:xml:ns:xmpp-sasl' > <mechanism> DIGEST-MD5 </mechanism> <mechanism> KERBEROS_V4 </mechanism> </mechanisms> </stream:features>
- 步骤 4: Server1 发送 STARTTLS 命令给 Server2:
<starttls xmlns ='urn:ietf:params:xml:ns:xmpp-tls' />
- 步骤 5: Server2 通知 Server1 允许继续进行:
<proceed xmlns ='urn:ietf:params:xml:ns:xmpp-tls' />
- 步骤 5 (或者): Server2 通知 Server1 TLS握手失败并关闭流:
<failure xmlns ='urn:ietf:params:xml:ns:xmpp-tls' /> </stream:stream>
- 步骤 6: Server1 和 Server2 尝试通过 TCP 完成 TLS 握手.
- 步骤 7: 如果 TLS 握手成功, Server1 初始化一个新的流给 Server2:
<stream:stream xmlns ='jabber:server' xmlns:stream ='http://etherx.jabber.org/streams' to ='example.com' version ='1.0' >
- 步骤 7 (或者): 如果 TLS 握手不成功, Server2 关闭 TCP 连接.
- 步骤 8: Server2 发送一个包含任何可用流特性的流头信息给 Server1 :
<stream:stream xmlns ='jabber:server' xmlns:stream ='http://etherx.jabber.org/streams&#
最低0.47元/天 解锁文章
扫一扫
268
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
