XMPP 3920 最靠谱的中文翻译文档

用于指定缺省语言，此语言可以是任何通过流发送的人类可读的 XML字符数据。如果属性包含在内，接收实体应当记住此值并做为初始流与响应流的缺省值；如果此属性不包含在内，接收实体应当为两个流使用一个可配置的缺 省值，它必须为响应流在头中通信。对所有通过初始化流发送的节，如果初始实体不包含‘xml:lang’属性，接收实体应当应用缺省值；如果初始实体包含 ‘xml:lang’属性，接收实体不准修改或删除它（参考xml:lang（9.1.5））。‘xml:lang’属性值必须是一个NMTOKEN（定 义在[XML]（2.3）），并且必须与定义在RFC3006[LANGTAGS]中的格式一致。

5） version—版本属性出现设到至少是“1.0”信号值，支持定义在说明书中的相关流协议（包括流特征）。有关代与属性处理的具体规则定义如下： 可总结如下：

| initiating to receiving | receiving to initiating ---------+---------------------------+----------------------- to | hostname of receiver | silently ignored from | silently ignored | hostname of receiver id | silently ignored | session key xml:lang | default language | default language

version | signals XMPP 1.0 support | signals XMPP 1.0 support

4.4.1版本支持

XMPP版本在此指定为“1.0”，特别的，这封装了流相关协议（TLS应用（5），SASL应用（6），流错误（4.7）），还有三个已定义的XML节 类型（, , and ）的语义。XMPP版本的编号方案是“.”。Major与minor数字必 须作为分离的整数对待，并且每个数字可能并不按单数字增加。因此\是一个比\低的版本，依次低于\。前导零（例如：\）必须被接收者忽略并不准发送。 Major版本号应当增加，只要流与节格式或是所需行为已很大程度上改变，以至于老版本如果对它不理解的并采取在旧版说明中指定的动作时，只简单忽略元素 与属性时无法与新版本实体互操作，就要增加主版本号。次版本号指新能力，并且必须被有一个更小次版本号的实体所忽略，但被有更大次版本号的实体作信息目的 用。举例：次版本号可能指处理消息，出席，或IQ节新近定义的‘type’属性值；有更大次版本号的实体将简单注意它的通信

者不理解此‘type’属性 值，并因此而不发送它。

以下规则由实现应用于产生与处理在流头中的‘版本’属性：

1） 初始实体必须在初始流头中将版本属性值设到它所支持的最高版本号（例如：如果它所支持的最高版本号定义在此说明中，必须设值为“1.0”）

2） 接收实体必须在响应流头中设置版本属性值或者是初始实体提供的值，或者是接收实体所支持的最高版本号，无论哪一个更低。接收实体必须对主、次版本号做数字比较，而不是\字符串匹配。

3） 如果包含在响应流头中的版本号至少一个主版本号低于包含在初始流头中的版本号，并且新版本实体不能像上述那样与旧版本互操作，初始实体应当产生一个流错误，并终止XML流与潜在的TCP连接。

4） 如果每个实体都收到一个带有“无版本号”属性的流头，实体必须考虑由其它实体支持版本将是“0.0”并不应当在发送响应流时包括‘version’属性。

4.5 命名空间声明

流元素必须拥有流命名空间声明和一个缺省的命名空间声明（命名空间声明定义在XML命名空间说明文档[XML-NAMES]中）。对有关流命名空间与缺省命名空间的更细节的信息，看命名空间名称与前缀（11.2）。

4.6 流特征

如果初始化实体包含版本属性，并在初始流头中，其值至少设为“1.0”，那么接收实体必须发送一个子元素（由流命名空 间前缀作前缀）给初始实体，以宣布任何可被协商的（或另外需要被广告的能力）流级别的特征。当前，这仅用于广告在此定义的TLS应用（5），SASL应用 （6）和资源绑定（7），并且，会话按照[XMPP-IM]中所定义的来建立；然而，流特征的功能性可被用于广告其它将来可协商的特征。如果实体不理解或 不支持某些特征，那么它应当默默的忽略。如果一个或多个安全特征（例如：TLS与SASL）需要在非安全特征（例如：资源绑定）被提供之前成功被协商，非 安全相关特征不应当在相关安全特征被协商之前包含在流特征中被广告。

4.7 流错误

根流元素可能包含一个子元素，此元素由流命名空间前缀来加前缀。如果错误

子元素感觉到一个流级别错误发生，它必须由一个兼容实体（通常是一个服务器而不是一个客户端）来发送。

4.7.1 规则

以下规则应用于流级别错误：

1） 设想所有流级别错误均是不可恢复的；因此，如果一个错误在流级别层发生，那么检测错误的实体必须发送一个流错误给其它实体，发送一个关闭标记，并终止潜在的TCP连接。

2） 如果在流被建立期间发生错误，接收实体必须一直发送起始标记，将元素作为流元素的子元素，发送 关闭标记，并终止潜在的TCP连接。此种情况下，如果初始实体在‘to’属性（或根本没提供‘to’属性）中提供了一个未 知主机，服务器应当在流头的‘from’属性中提供服务器的授权主机名，并在终止前发送。

4.7.2 语法

流错误语法如下：

OPTIONAL descriptive text

[OPTIONAL application-specific condition element]

元素：

1） 必须包含一个子元素，此子元素与以下定义的已定义的节错误条件之一相一致；此元素必须被'urn:ietf:params:xml:ns:xmpp-streams'命名空间认为是合格的。

2） 可能包含一个子元素，此子元素包含了更详细描述错误的XML字符数据；此元素必须被 'urn:ietf:params:xml:ns:xmpp-streams'命名空间认为是合格的，并且，应当拥有一个'xml:lang'属性来指明 XML字符数据的自然语言。

3） 可能包含一个用于说明特殊应用错误条件的子元素；此元素必须由一个已定义应用命名空间来认证，并且，它的结构由那个命名空间来定义。

元素是可选的。如果包含了此元素，它应当仅用于提供描述性或诊断性的信息，来补充一个已定义的条件或特殊应用条件的意思；它不 应当由一个应用以程序化的形式叙述。它不应当作为错误消息展示给一个用户，但可能另外显示与包含条件元素（或元素们）相关的错误消息。

4.7.3 已定义条件

以下定义了流级别错误条件：

1）--已经发送XML的实体不能被处理；此错误可能用于代替更特殊的XML相关错误，例如：, ,

, , ，虽然更特殊的错误是首选。

2）--实体已经发送了一个不被支持的名空间前缀，或在一个需要那样一个前缀的元素中发送了没有命名空间的前缀（参考XML命名空间名与前缀（11.2））。 3）--服务器正为实体关闭活动流，因为一个已经被初始化的新流与现存流冲突。

4）--一段时间内（可根据本地服务策略配置）实体并不通过流产生任何通信。

5）--由初始实体在流头中提供的‘to’属性值对应于一个主机名，而此主机名已不再被一个服务器当作主机了。

6）--由初始实体在流头中提供的‘to’属性值于服务器所拥有的主机名不一致。

7）--一个在两个服务器间发送的节，缺少‘to’或‘from’属性（或此属性无值）

8）--服务器经历了错误配置或其它未定义内部错误使其无法提供服务。

9）--在‘from’地址中提供的JID或主机名与已授权的JID或有效域协商不匹配，此有效域协商为通过SASL或回叫服务器间的协商，或通过授权与资源绑定的客户端