[Members] Publishing Non-Open-Standard Specifications

Ralph Meijer ralphm at ik.nu
Wed Jan 15 19:01:06 UTC 2020


On 15-01-2020 19:22, Dave Cridland wrote:
> On Tue, 14 Jan 2020 at 13:13, Marvin W <xmpp at larma.de 
> <mailto: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.


The standards process of the IETF is described in a lot more detail than 
ours. For reference, a good starting point is RFC 2026, section 4.2.2 
[1]. But I'm sure you can easily spend a day reading all of the RFCs 
updating this one.


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

We have the same problem, already, and would not like to see this affect 
our normal standards process.


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

Like the IETF we would need to be very explicit about this, were we to 
follow that example. Especially around it not being covered by some of 
our regular policies.

Do you know of any specifications that might have been a candidate, 
outside of OMEMO. I.e. is this actually a problem we need to solve?

[1] https://tools.ietf.org/html/rfc2026#section-4.2.2

-- 
ralphm


More information about the Members mailing list