[Standards] XEP-0384: Rejecting? [Was: Re: Proposed XMPP Extension: Ephemeral Messages]
ralphm at ik.nu
Thu Jan 2 14:17:47 UTC 2020
On 02-01-2020 14:36, Marvin W wrote:
> The board did not update the diagram alone, it also specifically added a
> rule in the text to allow that behavior . If it happened before, it
> was behavior outside the rules of XEP-0001.
We updated this for clarity, so there's a clear process.
>> 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.
The "removing from further consideration" means retraction in this
context. That's is up to the author, but unrelated to moving to Rejected.
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
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.
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.
More information about the Standards