[Members] Publishing Non-Open-Standard Specifications

Jonas Schäfer jonas at wielicki.name
Thu Jan 16 18:18:42 UTC 2020


On Donnerstag, 16. Januar 2020 16:56:03 CET Guus der Kinderen wrote:
> 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. 

Actually, I think adoption by someone except the XSF would be great, but I 
fear that this is not going to happen. Instead, we will see tribal knowledge 
like with AESGCM and the various MUC hacks which are barely documented. This 
makes it hard for newcomers to implement a modern XMPP client.

I, however, see your points about being an Open Standards organization and 
having principles. Maybe we simply need to find a different venue for some of 
the extensions needed for XMPP-as-a-modern-IM-system. That feels like a lot of 
overhead for AESGCM and OMEMO though.

kind regards,
Jonas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/members/attachments/20200116/7b4c77bb/attachment.sig>


More information about the Members mailing list