On 1/16/20 2:49 PM, Dave Cridland wrote: [ historical inaccuracies elided :P ]
> > Peter Saint-Andre (I think) designed our standards process to > avoid the > > Internet Draft stage and go straight to the wild-west of Experimental, > > but it's otherwise the same as the original IETF design. > > Originally, the Editor (me) accepted anything for publication as a JEP, > after minimal coherence / formatting checks and IPR assignment. Then the > Council decided it wanted to act as a gate to publication, which is how > got here. Instead of adding more epicycles, I propose that we remove the > one we added. Consider me in favor of the "Daniel Plan". > > I can easily be persuaded to go for the Florian Plan (or indeed the > closely-related Kev Plan), but I rather lean toward the Daniel Plan - as > you note, it fits the history of the XSF much better. I would be > fascinated to hear the original reasoning for the Council wanting the > veto in the first place, and I doubt it has much to do with how it's > used now. Control. Power. The usual suspects. ;-) I don't exactly recall - we'd need to look at the list archives. But I'd say this happened in 2004 or 2005 because, for instance, XEP-0143 went directly to version 0.1 on 2004-09-15 whereas subsequent specs underwent several and sometimes multiple revisions based on Council feedback before being published as XEPs. > My concern is that on several occasions the Council has been the only > thing preventing encumbered specifications from entering the Standards > Track, so I think this use of the veto is risky to lose entirely. Did we receive any encumbered specifications before ~2004-2005? Did this issue even arise back then, and if not does it make sense to attribute this magical power of saving us from encumbered specifications to the Council? How do we determine that specifications are encumbered and do we actually need the Council for that? Peter _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
