xmpp协议11

9.3.  节错误

节有关的错误（stanza-related errors）以类似于处理流错误的方式处理。可是，与流错误不同的是，节错误是可恢复的；因此节错误包含了与初始实体为了挽回错误而携带的动作（actions）相关的信息。

9.3.1.  规则

下列规则应用于stanza-related errors：

    * The receiving or processing entity that detects an error condition in relation to a stanza MUST return to the sending entity a stanza of the same kind (message, presence, or IQ), whose 'type' attribute is set to a value of "error" (such a stanza is called an "error stanza" herein).
    * The entity that generates an error stanza SHOULD include the original XML sent so that the sender can inspect and, if necessary, correct the XML before attempting to resend.
    * An error stanza MUST contain an <error/> child element.
    * An <error/> child MUST NOT be included if the 'type' attribute has a value other than "error" (or if there is no 'type' attribute).
    * An entity that receives an error stanza MUST NOT respond to the stanza with a further error stanza; this helps to prevent looping.

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>

节类型是message、presence或iq中的一种。

<error/>元素的‘type’属性值必须（MUST）是以下之一：

    * cancel -- 不要再尝试(the error is unrecoverable)
    * continue -- 继续进行 (the condition was only a warning)
    * modify -- 改变发送的数据后再试
    * auth -- 提供凭证后再试
    * wait -- 等待一段时间后在试(the error is temporary)

<error/>元素：

    * 必须包含一个 与下面定义的节错误情形之一相应的子元素；且该元素必须有‘urn:ietf:params:xml:ns:xmpp-stanzas’命名空间限定。
    * 可以包含一个<text/>子元素，含有用于描述详细的错误信息的XML字符数据；该元素必须（MUST）由‘urn:ietf:params:xml:ns:xmpp-stanzas’命名空间限定修饰，且应该（SHOULD）要有一个‘xml:lang’属性。
    * 可以包含一个子元素用于application-specific的错误情形；该元素必须（MUST）由一个application-defined命名空间限定修饰，而且它的结构也由此命名空间定义。

<text/>元素是可选的。若是包含了，它应该仅用于提供描述性的或诊断性的信息，来补充定义的情形或application- specific 的情形的信息。应用程序不应该（SHOULD NOT）自动的解释它。它也不应该（SHOULD NOT）被用做呈现给用户的错误信息 ，但是可以指示除与已包括的元素相关的错误信息之外的信息。

最后，我了保持向后的兼容性，该模式（定义在[XMPP?IM]中）允许在<error/>元素中包含一个可选的‘code’属性 。

9.3.3.  定义的情形

以下是为节错误定义的情形。

    * <bad-request/> -- the sender has sent XML that is malformed or that cannot be processed (e.g., an IQ stanza that includes an unrecognized value of the 'type' attribute); the associated error type SHOULD be "modify".
    * <conflict/> -- access cannot be granted because an existing resource or session exists with the same name or address; the associated error type SHOULD be "cancel".
    * <feature-not-implemented/> -- the feature requested is not implemented by the recipient or server and therefore cannot be processed; the associated error type SHOULD be "cancel".
    * <forbidden/> -- the requesting entity does not possess the required permissions to perform the action; the associated error type SHOULD be "auth".
    * <gone/> -- the recipient or server can no longer be contacted at this address (the error stanza MAY contain a new address in the XML character data of the <gone/> element); the associated error type SHOULD be "modify".
    * <internal-server-error/> -- the server could not process the stanza because of a misconfiguration or an otherwise-undefined internal server error; the associated error type SHOULD be "wait".
    * <item-not-found/> -- the addressed JID or item requested cannot be found; the associated error type SHOULD be "cancel".
    * <jid-malformed/> -- the sending entity has provided or communicated an XMPP address (e.g., a value of the 'to' attribute) or aspect thereof (e.g., a resource identifier) that does not adhere to the syntax defined in Addressing Scheme; the associated error type SHOULD be "modify".
    * <not-acceptable/> -- the recipient or server understands the request but is refusing to process it because it does not meet criteria defined by the recipient or server (e.g., a local policy regarding acceptable words in messages); the associated error type SHOULD be "modify".
    * <not-allowed/> -- the recipient or server does not allow any entity to perform the action; the associated error type SHOULD be "cancel".
    * <not-authorized/> -- the sender must provide proper credentials before being allowed to perform the action, or has provided improper credentials; the associated error type SHOULD be "auth".
    * <payment-required/> -- the requesting entity is not authorized to access the requested service because payment is required; the associated error type SHOULD be "auth".
    * <recipient-unavailable/> -- the intended recipient is temporarily unavailable; the associated error type SHOULD be "wait" (note: an application MUST NOT return this error if doing so would provide information about the intended recipient's network availability to an entity that is not authorized to know such information).
    * <redirect/> -- the recipient or server is redirecting requests for this information to another entity, usually temporarily (the error stanza SHOULD contain the alternate address, which MUST be a valid JID, in the XML character data of the <redirect/> element); the associated error type SHOULD be "modify".
    * <registration-required/> -- the requesting entity is not authorized to access the requested service because registration is required; the associated error type SHOULD be "auth".
    * <remote-server-not-found/> -- a remote server or service specified as part or all of the JID of the intended recipient does not exist; the associated error type SHOULD be "cancel".
    * <remote-server-timeout/> -- a remote server or service specified as part or all of the JID of the intended recipient (or required to fulfill a request) could not be contacted within a reasonable amount of time; the associated error type SHOULD be "wait".
    * <resource-constraint/> -- the server or recipient lacks the system resources necessary to service the request; the associated error type SHOULD be "wait".
    * <service-unavailable/> -- the server or recipient does not currently provide the requested service; the associated error type SHOULD be "cancel".
    * <subscription-required/> -- the requesting entity is not authorized to access the requested service because a subscription is required; the associated error type SHOULD be "auth".
    * <undefined-condition/> -- the error condition is not one of those defined by the other conditions in this list; any error type may be associated with this condition, and it SHOULD be used only in conjunction with an application-specific condition.
    * <unexpected-request/> -- the recipient or server understood the request but was not expecting it at this time (e.g., the request was out of order); the associated error type SHOULD be "wait".

9.3.4.  特定应用的情形

如我们说知道的，应用程序可以（MAY）通过在错误元素中包含一个由适当的命名空间限定的子元素，提供特定应用（application- specific）的节错误信息。这个application-specific元素应该（SHOULD）补充或更进一步的限定一个定义的元素。因此，元素将会包含2、3个子元素：

<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>