[Standards] XEP-0384: Rejecting? [Was: Re: Proposed XMPP Extension: Ephemeral Messages]
dave at cridland.net
Thu Jan 2 13:11:06 UTC 2020
On Thu, 2 Jan 2020 at 12:56, Marvin W <xmpp at larma.de> wrote:
> On 1/1/20 10:03 PM, Dave Cridland wrote:
> > I can't see what we do if we don't have specifications that you can
> > implement from. That is surely what we do?
> There is a number of XEPs that can't be implemented because they are
> inherently broken, have open TODOs in them or lack essential parts of
> the protocol by just not mentioning them.
> In contrast, OMEMO can be implemented from the XEP (by using libsignal,
> requiring GPL) and if you include the specifications under the public
> domain from https://signal.org/docs/ (which for some reason are not
> referenced in the XEP) and put some effort into it, it should be
> possible to do a clean implementation under public domain.
We have been specifically told that a particular library is required, and
that the documentation is not considered sufficient by those involved in
That is, the documentation explains what the library does (to some degree);
it is not sufficient to write a library from the docs alone.
> If you are more specific on what you need to implement OMEMO (beside a
> link to https://signal.org/docs/ of course) we can surely add that to
> the XEP. That is what the Experimental phase is for, to find issues in
> the XEP and fix them, not rejecting it because of existing issues.
These issues have been raised before, and nothing has happened (literally,
for 18 months).
In fact, these issues were raised prior to the XEP being adopted; it was a
ProtoXEP for weeks if not months as a result until it was agreed to base it
on the (similar, but well-documented) Olm instead.
Subsequent to its acceptance, the XEP was edited to use Signal again.
> Also please note that according to my understanding of XEP-0001, the
> council is not authorized to move a XEP from Experimental to Rejected
> without it being proposed first, which should only happen if the council
> agrees that the XEP is ready to be considered for advancement, which
> seems not to be the case. Check the nice state diagram at
The diagram is clearly marked as including the possible states, but does
not describe itself as exhaustive on what state transitions are allowed (or
"authorised"). Indeed, the Board fairly recently updated that diagram to
reflect the Council's common practice of bouncing XEPs back to Experimental
from Proposed rather than only to Draft or Rejected.
The text says:
A XEP of any type is in the Rejected state if the XMPP Council has deemed
it unacceptable and has voted to not move it forward within the standards
I am suggesting a motion that the XMPP Council deems it unacceptable, and
votes not to move it forward within the standards process.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards