[Members] Publishing Non-Open-Standard Specifications

Dave Cridland dave at cridland.net
Wed Jan 15 18:22:12 UTC 2020


On Tue, 14 Jan 2020 at 13:13, Marvin W <xmpp at larma.de> wrote:

> > The XMPP Standards Foundation was founded in the year 2001 to openly
> > document, safeguard, manage, and extend the wire protocols used within
> > the XMPP developer community.
>
> So what if there is a wire protocol used within the XMPP developer
> community, there are >10 clients that fully implemented it and >5 with
> incomplete implementations. That wire protocol it so popular, some
> people would implement it before MUC in a new client. According to §2 we
> are supposed to document, safeguard, manage and extend such protocols,
> not to reject them.
>
>
This, I thought, was an interesting and valid point.

There is an obvious tension between the desire to publish a reasonably
popular protocol, and the desire to ensure the protocols we do publish
conform to the definition of an Open Standard. I see the latter as
paramount, but I understand the desire to do the former.

The IETF resolves this by publishing things as Informational if they are
unsuited to Standards Track; whereas we have no similar XEP Type - our
Historical comes closest but is still only for use as a mechanism to
publish specifications which meet the essential definition of Open Standard.

But in the spirit of compromise, rather than either outright refusing to
publish such specifications, or destroying the XSF as an Open Standards
organisation, I wonder if there's an alternative where the XSF
[exceptionally?] publishes some specifications that are important for
various reasons but do not conform to the definition of Open Standard.

We could:

a) Publish the XEP in a new type, call it "External", and mark all such
XEPs as "This XEP describes a specification that was developed externally
and may impose additional licensing requirements yada yada yada". This
would have a single State of Active, perhaps with an Obsoleted/Rejected/etc
state to indicate withdrawal etc.

b) Change "Historical" to match this, as this is the closest existing type.

c) Create an entirely distinct specification, no longer a XEP.

I believe those are the only options that fit such a compromise, though I
may be wrong.

Of these, I least prefer (b), since many useful and well-deployed Open
Standards are Historical. I like the notion of (c), especially given the
difficulty the IETF has with getting people to understand an RFC is not
always a "Standard" in any form, but I suspect it has an overhead that's
quite significant.

That suggests our best option is (a).

If such a thing existed, I would propose that XEPs are adopted into it only
by Council, as with other XEPs. Being Active from the outset means that
further edits would also be under a vote by Council, to avoid performing
any kind of "end run" around the standards process. I'm not very clear on
precisely what guidance we should give to Council on this, however.

Would this be an acceptable path forward?

Dave.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/members/attachments/20200115/809edb5f/attachment.html>


More information about the Members mailing list