Fri, 25 Aug 2017 12:33:54 +0100 Dave Cridland <[email protected]> wrote:
> Comments are most welcome! While the spec itself is okayish at the first glance, I think it creates more problems than it solves. Really, two-factor authentication can be done using sequential SASL auth with stream restarts, requirement for password change can be done by updating XEP-0077 (using mandatory to negotiate feature, as I suggested in the previous discussion of the topic), a bind+resume+mam combo can be wrapped into some transation, hell, even stream restarts can be avoided by telling "hey, don't restart the stream, it's stupid" (because why not, we already bypass RFC6120 rules in this proto XEP). I personally really don't know how this solves problems of client developers, but for me, as a server developers, all this creates additional burden, because I need to maintain both SASL protocols anyhow, blowing already over-complicated stream management, so this only creates complexity for me. I'm absolutely not motivated implementing this just because client developers are pussies who failed to write code, and I really don't understand why otherwise one needs this new SASL stuff - I don't consider stream restarts and sequential stanza processing as a problem. Another problem is that with specs like this we move far and far away from RFC6120, rendering it more and more useless. _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
