6．使用SASL 6．1 概述
XMPP包含一个认证流的方法，此方法依靠一个简单认证与安全层（SASL）协议[SASL]的XMPP-specific profile。SASL提供一个一般化方法，用于给基于连接的协议加认证支持，并且，XMPP使用一个一般化XML命名空间profile，用于 SASL，遵从[SASL]的profiling需求。
以下规则应用：
1） 如果两个服务器间发生SASL协商，直到由服务器宣称的域名系统（DNS）主机名被解析了（参考服务器到服务器通信（14.4）），通信才可处理。
2） 如果实始实体能够进行SASL协商，，它必须在初始流头中包含值至少为“1.0”的版本属性。
3） 如果接收实体能够进行SASL协商，它必须在一个
5） 任何包含在XML元素中的XML字符数据，在SASL协商期间使用，必须使用base64编码，编码在RFC3548第三节有定义。
6） 如果所提供的一个“简单用户名”能够被选定SASL机制（例：由DIGEST-MD5与CRAM-MD5机制所支持，但不靠EXTERNAL与 GSSAPI机制所支持）所支持，在认证期间，初始实体应当作为简单用户名提供它的发送域（IP地址或包含在域标识符中的全认证域名）在服务器对服务器的 通信情况下，或是它的已注册帐户名（包含在XMPP结点标识符中的用户或结点名）在客户到服务器的通信情况下。
7） 如果初始实体希望代表其它实体与支持授权身份传输的被选SASL机制来行动，初始实体在SASL协商期间必须提供一个授权身份。如果初始实体不希望代表另 一个实体行动，它不准提供一个授权身份。正如[SASL]中指定的，初始实体不准提供一个授权身份，除非一个授权身份不同于缺省授权身份，此缺省授权身份 派生于描述在[SASL]中的认证身份。如果提供了，授权身份值对服务器来说必须是
对客户 端来说，必须是
8） 靠涉及到安全层协商的SASL协商的成功，接收实体必须抛弃来自本身没有获得SASL协商的初始实体的任何知识。
9） 靠涉及到安全层协商的SASL协商的成功，初始实体必须抛弃来自本身没有获得SASL协商的接收实体的任何知识。
10） 参考必须被支持的相关机制的强制实施技术（14.7）。
6．2叙述
当初始实体使用SASL认证接收实体时，步骤如下：
1） 初始实体请求SASL认证，通过在开放XML流头中包含版本属性，并将其发送给接收实体，属性值设为“1.0”。
2） 发送一个XML流头作为回应后，接收实体广告一个可利用的SASL认证机制列表；列表中每一项都是一个