[Standards] Experimental XEPs

Peter Saint-Andre stpeter at jabber.org
Thu Aug 16 15:35:20 UTC 2007

Dave Cridland wrote:
> On Wed Aug 15 21:01:07 2007, Peter Saint-Andre wrote:
>> The XSF is a standards development organization. We're supposed to be
>> developing standards. If people want to publish the results of their
>> experiments on their own websites as input to the XSF's standards
>> development process, they are free to do so. But as far as I can see,
>> nothing in the XSF's mission or bylaws dictates that such experiments
>> deserve to be published by the XSF.
> Actually I disagree. Not publishing (in some way, it doesn't have to be
> as a XEP) experiments and early-stage working documents, and in
> particular encouraging these to be privately published, does not
> encourage the kind of commonly-owned specification that can be developed
> into (or used as input for) a proper standard.
> I suspect - without much justification, I'll admit - that the result of
> encouraging specifications to be worked on outside the XSF would lead to
> fragmentation and proprietary extensions (by which I mean the term in
> the sense of not held under common ownership).

Yes, that result is to be avoided.

> A good SDO, therefore, not only encourages open participation (as we and
> the IETF do), but also encourages open publication of proposals (as the
> IETF does with it's I-D documents, which represent a low barrier to
> entry, centralized, publication mechanism). We tend toward promoting a
> "do or die" approach to publishing XEPs, which leads to the bulk of a
> specification being developed outside the XSF, potentially encouraging
> multiple non-interoperable approaches to the same goal.

Well, it's odd. I used to be very liberal about publishing JEPs (before
they were XEPs). This was back when the JEP Editor (me) decided which
specs would get published, and the only hurdle was that the spec was
properly formatted. Look at lots of the early specs and you'll see that
many of them were little experiments that people did. Then folks wanted
to control the process more and we instituted the Council as a gating
function. If it were still up to me I'd argue for the liberal approach.

> This has demonstrably happened with the whiteboarding proposals, and
> it's obviously not in our interests - whether that's as a result of the
> XSF's processes is most certainly a matter for debate, but I feel the
> XSF's processes might be adjusted to try to reduce this.

Yes, I prefererd the old way. But then I'm pretty much of an anarchist
anyway. ;-)

> I believe the best mechanism for encouraging interoperable protocols
> through the XSF is to support their publication, even when the proposal
> has flaws that the Council require to be rectified. Hence my comments in
> another message about adjusting our processes to allow for a long-term
> use of the Inbox without forcing publication as a XEP.

Or just publish-at-will and take greater care about reviewing specs.


Peter Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7354 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070816/08b6e9c5/attachment.bin>

More information about the Standards mailing list