随笔- 1  评论- 21  文章- 16 

XMPP翻译:RFC 3920[9](Chapter11-13)

本篇翻译了XMPP核心协议RFC 3920的第十一、十二及十三章。

内容提要

XML Usage within XMPP //处理XML节的服务器端规则

    1. 限制
    2. XML命名空间名和前缀 
      1. 流命名空间 
      2. 缺省命名空间
      3. 回拨命名空间
    3. 验证
    4. 包含文本声名
    5. 字符编码

Core Compliance Requirements //

  1. 服务器 
  2. 客户端

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'属性。

posted on 2006-11-30 15:45 Hunts.C 阅读(...) 评论(...) 编辑 收藏