XMPP 3920 最靠谱的中文翻译文档

from='Receiving Server' to='Originating Server' id='457F9224A0...'> 98AF014EDC0...

注：经过这儿的是来自接收服务器的流头的主机名、源标识符，到步骤3中的发起服务器，源服务器发送给接收服务器的密钥在步骤4。根据这些信息，还有授权服 务器网络中的共享密钥信息，密钥被验证。任何验证方法可能用于产生密钥。如果‘to’地址值与授权服务器识别的主机名不匹配，那么，授权服务器必须产生一 个流错误条件并终止两个XML与潜在的TCP连接。如果‘from’地址值与源服务器打开TCP连接时（或任 意相关有效域，例如接收服务器的主机名或其它有效域一个有效子域）所表示的主机名不匹配，则授权服务器必须产生一个流错误条件并终止两个XML流与潜在的TCP连接。

9） 授权服务器验证密钥是否有效

from='Originating Server' to='Receiving Server' type='valid'

id='457F9224A0...'/>

或

from='Originating Server' to='Receiving Server' type='invalid' id='457F9224A0...'/>

注：如果ID与步骤3中的接收服务器不匹配，那么接收服务器必须产生一个流错误条件并终止两个XML流与潜在的 TCP连接。如果‘to’地址值与接收服务器所识别的主机名不匹配，则接收服务器必须产生一个流错误条件并终 止两个XML流与潜在的TXP连接。如果‘from’地址值与源服务器打开TCP连接时（或任意相关有效域，例如接收服务器的主机名或其它有效域一个有效 子域）所表示的主机名不匹配，则接收服务器必须产生一个流错误条件并终止两个XML流与潜在的TCP连接。返 回认证信息给接收服务器之后，授权服务器应当终止他们之间的流。 10） 接收服务器通知源服务器结果：

from='Receiving Server' to='Originating Server' type='valid'/> 注：在这里，连接可通过一个type='valid'或报告为无效来被认证。如果连接无效，则接收服务器必须终止两个XML流与潜在的TCP连接。如果连 接被认证，数据可被源服务器发送并被接收服务器读取；在此这前，所有发送给接收服务器的XML节应该默默被扔掉。

前述结果是接收服务器已经认证了源服务器的身份，为了节通过“初始流”（如，

从源服务器到接收服务器的流）的XML能被源服务器发送与接收服务器能接收，为了验证使用“响应流”（如，从接收服务器到源服务器）实体的身份，回叫必须以相反方向完成。

成功回叫协调后，接收服务器应当接收来自通过现存已认证连接的源服务器的子序列包（例如，认证需求发送到子域或其它 由接收服务器服务主机名）；这使在一个方向上的原来的已认证连接的\成为可能。

即使回叫协调成功，服务器必须认证从其它服务器接收的XML节，包括‘from’属性与‘to’属性；如果一个节并不满足此限制，接收节的服务器必须产生 一个流错误条件并终止两个XML流与潜在的TCP连接。进一步讲，服务器必须认证从其它服务 器，包括流的一个已验证域的‘from’属性；如果节并不满足此限制，收到节的服务器必须产生一个流错误条件 并终止两个XML流与潜在的TCP连接。这两个检查有助于阻止关联到特别节的哄骗。

9．XML节

TLS协商（5节）后，如果需要SASL协商（6节）与资源绑定（7节），XML节可通过流来发送。定义了三种XML节用于 'jabber:client'与'jabber:server'命名空间：

, , and 。另外，这种节有五个通用属性。这些通用属性，像三种节的基本语义一样，都定义在此；与即时消息与表示应用相关的XML节的更详细 信息在[XMPP-IM]中提供。

9．1通用属性

以下五个属性对message, presence与IQ均通用：

9．1．1 to

‘to’属性指定接收节的JID。

在‘jabber:client’命名空间中，节应当处理‘to’属性，虽然，由服务器处理的从客户端到服务器端的节不应该拥有‘to’属性。 在'jabber:server'命名空间中，节必须拥有‘to’属性；如果服务器收到一个不满足此限制的节，它必须产生一个流错误条件并终止两个XML流与错误服务器的潜在连接。

如果‘to’属性无效或不能连接，发现此事实的（通常是发送的或接收的服务器）实体必须返回一个合适的错误给发送者，设置错误节的‘from’属性为错误服务器提供的‘to’属性值。

9．1．2 from

‘from’属性指明发送者的IID。

当服务器收到一个在由'jabber:client'命名空间认证的已授权流的上下文中的XML节，它必须做以下事件之一：

1） 验证客户端提供的‘from’属性值就是用于联合实体的已连接资源的值。 2） 加一个‘from’地址值给节，此节的值是裸JID（）或全JID

（），这些JID由服务器决定用于产生节的已联接资源（看地址决定（3.5节））。

如果一个客户端试图发送‘from’属性并不匹配实体的已联接资源的XML节，服务器应该返回一个流错误给客 户端。如果一个客户端试图通过一个流来发送一个还未授权的XML节，服务器应当返回一个流错误给客户端。 如果产生了，这些条件都必须关闭流并终止潜在的TCP连接；这有助于阻止来自于欺诈客户端的否认服务攻击。

当一个服务器产生一个来自于服务器本身的节，用于传送到一个已连接的客户端（例如：在由服务器代表客户端提供的数据存储服务的上下文中），节必须既（1） 不包括‘from’属性或（2）包括‘from’属性，其值是帐户的裸JID（）或客户的全 JID（）。服务器不准发送给客户端一个不包括‘from’属性的节，它必须设想节是从服务器 到已连接客户端。 在'jabber:server'命名空间中，一个节必须处理一个‘from’属性；如果服务器收到不满足此限制的节，它必须产生一 个流错误条件。更进一步，包含在‘from’属性中的JID的域标识符部分必须匹配发送服务器 （或任何已认证相关域，如发送服务器的主机名或其它由发送服务器已认证域）的主机名，当在SASL协商或回叫协商通信中；如果一个服务器收到一个不满足此 约束的节，它必须产生一个流错误条件。这些条件都必须关闭流并终止潜在的TCP连接；这有助于阻止欺诈服务器 的否认服务攻击。

9．1．3 id

可选‘id’属性可能由发送实体因内部跟踪收发（特别是跟踪固有在IQ节语义中的请求-响应交互）节而使用。对值‘id’属性来说，它是可选的唯一全局的，在域内的或流中的。IQ节语义强加了其它约束；看IQ语义（9.2.3）。

9．1．4 type

类型域属性指定目的或消息上下文，出席或IQ节的详细信息。‘type’属性的特别允许值依赖节是否是一个消息，出席，或IQ；消息与出席节的值是特别用 于即时消息与出席应用的，并因此定义义在[XMPP-IM]，然而IQ节的值特指IQ节在一个结构化的请求-响应“会话”中的角色，并因此定义在以下IQ 语义（9.2.3节）。对三种节仅有的一个通用‘type’值是“error”；看节错误（9.3节）。

9．1．5 xml:lang

此节应当处理一个‘xml:lang’属性（定义在[XML]2.2节），如果节包含倾向于表示到一个人类用户（RFC2277[CHARSET]中有解 释，“对人的国际化”）的XML字符数据。‘xml:lang’属性值指定任意人类可读XML字符数据的缺省语言，可能被特定的子元素的 ‘xml:lang’属性覆盖。如果节没有‘xml:lang’属性，实现必须设想为流指定的缺省语言已在以下流属性（4。4节）中定义。 ‘xml:lang’属性的值必须是一个NMTOKEN并必须遵从定义在3066[LANGTAGS]中的格式。

9．2基本语义 9．2．1消息语义

节种类可被看作“推”机制，一个实体推信息给其它实体，与EMAIL系统中发生的通信类似。所有消息节应该拥有‘to’ 属性，指定有意的消息接收者；根据接收到那样的一个节，服务器应该路由或传送它到有意的接收者（参考服务器处理用于相关XML节的通用路由与传送规则 XML节的规则（10节））。

9．2．2 出席语义

元素可被看作基本广播或“出版-订阅”机制，多实体收到他们已订阅（在这种情况下，网络可利用信息）实体的信息。总的 来说，出版实体应该发送一个不带‘to’属性的出席节，在这种情况下，与此实体相连的服务器应该广播或复用节给所有订阅实体。然而，一个出版实体也可能发 送一个带有‘to’属性的出席节，此种情况下，服务器应该路由或传送节到有意的接收者。参考处理XML节（10节）的服务器规则，用于通用路由与相关 XML节的传送规则，并且用于即时消息与出席应用的出席-特定规则[XMPP-IM]。

9．2．3 IQ语义

信息/请求，或IQ，是一个请求-响应机制，与[HTTP]在某些方面相似。IQ语义让一个实体向其它实体请求或接收其它实体的响应成为可能。请求与响应 的数据内容由IQ无素的直接子元素的命名空间声明定义，并且，交互由请求实体通过使用‘id’属性来跟踪。因此，IQ交互遵从结构化数据交换的一个通用模 式，此交换例如得到/结果或设置/结果（虽然如果合适的话，对一个请求的响应可能会以错误返回）：

Requesting Responding Entity Entity ---------- ---------- | | | | | ------------------------> | | | | | | <------------------------ | | | | | | ------------------------> | | | | | | <------------------------ | | |

为了加强这些语义，以下规则应用： 1） 对IQ节来说，‘id’属性是REQUIRED。

2） 对IQ节来说。‘type’属性是需要的。值必须是以下之一： *get——节是一个用于信息或需求的请求。

*set——节提供所需数据，设置新值，或替换现存值。 *result——节是成功得到或设置请求的响应。

*error——先前发送得到或设置的相关过程或传送的错误（参考节错误（9.3节））。 3） 收到类型为“get”或“set”的IQ请求的实体必须以类型为“result”或“error”的IQ响应来响应（响应必须保留请求的‘id’属性）。

4） 收到类型为“result”或“error”的节不准靠发送一个进一步的类型为“result”或“error”的IQ响应节来响应；然而，如以上显示，请求实体可能发送另一个请求（如：一