Clarify SASL2 and BIND" interaction.
Clarify SASL2 and BIND2 interaction.
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.
+&xep0388; mandates that the <success> element is immeditaly followed by stream features. If a former stream has been successfully resumed using this specification, the stream is considered re-established immediately after the <success/> element instead and stream features MUST NOT be sent in this case.
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;).