[Standards] XEP-0384: Rejecting? [Was: Re: Proposed XMPP Extension: Ephemeral Messages]
xmpp at larma.de
Thu Jan 2 14:46:09 UTC 2020
On 1/2/20 3:17 PM, Ralph Meijer wrote:
> The "removing from further consideration" means retraction in this
> context. That's is up to the author, but unrelated to moving to Rejected.
I read this as if such "remove an Experimental XEP from further
consideration" happens, it is a retraction. And that this can only be
done by the author. It doesn't say "only a XEP author can move to
retracted", it says "only a XEP author may remove, resulting in retracted".
I also think that this makes perfect sense. After all Experimental XEPs
are still in development and unfinished. The council already accepted
the general idea when it allowed OMEMO (even if it was different back
then) to become an Experimental XEP. 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.
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. 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.
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.
> The bigger problem is the change by Daniel back in 2017, that changed
> the specification to be based on the so-called Signal Protocol. It is
> unclear to me if it is possible to implement OMEMO without libsignal
> and/or in non-GPL implementations. If that is indeed not possible, it
> violates one of the XSF Objectives set out in section 2 of XEP-0001:
> 4. To guarantee that any person or entity can implement the protocols
> without encumbrance.
> And thus, unless this restriction is somehow lifted, XEP-0384 cannot
> progress within our standards process. Eventually rejecting it seems a
> valid course of action to me, and I am not even sure if it can remain
> Experimental or Deferred because of this.
As mentioned before, we have a a number of Experimental XEPs that cannot
be implemented due to lack of documentation. I don't see why the partial
lack of non-GPL documentation is a bigger issue than the lack of any
Nobody argues to propose the XEP for becoming a Draft (well Dave just
did, but merely to bypass the rules).
> The earlier mentioned MLS effort at IETF specifies a new protocol based
> on the Double Ratchet Algorithm, which would be free to implement for
> everyone. Maybe we should put more effort in supporting this.
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).
More information about the Standards