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:
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: [email protected]
_______________________________________________
