xmpp协议10
XML Stanzas //XML节
1. Common Attributes //共同的属性
2. Basic Semantics //基本的语义
3. Stanza Errors //节错误
在TLS协商后（假定希望TLS协商），如果需要SASL协商和资源绑定，可以通过流发送XML节。我们定义为'jabber:client' 和'jabber:server' 命名空间定义了三种类型的XMl节：<message/>、<presence/>、<iq/>。另外，这些节有五个通用的属性。这里定义了这些通用属性以及这些节类型的基本语义；[XMPP-IM]中提供有关（涉及到XMPP应用程序的）XML节的更多详细的信息。
9.1. 共同的属性
下面的五个属性通用于message、presence和IQ节：
9.1.1. to
‘to’属性指定了节所要的接收者的JID
在‘jabber:client’命名空间里，节应该（SHOULD）要持有一个‘to’属性，虽然从客户端发送到服务器，让服务器处理的节（例如，为了广播到其它实体而发送的presence）不应该（SHOULD NOT）有‘to’属性。
在‘jabber:server’命名空间里，节（MUST）持有一个‘to’属性；如果服务器接收到了一个不符合该规定的节，他必须（MUST）生成一个<improper-addressing/>流错误信息，并且终止与出错服务器的XML流和TCP连接。
如果‘to’属性值无效或无法连接，意识到这个错误的实体（）必须（MUST）返回一个适当的错误报告给发送者，将报告（一个节）的‘from’属性设置成出错节的‘to’属性值。
9.1.2. from
‘from’属性指定了发送者的JID。
当服务器接收到在‘jabber:client’命名空间下的已认证的流的上下文中的XML节，它做下列事件之一：
1. 确认客户端提供的‘from’属性值是已关联实体的已连接的资源
2. add a 'from' address to the stanza whose value is the bare JID (<node@domain>) or the full JID (<node@domain/resource>) determined by the server for the connected resource that generated the stanza (see Determination of Addresses)
如果客户端尝试发送一个XML节，而该节的‘from’属性值与实体的连接资源不符，服务器应该（SHOULD）返回流错误到客户端。如果客户端尝试通过还未认证的流发送XML节，服务器应该（SHOULD）返回一个<not-authorized/>流错误到客户端。如果发生了，这些情形中，都必须（MUST）关闭流并终止underlyingTCP连接；这有助于在流氓客户端发起的攻击时预先拒绝服务。
当服务器自身产生一个节发送到已连接的客户端（例如，服务器代表提供的数据存储服务的上下文中），该节必须（MUST）要么不包含 ‘from’属性，要么所包含的‘from’的属性值是the account's bare JID (<node@domain>) or client's full JID (node@domain/resource)。当节是由服务器自身产生的，服务器则禁止（MUST NOT）给客户端发送不带有‘from’属性的此类节。当客户端接收到不包含‘from’属性的节，它必须（MUST）假设该节是从它所连接的服务器发来的。
在‘jabber:server’命名空间里，节必须（MUST）持有‘from’属性；如果服务器接收到不满足这个约束的节时，它必须（MUST）产生一个<improper-addressing/>流错误报告。另外，‘from’属性中包含的JID的域标识符部分必须（MUST）与发送该JID的服务器（或者在其中的任何有效域，如发送服务器主机名的一个有效的子域或发送服务器掌控的的其它有效的域）的主机名相匹配，与SASL协商或回拨协商时一样；如果服务器接收到了不满足这个条件的节时，它必须（MUST）产生一个<invalid-from/>流错误报告。这些情形中，都必须（MUST）关闭流并终止underlyingTCP连接；这有助于在流氓服务器发起的攻击时预先拒绝服务。
9.1.3. id
可选的‘id’属性可以被发送实体用于内在的跟踪（internal tracking）它所发送和接收的节（尤其用于跟踪IQ节的内在语义中的请求/响应交互）。在一个域中或是一个流中，把‘id’属性值设为全球唯一也是可选的。IQ节的语义强加了额外的限制；参见IQ语义。
9.1.4. type
‘type’属性定义了与message、presence或IQ节的意图或上下文有关的详细信息。‘type’属性允许的特定值因是messge 或是presence，或是IQ而变化；message和presence节的这些值特定于即时信息和即时出席，所以定义在[XMPP-IM]中，而IQ 节的值指定了在结构化的请求/响应“会话”中的IQ节的作用，因此被定义在[IQ语义]中。与这三种节有共同点的唯一的‘type’值是‘error’；参见节错误。
9.1.5. xml:lang
若节包含了XML字符数据，这数据是要呈现给用户的，那么这节应该（SHOULD）要有个‘xml:lang’属性（RFC 2277[CHARSET]中有说明，“为用户国际化”）。‘xml:lang’属性值定义了这些用户可读的XML字符数据的缺省语言，它可以（MAY）被特定子元素的‘xml:lang’属性值覆盖。倘若节没有‘xml:lang’属性，针对这个数据的实现（implementation）必须（MUST）假设缺省语言是流属性中定义的缺省语言（在前面的“流属性”中有详细说明）。‘xml:lang’属性值必须（MUST）是NMTOKEN，而且必须（MUST）符合RFC 3066[LANGTAGS]中的规定。
9.2. 基本的语义
9.2.1. Message的语义
<message/>节类型可以看做事一个“push”机制，实体通过它将信息push给其它实体，这类似于发生在email系统中的通信。所有的message节应该（SHOULD）要有‘to’属性，用于指定message目标容器；在接收到这样一个节后，服务器应该（SHOULD）将其路由或递送到目标容器（参见Server Rules for Handling XML Stanzas for general routing and delivery rules related to XML stanzas）。
9.2.2. Presence的语义
<presence/>元素可以看成是一个基础的广播或“publish-subscribe”机制，其它众多的实体通过此机制得到它们订阅的实体的信息(即，网络的可用性信息)。一般来说，发布者（实体）应该（SHOULD）发送一个不带‘to’属性的presence节，此时，与此实体连接的服务器应该（SHOULD）广播或多元化该节给所有的订阅者（实体）。然而发布者也可以（MAY）发送带有‘to’属性的节，此时，服务器则应该（SHOULD）路由或递送此节到目标容器。参见Server Rules for Handling XML Stanzas for general routing and delivery rules related to XML stanzas和[XMPP?IM] for presence-specific rules in the context of an instant messaging and presence application。
9.2.3. IQ的语义
Info/Query或IQ，使一个请求/响应机制，某些方面类似于HTTP。IQ的语义让实体能够向其它实体发送请求，以及从其它实体接收响应。请求/响应数据的内容定义在IQ节的一个直接子元素的命名空间声明里，请求实体通过使用‘id’属性跟踪这个请求/响应交互。因此，IQ节的交互遵循结构化数据交互的通用模式，像get/result或 set/result（尽管也可能会返回适当的错误）：
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’ 属性是必需的（REQUIRED）。其值必须（MUST）是以下之一：
* get -- The stanza is a request for information or requirements.
* set -- The stanza provides required data, sets new values, or replace* **isting values.
* result -- The stanza is a response to a successful get or set request.
* error -- An error has occurred regarding processing or delivery of a previously-sent get or set (see Stanza Errors).
3. 接收到‘type’为“get”或“set”的IQ节的实体必须（MUST）回复type为“result”或“error”的IQ响应（响应必须保持请求的‘ID’属性）。
4. 接收到‘type’为“result”或“error”的IQ节的实体必须（MUST）回复type为“result”或“error”的更深一层次的IQ 响应；然而，正如前面所说的，发送请求的实体可以（MAY）发送其它请求（例如，一个type为“set”的节，用来提供那些通过get/result对所发现的被需要的信息）。
5. type为“get”或“set”的IQ节，必须（MUST）包含一个且仅有一个指定特定的request或response语义的子元素。
6. type为“result”必须（MUST）是包含0/1个子元素。
7. type为“error”应该（SHOULD）包含一个与“get”或“set”相关的节中的子元素，且必须（MUST）包含一个<error/>子元素; 详见Stanza Errors.
1. Common Attributes //共同的属性
2. Basic Semantics //基本的语义
3. Stanza Errors //节错误
在TLS协商后（假定希望TLS协商），如果需要SASL协商和资源绑定，可以通过流发送XML节。我们定义为'jabber:client' 和'jabber:server' 命名空间定义了三种类型的XMl节：<message/>、<presence/>、<iq/>。另外，这些节有五个通用的属性。这里定义了这些通用属性以及这些节类型的基本语义；[XMPP-IM]中提供有关（涉及到XMPP应用程序的）XML节的更多详细的信息。
9.1. 共同的属性
下面的五个属性通用于message、presence和IQ节：
9.1.1. to
‘to’属性指定了节所要的接收者的JID
在‘jabber:client’命名空间里，节应该（SHOULD）要持有一个‘to’属性，虽然从客户端发送到服务器，让服务器处理的节（例如，为了广播到其它实体而发送的presence）不应该（SHOULD NOT）有‘to’属性。
在‘jabber:server’命名空间里，节（MUST）持有一个‘to’属性；如果服务器接收到了一个不符合该规定的节，他必须（MUST）生成一个<improper-addressing/>流错误信息，并且终止与出错服务器的XML流和TCP连接。
如果‘to’属性值无效或无法连接，意识到这个错误的实体（）必须（MUST）返回一个适当的错误报告给发送者，将报告（一个节）的‘from’属性设置成出错节的‘to’属性值。
9.1.2. from
‘from’属性指定了发送者的JID。
当服务器接收到在‘jabber:client’命名空间下的已认证的流的上下文中的XML节，它做下列事件之一：
1. 确认客户端提供的‘from’属性值是已关联实体的已连接的资源
2. add a 'from' address to the stanza whose value is the bare JID (<node@domain>) or the full JID (<node@domain/resource>) determined by the server for the connected resource that generated the stanza (see Determination of Addresses)
如果客户端尝试发送一个XML节，而该节的‘from’属性值与实体的连接资源不符，服务器应该（SHOULD）返回流错误到客户端。如果客户端尝试通过还未认证的流发送XML节，服务器应该（SHOULD）返回一个<not-authorized/>流错误到客户端。如果发生了，这些情形中，都必须（MUST）关闭流并终止underlyingTCP连接；这有助于在流氓客户端发起的攻击时预先拒绝服务。
当服务器自身产生一个节发送到已连接的客户端（例如，服务器代表提供的数据存储服务的上下文中），该节必须（MUST）要么不包含 ‘from’属性，要么所包含的‘from’的属性值是the account's bare JID (<node@domain>) or client's full JID (node@domain/resource)。当节是由服务器自身产生的，服务器则禁止（MUST NOT）给客户端发送不带有‘from’属性的此类节。当客户端接收到不包含‘from’属性的节，它必须（MUST）假设该节是从它所连接的服务器发来的。
在‘jabber:server’命名空间里，节必须（MUST）持有‘from’属性；如果服务器接收到不满足这个约束的节时，它必须（MUST）产生一个<improper-addressing/>流错误报告。另外，‘from’属性中包含的JID的域标识符部分必须（MUST）与发送该JID的服务器（或者在其中的任何有效域，如发送服务器主机名的一个有效的子域或发送服务器掌控的的其它有效的域）的主机名相匹配，与SASL协商或回拨协商时一样；如果服务器接收到了不满足这个条件的节时，它必须（MUST）产生一个<invalid-from/>流错误报告。这些情形中，都必须（MUST）关闭流并终止underlyingTCP连接；这有助于在流氓服务器发起的攻击时预先拒绝服务。
9.1.3. id
可选的‘id’属性可以被发送实体用于内在的跟踪（internal tracking）它所发送和接收的节（尤其用于跟踪IQ节的内在语义中的请求/响应交互）。在一个域中或是一个流中，把‘id’属性值设为全球唯一也是可选的。IQ节的语义强加了额外的限制；参见IQ语义。
9.1.4. type
‘type’属性定义了与message、presence或IQ节的意图或上下文有关的详细信息。‘type’属性允许的特定值因是messge 或是presence，或是IQ而变化；message和presence节的这些值特定于即时信息和即时出席，所以定义在[XMPP-IM]中，而IQ 节的值指定了在结构化的请求/响应“会话”中的IQ节的作用，因此被定义在[IQ语义]中。与这三种节有共同点的唯一的‘type’值是‘error’；参见节错误。
9.1.5. xml:lang
若节包含了XML字符数据，这数据是要呈现给用户的，那么这节应该（SHOULD）要有个‘xml:lang’属性（RFC 2277[CHARSET]中有说明，“为用户国际化”）。‘xml:lang’属性值定义了这些用户可读的XML字符数据的缺省语言，它可以（MAY）被特定子元素的‘xml:lang’属性值覆盖。倘若节没有‘xml:lang’属性，针对这个数据的实现（implementation）必须（MUST）假设缺省语言是流属性中定义的缺省语言（在前面的“流属性”中有详细说明）。‘xml:lang’属性值必须（MUST）是NMTOKEN，而且必须（MUST）符合RFC 3066[LANGTAGS]中的规定。
9.2. 基本的语义
9.2.1. Message的语义
<message/>节类型可以看做事一个“push”机制，实体通过它将信息push给其它实体，这类似于发生在email系统中的通信。所有的message节应该（SHOULD）要有‘to’属性，用于指定message目标容器；在接收到这样一个节后，服务器应该（SHOULD）将其路由或递送到目标容器（参见Server Rules for Handling XML Stanzas for general routing and delivery rules related to XML stanzas）。
9.2.2. Presence的语义
<presence/>元素可以看成是一个基础的广播或“publish-subscribe”机制，其它众多的实体通过此机制得到它们订阅的实体的信息(即，网络的可用性信息)。一般来说，发布者（实体）应该（SHOULD）发送一个不带‘to’属性的presence节，此时，与此实体连接的服务器应该（SHOULD）广播或多元化该节给所有的订阅者（实体）。然而发布者也可以（MAY）发送带有‘to’属性的节，此时，服务器则应该（SHOULD）路由或递送此节到目标容器。参见Server Rules for Handling XML Stanzas for general routing and delivery rules related to XML stanzas和[XMPP?IM] for presence-specific rules in the context of an instant messaging and presence application。
9.2.3. IQ的语义
Info/Query或IQ，使一个请求/响应机制，某些方面类似于HTTP。IQ的语义让实体能够向其它实体发送请求，以及从其它实体接收响应。请求/响应数据的内容定义在IQ节的一个直接子元素的命名空间声明里，请求实体通过使用‘id’属性跟踪这个请求/响应交互。因此，IQ节的交互遵循结构化数据交互的通用模式，像get/result或 set/result（尽管也可能会返回适当的错误）：
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’ 属性是必需的（REQUIRED）。其值必须（MUST）是以下之一：
* get -- The stanza is a request for information or requirements.
* set -- The stanza provides required data, sets new values, or replace* **isting values.
* result -- The stanza is a response to a successful get or set request.
* error -- An error has occurred regarding processing or delivery of a previously-sent get or set (see Stanza Errors).
3. 接收到‘type’为“get”或“set”的IQ节的实体必须（MUST）回复type为“result”或“error”的IQ响应（响应必须保持请求的‘ID’属性）。
4. 接收到‘type’为“result”或“error”的IQ节的实体必须（MUST）回复type为“result”或“error”的更深一层次的IQ 响应；然而，正如前面所说的，发送请求的实体可以（MAY）发送其它请求（例如，一个type为“set”的节，用来提供那些通过get/result对所发现的被需要的信息）。
5. type为“get”或“set”的IQ节，必须（MUST）包含一个且仅有一个指定特定的request或response语义的子元素。
6. type为“result”必须（MUST）是包含0/1个子元素。
7. type为“error”应该（SHOULD）包含一个与“get”或“set”相关的节中的子元素，且必须（MUST）包含一个<error/>子元素; 详见Stanza Errors.
