On Thu, 5 Jan 2023 at 21:38, Florian Schmaus <f...@geekplace.eu> wrote:
> On 05/01/2023 16.31, Peter Saint-Andre wrote: > > On 1/5/23 3:18 AM, Florian Schmaus wrote: > > > >> I become more and more convinced that we may be better with an IETF > >> I-D / RFC style standardization process. Where an I-D is a mutable, > >> living document on the road to become an immutable RFC. > > > > You know, we could move all of our activities to an IETF Working Group... > > I would not want to replace our document tooling with xml2rfc. I really > like what we have to produce high quality publishable standards documents. > > > It is really just the process that needs to change. My idea is as follows: > > I think all you've done is "shift left", so that ProtoXEPs take the place of Experimental, and Stable/Final become formally frozen in terms of compatibility. Changing Experimental for ProtoXEP is really just a name change (modulo you'd like to publish without Council approval, and I am ambivalent to that). You're removing, though, a lot of the protections for deployability we have with Experimental. Then you're tightening Stable/Final, so that namespace bumps there would never happen (though they're astonishingly rare now). So I'm left wondering what problem you think you're actually solving here? It might - if we're to rehash the standards process at all - be good to list the desirable outcomes, then the problems we have, and only then worry about finding a solution. I don't pretend our process is perfect (or slim enough), but I do think it's mostly OK. > Introduce an I-D-like incubating phase of ProtoXEPs. Everyone is able to > create a new incubating ProtoXEP, no Council review required. The > ProtoXEP is mutable at any time and there are no namespace bumps > required for breaking protocol changes. But there are fixed revisions of > incubating ProtoXEPs that can be referenced (akin to I-D revisions). > > When the authors feel the ProtoXEP is ready for a council review they > submit it. The council should check, amongst other things, if the > specification is idiomatic XMPP (but ideally, such things are already > taken core of in the incubating phase). Even if the council demands > breaking changes to the specification it should be trivial to > incorporate them, as specification was a moving target before anyway. If > the authors oppose the changes, then they still have a document with a > stable ID (and URL) to share, even if not blessed by the council and not > a "real" XEP. > > Once the council accepts a ProtoXEP and it becomes a XEP. And only the > addition of editorial changes, clarifications, and implementation advice > is allowed [1]. Namespace bumps are not allowed, but instead should be > done via a new incubating XEP. > > XEP states would cease to exists. But council may later elevate a XEP to > become recommended and/or adds it to the compliance suite. > > > I've been thinking about such a change for a while (years). And I spoke > with a few of you about it at various occasions. But this is the first > time I wrote it on standards@ and I would appreciate any feedback. > > - Flow > > 1: So it is different from an RFC, which is strictly immutable once > published. The IETF has an errata process to pin information to an RFC > after it was published. > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > _______________________________________________ >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
