Hi Florian, On Tue, 18 Oct 2022 at 18:55, Florian Schmaus <f...@geekplace.eu> wrote: > On 18/10/2022 16.01, Matthew Wild wrote: > > 1) Advertisement of supported "inline" features > > […] > > While implementing, I quickly realised that the server supporting > > SASL2 and also supporting XEP-0198 is not enough information to > > determine that the server supports negotiating XEP-0198 inline within > > SASL2. For this reason we added the <inline> element within the SASL2 > > stream feature element. This <inline> lists the features that are > > supported for SASL2 inlining. An example of this can be found here: > > https://dyn.eightysoft.de/final/xep-0388.html#example-2 > > …do we really need <inline/>? > > Couldn't clients create a sasl2 <authenticate/> nonza, opportunistically > adding all extensions the client suspects, derived from the stream > features, that server supports via bind2? Then we only need to require > that the server (briefly) acknowledges each supported feature in the > response, which is potentially already the case for the majority of > features.
I don't immediately see a reason why this really couldn't work, but it seems a bit awkward to me. Firstly, some extensions (such as bind2) can get a bit verbose, and I guess it's potentially a bunch of duplicated traffic on every connection. Also, it assumes that everything has a response from the server. New Bind 2 has a similar model, and there CSI does not have a response (just like when it's not inlined). > Features that the server does not support via sasl2, and hence where not > acknowledged, could be enabled "traditionally" by the client. This is > something clients may want to support anyway, in case the server does > not announce the feature <inline/>, but otherwise supports it. Or am I > mistaken here? I don't see why a server would support inlining a feature but not announce it correctly. > In any case, I feel that <inline/>, and related mechanisms, is more > bind2 territory than sasl2. If <inline/> stays in sasl2, then wouldn't > we potentially end-up with <inner-inline/> in bind2 too? New Bind 2 does indeed have its own <inline> too :) The split is between things that are enabled before resource binding, and those that are enabled after resource binding. You can see an example here: https://matthewwild.co.uk/uploads/xeps-tmp/xep-0386.html#example-1 > Luckily we appear to have already some implementations of the proposed > protocol (changes). Could the maintainers of such implementations maybe > provide some real world exchanges of the (currently) most sophisticated > sasl2 XMPP-session establishments currently being performed. I am > thinking of MAM, carbons, SM resumption, and more. I would like to get a > better understanding how sasl2 can be used with existing widely-deployed > protocols and with bind2. Or is bind2 outside the scope (for now?)? New Bind 2 is already implemented by at least Prosody, Conversations and Monal. We learnt a lot from our collaboration and testing, and have tweaked and improved various things along the way as we discovered what did and didn't work well during implementation. Overall, I'm pretty happy with what we have working. I think we have the opportunity right now to determine a new login flow that will see us through the next 20 years of XMPP. Over the past couple of decades we've bolted various things on (XEP-0198, carbons, etc.) that are almost universally implemented. This has led to the stream setup process getting quite difficult to explain to newcomers, increased complexity in clients and gradually worse performance on poor networks due to the required round-trips. We all knew about the problem - SASL2 and Bind 2 have been waiting in the wings for a while now, and combined together they allow the client to describe its desired stream state to the server, and the server to respond with the final state. Ideally these updates provide the XEPs with enough polish to make implementations practical and useful. Once SASL2/Bind2/XEP-0198 updates have settled, I plan to write up an informational XEP, mostly of examples, demonstrating possible connection flows. Meanwhile, as requested, here is an example flow from a real client (with some replacement of identifiers, etc.): https://matthewwild.co.uk/uploads/sasl2-example.xml In this flow, the client is using token auth, but SCRAM would be pretty much the same with the addition of a <challenge> and <response> in the middle. As well as resource binding, it also shows the client requesting to resume a XEP-0198 session, but the server responds that the session has expired. Because of this, the server proceeds to process the resource bind request, which includes a request to enable XEP-0198, and a new session is successfully established. Hopefully this helps put some of this stuff into context. Regards, Matthew _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
