XMPP 3920 最靠谱的中文翻译文档（六）

XMPP 3920 最靠谱的中文翻译文档（六）

2009-10-17 19:58

10． 处理XML节的服务器规则        兼容服务器实现必须确保有序处理任两实体间的XML节。 超出有序处理的需求，每个服务器实现将包含它自己的“传送树”用于处理它所接收的节。那样的一个树决定是否一个节需要被路由到其它域，内部处理，或传送到与被连节点相关的资源。以下规则应用： 10．1 无‘to’地址        如果节拥有无‘to’属性，服务器应当代表发送它的实体处理它。因为所有从其它服务器收到的节必须拥有一个‘to’属性，此规则仅应用于从一个连到服务器的已注册实体（如客户端）收到的节。如果服务器收到一个无‘to’属性的出席节，服务器应当广播它到被订阅到发送实体的出席实体，如果可利用的话（用于定义在[XMPP-IP]即时消息与表示应用的出席广播的语义。）如果服务器接收一个类型为“get”或“set”的没有‘to’属性的IQ节，并且它理解认证节内容的命名空间，它必须也能代表发送实体处理节或返回给发送实体（在“process”意思处被认证命名空间的语义决定）一个错误。 10．2 外部域        如果JID的域标识符部分的主机包含在‘to’属性中并不匹配服务器本身的已配置主机名或子域中的已配置主机之一，服务器应当路由节到外部域（服从本地服务提供与相关内部域通信的安全策略）。有两种可能情况：        一个服务器到服务器流已在两域间存在：发送者的服务器为现存流的外部域路由节到已授权服务器。        两域间存在无主机到主机流：发送者的服务器（1）解析外部域（定义在以下服务器到服务器通信（节14。4））的主机名，（2）在两域间（定义在如下使用TLS（节5）并且使用SASL（节6））协商服务器到服务器的流，并（3）为通过新近-建立的流的外部域路由节到授权服务器。        如果路由到接收者的服务器不成功，发送者的服务器必须返回一个错误给发送者；如果接收者的服务器能被联系但被接收者的服务器传送到接收者是不成功的，接收者的服务器必须经由发送者的服务器返回一个错误给发送者。 10．3 子域        如果包含在‘to’属性中的JID域标识符部分的主机名匹配服务器本身已配置主机名之一的子域，服务器必须也处理节本身或路由节到一个特别的对那个子域（如果子域被配置）有责任的服务，或返回一个错误给发送者（如果子域不被配置）。 10．4 仅有域或特别资源        如果包含在‘to’属性中的JID域标识符部分的主机名匹配服务器本身的一个已配置主机名，并且包含在‘to’属性中的JID是<domain>或<domain/resource>形式，服务器（或在内的一个已定义资源）必须合乎节种类处理节或返回错误节给发送者。 10．5 同域中的节点        如果包含在‘to’属性中的JID域标识符部分的主机名匹配服务器本身的一个已配置主机名，并且包含在‘to’属性中的JID是<node@domain>或<node@domain/resource>形式，服务器应当传送节到由包含在‘to’属性中的JID表达的节的意向接收者。以下规则应用： 1） 如果JID包含一个资源标识符（例：是<node@domain/resource>形式）并且，这儿存在一个已连接资源匹配全JID，接收者的服务器应当传送的节到确切匹配此资源标识符流或会话。 2） 如果JID包含一个资源标识符并且这儿存在匹配全JID的无连接资源，接收者的服务器应当返回一个<service-unavailable/>节错误给发送者。 3） 如果JID是<node@domain>形式，并且这儿存在为此结点的至少一个已连接资源，接收者的服务器应当传送节到连接资源的至少一个，根据应用-特殊规则（一套传送规则，用于定义在[XMPP-IM]即时消息与出席应用）。 11． XMPP内的XML使用 11．1 约束        XMPP是流XML元素的一个简单与特殊的协议，用来近实时的交换结构化信息。由于XMPP不需要任意分析与完整XML文档，这儿没有XMPP需要支持[XML]全特征的需求。特别的，以下约束应用。        关于XML产生，一个XMPP实现不准注入以下任意一个XML流： *评论（定义在[XML]节2。5） *处理说明（2。6节） *内部或外部DTD子集（2。8节） *除了预定义实体（4。6节）的内部或外部实体参考。 *包含映射到预定义实体（4。6节）保留字符的字符数据或属性值；那样的字符必须被避免        关于XML处理，如果一个XMPP实现接收到那样的约束XML数据，它必须忽略此数据。 11．2 XML命名空间名与前缀        XML命名空间[XML-NAMES]被用在所有与XMPP-兼容的XML中，去创建数据拥有权的严格界限。命名空间的基本功能是分离结构的混合在一起的XML元素的不同词汇。确保XMPP-兼容XML是命名空间-了解使任意允许的XML能够与XMPP中的任意数据元素结构化的混合。XML命名空间名与前缀的规则定义在以下子部分。 11．2．1 流命名空间        流命名空间声明在所有XML流头中都是需要的。流命名空间名必须是'http://etherx.jabber.org/streams'。<stream/>元素与它的<features/>与<error/>子元素的元素名必须被所有实例中的流命名空间认定合格。一个实现应当为那些元素产生仅有的'stream:'前缀，并且因为历史原因可能接受仅有的'stream:'前缀。 11．2．2 缺省命名空间        缺省命名空间声明是需要的，并且用在所有XML流中，为了定义允许的根流元素的第一级子元素。此命名空间声明必须与初始流与响应流相同，为了两个流一致的被认证合格。缺省命名空间声明应用于流与所有在由其它命名空间认证合格的流（除非由另一命名空间显示认定合格，或由流命名空间或回叫命名空间前缀认证）中发送的节。        服务器实现必须支持以下两个缺省命名空间（由于历史原因，一些实现可能支持仅有的那些两个缺省命名空间）： *jabber:client——缺省命名空间，当流用于客户端与服务器通信时所声明的。 *jabber:server——缺省命名空间，当流用于两服务器间通信时声明的。        客户端实现必须支持'jabber:client'缺省命名空间，并且由于历史原因可能只支持缺省命名空间。        实现不准为缺省命名空间中的元素产生命名空间前缀，如果缺省命名空间是'jabber:client'或'jabber:server'。一个实现不应当为元素产生命名空间前缀，元素由'jabber:client'与'jabber:server'之外的内容（与流相反）命名空间认证的。        注：'jabber:client'与'jabber:server'命名空间是接近同一的，但用在不同的上下文中（客户端到服务顺通信用'jabber:client'与服务器到服务器通信用'jabber:server'）。这两个仅有的不同是‘to’与‘from’属性在'jabber:client'中发送的节中是可选的，然而在'jabber:server'中发送的节是必须的。如果一个兼容实现接受一个由'jabber:client'或'jabber:server'命名空间认证合格的流，它必须支持所有三个核心节种类的（消息，出席，与IQ）通用属性（9。1节）与基本语义（9。2节）。 11．2．3 回叫命名空间        回叫命名空间声明对于所有用在服务器回叫（8节）中的元素都是需要的。回叫命名空间的名字必须是'jabber:server:dialback'。所有由这个命名空间认证合格的元素必须被加前缀。一个实现应当为那种元素仅产生'db:'前缀并可能接受仅有的'db:'前缀。 11．3 确认（验证）        除了'jabber:server'命名空间中节的相关‘to’与‘from’地址，服务器不为转发到客户端或另一个服务器的XML元素负责；一个实现可能选择提供仅有的认证数据元素，但这是可选的（虽然一个实现不准接受XML，那也不是好格式）。客户端不应当依赖此能力去发送数据，这些数据与方案并不符，并且应当忽略一个来的XML流中的非构造元素或属性。XML流与节的验证是可选的，包含在此的方案仅用于描述目的。 11．4 包含文本声明        实现应当在发送流头之前发送文本声明。应用必须遵循文本声明包含在内的相关环境的[XML]中的规则。 11．5 字符编码        实现必须支持UTF-8 (RFC 3629 [UTF-8])统一字符集(ISO/IEC 10646-1 [UCS2])字符传输，RFC 2277 [CHARSET]中查。实现不准试图使用其它编码。

http://hi.baidu.com/xboxsky/blog/item/7a461e17732be70b4b90a70b.html