RFC3920可扩展消息出席协议（XMPP）：核心 9 XML节

9．XML节
      TLS协商（5节）后，如果需要SASL协商（6节）与资源绑定（7节），XML节可通过流来发送。定义了三种XML节用于'jabber:client'与'jabber:server'命名空间：<message/>, <presence/>, and <iq/>。另外，这种节有五个通用属性。这些通用属性，像三种节的基本语义一样，都定义在此；与即时消息与表示应用相关的XML节的更详细信息在[XMPP-IM]中提供。

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

9．1．1 to
      ‘to’属性指定接收节的JID。
      在‘jabber:client’命名空间中，节应当处理‘to’属性，虽然，由服务器处理的从客户端到服务器端的节不应该拥有‘to’属性。
      在'jabber:server'命名空间中，节必须拥有‘to’属性；如果服务器收到一个不满足此限制的节，它必须产生一个<improper-addressing/>流错误条件并终止两个XML流与错误服务器的潜在连接。
      如果‘to’属性无效或不能连接，发现此事实的（通常是发送的或接收的服务器）实体必须返回一个合适的错误给发送者，设置错误节的‘from’属性为错误服务器提供的‘to’属性值。

9．1．2 from
      ‘from’属性指明发送者的IID。
      当服务器收到一个在由'jabber:client'命名空间认证的已授权流的上下文中的XML节，它必须做以下事件之一：
1） 验证客户端提供的‘from’属性值就是用于联合实体的已连接资源的值。
2） 加一个‘from’地址值给节，此节的值是裸JID（<node@domain>）或全JID（<node@domain/resource>），这些JID由服务器决定用于产生节的已联接资源（看地址决定（3.5节））。

        如果一个客户端试图发送‘from’属性并不匹配实体的已联接资源的XML节，服务器应该返回一个<invalid-from/>流错误给客户端。如果一个客户端试图通过一个流来发送一个还未授权的XML节，服务器应当返回一个<not-authorized/>流错误给客户端。如果产生了，这些条件都必须关闭流并终止潜在的TCP连接；这有助于阻止来自于欺诈客户端的否认服务攻击。
        当一个服务器产生一个来自于服务器本身的节，用于传送到一个已连接的客户端（例如：在由服务器代表客户端提供的数据存储服务的上下文中），节必须既（1）不包括‘from’属性或（2）包括‘from’属性，其值是帐户的裸JID（<node@domain>）或客户的全JID（<node@domain/resource>）。服务器不准发送给客户端一个不包括‘from’属性的节，它必须设想节是从服务器到已连接客户端。
        在'jabber:server'命名空间中，一个节必须处理一个‘from’属性；如果服务器收到不满足此限制的节，它必须产生一个<improper-addressing/>流错误条件。更进一步，包含在‘from’属性中的JID的域标识符部分必须匹配发送服务器（或任何已认证相关域，如发送服务器的主机名或其它由发送服务器已认证域）的主机名，当在SASL协商或回叫协商通信中；如果一个服务器收到一个不满足此约束的节，它必须产生一个<invalid-from/>流错误条件。这些条件都必须关闭流并终止潜在的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消息语义
      <message/>节种类可被看作“推”机制，一个实体推信息给其它实体，与EMAIL系统中发生的通信类似。所有消息节应该拥有‘to’属性，指定有意的消息接收者；根据接收到那样的一个节，服务器应该路由或传送它到有意的接收者（参考服务器处理用于相关XML节的通用路由与传送规则XML节的规则（10节））。

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

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

   Requesting                 Responding
     Entity                     Entity
   ----------                 ----------
       |                           |
       | <iq type='get' id='1'>    |
       | ------------------------> |
       |                           |
       | <iq type='result' id='1'> |
       | <------------------------ |
       |                           |
       | <iq type='set' id='2'>    |
       | ------------------------> |
       |                           |
       | <iq type='error' id='2'>  |
       | <------------------------ |
       |                           |

      为了加强这些语义，以下规则应用：
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响应节来响应；然而，如以上显示，请求实体可能发送另一个请求（如：一个类型为“set”的IQ，为了提供通过得到/结果对发现的所需的信息）。
5） 类型为“get”或“set”的IQ节必须包含一个并仅有一个子元素，指定特别的请求或响应语义。
6） 一个类型为“result”的IQ节必须包含0或一个子元素。
7） 类型为“error”类型的IQ节应当包含在相关“get”或“set”子元素中，并且，必须包含一个<error/>子元素；详细信息，参考节错误（9.3节）。

9．3 节错误
      节相关错误以类似流错误（4.7节）的方式处理。然而，不像流错误，节错误不可是不可恢复的；因此，暗含相关源发送者行为的错误节能按顺序纠正错误。

9．3．1 规则
      以下规则应用于节相关错误：
1） 检测相关节错误条件的接收或处理实体必须返回给发送实体一个同种节（消息，出席或IQ），它的‘type’属性被设置成值“error”（那样的节在此被称为“错误节”）。
2） 产生错误节的实体应当包含被送的源XML，为了发送者能够检测，并且，如果必要的话，在试图重送前纠正XML。
3） 一个错误节必须包含一个<error/>子元素。
4） 一个<error/>子元素不准被包括，如果‘type’属性有不止一个“错误”值（或无‘类型’属性）。
5） 接收一个错误节的实体不准响应带有进一步错误节的节；这有助于阻止循环。

9．3．2 语法
      节相关错误语法如下：
   <stanza-kind to='sender' type='error'>
     [RECOMMENDED to include sender XML here]
     <error type='error-type'>
       <defined-condition xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
       <text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'
             xml:lang='langcode'>
         OPTIONAL descriptive text
       </text>
       [OPTIONAL application-specific condition element]
     </error>
   </stanza-kind>

      节种类是消息、出席或iq之一。
<error/>元素的‘type’属性值必须是以下之一：
*cancel——不重试（错误不可恢复）
*continue——进行（仅是一个警告条件）
*modify——改变数据发送后重试
*auth——提供信任后重试
*wait——等待之后重试（错误是临时的）

      <error/>元素：
      必须包含一个子元素，此子元素与以下指定的已定义的节错误条件一致；此元素必须被'urn:ietf:params:xml:ns:xmpp-stanzas'命名空间所认证。
      可能包含<text/>子元素，此子元素包含XML字符数据，用于描绘更细节的错误；此元素必须被'urn:ietf:params:xml:ns:xmpp-stanzas'命名空间所认证，并且应该拥有一个'xml:lang'属性。
      可能包含一个子元素，用于特殊-应用错误条件；此元素必须由一个已定义-应用命名空间认证，并且，它的结构由此命名空间定义。

      <text/>元素是可选的。如果包括在内，它应当仅用于提供描述性或诊断性信息，这些信息用于补充已定义条件或特殊-应用条件的意思。它不应当由应用程序性的描述。它不应当用作向用户表达的错误信息，但可能显示除与包含条件元素（或元素们）相关的错误消息。

      最后，为维护向后兼容性，此方案（在[XMPP-IM]中指定的）允许可选的在<error/>元素中包含‘code’属性。

9．3．3 已定义条件
      以下条件被定义用于节错误。

<bad-request/>——发送者已发送畸形的或不能被处理的（例如，一个包含未识别‘type’属性值的IQ节）XML；相关错误类型应当是“modify”。

<conflict/>——访问不被授权，因为一个现存资源或会话以同样名字或地址存在；相关错误类型应当是“cancel”。

<feature-not-implemented/>——被请求特征未被接收者或服务器实现，并且因此不能被处理；相关错误类型应当是“cancel”。

<forbidden/>——请求实体不拥有执行行为的所需许可；相关错误类型应当是“auth”。

<gone/>——接收者或服务器不在以此地址联系（错误节可能包含一个新地址在<gone/>元素的XML字符数据中）；相关错误类型应当是“modify”。

<internal-server-error/>——服务器不能处理节，因为错误配置或一个另外-未定义内部服务器错误；相关错误类型应当是“wait”。

<item-not-found/>——JID地址或被请求项不能被发现；相关错误类型应当是“cancel”。

<jid-malformed/>——已提供的发送实体或与一个XMLL地址（例：‘to’属性值）通信或其它方面（例：资源标识符）与地址方案（3节）中定义的语法不符；相关错误类型应当是“modify”。

<not-acceptable/>——接收者或服务器理解请求，但拒绝处理它，因为它不满足由接收者或服务器（例：消息中相关可接受字的本地策略）所定义的标准；相关错误类型应当是“modify”。

<not-allowed/>——接收者或服务器不允许任何实体执行动作；相关错误类型应当是“cancel”。

<not-authorized/>——发送者必须在被允许执行动作前提供合适的信任，或已经提供不合适的信任；相关错误类型应当是“auth”。

<payment-required/>——请求实体未授权去访问被需求服务，因为需要付费；相关错误类型应当是“auth”。

<recipient-unavailable/>——有意的接收者临时不可用；相关错误类型应当是“wait”（注：一个应用不准返回此错误，如果这样做将提供关于意向接收 者对未授权知道此类信息的实体的网络可利用性信息）。

<redirect/>——接收者或服务器为此信息重定向请求到其他实体，通常是临时的（错误节应当包含可替换地址，必须是一个有效的JID，在<redirect/>元素的XML字符数据中）；相关错误类型应当是“modify”。

<registration-required/>——请求实体未被授权访问所请求服务，因为需要注册；相关错误类型应当是“auth”。

<remote-server-not-found/>——一个指定作为意向接收者的部分或全部的JID的远程服务器或服务不存在；相关错误类型应当是“cancel”。

<remote-server-timeout/>——一个指定作为意向接收者（或被请求去执行一个请求）的部分或全部的JID的远程服务器或服务不能在一个合理的时间内被联系到；相关错误类型应当是“wait”。

<resource-constraint/>——服务器或接收者缺少必要的系统资源去服务请求；相关错误类型应当是“wait”。

<service-unavailable/>——服务器或接收者当前并不提供所请求的服务；相关错误类型应当是“cancel”。

<subscription-required/>——请求实体不被授权访问被请求服务，因为需要订阅；相关错误类型应当是“auth”。

<undefined-condition/>——错误条件并不是此列表中由其它条件定义的那些之一；任何错误类型可能与此条件相关，并且，它应当仅用于与一个特殊-应用条件相连。

<unexpected-request/>——接收者或服务器理解请求，但此时（例：请求无序/请求不在状态）并不期望它；相关错误类型应当是“wait”。

9．3．4 特殊-应用条件
      像所知道的，一个应用可能靠包含一个错误元素中的合适的-命名空间的子元素来提供特殊-应用节错误信息。特殊-应用元素应当补充或进一步认证一个已定义元素。因此，<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>