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

Dave Cridland dave at cridland.net
Thu Jan 2 14:12:35 UTC 2020

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

> On 1/2/20 2:11 PM, Dave Cridland wrote:
> > We have been specifically told that a particular library is required,
> > and that the documentation is not considered sufficient by those
> > involved in OMEMO.
> Any information that is required beside the documentation and the XEP
> can be added to the XEP. That's why the XEP is in Experimental state,
> it's not finished and still has pending information. Until now, I am not
> aware of anyone trying to implement the OMEMO protocol just from
> documentation existing to find out what is missing from the current
> documentation. This might be a good reason to move the XEP to deferred,
> but not to reject it.

Well, my view is that if we would have (and, indeed, *did*) reject a
ProtoXEP on this basis, we should reject it now if it explicitly violates
that same basis.

Moreover, deferred is automatic and should have happened months ago - the
last substantive edit was made in May 2018.

The information needed to be added to the XEP does not, we are informed,
exist. Someone would have to write a specification for the Signal Protocol,
and given that should the Signal library changed, it would be meaningless,
it's a waste of time and effort.

Let's get this entirely straight for the record:

1) The document was submitted as a ProtoXEP in October 2015.

2) The Council rejected it because it was based on a GPL library rather
than a specification (and, moreover, the copyright owner of that library
had been known to declare any other implementation of the protocol a
violation of his copyright).

3) After much discussion, an agreement was reached where the OMEMO would be
based on Olm. This change was made in September 2016, and the document was
adopted as a XEP in December 2016.

4) In June 2017, this change was essentially reverted and the namespace
changed to a non-standard namespace. This essentially subverted the
Council's previous decision. The argument given at the time was that Signal
now had documentation (though this has now been revealed as a sham).

Since then, the only edit that could be claimed as vaguely substantive has
been a change to the (informative) schema in May 2018.

> > 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 board did not update the diagram alone, it also specifically added a
> rule in the text to allow that behavior [1]. If it happened before, it
> was behavior outside the rules of XEP-0001.
> > 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 process.
> You are merely quoting from the description of the Rejected state, it
> does not describe when the council is allowed to do so. For a standards
> track XEP there is a very accurate specification of the possible state
> changes (even outside the diagram):
> > The ideal path is for a Standards Track XEP is to be advanced by the
> XMPP Council from Proposed to Draft to Final (the criteria for this
> advancement are described in the following paragraphs). However, an
> Experimental XEP shall be assigned a status of Deferred if it has not been
> updated in twelve (12) months (e.g., because of a lack of interest or
> because it depends on other specifications that have yet to move forward).
> In addition, rather than being advanced from Proposed to Draft, a Standards
> Track XEP may be voted to a status of Rejected if the XMPP Council deems it
> unacceptable. (Note that if a XEP is Deferred, the XMPP Extensions Editor
> may at some point re-assign it to Experimental status, and that, even if a
> XEP is Rejected, it is retained in source control and on the XMPP Standards
> Foundation website for future reference.) Finally, (only) a XEP author may
> voluntarily remove an Experimental XEP from further consideration,
> resulting in a status of Retracted.
> Note how it explicitly says that *only* the XEP author may remove an
> Experimental XEP from further consideration. You are trying to do so
> without being the XEP author so you are clearly violating this rule.
I read that as says that only an author can move it to Retracted.

But I accept it could be read as you interpret it. I'll alter my motion to

a) Move the document to Proposed and then immediately to Rejected. (I don't
see any requirement to Last Call, merely that a Last Call so moves it).

b) Move the document to Proposed by issuing a Last Call and thence Reject

c) Change the document's author to a Council member and Retract it.

The latter two are procedurally simplest, though both feel like they're
dancing around the point.

Alternately I can create a PR for XEP-0001 and place it before the Board.

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

More information about the Standards mailing list