[Members] Publishing Non-Open-Standard Specifications

Guus der Kinderen guus.der.kinderen at gmail.com
Thu Jan 16 15:56:03 UTC 2020


On Wed, 15 Jan 2020 at 19:22, Dave Cridland <dave at cridland.net> wrote:

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

Your goal of compromise is admirable. Thanks for putting in so much effort
once again. It is greatly appreciated.

If the goal of the XSF is to be an Open Standards organisation in the way I
feel you and me define it, I feel that it cannot promote a XEP that clearly
breaks with that objective. I feel that we should stand by our objectives,
as those reflect primary principles of the XSF. By introducing
'wiggle-room', we'd send out a signal that we have principles, but only
when they're not inconvenient.

I'm also worried about the precedent that this creates.

Not publishing (or advancing) a specification does not mean that all of the
previous work suddenly dissolves into thin air. For reference purposes, all
of what has been published will remain available for people to base their
implementations on. And, true, we'd limit future development of such a
specification (or risk it being adopted by another entity than the XSF),
but I feel that, in such cases, this is the lesser evil. Specifications
that are submitted to the XSF that break with its objectives should end up
in Rejected (explicitly stating why) as far as I'm concerned. If we don't
do this, we might as well remove the objective.

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


More information about the Members mailing list