Clarify SASL2 and BIND" interaction.
&xep0388; (SASL2) describes a way of inlining the stream resumption into the authentication process to reduce the round-trips needed for authentication and subsequent stream resumption. Similarly &xep0386; (BIND2) defines a way of inlining the stream management <enable/> into the resource binding process to reduce round-trips.
+To indicate support for inlining the activation of Stream Management into the resource binding process, the server adds a <feature/> element in the namespace "urn:xmpp:sm:3" into the <inline/> element of BIND2 which is sent in the stream features.
+If the client wishes to begin a new session (i.e. it has no prior session to resume), it simply includes the <enable/> element defined by this specification in its &xep0386; <bind/> request which itself is a child of the <authenticate/> element of SASL2.
+In the unexpected case where the server was able to bind a resource for the client, but unable to enable stream management, it will include a <failed/> element as defined by this specification within the <bound/> response defined by &xep0386;.
+To indicate support for inlining stream resumption into the authentication process, the server adds a <resume/> element in the namespace "urn:xmpp:sm:3" to the <inline/> element of SASL2.
+If the client wishes to resume an existing session it, it simply includes the <resume/> element defined by this specification in the SASL2 <authenticate/> element.
+Note: If the client included a <resume/> element in its SASL2 <authenticate/> element, that MUST be processed first by the server. If that resumption is successful, the server MUST skip resource binding (a resumed session already has a resource bound) and MUST entirely ignore the <bind/> request that might also be inlined in the <authenticate/> element.
+Sometimes resumption might fail - for example, because the session has been disconnected longer than the server’s resumption timeout. In this case, the server MUST include the <failed/> element defined by this specification in its SASL2 <success/> response, but also MUST continue to process the <bind/> in order to establish a new session for the client.
+The client can find details about its new session in the <bound/> response (defined by &xep0386;).
+As noted, a server MUST NOT allow a client to resume a stream management session until after the client has authenticated (for some value of "authentication"); this helps to prevent session hijacking.
+If SASL2 is used to inline stream resumption implementations must adhere to the security considerations defined in &xep0388; regarding the inclusion of SASL2 requests and inline feature negotiation in TLS 0-RTT ("early data") extensions. That is, they MUST NOT be sent or processed if the stream would be resumed solely based on 0-RTT data, except when appropriate mitigations are in place (which are beyond the scope of this document, but may be defined by others).