XMPP--XML节

通用属性

以下五种属性通用于 message, presence, 和 IQ 节:

'to' 属性表示节的预期接收者的JID.
在'jabber:client'名字空间中, 一个节应该（SHOULD）处理一个'to'属性, 尽管由服务器处理的从客户端发给服务器的节(如, 发送给服务器用于广播给其他实体的出席信息) 应该不（SHOULD NOT）处理'to'属性.
在'jabber:server'名字空间中, 一个节必须（MUST）处理一个'to'属性; 如果一个服务器收到一个不符合此限定的节, 它必须（MUST）生成一个<improper-addressing/>流错误条件并终止和这个非法服务器的XML流和相应的TCP连接.
如果'to'属性的值非法或无法联络, 发现这个事实的实体（通常是发送者或接收者的服务器）必须（MUST）返回一个适当的错误给发送者, 错误节的'from'属性设置成非法节的提供的'to'属性的值.

'from' 属性表示发送者的 JID .
当一个服务器接收了一个符合'jabber:client'名字空间的合法流的XML节, 它必须(MUST)做以下步骤中的一步:
验证客户端提供的'from'属性值就是那个相关实体连接的资源
为生成这个节的已连接的资源增加一个'from'地址（由服务器决定是纯JID或全JID）(参见 地址的决定 Determination of Addresses (第三章第五节))
如果一个客户端试图发送一个XML节，而它的'from'属性和这个实体已连接的资源不符, 服务器应该(SHOULD)返回一个<invalid-from/>流错误条件给客户端. 如果一个客户端试图通过一个尚未验证的流发送一个XML节, 服务器应该（SHOULD）返回一个<not-authorized/>流错误条件给客户端. 如果生成了, 所有这些条件必须（MUST）导致流的关闭和相应的TCP连接的终止; 这有助于防止不诚实的客户的拒绝服务攻击.
当一个服务器从服务器自身生成一个节用于一个已连接的客户端的信息发布(例如, 在服务器为客户端提供数据存储服务的情况下), 这个节必须(MUST) (1) 不包含 'from' 属性 或 (2) 包含一个'from'属性，它的值是这个账号的纯 JID (<node@domain>) 或 客户端的全 JID (<node@domain/resource>). 如果节不是由服务器自身生成的，那么一个服务器不能（MUST NOT）发送不带'from'属性的节. 当一个客户端接收到一个不包含'from'属性的节, 它必须(MUST)认为这个节是从客户端连接的服务器发来的.
在'jabber:server'名字空间, 一个节必须(MUST)处理一个'from'属性; 如果一个服务器接收到一个不符合此限定的节, 它必须(MUST)生成一个<improper-addressing/>流错误条件. 而且, 'from'属性的 JID值的域名ID部分必须（MUST）和以SASL协商连接或以回拨协商连接的发送服务器的主机名（或任何合法的域，如发送服务器主机名的合法子域，或其他寄宿在发送服务器上的合法域）吻合; 如果一个服务器接收到的节不符合此限定, 它必须（MUST）生成一个<invalid-from/>流错误条件. 所有这些条件都必须（MUST）导致流的关闭和相应的TCP连接的终止; 这有助于防止不诚实的客户端发起的拒绝服务攻击.

可选的'id' 属性可以（MAY）用于为节的内部跟踪发送实体，从IQ节 语义来讲，就是通过发送和接收这些节来跟踪“请求-应答”型的交互行为。这个可选的（OPTIONAL）'id'属性值在一个域或一个流中是全局唯一的。IQ节语义学中对此有附加限定；见IQ Semantics (第九章第二节第三小节)。

'type' 属性指明消息、出席信息或IQ节的意图或上下文的详细信息。'type'属性所允许的值依据节的类型是消息、出席信息还是IQ而有很大不同； 用于消息和出席信息节的值定义在即时消息和出席信息应用中，所以在[XMPP-IM|XMPP文档列表/XMPP正式RFC标准/RFC3921]中定义，反之用于IQ节的值定义了在一个 请求\-应答 的“会话”中IQ节的角色，所以定义在IQ语义学中（第九章第二节第三小节）。 所有三种节的通用'type'值是"error"；见Stanza Errors (第九章第三节)。

如果一个节包含用于显示给人human user看的XML字符数据(在RFC 2277中有所解释\[CHARSET\],"internationalization is for humans")，这个节应该（SHOULD）处理一个'xml:lang'属性(定义在第二章第十二节\[XML\])。'xml:lang'属性的值指明任何一个人类可读的XML字符数据的缺省语言，它可以（MAY）被特定的子元素的'xml:lang'值重载。如果一个节不处理一个'xml:lang'属性,一个实现必须(MUST)认为缺省的语言就是流属性中定义的语言(第四章第四节). 'xml:lang'属性值必须(MUST)是一个NMTOKEN 并且必须(MUST)遵守RFC 3066\[LANGTAGS\]中定义的格式.

基本语义学

消息语义学：

<message/>节类型可以被看作是一个"push"机制用于一个实体推送信息给另一个实体,类似发生在email系统中的通信. 所有消息节应该（SHOULD）处理一个表明预定的消息接收者的'to'属性;接收了这样一个节之后,一个服务器应该（SHOULD）路由或递送它给预定的接收者(见 Server Rules for Handling XML Stanzas (第十章)的XML节相关的通用路由和递送规则).

出席信息语义学：

<presence/> 元素可以被看作一个基本的广播或“出版-订阅”机制,用于多个实体接收某个已订阅的实体的信息(在这里,是网络可用性信息). 通常,一个发行实体应该（SHOULD）不带'to'属性发送一个出席信息,这时这个实体所连接的服务器应该（SHOULD）广播或多播(multiplex?)那个节给所有订阅的实体.无论如何,一个发行实体也可以(MAY)带'to'属性发送一个出席信息节,这时服务器应该(SHOULD)路由或递送这个节给预定的接收者.见 Server Rules for Handling XML Stanzas (第十章)的XML节相关的通用路由和递送规则,以及[XMPP-IM|XMPP文档列表/XMPP正式RFC标准/RFC3921]中即时消息和出席信息应用中出席信息的特定规则.

IQ语义学：

信息/查询(Info/Query),或曰IQ,是一个 请求-回应 机制,某些情况下类似\[HTTP\].IQ语义学使一个实体能够向另一个实体做出请求并做出应答. 请求和应答所包含的数据定义在IQ元素的一个直接的子元素的名字空间声明中, 并且由请求实体用'id'属性来跟踪这一交互行为. 因而,IQ交互伴随着一个结构化的数据交换的通用模式例如 get/result 或 set/result (尽管有时候会以一个错误信息应答某个请求):
以下是IQ的流程图，参见附件iq.png
{image:img=iq}
为了强制执行这些语义学,要应用以下规则:
1. 对于IQ节来说'id'属性是必需的（REQUIRED）.
2. 对于IQ节来说'type'属性是必需的（REQUIRED）. 它的值必须（MUST）是以下之一:
get -- 这个节是一个对信息或需求的请求.
set -- 这个节提供需要的数据, 设置新的值, 或取代现有的值.
result -- 这个节是一个对一个成功的 get 或 set 请求的应答.
error -- 发生了一个错误，关于处理或递送上次发送的 get 或 set的(参见 节错误 Stanza Errors(第九章第三节)).
3. 一个接收到"get" 或 "set" 类型的IQ请求的实体必须（MUST）回复一个"result"或"error"类型的IQ应答(这个应答必须（MUST）保留相关请求的'id'属性).
4. 一个接收到"result"或"error"类型的IQ节的实体不能（MUST NOT）再发送更多的"result"或"error"类型的IQ应答; 无论如何, 如上所述, 请求实体可以（MAY）发送另一个请求(如, 一个"set"类型的IQ，通过get/result对提供查询(discovery)所需的信息).
5. 一个"get" 或 "set" 类型的IQ节必须（MUST）包含并只包含一个子元素指明特定请求或应答的语义.
6. 一个"result"类型的IQ节必须（MUST）包含零或一个子元素.
7. 一个"error"类型的IQ节应该（SHOULD）包含和"get"或"set"相关联的那个子元素并且必须（MUST）包含一个<error/>子元素;详细信息,见Stanza Errors (第九章第三节).

节错误

规则：

以下规则适用于节相关的错误:
接收或处理实体察觉到一个节相关的错误条件时应该（MUST）返回给发送实体一个同类型的节(消息,出席信息,或IQ),这个节的'type'属性值则设置为"error"(这里这样的节称之为"error stanza").
生成一个错误节的实体应该（SHOULD）包含原来发送的XML，这样发送者可以检查它，并且如果必要，在尝试重新发送之前纠正它.
一个错误节必须（MUST）包含一个<error/>子元素.
如果'type'属性值不是"error"（或没有"type"属性），节不能(MUST NOT)包含一个<error/>子元素.
接收到一个错误节的实体不能(MUST NOT)应答这个节更多的错误节; 这有助于防止死循环.

语法：

以下规则适用于节相关的错误:
接收或处理实体察觉到一个节相关的错误条件时应该（MUST）返回给发送实体一个同类型的节(消息,出席信息,或IQ),这个节的'type'属性值则设置为"error"(这里这样的节称之为"error stanza").
生成一个错误节的实体应该（SHOULD）包含原来发送的XML，这样发送者可以检查它，并且如果必要，在尝试重新发送之前纠正它.
一个错误节必须（MUST）包含一个<error/>子元素.
如果'type'属性值不是"error"（或没有"type"属性），节不能(MUST NOT)包含一个<error/>子元素.
接收到一个错误节的实体不能(MUST NOT)应答这个节更多的错误节; 这有助于防止死循环.

已定义的条件：

以下条件定义用于节错误.
<bad-request/> -- 发送者发送的XML是不规范的或不能被处理(例如 一个IQ节包含了一个未被承认的'type'属性值); 相关的错误类型应该（SHOULD）是"modify".
<conflict/> -- 不同意访问，因为相同的名字或地址已存在一个资源或会话;相关的错误类型应该（ SHOULD）是"cancel".
<feature-not-implemented/> -- 请求的特性未被接收者或服务器实现所以不能处理;相关的错误类型应该（SHOULD）是"cancel".
<forbidden/> -- 请求实体没有必需的许可来执行这一动作;相关的错误类型应该（SHOULD）是"auth".
<gone/> -- 接收者或服务器无法再以这个地址进行联系(错误节可以（MAY）在<gone/>元素的XML字符数据中包含一个新的地址);相关的错误类型应该（SHOULD）是"modify".
<internal-server-error/> -- 服务器不能处理节，因为错误的配置或其他未定义的内部服务器错误;相关的错误类型应该（SHOULD）是"wait".
<item-not-found/> -- JID地址或申请的条目无法找到;相关的错误类型应该（SHOULD）是"cancel".
<jid-malformed/> -- 发送的实体提供的XMPP地址或与之通信的某个XMPP地址(如一个'to'属性值)或这个XMPP地址中的一部分(如一个资源ID)不符合寻址方案的语法(第三章);相关的错误类型应该（SHOULD）是"modify".
<not-acceptable/> -- 接收者或服务器理解这个请求但是拒绝处理，因为它不符合某些接收者或服务器定义的标准(例如,一个关于消息中可接收的单词的本地策略);相关错误类型应该（SHOULD）是"modify".
<not-allowed/> -- 接收者或服务器不允许任何实体执行这个动作;相关错误类型应该（SHOULD）是"cancel".
<not-authorized/> -- 在被允许执行某个动作之前发送者必须提供适当的证书,或已提供了不正确的证书;相关错误类型应该（SHOULD）是"auth".
<payment-required/> -- 请求实体未被授权访问请求的服务，因为需要付费;相关错误类型应该（SHOULD）是"auth".
<recipient-unavailable/> -- 预定的接收者暂时不可用;相关错误类型应该（SHOULD）是"wait"(注意: 如果这样做会导致泄露预定接收者的网络可用性给一个未被授权了解此信息的实体，应用程序不应该（MUST NOT）返回这个错误).
<redirect/> -- 接收者或服务器重定向这个请求信息到另一个实体，通常是暂时的(这个错误节应该 （SHOULD）在<redirect/>元素的XML字符数据中包含一个预备的地址,它必须（MUST）是一个合法的JID); 相关的错误类型应该（SHOULD）是"modify".
<registration-required/> -- 请求实体未被授权访问请求的服务，因为需要注册;相关错误类型应该（SHOULD）是"auth".
<remote-server-not-found/> -- 在预定的接收者的全部或部分JID中的一个远程服务器或服务不存在;相关错误类型应该（SHOULD）是"cancel".
<remote-server-timeout/> -- 在预定的接收者（或需要完成的一个申请）的全部或部分JID中的一个远程服务器或服务无法在合理的时间内联系到;相关错误类型应该（SHOULD）是"wait".
<resource-constraint/> -- 服务器或接收者缺乏足够的系统资源来服务请求;相关错误类型应该（SHOULD）是"wait".
<service-unavailable/> -- 服务器或接收者目前无法提供被请求的服务;相关错误类型应该（SHOULD）是"cancel".
<subscription-required/> -- 请求实体未被授权访问能请求的服务，因为需要订阅;相关错误类型应该（SHOULD）是"auth".
<undefined-condition/> -- 错误条件不是本列表中定于的其他条件之一;任何错误类型可能和这个条件有关,并且它应该（SHOULD）仅用于关联一个应用程序定义的条件.
<unexpected-request/> -- 接收者或服务器理解这个请求但是不希望是在这个时间(比如,请求的顺序颠倒);相关错误类型应该（SHOULD）是"wait".

应用程序定义条件:

大家知道,一个应用程序可以（MAY）通过在错误元素里包含一个适当名字空间的字符素来提供应用程序定义的节错误信息. 应用程序定义的元素应该（SHOULD）补充或进一步限定一个已定义的元素. 因而,<error/>元素将包含两个或三个子元素:
   <iq type='error' id='some-id'>
     <error type='modify'>
       <bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
       <too-many-parameters xmlns='application-ns'/>
     </error>
   </iq>
   <message type='error' id='another-id'>
     <error type='modify'>
       <undefined-condition xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
       <text xml:lang='en' xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>
         Some special application diagnostic information...
       </text>
       <special-application-condition xmlns='application-ns'/>
     </error>
   </message>