xmpp协议9
5. Receiving Server与Originating Server声称的域名回建一个TCP连接，然后连接到上了Authoritative Server。 (注意：优化考虑，实现中也可能（MAY）重用这里已存在的一个连接。）
6. Receiving Server向Authoritative Server发送一个stream header：
<stream:stream
xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server'
xmlns:db='jabber:server:dialback'>
注意：流的根元素上的‘to’和‘from’属性是可选的。如果命名空间名不正确，则Originating Server必须（MUST）产生一个<invalid-namespace/>流错误，并且终止XML流和underlying TCP连接。
7. Authoritative Server向Receiving Server发送一个stream header：
<stream:stream
xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server'
xmlns:db='jabber:server:dialback'
id='1251A342B...'>
注意：如果命名空间名不正确，那么Receiving Server则必须（MUST）生成一个<invalid-namespace/>流错误因素并且终止它与Authoritative Server之间的XML流和underlying TCP连接。如果流错误发生在Receiving Server和Authoritative Server之间，那么Receiving Server则必须（MUST）生成一个<remote-connection-failed/>流错误因素并且终止它与 Originating Server之间的XML流和underlying TCP连接。
8. Receiving Server向Authoritative Server发送一个确认key的请求：
<db:verify
from='Receiving Server'
to='Originating Server'
id='457F9224A0...'>
98AF014EDC0...
</db:verify>
注意：这里流过的是主机名，此主机名是在第三步中从Receiving Server的stream header到Originating Server的初始标识符，而key则是第四步中Originating Server发给Receiving Server的。基于这个信息，连同Authoritative Server网络中共享的secret信息，key得到了验证。任何可检验的方法都可被用于生成key。如果‘to’地址的值与 Authoritative Server承认的主机名不符，那Authoritative Server就必须（MUST）生成一个<host-unknown/>流错误因素终止XML流和underlying TCP连接。如果‘from’地址的值与在打开TCP连接时Receiving Server呈现的主机名不符（或者它的任何有效的域，例如Receiving Server主机名的一个有效的子域或Receiving Server持有的其它有效的域），那么Authoritative Server则必须（MUST）生成一个<invalid-from/>流错误因素并终止XML流和underlying TCP连接。
9. Authoritative Server 验证是否有效：
<db:verify
from='Originating Server'
to='Receiving Server'
type='valid'
id='457F9224A0...'/>
或
<db:verify
from='Originating Server'
to='Receiving Server'
type='invalid'
id='457F9224A0...'/>
注意：如果ID与第三步中Receiving Server所提供的ID不相符，那么Receiving Server必须（MUST）生成一个<invalid-id/>流错误因素并终止XML流和underlying TCP连接。如果‘to’地址的值与Receiving Server承认的主机名不符，那Receiving Server就必须（MUST）生成一个<host-unknown/>流错误因素终止XML流和underlying TCP连接。如果‘from’地址的值与在打开TCP连接时Originating Server呈现的主机名不符（或者它的任何有效的域，例如Receiving Server主机名的一个有效的子域或Originating Server持有的其它有效的域），那Receiving Server就必须（MUST）生成一个<invalid-from/>流错误因素并终止XML流和underlying TCP连接。在对Receiving Server进行了确认，Authoritative Server应该（SHOULD）终止它们之间的流。
10. Receiving Server告知Originating Server 验证结果：
<db:result
from='Receiving Server'
to='Originating Server'
type='valid'/>
注意：在这里，连接或者是通过type='valid'来证实其有效，或者报告连接无效invalid。如果连接无效，那Receiving Server 必须（MUST）终止XML流及underlying TCP连接。如果连接有效，Originating Server便可以发送数据Receiving Server则可以读取数据了；在此之前，所有发送给Receiving Server的XML节应该（SHOULD）被默认丢弃。
前面所述的结果是Receiving Server核实了Originating Server的身份，所以Originating Server能够发送，而Receiving Server则可以接收，在“初始流”（即，从Originating Server到Receiving Server的流）上的XML节。为了验证使用“响应流”（即，从Receiving Server到Originating Server的流）的实体的身份，必须（MUST）也完成在反方向上的回拨。
在成功的回拨协商后，Receiving Server应该（SHOULD）承认后来的由Originating Server通过已存在的有效连接发送的<db:result/>信息包（例如，发送给Receiving Server提供的子域或其他主机名的有效请求）；这使在一个方向上的初始的有效连接能够进行“捎带确认”。
即使回拨协商成功了，服务器还必须（MUST）验证从其它服务器接收的所有XML节是否包含有一个‘from’属性和一个‘to’属性；如果节不满足这个约束，接收这节的服务器必须（MUST）生成一个<improper-addressing/>流错误因素并终止XML流和underlying TCP连接。此外，服务器必须验证接收自其它服务器的节的‘from’属性包含一个提供给流的有效的域，如果节不满足这个约束，接收这节的服务器必须（MUST） 生成一个<invalid-from/>流错误因素并终止XML流和underlying TCP连接。这两个核查都有助于防止与特定节相关的欺骗发生。
6. Receiving Server向Authoritative Server发送一个stream header：
<stream:stream
xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server'
xmlns:db='jabber:server:dialback'>
注意：流的根元素上的‘to’和‘from’属性是可选的。如果命名空间名不正确，则Originating Server必须（MUST）产生一个<invalid-namespace/>流错误，并且终止XML流和underlying TCP连接。
7. Authoritative Server向Receiving Server发送一个stream header：
<stream:stream
xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server'
xmlns:db='jabber:server:dialback'
id='1251A342B...'>
注意：如果命名空间名不正确，那么Receiving Server则必须（MUST）生成一个<invalid-namespace/>流错误因素并且终止它与Authoritative Server之间的XML流和underlying TCP连接。如果流错误发生在Receiving Server和Authoritative Server之间，那么Receiving Server则必须（MUST）生成一个<remote-connection-failed/>流错误因素并且终止它与 Originating Server之间的XML流和underlying TCP连接。
8. Receiving Server向Authoritative Server发送一个确认key的请求：
<db:verify
from='Receiving Server'
to='Originating Server'
id='457F9224A0...'>
98AF014EDC0...
</db:verify>
注意：这里流过的是主机名，此主机名是在第三步中从Receiving Server的stream header到Originating Server的初始标识符，而key则是第四步中Originating Server发给Receiving Server的。基于这个信息，连同Authoritative Server网络中共享的secret信息，key得到了验证。任何可检验的方法都可被用于生成key。如果‘to’地址的值与 Authoritative Server承认的主机名不符，那Authoritative Server就必须（MUST）生成一个<host-unknown/>流错误因素终止XML流和underlying TCP连接。如果‘from’地址的值与在打开TCP连接时Receiving Server呈现的主机名不符（或者它的任何有效的域，例如Receiving Server主机名的一个有效的子域或Receiving Server持有的其它有效的域），那么Authoritative Server则必须（MUST）生成一个<invalid-from/>流错误因素并终止XML流和underlying TCP连接。
9. Authoritative Server 验证是否有效：
<db:verify
from='Originating Server'
to='Receiving Server'
type='valid'
id='457F9224A0...'/>
或
<db:verify
from='Originating Server'
to='Receiving Server'
type='invalid'
id='457F9224A0...'/>
注意：如果ID与第三步中Receiving Server所提供的ID不相符，那么Receiving Server必须（MUST）生成一个<invalid-id/>流错误因素并终止XML流和underlying TCP连接。如果‘to’地址的值与Receiving Server承认的主机名不符，那Receiving Server就必须（MUST）生成一个<host-unknown/>流错误因素终止XML流和underlying TCP连接。如果‘from’地址的值与在打开TCP连接时Originating Server呈现的主机名不符（或者它的任何有效的域，例如Receiving Server主机名的一个有效的子域或Originating Server持有的其它有效的域），那Receiving Server就必须（MUST）生成一个<invalid-from/>流错误因素并终止XML流和underlying TCP连接。在对Receiving Server进行了确认，Authoritative Server应该（SHOULD）终止它们之间的流。
10. Receiving Server告知Originating Server 验证结果：
<db:result
from='Receiving Server'
to='Originating Server'
type='valid'/>
注意：在这里，连接或者是通过type='valid'来证实其有效，或者报告连接无效invalid。如果连接无效，那Receiving Server 必须（MUST）终止XML流及underlying TCP连接。如果连接有效，Originating Server便可以发送数据Receiving Server则可以读取数据了；在此之前，所有发送给Receiving Server的XML节应该（SHOULD）被默认丢弃。
前面所述的结果是Receiving Server核实了Originating Server的身份，所以Originating Server能够发送，而Receiving Server则可以接收，在“初始流”（即，从Originating Server到Receiving Server的流）上的XML节。为了验证使用“响应流”（即，从Receiving Server到Originating Server的流）的实体的身份，必须（MUST）也完成在反方向上的回拨。
在成功的回拨协商后，Receiving Server应该（SHOULD）承认后来的由Originating Server通过已存在的有效连接发送的<db:result/>信息包（例如，发送给Receiving Server提供的子域或其他主机名的有效请求）；这使在一个方向上的初始的有效连接能够进行“捎带确认”。
即使回拨协商成功了，服务器还必须（MUST）验证从其它服务器接收的所有XML节是否包含有一个‘from’属性和一个‘to’属性；如果节不满足这个约束，接收这节的服务器必须（MUST）生成一个<improper-addressing/>流错误因素并终止XML流和underlying TCP连接。此外，服务器必须验证接收自其它服务器的节的‘from’属性包含一个提供给流的有效的域，如果节不满足这个约束，接收这节的服务器必须（MUST） 生成一个<invalid-from/>流错误因素并终止XML流和underlying TCP连接。这两个核查都有助于防止与特定节相关的欺骗发生。
