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

Dave Cridland dave at cridland.net
Thu Jan 2 15:08:05 UTC 2020

On Thu, 2 Jan 2020 at 14:46, Marvin W <xmpp at larma.de> wrote:

> The council already accepted
> the general idea when it allowed OMEMO (even if it was different back
> then) to become an Experimental XEP.

No, that's not the case at all.

Council's acceptance was predicated on the change to use Olm instead of
(what was then) Axolotl.

The ProtoXEP was then changed to use Olm, accepted (and published as
XEP-0384) and then changed back afterwards.

So Council actually explicitly rejected the form this XEP has taken.

> So I think it's rather the task of
> the council to help with the development of this XEP so that it can
> advance to Draft instead of rejecting it while still in development.

Again, no. The Council doesn't have any obligation to help develop any
XEPs, least of all any moral obligation to help a XEP it explicitly

> I agree there was little development progress on this specific XEP in
> the last 12 months, which is a good reason for it to be send to deferred
> state.

No development at all for in excess of 12 months means that the XEP should
have been automatically deferred, there's no decisions to be made here.

> Also, one could ask the author if they are willing to continue
> the development, move ownership to a different person or completely
> retract it, so this doesn't get stuck.

We could indeed, but the author hasn't done anything for years so I feel we
can skip that step. Indeed, the author hasn't done anything since first
writing the XEP.

> But this spontaneous "let's get rid of what many use in practice and
> what significantly boosted XMPPs popularity in the last years" without a
> proper replacement plan makes little sense to me.

It's not spontaneous. This was because it was explicitly and unequivocally
clarified on this list that the XEP depends on a GPL library, as was
originally rejected by Council in 2016.

> Funny that you mention MLS. I am all for looking forward for MLS, but I
> am also pretty certain that the current state of MLS can not be fully
> implemented from its documentation (because it is not finished).

This is a silly argument for two reasons:

1) There is a clear intent that the specifications will be completed and
will be available to implement without restriction (ie, any person will be
able to implement without encumbrance). This is no more than what we expect
from a mature standards organisation. It should be what we hold ourselves
to as well.

2) It can be implemented from the specifications, and indeed has been.
These specifications may, however, change - but that is not a good reason
to reject a specification based on them since after all that's the case for
Experimental anyway.

You keep conflating the notion that OMEMO is incomplete with the notion
that it is not possible to create an unencumbered implementation. These are
entirely distinct concepts.

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

More information about the Standards mailing list