<remark><p>Modified recommended order of for server-to-server negotiations if service provisioning requires dialback after TLS negotiation.</p></remark>
<p>During its formalization of the core Jabber protocols, the IETF's XMPP WG introduced the concept of XML stream features. While the order in which features shall be negotiated is clearly defined for the features specified in &rfc3920; and &rfc3921;, the number of possible features is open-ended (which is why the ®ISTRAR; maintains a registry of stream features). This document specifies the recommended order for negotiation of various stream features.</p>
<p>&xep0138; is negotiated when it is not possible to set up TLS compression for whatever reason. It seems safest to negotiate stream compression after negotiation of both TLS (to safely complete the negotiation) and SASL (to prevent certain denial-of-service attacks). Therefore the following order is RECOMMENDED:</p>
<p>The &xep0077; protocol can be used to establish an account before logging in. That step would be completed before SASL because an entity cannot authenticate if it does not first create an account. Therefore the following order is RECOMMENDED:</p>
<p>The XMPP RFCs define an ordering for the features defined therein, namely:</p>
<ol>
<li>TLS</li>
<li>SASL</li>
</ol>
<p>That order MUST be followed if no other stream features are negotiated.</p>
</section2>
<section2topic='Dialback'anchor='s2s-dialback'>
<p>RFC 3920 requires SASL negotiation after TLS negotiation. When the certificate presented by the initiating entity makes reference to a trusted root certification authority, SASL negotiation provides meaningful authentication. In that case, the order shown above is recommended.</p>
<p>However, it is possible that the initiating entity will present a self-signed certificate or a certificate whose associated root certification authority is not trusted by the receiving entity. In this situation, service provisioning policies at the receiving entity may dictate the use of server dialback in order to provide a stronger level of trust for the server-to-server stream (where such trust is essentially trust in the underlying Domain Name System), even though server dialback explicitly does not provide authentication. In this case, the following order is RECOMMENDED:</p>
<p>&xep0138; is negotiated when it is not possible to set up TLS compression for whatever reason. It seems safest to negotiate stream compression after negotiation of both TLS (to safely complete the negotiation) and SASL (to prevent certain denial-of-service attacks). Therefore the following order is RECOMMENDED:</p>