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/
smime.p7s
Description: S/MIME Cryptographic Signature
