XMPP翻译：RFC 3920[9]（Chapter11-13）
本篇翻译了XMPP核心协议RFC 3920的第十一、十二及十三章。
内容提要：
XML Usage within XMPP //处理XML节的服务器端规则
- 限制
- XML命名空间名和前缀
- 流命名空间
- 缺省命名空间
- 回拨命名空间
- 验证
- 包含文本声名
- 字符编码
Core Compliance Requirements //
- 服务器
- 客户端
Internationalization Considerations //国际化考虑
11. XML Usage within XMPP
11.1. 限制
XMPP是用于传输以实现近乎实时的交换结构化信息得XML元素的简化的、专用的协议。由于XMPP不需要解析任意的、完全的XML文档，所以不要求XMPP必须支持XML的全部特性。特别的说要应用以下限制：
在生成XML时，XMPP实现MUST NOT将以下元素放入XML流：
- 注释
- 处理说明
- 内部或外部的DTD子集
- 除了预定义外的内部及外部实体引用
- 包含与预定义实体相关的非转义字符的字符数据或属性值；这些字符MUST被转义
在处理XML时，如果XMPP实现接收到了这类受限制的XML数据，则MUST忽略这些数据。
11.2. XML命名空间名和前缀
XML命名空间[XML‑NAMES]被用于所有的符合XMPP的XML，以创建数据所有权的严格界限。命名空间的基本功能是分开那些结构上混杂在一起的XML元素的符号集。确保在XMPP中，符合XMPP的XML是namespace-aware的，使任何合法的XML能够与任何其他的数据元素在结构上混杂在一起。XML命名空间名和前缀的规定定义在以下的子章节中。
11.2.1. 流命名空间
所有的XML流header中都需要声名流的命名空间。流的命名空间名MUST是'http://etherx.jabber.org/streams'。<stream/>元素的元素名和它的字元素<features/>和<error/>在任何实例中都MUST由该命名空间前缀限定。程序SHOULD只能给这些元素生成'stream:'前缀，而且因为历史原因MAY只接受'stream:'前缀。
11.2.2. 缺省命名空间
为了定义根元素合法的第一级子元素，需要声名一个缺省的命名空间且用于所有的XML流。初始流和响应流的命名空间声名MUST是一样的，两个流要有一致的限定。缺省的命名空间应用于流和流中发送的节(除非明确的由其他命名空间限定，或是流命名空间的前缀或回拨命名空间)。
服务器实现MUST支持下面的两个缺省命名空间(由于历史原因，有一些实现可能只支持这两个缺省的命名空间):
- jabber:client -- 当流用于客户端与服务器间通信时声名此缺省命名空间
- jabber:server -- 当流用于两服务器间通信时声名此缺省命名空间
客户端实现MUST支持'jabber:client'命名空间，且由于历史原因MAY只支持此命名空间。
如果缺省命名空间是'jabber:client'或'jabber:server'，实现MUST NOT给在命名空间里的元素生成命名空间前缀。实现SHOULD NOT给在内容命名空间里的元素生成前缀，除了'jabber:client'和'jabber:server'限定的元素(这与流相反)。
注意：'jabber:client'和'jabber:server'命名空间几乎相同，但是用于不同的上下文中(C2S的通信用'jabber:client' ，S2S的通信用'jabber:server')。两者唯一的不同点是在'jabber:client'中发送的节的'to'和'from'属性是可选的，而在'jabber:server'中发送的节是需要它们的。如果一个合法的实现接受由'jabber:client'和'jabber:server'命名空间限定的流， 它必须支持三种核心节类型(message, presence, and IQ)的公共属性和基本语义。
11.2.3. 回拨命名空间
服务器回拨中使用的所有元素都需要声名一个回拨命名空间。回拨命名空间名MUST是'jabber:server:dialback'。所有由这个命名空间限定的元素都MUST加前缀。实现SHOULD只给这些元素生成'db:'前缀，并且可能只接受'db:'前缀。
11.3. 验证
除了关注有关'jabber:server'命名空间里节的'to'和'from'地址，服务器没有责任验证这些传向客户端或另一个服务器的XML元素；实现MAY选择只提供验证过的数据元素，但是这是可选的(尽管实现MUST NOT接受不规范的XML)。客户端SHOULD NOT 依靠发送不符合模式的数据的能力，且SHOULD忽略到来的XML流中任何不规范的元素或属性。是否验证XML流和节是可选的，在这里提及该模式仅为了描述。
11.4. 包含文本声名
实现SHOULD在发送流header前先发送一个文本声名。应用程序MUST遵循[XML]中有关那些包含文本声名的情况的规则。
11.5. 字符编码
实现MUST支持通用字符集(ISO/IEC 10646-1 [UCS2])字符转换为UTF-8(RFC 3629 [UTF‑8])，RFC 2277 [CHARSET]中有规定。 实现MUST NOT尝试使用任何其它的字符集。
12. Core Compliance Requirements
这章总结了XMPP的那些为了合法的实现，服务器及客户端所必须支持的特殊方面，同时也应该支持附加协议。为了compliance的目的，我们描绘了核心协议（必须被任何服务器或客户端支持，不管是否特定的应用）和即时通信协议（只需建立在核心协议上的即时通信和出席应用支持）的差别。Compliance要求应用于这章中指定的所有服务器和客户端；用于即时通信服务器和客户端的Compliance要求，在[XMPP-IM]的相应章节。
12.1. Servers
除所有已定义的关于安全、XML用法及国际化的要求外，服务器MUST支持下面的核心协议，以to be considered compliant：
- [NAMEPREP]的应用，用于地址的[STRINGPREP]的Resourceprep profiles(包括保证域标识符是[IDNA]中规范的国际化的域名)
- XML流，包括Use of TLS、Use of SASL和Resource Binding
- 三种定义的节类型的语义(i.e., <message/>, <presence/>, and <iq/>)
- 产生与流、TLS、SASL及XML节相关的错误的语法和语义
另外，服务器MAY支持以下的核心协议：
- 服务器回拨
12.2. Clients
客户端MUST支持下面的核心协议，以to be considered compliant：
- XML流，包括Use of TLS、Use of SASL和Resource Binding
- 三种定义的节类型的语义(i.e., <message/>, <presence/>, and <iq/>)
- 处理与流、TLS、SASL及XML节相关的错误的语法和语义
另外，服务器SHOULD支持以下的核心协议：
- 产生[NAMEPREP]和[STRINGPREP]的Resourceprep profiles能够成功的应用的地址
13. Internationalization Considerations
XML流MUST编码为UTF-8。 Stream Attributes一章中指定，XML流SHOULD包含一个'xml:lang'属性，这被当作通过流传送（打算呈现给一个用户）的任何XML字符的缺省语言。xml:lang中指定，如果XML节中包括了要呈现给用户的XML字符数据，那么这个XML节SHOULD包含一个'xml:lang'属性。服务器SHOULD代表连接的实体应用缺省的'xml:lang'属性给它要路由或分发的节，且MUST NOT编辑或删除从其它实体接收来的XML节的'xml:lang'属性。
