[Standards] Experimental XEPs

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


Dave Cridland wrote:
> On Wed Aug 15 22:57:23 2007, Peter Saint-Andre wrote:
>> Based on my experience in the IETF since 2002, I am not familiar with a
>> formal process for doing draft proposals there. You just publish an
>> Internet-Draft, others may propose similar or competing I-Ds, and you
>> hash it out on mailing lists and at in-person meetings. Hmm, that sounds
>> awfully familiar...
>>
>>
> There is a formal process, it's just very lightweight.
> 
> In order to publish an ID, you need to have the formatting correct and
> have the IPR boilerplate correct (and current). You also need to name
> your draft correctly, and a handful of other minor things.

That's essentially the approach we had for the first 2+ years of our
existence.

> In return, the IETF Secretariat then publish it for you for six months.
> In practice, it's longer than that, since the Tools Team publish the lot
> in perpetuity.
> 
> This is all very similar to the Inbox we have, although there's a
> general expectation that a document still undergoing serious work will
> remain an ID - it's only published as an RFC much later in the process,
> when it's generally believed to be finished. This is in part a
> reflection of the original paper-based publication method - once
> something's published, you can't change it if it's been sent out in the
> post. (Anyone wondering why they used to be paper needs to figure out
> what the IETF developed).
> 
> For our purposes, simply lessening the expectation that anything hitting
> the Inbox should immediately be published or killed would be sufficient.

Or simply publish-at-will, but lessen the expection that publication as
a XEP means much of anything. It's advancement to Draft that has meaning
(roughly equivalent to advancement of an I-D to RFC).

> I would personally recommend revisiting XEP-1's section 5. In
> particular, I'd suggest that the publication of something in the Inbox
> and the request to the Council should be distinct actions, and the
> latter should be handled by the document author, not the XMPP Extensions
> Editor. (Although they're often the same person...)
> 
> I suspect that this would reduce the number of published XEPs, leaving -
> hopefully - only those that we want to keep, and only that subset of
> them that are reasonably stable and complete.

Or give Draft and Final XEPs special prominence, and Experimental XEPs
less prominence. We used to do this via http://www.jabber.org/protocol/
(showing only approved specs).

> As for developing WG-like entities again, we could certainly look at
> that. There are advantages to this kind of behaviour - we limit the
> traffic on mailing lists somewhat - but it can also lead to
> fragmentation. 

In the past it has led to fragmentation and fewer eyes reviewing specs.

> It might be better to encourage initial design work to
> happen on alternate lists, but to move back onto the primary list for
> finalization, to gain a wider audience (in particular before it becomes
> a XEP). I think it needs thought. (Which could come from a SIG, of course).

We've tried that too, but it hasn't worked so well either.

Maybe we need to have more groupchat meetings in the design phase (wow,
what a concept, use our own technologies!) and then move things more to
the list once we've finished that brainstorming/design phase.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- 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/4d64f9e2/attachment.bin>


More information about the Standards mailing list