[Standards] XEP-0384: Rejecting? [Was: Re: Proposed XMPP Extension: Ephemeral Messages]

Dave Cridland dave at cridland.net
Wed Jan 1 21:03:25 UTC 2020


On Wed, 1 Jan 2020 at 18:40, Maxime Buquet <pep at bouah.net> wrote:

> I'm curious if you have any viable alternative to propose while you
> reject the only widely used encryption mechanism? If not, I think doing
> this is only going to harm the community.
>
>
I don't think the only harm possible is by rejecting the only widely used
encryption mechanism we have. Another harm to the community is possible by
changing what we are without discussion from a standards group interested
interoperable solutions into a ... well, I honestly don't know what we are
if not that.


> It feels to me our current process doesn't reflect the reality of
> things.
>
>
I can't see what we do if we don't have specifications that you can
implement from. That is surely what we do?


> If you need a standard for your company use-case, OX is a thing.
> Otherwise maybe in 5-10 years we'll have MLS?
>
>
Or someone else can publish a non-standard, call it OMEMO.

Or just drop back to OTR if you need something non-GPL.

I get there's a need for E2EE. There's actually lots of different (and
sometimes conflicting) needs for E2EE. OMEMO fits some of these. But is the
XSF the venue for a common mechanism for using a library?

If we reject specifications at the ProtoXEP stage because they're not open
standard (RTMP, STANAG 5066, as previous examples - in the latter case NATO
simply published their spec after we prompted), shouldn't we reject OMEMO?
I should remind you that OMEMO *was* rejected at ProtoXEP stage for
precisely this reason, and was later reverted to being based off the Signal
library after acceptance.

Or is your view that we should allow XEPs based on specifications and
libraries with restrictive licenses?

If that is your view, I suggest you raise this at Board level; it would be
a radical departure from previous policy as established by precedent, and
would in my view represent a radical change in the XMPP Standards
Foundation's mission.

Dave.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200101/a758bfd3/attachment.html>


More information about the Standards mailing list