[Standards] OMEMO Key Agreement

Florian Schmaus flo at geekplace.eu
Fri Jun 2 12:12:29 UTC 2017


On 02.06.2017 13:48, Kevin Smith wrote:
> 
>> 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.

Nobody wants the XEP-0384 to say "We've stopped working on OMEMO", that
is why we add put a big notice with an link to OMEMO-NEXT on top.

- Florian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 642 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20170602/3aa23881/attachment.sig>


More information about the Standards mailing list