[Members] Publishing Non-Open-Standard Specifications
dave at cridland.net
Wed Jan 15 21:06:27 UTC 2020
On Wed, 15 Jan 2020 at 19:01, Ralph Meijer <ralphm at ik.nu> wrote:
> 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
> > > 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
> > 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
> > 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
> 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
> . But I'm sure you can easily spend a day reading all of the RFCs
> updating this one.
Quite; and RFC 2026 et passim only cover those RFCs from the "IETF Stream";
there are other streams as well.
> > 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
> > 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.
We do have the same problem to a degree, though we also have a current
situation wherein it doesn't matter as much.
I agree wholeheartedly that I wouldn't want this to make the problem worse.
However, unless the XEP Editor wants to explicitly say that an entirely new
document is a totally acceptable increase to their workload, I'm going to
assume it'd be an unfair imposition, and a mere new Type is preferable.
> > 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.
Unlike the IETF...
Yes, I agree, which is why I am suggesting boilerplate text at the top of
the document which clearly indicates this status in general terms, and
ideally I'd appreciate some text somewhere in the XEP which indicates what
the IPR pitfalls are for that case.
> 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?
I don't know of any other XEP currently.
Previously, this would have applied to the RTMP XEP (referenced here, but
seems to have actually been deleted from the Inbox:
would have applied to the STANAG 5066 XEP originally (See the thread
discussing this here:
also explains the RTMP case.
Both of these are moot points now - NSO published STANAG 5066 openly, and
RTMP was a Flash thing which is probably of no interest to anyone anymore.
But whenever these things come up, they are highly contentious. The
compromise that allowed OMEMO to be published was that it would be "fixed";
this hasn't happened and that has left us in the awkward position we find
ourselves in. Part of the reason this compromise was arrived at was a
strong feeling that the XSF *should* document OMEMO as it was deployed,
even though this would have meant pointing to a specific archived version
of the XEP. Unfortunately, this has ended up resulting in a Standards Track
XEP that does not meet our requirements - or indeed anyone's - for an Open
Had we had an External Type, or another document stream, I think we'd have
picked that option, and avoided much of the entire saga.
A closely related case would have been the discussions around what became
XEP-0299, where we had essentially no viable Open Standard choice for a
video codec (but many widely implemented proprietary options). While this
resulted in no MTI video codec at all, and probably wouldn't have been
helped by an External Type, it would have allowed us to document H.264 over
Jingle and others which might have helped general Jingle video adoption -
again, this is a moot point now.
So overall, the question of publishing pragmatic [and ideally clear and
interoperable] specifications which do not qualify as Open Standard has on
multiple occasions caused considerable heat and little light. The proposal
here is to reduce the heat and increase the light.
As a compromise, I am not expecting anyone to like it. I'm just hoping
everyone can agree not to hate it.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Members