4） 如果初始实体选择使用TLS，TLS协商必须在SASL协商处理之前完成；这种协商顺序是必要的，用于帮助保护SASL协商期间发送认证信息，并在TLS协商之前这段时间，使基于使用认证的SASL EXTERNAL机制成为可能。
5） 在TLS协商期间，实体不准在根流元素中发送任何空白字符（匹配[XML]内容，产品[3]）作为元素间（任何在TLS例子中的空白字符都只是为了便于阅读）的分隔符；这种限制有助于确保合适的安全层字节精度。
6） 接收实体必须考虑TLS协商在发送
7） 初始实体必须验证由接收实体表示的证书；参考证书验证（14.2）相关证书验证步骤。
8） 证书必须根据初始实体（例如：一个用户）提供的主机名来检查，而不是通过域名系统解析的主机名；例如：如果用户指定一个\的主机 名，而DNS SRV[SRV]查找并返回\，证书必须作为\被检查。如果对任何此种XMPP实体（例如，客户 端或服务器）的一个JID在一个证书中被表示，它必须作为一个UTF8String来表示，UTF8String在位于subjiectAltName中 的一个otherName实体中，使用[ASN.1]对象标识符\，在本文档5.1.1中说明。
9） 如果TLS协商成功，接收实体必须抛弃TLS生效之前，来自初始实体的任何非安全格式的知识。
10） 如果TLS协商成功，初始实体必须抛弃TLS生效之前，来自接收实体的任何非安全格式知识。
11） 如果TLS协商成功，接收实体不准提供STARTTLS扩展给当流重新开如时被提供的带有其他流特征的初始实体。
12） 如果TLS协商成功，初始实体必须继续SASL协商。
13） 如果TLS协商结果失败，接收实体必须终止XML流与潜在的TCP连接。 14） 参考强制实施技术（14.7）相关的必须被支持的机制。
5.1.1 ASN.1用于XMPP地址的对象标识符
上述[ASN.1]对象标识符\定义如下：
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
id-on OBJECT IDENTIFIER ::= { id-pkix 8 } -- other name forms
id-on-xmppAddr OBJECT IDENTIFIER ::= { id-on 5 }
XmppAddr ::= UTF8String
对象标识符可能也以点分制显示，格式为\
5．2 叙述
当初始实体使用TLS保护一个带有接收实体的流时，步骤如下：
1） 初始实体打开一个TCP连接，靠发送开放XML流头给接收实体，此流头包含版本属性，并设其值至少为“1.0”，来初始化流。
2） 接收实体以打开一个TCP连接并发送一个XML流头给初始实体作为响应，此流头包含值至少为“1.0”版本属性。
3） 接收实体靠包含带有其它支持流特征（如果TLS需要与接收实体交互，它应当靠包含一个