Here are links to unpublished yet versions of XEPs which have changes (or comments with changes) and should be published soon. We should use them as those are expected to be published soon and to be implemented:

• https://matthewwild.co.uk/uploads/xeps-tmp/xep-0386.html
• https://pad.nixnet.services/nBuJUsKFRxaEmwvoB9E8Ag?view#Example-1-Server-indicates-support-for-inline-resource-binding
• https://xmpp.org/extensions/xep-0386.html
• https://dyn.eightysoft.de/xeps/xep-0388.html#outcome

@bmalkow I've implemented support for SASL2 and Bind2 and pushed those changes to issue #1332 branch of Tigase XMPP Server. Please use this version of server for testing your implementation and if/when you'll have Halcyon ready, we will need test cases in TTS-NG for SASL2 & Bind2 (including stream management resumption part).

Our current implementation does not support "upgrade" mechanism, but it can be used only if advertised by the server, so we can add it later on.

@bmalkow I've reviewed your test cases for SASL2 for TTS-NG and they look ok.

However, I think those test may fail in rare cases, ie. when run as a first test (or last one?) on our build machine. In this case, admin account may do not exist on the server and TTS-NG (Jaxmpp) checks if account exists (tries to log in) and if it fails to confirm account exists it tries to create it. On the other hand Halcyon test just uses existing account and this may not work if account would not exists (wouldn't be created by Jaxmpp).

Moreover, Jaxmpp tests which are creating accounts (also admin account), vhosts, pubsub nodes and api keys are after execution cleaning up after tests, by removing all created accounts, vhosts, pubsub nodes and api keys (created for or during the test). If I'm correct, those accounts are removed even if tests will fail. This is done by usage of "managers" which are created in "base" test class which are informed by @AfterSuite annotated method, that tests are completed and we need to clean up.

I think that for current use, it would be good it Halcyon base test class would exist and at least register and remove (if needed) admin account after the test. I think, this could be done by usage of AccountManager java class in Kotlin code (at least to keep if simple for now).

As are going to release Tigase XMPP Server 8.3.0 now, I'm disabling by default preview implementation of SASL2 & Bind2 in the source code before the release.

To enable it, please enable SASL2 and Bind2 beans in sess-man section as in the example:

'sess-man' {
    ...
    'urn:xmpp:bind:0' () {}
    'urn:xmpp:sasl:2' () {}
    ...
}

While working on BeagleIM/Martin, I've identified the issue with SASL2/Bind2. When SASL2 processor was processing Bind2 and other inlines (in it), session was considered authorized and resource was bound (due to Bind2 being inlined). That resulted in Stream Management and Message Carbons being enabled on the account that was authenticated and bound (correct behavior). However, due to longer processing time, this allowed Tigase XMPP Server to start delivering stanza to the new connection before it <success/> response was sent back.

I've resolved that issue by postponing setting resource to "after" Bind2 inlines are processed.

With those changes now SASL2 works correctly (at least with Martin, Beagle, and Conversations).

I wonder if we should not enable it now on some of our deployments for testing and for faster reconnection speeds.

I wonder if we should not enable it now on some of our deployments for testing and for faster reconnection speeds.

+1, let's start with tigase.org and dogfood it?