From ca6c983db188e7adceaaa4b54e47e4793f0321ee Mon Sep 17 00:00:00 2001 From: Thilo Molitor Date: Thu, 17 Nov 2022 21:43:43 +0100 Subject: [PATCH] Clarify interaction with stream features after auth --- xep-0198.xml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/xep-0198.xml b/xep-0198.xml index b6e29980..ce27e058 100644 --- a/xep-0198.xml +++ b/xep-0198.xml @@ -33,7 +33,7 @@ 1.6.1 2022-10-05 tm -

Clarify SASL2 and BIND" interaction.

 +

Clarify SASL2 and BIND2 interaction.

 1.6 @@ -573,6 +573,7 @@

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;).