资源标识符是一个可选的第三位标识符，位于域标识符之后，后跟‘/’作为分隔符。资源标识符可以修改< [url=mailto:node@domain]node@domain[/url]>也可以只是地址。它通常表示 一个特别的会话、连接（例如：一个设备或位置），或属于带有节点标识符的对象（例如：在多用户聊天室的一个参与者）。当提供必要的信息来完成资源绑定（第 7节）时，资源标识符对服务器与其它客户端均不透明，并且由客户端实现来定义，以后，它作为一个“已连接资源”参考。实体可能同时维护多连接，每个已连接 的资源均由资源标识符来进行区别。

资源标识符必须按Resourceprep profile of [STRINGPREP]格式化，才能无错应用。比较两个资源标识符前，服务器必须（客户端应该）首先为每个标识符应用Resourceprep profile。 3.5 决定地址

SASL协商后（第6节），如果正确，资源绑定（第7节），流接收实体必须决定初始实体的JID。

如果SASL协商（第6节）期间未指定授权身份，对服务器与服务器间的通信，初始实体的JID应当被授权身份，派生于认证身份，在SASL（Simple Authentication and Security Layer简单授权与安全层）说明[SASL]中定义。

如果SASL协商（第6节）期间未指定授权身份，对客户端到服务器的通信，“bare JID”（<[url=mailto:node@domain]node@domain[/url]>）应该被授权身份，被派生于授权认证， 定义在[SASL]。在资源绑定期间（第7节）“full JID”

（<[url=mailto:node@domain/resource]node@domain/resource[/url]& gt;）的资源标识符部分应当是客户端与服务器间协商的资源标识符。

接收实体必须确保结果JID（包括结点标识符，域标识符，资源标识符，分隔符）遵从此节中前面所定义的规则与格式；为满足此限制，接收实体可能需要替代由接收实体所决定的规范的JID初始实体所发送的JID。 XMPP 3920 最靠谱的中文翻译文档（二） XML流 4.1概述

使presence-aware实体间能够相互迅速的、异步交换相关的小负载的结构化信息有两种基本元素：XML流与XML节。术语定义如下：

XML流定义：XML流是一个容器，用于网络上任意两实体间交换XML元素。XML流的开始是以一个起始的XML标记（有合 适的属性与命名空间声明）表示，XML流的结尾以一个结束的XML标记表示。在流的生命周期中，初始化它的实体能够通过流 发送极多的XML元素，元素与XML节（定义在此，, , 或 元素由缺省命名空间验证）都用于协商流（例：协商使用TLS（第5节）或使用SASL（第6节））。“初始流”是从初始实体（通常 是一个客户端或服务器）到接收实体（通常是一个服务器）的协商，并被看作与从初始实体到接收实体的会话一致。初始流能从初始实体到接收实体单向通信；为了 能够从接收实体到初始实体的信息交换，接收实体必须在反方向协商一个流（“响应流”）。

XML节定义：XML节是一个不连续的结构化信息语义单元，通过XML流从一个实体发送到另一个实体。XML节以根的直接子层存在，如果它匹配产品[43]内容[XML]，则可以很好的平衡。

任何XML节的开始都由深度为1的XML流（例如：）的开始标记元素来清楚的表示，XML节的结尾由相应的深度为1的关 闭标记来清楚的表示。为传送想要的信息，一个XML节可能包含必要的子元素（带有属性，元素，XML字符数据）。在此定义的仅有的XML节 是，，元素，由流的缺省命名空间验证，在XML节（第9节） 中描述；为传输层安全（TLS：Transport Layer Security）协商，SASL协商，或服务器回叫（第8节）而发送的XML元素，并不会当作XML节来考虑。

考虑一个客户端与服务器的会话例子。为了连接到服务器，客户端必须初始化一个XML流：发送一个起始的标记给服务，可选先于 一个指定XML版本的文本声明与字符编码支持（参考文本声明的内容（11.4）；也可参考字符编码（11.5））。服从本地策略与所提供的服务，服务器接 下来应该回复另一个XML流给客户端，再次可选先于一个文本声明。一但客户端完成了SASL协商（第6节），客户端可以通过流发送极多的XML节给网络上 的任意容器。当客户端想关闭流时，它简单发送一个关闭标记给服务器（也可以由服务器来关闭流），从这以后，客户端与服务器 都应终止潜在的连接（通常是一个TCP连接）。

习惯于将XML考虑成以文档为中心的人可能希望看到客户端与服务器的会话作为两个末端开口的（自由回答的）XML文档的组成部分：一个从客户端到服务器， 另一个从服务器到客户端。从这个观点看，根元素可被认为是每个“文档”的文档实体，两个“文档”都由通过两个XML流发送 的XML节的集聚来建立。然而，这种观点仅是一种方便；XMPP并不以文档处理，而是以XML流或XML节来处理。

本质上，那么，一个XML流充当了所有通过会话发送的XML节的信封。可用图简单表示如下：

|--------------------| | | |--------------------| | | | | | | |--------------------| | | | | | | |--------------------| | | | | | | |--------------------| | ... | |--------------------| | | |--------------------|

4.2 绑定到TCP

虽然将一个XML流结合到一个[TCP]连接上不是必须的（例如：两个实体能通过其它诸

如[HTTP]投票选举机制而彼此互连），此说明也只定义了 XMPP到TCP的绑定。在客户端到服务器端通信的上下文中，服务器必须允许客户端为了从客户端到服务器与服务器到客户端的XML节发送共享的一个单 TCP连接。在服务器到服务器的通信上下文中，服务器必须使用一条TCP连接用于从服务器到其对等服务器的XML节传送，另一条TCP连接（由对等初始 化）用于对其等服务器到服务器的XML节传送，总共有两条TCP连接。

4.3 流安全

当在XMPP1.0中协商XML流时，TLS应当按TLS应用（第5节）所定义的来使用，SASL必须按SASL（第6节）所定义的来使用。“初始流” （例如：从初始实体到接收实体的流）与“响应流”（例如：从接收实体到初始实体的流）必须被分别保护，即使双向安全可能已通过相互的认证机制所建立。实体 不应当在流被认证之前，尝试通过流发送XML节（第9节），但如果这样做了，那么，其它实体不准接受此类节，并应当返回一个流错误，然后终止两端的XML流与潜在的TCP连接；注意，这只适用于XML节（例如：, , 元素，由缺省命名空间检查）并不适用于流协商（例如：用于协商使用TLS（第5节）或使用SASL（第6节））的XML元素。

4.4 流属性

流元素属性如下：

1） to—‘ to’属性应当仅用于从初始实体到接收实体的XML流头中，并且必须被设成一个接收实体服务的主机名。‘to’属性不应当设在接收实体回应初始实体的XML流头中；然而，如果‘to’属性包括在内，它应当被初始实体默默忽略。

2） from—‘ from’属性应当仅用于从接收实体到初始实体的XML流头中，并且必须被设成一个接收实体服务的主机名，此接收实体正授权访问初始实体。‘from’属 性不应在初始实体发送到接收实体的流头中；然而，如果‘from’属性包括在内，它应当被接收实体忽略。 3） id—‘ id’属性应当仅用于从接收实体到初始实体的XML流头中。此属性是唯一一个由接收实体创建的，作为初始实体流与接收实体间会话的密钥，并且，在接收应用 （通常是一个服务器）中是唯一的。注意：流ID可能是严格安全的，并且因此必须是即不能预测也不能重复的（参考[RANDOM]推荐关于随机安全观点）。 ‘id’属性不应在初始实体到接收实体的XML流头中；然而，如果‘id’属性包含在内，应被接收实体忽略。

4） xml:lang—‘ xml:lang’属性（定义在[XML]的12.2）应当包含在初始实体的初始流头中，