xmpp协议2
决定地址
SASL协商后(第6节),如果正确,资源绑定(第7节),流接收实体必须决定初始实体的JID。
如果SASL协商(第6节)期间未指定授权身份,对服务器与服务器间的通信,初始实体的JID应当被授权身份,派生于认证身份,在SASL(Simple Authentication and Security Layer简单授权与安全层)说明[SASL]中定义。
如果SASL协商(第6节)期间未指定授权身份,对客户端到服务器的通信,“bare JID”(<node@domain>)应该被授权身份,被派生于授权认证,定义在[SASL]。在资源绑定期间(第7节)“full JID”(<node@domain/resource>)的资源标识符部分应当是客户端与服务器间协商的资源标识符。*
接收实体必须确保结果JID(包括结点标识符,域标识符,资源标识符,分隔符)遵从此节中前面所定义的规则与格式;为满足此限制,接收实体可能需要替代由接收实体所决定的规范的JID初始实体所发送的JID。
XML流与XML节点这两个基础的概念使得可以快速、 异步的在presence-aware实体间交换相关的小量结构化信息。这两个术语定义如下:
1. XML流的定义:
1. XML流是用于任意两个实体间通过网络进行XML元素交换的容器。XML流的开端明确的由一个开的XML<stream>标记标明(含有适当的属性及命名空间的声明),XML流的结束明确的由一个闭的XML</stream>标记标明。在XML流的生命周期里,初始化它的实体能够通过流发送大量的XML元素,元素也通常制定一个特定的 XML流(例:来制定使用TLS(第5节)或使用SASL(第6节))或者XML节点(如定义在这些由缺省命名空间限定的<message/>、<presence/>和<iq/>元素上)。 “初始流”是由发送实体(通常是一个客户端或服务器)给接收实体(通常是一个服务器)制定的,可以见到它是与发送实体和接收实体间的会话相一致的。发送流能进行从发送实体到接收实体的单向通信;为了实现从接收实体到发送实体的信息交换,接收实体必须在反方向上制定一个流(“响应流”)。
2. XML节的定义:
1. XML节是一个不连续的通过XML流从一个实体到另一个实体所传送的结构化信息的语义单元。XML节存在于根元素<stream/>的直接子层上,and is said to be well-balanced if it matches the production [43] content of [XML] 。任何XML节的开端都由处于XML流中深度为1的层上的元素开标记符明确标明(如,<presence>), 其结尾则由在深度为1的层上的相应闭标记符明确标明(如,</presence>)。为了传送期望的信息,一个XML节可能需要包含子元素(带有一些属性、元素、XML字符数据)。在这(RFC 3920中)定义的用于流的XML节仅有在缺省命名空间限定下的<message/>、<presence/>和< iq/>元素,这些在XML节(第9节)中会讲到;为制定TLS和SASL,以及服务器回叫而发送的XML元素,并不会当作XML节来考虑。
考虑一个客户端与服务器会话的例子。为了连接到服务器,客户端必须初始化一个XML流:发送一个开的<stream>标记到服务器,在这之前可以(OPTIONAL)有一个指定XML版本与字符编码支持的文本声明(参考文本声明的内容(11.4);也可参考字符编码(11.5))。根据本地策略与所提供的服务,服务器接下来应该(SHOULD)回应一个XML流给客户端,然后也可以具有一个可选的文本声名。一旦客户端完成了SASL (第6节),客户端可以(MAY)可以通过流发送大量的XML节给网络上的任意接受实体。当客户端想关闭流时,它只需简单的发送一个闭< /stream>标记符给服务器(也可以由服务器来关闭流),接着,客户端与服务器都应(SHOULD)终止underlying连接(通常是一个TCP连接)。
习惯于以基于文档的方式来考虑XML的人可能一厢情愿的把客户端与服务器的会话看作是由两个无限制的XML文档所组成:一个从客户端到服务器,另一个从服务器到客户端。依这种看法,根<stream/>元素可被认为是每个“文档”的文档实体,两个“文档”都是通过两个XML流发送的 XML节的堆积而建立。然而,这种观点仅是图个方便;XMPP并不以文档的方式处理,而是以XML流或XML节来处理。
从本质上看,那么一个XML流其实是充当了在会话中所发送的所有XML节的信封。我们可将其用简图表示如下:
|--------------------|
| <stream> |
|--------------------|
| <presence> |
| <show/> |
| </presence> |
|--------------------|
| <message to='foo'> |
| <body/> |
| </message> |
|--------------------|
| <iq to='bar'> |
| <query/> |
| </iq> |
|--------------------|
| ... |
|--------------------|
| </stream> |
|--------------------|
4.2. 绑定到TCP
虽然没必要将一个XML流结合到一个TCP连接上(例如:两个实体能通过其它诸如通过HTTP来polling的机制实现彼此互连),此规范也只定义了XMPP到TCP的绑定。在客户端到服务器端的通信中,服务器必须(MUST)允许客户端共享一条单一的TCP连接来发送从客户端到服务器或服务器到客户端的XML节。在服务器到服务器的通信中,服务器必须(MUST)使用一条TCP连接来用于传送从服务器到其它对等服务器的XML节,和另外的一条TCP连接(由对等服务器初始化)用于传送其它对等服务器到服务器的XML节,总共有两条TCP连接。
4.3. 流的安全
当在XMPP1.0中制定XML流时,TLS(第5节)和SASL(第6节)应当(SHOULD)按其所定义的来使用。“初始流”(例如:从发送实体到接收实体的流)与“响应流”(例如:从接收实体到发送实体的流)必须(MUST)被分别保护,即使两个方向上的安全可能(MAY)由提供相互认证的机制建立起来。实体也不应当(SHOULD NOT)在流被认证之前,尝试通过该流发送XML节(第9节),但如果这么做了,那么,其它实体禁止(MUST NOT)接受此类XML节,并应当(SHOULD)返回一个<non-authorized/>流错误,然后终止两端的XML流与underlyingTCP连接;注意,这只适用于XML节(例如:缺省命名空间限定<message/>、<presence/>、<iq/>元素),并不适用于制定流的的XML元素(例如:用于制定TLS(第5节)或SASL(第6节)的XML元素)。
4.4.流的属性
流元素的属性如下:
* to -- ‘to’属性应当(SHOULD)只用在从发送实体到接受实体的XML流的header中,而且必须(MUST)被设置成一个由接受实体所提供的主机名。不应当(SHOULD NOT)有‘to’设置在接受实体回应给发送实体的XML流的header中;然而,如果已经被包含了,它应当(SHOULD)被发送实体默默地忽略掉。
* from -- ‘from’属性应当(SHOULD)只用在从接受实体到发送实体的XML流的header中,而且必须(MUST)被设置成一个由以准许连接到发送实体的接受实体所提供的主机名。不应当(SHOULD NOT)有‘from’设置在发送实体传送给接受实体的XML流的header中;然而,如果已经被包含了,它应当(SHOULD)被接送实体默默地忽略掉。
* id -- ‘id’属性应当(SHOULD)只用在从接受实体到发送实体的XML流的header中。id属性是由接受实体创建的,起到发送流与接受实体间会话的密钥的作用,且必须在接受应用程序中是唯一的(通常是个服务器)。注意到流的ID可能有安全隐患,因此此ID必须(MUST)不可预测且不重复的(参见[RANDOM]中关于随机的建议)。不应当(SHOULD NOT)有‘id’设置在发送实体传送给接受实体的XML流的header中;然而,如果已经被包含了,它应当(SHOULD)被接送实体默默地忽略掉。
* xml:lang -- ‘ xml:lang’属性(定义在[XML]的2.12中)应当包含在发送实体的初始流头中,用于指定任何通过流发送的人类可读的XML字符数据的缺省语言。如果属性包含在流内,接收实体应当记住此值并做为初始流与响应流的缺省值;如果此属性不包含在流内,接收实体应当(SHOULD)为两个流使用一个可配置的缺省值,该值必须放置到响应流的header中。对所有通过初始化流发送的节,如果发送实体不包含‘xml:lang’属性,接收实体应当(SHOULD)应用缺省值;如果初始实体包含‘xml:lang’ 属性,接收实体不准(MUST NOT)修改或删除它(参考xml:lang(9.1.5))。‘xml:lang’属性值必须是一个NMTOKEN(定义在[XML](2.3)中),并且必须与定义在RFC3006[LANGTAGS]中的格式一致。
* version -- 所出现的版本属性得设置值至少是“1.0”以标志支持定义在本规范中的相关流协议(包括流特征)。有关该属性的产生与处理的具体规则定义在之后的4.4.1节中。
我们可以总结为下表:
| 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节类型(<message/>、 <presence/>、<iq/>)的语义。XMPP版本的编号方案是这样的“<major>.<minor>”。major与minor数字必须(MUST)作为分离的整数对待,并且每个数字值可能增加到超过一位数。因此“XMPP 2.4”是一个比“XMPP 2.13”低的版本,依次又低于“XMPP 12.3”。而以零开头的(例如:“XMPP 6.01”)必须(MUST)被接收者忽略并不准(MUST NOT)发送。
major版本号只有当流与节的格式或是需要的行为已很大程度上改变,以至于老版本的实体不能够通过简单的忽略其元素和属性的方法来接受新版本的实体以及实现旧版本中定义的行为时,才应该增加。次版本号表示有新性能,并且必须(MUST)被带有更小的次版本号的实体所忽略,但被有更大次版本号的实体用作提供信息的目的。例如:次版本号可能标志了处理消息、出席或IQ节最新定义的‘type’属性值;有更大次版本号的实体将简单注意它的通信对象不会理解此‘type’属性值,并因此不会去发送它。
以下规则应用于产生与处理在实际应用中的流的headers中的‘版本’属性:
1. 发送实体必须(MUST)在初始流头中将版本属性值设到它所支持的最高版本号(例如:如果它所支持的最高版本号定义在此说明中,必须(MUST)设值为“1.0”)。
2. 接收实体必须(MUST)将响应流header中版本属性值设置成初始实体提供的值与接收实体所支持的最高版本号这两个中较低的一个。接收实体必须(MUST)分别对主、次版本号做数字比较,而不是简单的对"<major>.<minor>"进行字符串匹配。
3. 如果包含在响应流header中的版本号至少有一个主版本号低于包含在初始流header中的版本号,并且新版本实体不能像上述那样与旧版本互操作,发送实体应当(SHOULD)产生一个<unsupported-version/>流错误,并终止XML流及 underlyingTCP连接。
4. 如果任一实体收到了带有无“版本”属性的流header时,该实体必须(MUST)认为其它实体支持版本是“0.0”,并且不应当(SHOULD NOT)在发送响应流时包括‘version’属性。
4.5. 声名命名空间
流元素(MUST)同时具有流的命名空间声名和一个缺省的命名空间声明(“namespace declaration”定义在XML 命名空间规范[XML-NAMES]中)。关于流的命名空间和缺省的命名空间的详细信息,请参阅命名空间名与前缀(11.2节)
SASL协商后(第6节),如果正确,资源绑定(第7节),流接收实体必须决定初始实体的JID。
如果SASL协商(第6节)期间未指定授权身份,对服务器与服务器间的通信,初始实体的JID应当被授权身份,派生于认证身份,在SASL(Simple Authentication and Security Layer简单授权与安全层)说明[SASL]中定义。
如果SASL协商(第6节)期间未指定授权身份,对客户端到服务器的通信,“bare JID”(<node@domain>)应该被授权身份,被派生于授权认证,定义在[SASL]。在资源绑定期间(第7节)“full JID”(<node@domain/resource>)的资源标识符部分应当是客户端与服务器间协商的资源标识符。*
接收实体必须确保结果JID(包括结点标识符,域标识符,资源标识符,分隔符)遵从此节中前面所定义的规则与格式;为满足此限制,接收实体可能需要替代由接收实体所决定的规范的JID初始实体所发送的JID。
XML流与XML节点这两个基础的概念使得可以快速、 异步的在presence-aware实体间交换相关的小量结构化信息。这两个术语定义如下:
1. XML流的定义:
1. XML流是用于任意两个实体间通过网络进行XML元素交换的容器。XML流的开端明确的由一个开的XML<stream>标记标明(含有适当的属性及命名空间的声明),XML流的结束明确的由一个闭的XML</stream>标记标明。在XML流的生命周期里,初始化它的实体能够通过流发送大量的XML元素,元素也通常制定一个特定的 XML流(例:来制定使用TLS(第5节)或使用SASL(第6节))或者XML节点(如定义在这些由缺省命名空间限定的<message/>、<presence/>和<iq/>元素上)。 “初始流”是由发送实体(通常是一个客户端或服务器)给接收实体(通常是一个服务器)制定的,可以见到它是与发送实体和接收实体间的会话相一致的。发送流能进行从发送实体到接收实体的单向通信;为了实现从接收实体到发送实体的信息交换,接收实体必须在反方向上制定一个流(“响应流”)。
2. XML节的定义:
1. XML节是一个不连续的通过XML流从一个实体到另一个实体所传送的结构化信息的语义单元。XML节存在于根元素<stream/>的直接子层上,and is said to be well-balanced if it matches the production [43] content of [XML] 。任何XML节的开端都由处于XML流中深度为1的层上的元素开标记符明确标明(如,<presence>), 其结尾则由在深度为1的层上的相应闭标记符明确标明(如,</presence>)。为了传送期望的信息,一个XML节可能需要包含子元素(带有一些属性、元素、XML字符数据)。在这(RFC 3920中)定义的用于流的XML节仅有在缺省命名空间限定下的<message/>、<presence/>和< iq/>元素,这些在XML节(第9节)中会讲到;为制定TLS和SASL,以及服务器回叫而发送的XML元素,并不会当作XML节来考虑。
考虑一个客户端与服务器会话的例子。为了连接到服务器,客户端必须初始化一个XML流:发送一个开的<stream>标记到服务器,在这之前可以(OPTIONAL)有一个指定XML版本与字符编码支持的文本声明(参考文本声明的内容(11.4);也可参考字符编码(11.5))。根据本地策略与所提供的服务,服务器接下来应该(SHOULD)回应一个XML流给客户端,然后也可以具有一个可选的文本声名。一旦客户端完成了SASL (第6节),客户端可以(MAY)可以通过流发送大量的XML节给网络上的任意接受实体。当客户端想关闭流时,它只需简单的发送一个闭< /stream>标记符给服务器(也可以由服务器来关闭流),接着,客户端与服务器都应(SHOULD)终止underlying连接(通常是一个TCP连接)。
习惯于以基于文档的方式来考虑XML的人可能一厢情愿的把客户端与服务器的会话看作是由两个无限制的XML文档所组成:一个从客户端到服务器,另一个从服务器到客户端。依这种看法,根<stream/>元素可被认为是每个“文档”的文档实体,两个“文档”都是通过两个XML流发送的 XML节的堆积而建立。然而,这种观点仅是图个方便;XMPP并不以文档的方式处理,而是以XML流或XML节来处理。
从本质上看,那么一个XML流其实是充当了在会话中所发送的所有XML节的信封。我们可将其用简图表示如下:
|--------------------|
| <stream> |
|--------------------|
| <presence> |
| <show/> |
| </presence> |
|--------------------|
| <message to='foo'> |
| <body/> |
| </message> |
|--------------------|
| <iq to='bar'> |
| <query/> |
| </iq> |
|--------------------|
| ... |
|--------------------|
| </stream> |
|--------------------|
4.2. 绑定到TCP
虽然没必要将一个XML流结合到一个TCP连接上(例如:两个实体能通过其它诸如通过HTTP来polling的机制实现彼此互连),此规范也只定义了XMPP到TCP的绑定。在客户端到服务器端的通信中,服务器必须(MUST)允许客户端共享一条单一的TCP连接来发送从客户端到服务器或服务器到客户端的XML节。在服务器到服务器的通信中,服务器必须(MUST)使用一条TCP连接来用于传送从服务器到其它对等服务器的XML节,和另外的一条TCP连接(由对等服务器初始化)用于传送其它对等服务器到服务器的XML节,总共有两条TCP连接。
4.3. 流的安全
当在XMPP1.0中制定XML流时,TLS(第5节)和SASL(第6节)应当(SHOULD)按其所定义的来使用。“初始流”(例如:从发送实体到接收实体的流)与“响应流”(例如:从接收实体到发送实体的流)必须(MUST)被分别保护,即使两个方向上的安全可能(MAY)由提供相互认证的机制建立起来。实体也不应当(SHOULD NOT)在流被认证之前,尝试通过该流发送XML节(第9节),但如果这么做了,那么,其它实体禁止(MUST NOT)接受此类XML节,并应当(SHOULD)返回一个<non-authorized/>流错误,然后终止两端的XML流与underlyingTCP连接;注意,这只适用于XML节(例如:缺省命名空间限定<message/>、<presence/>、<iq/>元素),并不适用于制定流的的XML元素(例如:用于制定TLS(第5节)或SASL(第6节)的XML元素)。
4.4.流的属性
流元素的属性如下:
* to -- ‘to’属性应当(SHOULD)只用在从发送实体到接受实体的XML流的header中,而且必须(MUST)被设置成一个由接受实体所提供的主机名。不应当(SHOULD NOT)有‘to’设置在接受实体回应给发送实体的XML流的header中;然而,如果已经被包含了,它应当(SHOULD)被发送实体默默地忽略掉。
* from -- ‘from’属性应当(SHOULD)只用在从接受实体到发送实体的XML流的header中,而且必须(MUST)被设置成一个由以准许连接到发送实体的接受实体所提供的主机名。不应当(SHOULD NOT)有‘from’设置在发送实体传送给接受实体的XML流的header中;然而,如果已经被包含了,它应当(SHOULD)被接送实体默默地忽略掉。
* id -- ‘id’属性应当(SHOULD)只用在从接受实体到发送实体的XML流的header中。id属性是由接受实体创建的,起到发送流与接受实体间会话的密钥的作用,且必须在接受应用程序中是唯一的(通常是个服务器)。注意到流的ID可能有安全隐患,因此此ID必须(MUST)不可预测且不重复的(参见[RANDOM]中关于随机的建议)。不应当(SHOULD NOT)有‘id’设置在发送实体传送给接受实体的XML流的header中;然而,如果已经被包含了,它应当(SHOULD)被接送实体默默地忽略掉。
* xml:lang -- ‘ xml:lang’属性(定义在[XML]的2.12中)应当包含在发送实体的初始流头中,用于指定任何通过流发送的人类可读的XML字符数据的缺省语言。如果属性包含在流内,接收实体应当记住此值并做为初始流与响应流的缺省值;如果此属性不包含在流内,接收实体应当(SHOULD)为两个流使用一个可配置的缺省值,该值必须放置到响应流的header中。对所有通过初始化流发送的节,如果发送实体不包含‘xml:lang’属性,接收实体应当(SHOULD)应用缺省值;如果初始实体包含‘xml:lang’ 属性,接收实体不准(MUST NOT)修改或删除它(参考xml:lang(9.1.5))。‘xml:lang’属性值必须是一个NMTOKEN(定义在[XML](2.3)中),并且必须与定义在RFC3006[LANGTAGS]中的格式一致。
* version -- 所出现的版本属性得设置值至少是“1.0”以标志支持定义在本规范中的相关流协议(包括流特征)。有关该属性的产生与处理的具体规则定义在之后的4.4.1节中。
我们可以总结为下表:
| 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节类型(<message/>、 <presence/>、<iq/>)的语义。XMPP版本的编号方案是这样的“<major>.<minor>”。major与minor数字必须(MUST)作为分离的整数对待,并且每个数字值可能增加到超过一位数。因此“XMPP 2.4”是一个比“XMPP 2.13”低的版本,依次又低于“XMPP 12.3”。而以零开头的(例如:“XMPP 6.01”)必须(MUST)被接收者忽略并不准(MUST NOT)发送。
major版本号只有当流与节的格式或是需要的行为已很大程度上改变,以至于老版本的实体不能够通过简单的忽略其元素和属性的方法来接受新版本的实体以及实现旧版本中定义的行为时,才应该增加。次版本号表示有新性能,并且必须(MUST)被带有更小的次版本号的实体所忽略,但被有更大次版本号的实体用作提供信息的目的。例如:次版本号可能标志了处理消息、出席或IQ节最新定义的‘type’属性值;有更大次版本号的实体将简单注意它的通信对象不会理解此‘type’属性值,并因此不会去发送它。
以下规则应用于产生与处理在实际应用中的流的headers中的‘版本’属性:
1. 发送实体必须(MUST)在初始流头中将版本属性值设到它所支持的最高版本号(例如:如果它所支持的最高版本号定义在此说明中,必须(MUST)设值为“1.0”)。
2. 接收实体必须(MUST)将响应流header中版本属性值设置成初始实体提供的值与接收实体所支持的最高版本号这两个中较低的一个。接收实体必须(MUST)分别对主、次版本号做数字比较,而不是简单的对"<major>.<minor>"进行字符串匹配。
3. 如果包含在响应流header中的版本号至少有一个主版本号低于包含在初始流header中的版本号,并且新版本实体不能像上述那样与旧版本互操作,发送实体应当(SHOULD)产生一个<unsupported-version/>流错误,并终止XML流及 underlyingTCP连接。
4. 如果任一实体收到了带有无“版本”属性的流header时,该实体必须(MUST)认为其它实体支持版本是“0.0”,并且不应当(SHOULD NOT)在发送响应流时包括‘version’属性。
4.5. 声名命名空间
流元素(MUST)同时具有流的命名空间声名和一个缺省的命名空间声明(“namespace declaration”定义在XML 命名空间规范[XML-NAMES]中)。关于流的命名空间和缺省的命名空间的详细信息,请参阅命名空间名与前缀(11.2节)