Fri, 25 Aug 2017 17:39:14 +0100 Dave Cridland <[email protected]> wrote:
> 1) On the server side, handling both SASL profiles is actually > surprisingly simple, in my experience. The protocol as documented is > based on actually implementing it in full. I disagree. Maybe a mess with if/else is okay for you, but not for me. I have a well-defined finite state machine, adding new SASL means that I need to expand it, adding more states and transitions and this definitely complicates the FSM. > 2) Two-factor authentication isn't like two lots of single-factor. I > was surprised too - you'll note that this was how the first version > was modelled, and it's a real pain to make work. Not sure why it's significantly harder to implement, but ok. > 3) I felt it was simpler to ensure that on <success/>, the stream was > authenticated, whereas before it wasn't. Simplifies stream security. I didn't get this. How on earth <success/> could mean the stream is not authenticated? > 4) I'm not motivated to write this because client developers are > pussies - I don't think they are. I'm motivated to write this because > our general framework for session establishment in XMPP is an > organically grown mess, and starting over seems reasonable if the > gains are high enough. That's true. But our way looks like patching the mess, instead of getting rid of it. > We gain solid 2FA OK > significant RTT reduction Maybe a significant reduction in RTT, but this is a little part of the whole session traffic (the large part of which are pointless presences and some PEP). So you will connect in 1 second instead of 2. No? Then do you have benchmarking? > and atomic session establishment Yeah, I would like to see its fantastic atomicity in practice. _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
