Hi Flo, This feels somewhat like trying to torpedo the current compromise that’s on the table, so I’d like to make some comments.
On 7 Jun 2017, at 14:48, Florian Schmaus <[email protected]> wrote: > The council will likely soon [1] decide if the currently used OMEMO > protocol will be published as the next version of XEP-0384. While that > is great, the plan is to shift following versions of that XEP away from > the Double Ratchet Algorithm using XEdDSA. This means that newer > versions will be incompatible with all currently deployed OMEMO > implementations. This probably needs clarifying. There are no currently deployed OMEMO implementations (of which I’m aware) - everyone is implementing something that is different to the OMEMO spec. > As consequence, end-users will continue to use an old > version of XEP-0384 for the foreseeable future. This seems an odd argument to make on behalf of clients that were quite willing to implement a version of the protocol that was never standardised. If they had been that concerned about their compliance to XEP-0384, I suspect they would have implemented it instead of something else. We have on the table a compromise that both lets the existing clients say that they support (a particular version of) 384, while also letting 384 fulfil its original purpose of being a standards-track protocol. > there will be no canonical and official place within the XSF where the > currently used protocol can further evolve, That’s not really true, is it? Unlike currently (where the currently used protocol isn’t canonical, official, or within the XSF), this compromise does provide somewhere for the protocol to develop, as is always intended with Experimental XEPs, while also allowing existing clients to claim they implement OMEMO/XEP-0384, which they currently can't. > where we can address > security issues and specify new features. We would bury one of the most > successfully deployed XMPP end-to-end encryption system for the masses. Quite the opposite. This is trying to be a compromise that works (but is not ideal, this is the nature of compromise) for the various parties here. /K _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
