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

Dave Cridland dave at cridland.net
Thu Jan 16 09:50:12 UTC 2020

On Wed, 15 Jan 2020 at 22:30, Marvin W <xmpp at larma.de> wrote:

> I'd like to explain why my understanding of this does make more sense to
> me than yours.
The reason is primarily because it's your idea. If you didn't think it made
perfect sense to you, there would be a terrible idea. Everything else is

> In XEP-0001 it is written twice (in § 5 and § 8.1) that acceptance as
> experimental XEP does not imply any level of approval.

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 also think that the bare nature of the Experimental status conflicts
> with your understanding of IPR policy. If an Experimental XEP is
> underspecified (which happens a lot) the underspecified part can contain
> references to protocols with IP Claims, but it is impossible to verify
> this, because of underspecification. Due to its nature of rapid
> updating, it may also easily happen that an intermediary state of an
> Experimental XEP has IP Claims on it and as long as this is not intended
> I wouldn't see a problem with that, as production systems are not
> supposed to be created from Experimental XEPs (and if you only implement
> something for testing, you usually don't have issues with IP anyway).
There is, as Travis likes to point out, no way we can ever truly know if a
specification is not covered by a patent that could stand up in a court of
law, for example. The IETF deals with this by requiring contributors to
list any IPR they think might affect the specification.

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

> As the PR #878 suggests, replacing "Signal" with "TODO" in XEP-0384 may
> make it less useful for anything but experimental implementations, but
> obviously also means that noone can argue there are any Claims that
> would prevent its implementation.

"Pay no attention to the man behind the curtain."

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...?

As a more general remark: I think us putting efforts into having high
> quality Experimental XEPs is just another sign of failure for getting
> our standardization process right. If it was generally accepted that
> Experimental XEPs are not intended for production use (as this is
> written in ever Experimental XEP), we probably wouldn't have this
> discussion. By not advancing XEPs in the standardization process, all
> the rules that made sense once do not work that well anymore. If
> companies request they get Experimental XEPs implemented for a
> production system, we should consider this a problem of our process,
> because apparently it means nothing anymore if a XEP is Experimental,
> Deferred, Draft, Final or even Deprecated (I am looking at you XEP-0071).

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/members/attachments/20200116/71d582e8/attachment-0001.html>

More information about the Members mailing list