[Standards] OMEMO Key Agreement
kevin.smith at isode.com
Fri Jun 2 11:48:26 UTC 2017
> On 2 Jun 2017, at 11:57, Daniel Gultsch <daniel at gultsch.de> wrote:
> 2017-06-01 13:12 GMT+02:00 Kevin Smith <kevin.smith at isode.com>:
>> On 1 Jun 2017, at 11:22, Daniel Gultsch <daniel at gultsch.de> wrote:
>>> I went ahead an created a PR for XEP-0384 to match what is actually
>>> implemented in the wild.
>>> I changed the track from Standards to Historical.
>>> I checked: Track changes have happened before and are apparently
>>> possible if Council agrees.
>>> I think this is the best way forward given that developers and users
>>> who are *currently* looking for the OMEMO spec are probably looking
>>> for this XEP and not OMEMO-NEXT.
>>> Also we don't have to assign a new author as it would be the case if
>>> XEP-0384 would become OMEMO-NEXT.
>> I think that, while someone interested in implementing OMEMO-SIACS might find it convenient for 384 to be changed in this way, what the XSF wants is to push people towards Standards Track XEPs and in this case, 384 seems to be the logical place.
>> Conceptually, changing 384 to historical and changing the content is very odd
> If it is easier 'conceptually' I'm also fine with leaving it in the
> Standards track and marking it as deprecated.
> The point is that OMEMO in its current form is extremely popular. How
> many XEPs have Wikipedia and online news media (LWN, Golem) articles
> written about them?
I think that’s a significant argument for why 384 needs to remain the location of the XSF’s ongoing work on this. Many people are, as you note, interested that the XSF is working on a standard here, so saying “We’ve stopped working on it” would be misleading and unhelpful.
> If the current consensuses is to take OMEMO in a different direction
> with OMEMO-NEXT that's fine. But don't water down the current state by
> sending it to the attic.
> The state of OMEMO as described in my PR is what people will use for
> the foreseeable future.
I can see an argument for publishing a standards-track version of 384 reflecting the current state, so there’s a stable identifier for it under version 0.x, to reflect what’s deployed, before moving on with further development. Another option would be publishing a Historical XEP, and having a prominent reference to that in 384.
> If the XSF wants to push people in a different
> direction (OMEMO-NEXT) they can do this by deprecating XEP-384 (and
> create a link to OMEMO-NEXT)
I think the XSF’s focus should be on the ‘right solution’, not on how to best support some pre-standardisation implementations.
More information about the Standards