[Members] XEP-0001: Remove impossible guarantee from XSF Objectives

Marvin W xmpp at larma.de
Thu Jan 16 12:11:18 UTC 2020


On 1/16/20 10:50 AM, Dave Cridland wrote:
> This is true, but the Council can veto any specification from becoming a
> XEP, and as such, one reason is that there are obvious blockers to the
> specification ever progressing to Draft. This is, I think, one of the
> few consistently applied reasons for veto.

I agree. But Experimental XEPs can be changed and in many cases IPR
issues can be resolved by changes (at least copyright, patents might be
impossible to resolve).

> But the reverse is not true - we can very much know if a specification
> is definitely covered by well-known and actively enforced IPR.

Yes, and in such cases we should do our best to resolve any issues. And
of course any pending issues (including IPR) are a reason for a XEP not
to advance to Draft.
> You know it has to be libsignal to do anything useful. I know that.
> Everyone knows that. But as long as we don't say...?

If XEP-0384 was underspecified in such that it does not mention
libsignal, it's straight forward to realize that it *can* be implemented
without libsignal. You could probably use libolm or something completely
different, as long as it has the some concepts (double ratchet, prekeys,
etc). It doesn't need to use libsignal's protobuf or constants at all.

Yes, in such cases it might be incompatible with other implementations,
but that's normal if XEPs are underspecified. And that's perfectly fine,
because it is Experimental. You shouldn't use it in production systems
and you should expect significant modifications - like using libolm
instead of libsignal.

> While I agree, I would also note that the sole purpose of Experimental
> XEPs is to develop them into the Final state.
> 
> If something prevents that, we should fail fast.

I agree, but read above: in many cases IPR issues can be resolved by
changes.

After all, you are well aware that issues with XEP-0384 are about to be
tackled, and the changes required to do so can also just be done in
XEP-0384, thus XEP-0384 is not damned to never develop into Final state.
On the contrary, XEP-0384 was originally rejected because it contained
references to libsignal, which could later on be easily added again (as
seen), thus blocking a XEP for Experimental because it has *solvable*
issues makes little sense to me.

Just to give you an example where your point is perfectly valid: *If*
there was an actively enforced patent on "counting reactions to a
message and display a summary of them", something like MAM-FC could not
be accepted, because that's one of its basic ideas that it summarizes by
counting and removing that feature would be a significant change to the
concept.


More information about the Members mailing list