Re: [Standards] standardization process (was: Re: XEP-0353 propose id syntax)

[Florian Schmaus]

On 06/01/2023 14.10, Dave Cridland wrote:



On Thu, 5 Jan 2023 at 21:38, Florian Schmaus > 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.


Right, that's certainly a way to look at it.


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.


Reality is that there are many implementations that do not comply with 
XEPs (mostly experimental XEPs). I think this is because developers want 
a larger degree of freedom, allowing for experimental derivations of the 
standard, at this "early" stage.


I'd like the XSF to provide infrastructure to publish (and discuss) XEPs 
without Councils approval. Everyone can already publish stuff (cause 
"internet"). So the XSF not allowing this just scatters the documents 
around the web and does more harm.


I am not sure which protections you are referring to, given that there 
are implementations out there which not comply with "our" 
specifications. And this can simply not be prevented. Instead, we should 
make it more clear that incubating ProtoXEPs are 1. subject to change in 
any way without any backwards guarantees, and 2. implementations of such 
may not follow the spec (due to 1. and the fact that developers may 
decide to try something a little bit different).


I still want council to have a final word about an incubating ProtoXEP 
being adopted as official and council-approved XEP.


- Flow
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] standardization process (was: Re: XEP-0353 propose id syntax)

[Dave Cridland]

On Thu, 5 Jan 2023 at 21:38, Florian Schmaus  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
___

Re: [Standards] standardization process (was: Re: XEP-0353 propose id syntax)

[Florian Schmaus]

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: standards-unsubscr...@xmpp.org
___

[Standards] standardization process (was: Re: XEP-0353 propose id syntax)

[Peter Saint-Andre]

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...

Peter

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___