On 10/01/2023 15.03, Dave Cridland wrote:
On Sat, 7 Jan 2023 at 20:46, Florian Schmaus <[email protected]
<mailto:[email protected]>> wrote:
But let use assume that we remove the council approval requirement for
experimental XEPs. And further assume that we clearly state that
experimental XEPs may change protocol without namespace bumps.
Forgetting everything else for a moment, why do you want to get rid of
namespace bumps?
I do not want to get rid of namespace bumps in general. I like how XMPP
versions its protocols by XML namespaces. That is certainly one of the
outstanding things about XMPP.
However, in the "early" phase of the development of an extension
protocol, there seems to be a need to modify the protocol without
bumping the namespace. One reason is probably that people enjoy the
agility that this brings, while also avoiding the cost that the bump
entails.
This phase obviously contains the ProtoXEP phase. But IIRC I've heard
people considering not performing a namespace bump in the 'experimental'
stage of a XEP, when one would be required. I assume this desire comes
up, for example, with XEPs that rather quickly entered the
'experimental' stage. Probably without any, or just a few, corresponding
implementations, and insufficient prior review.
As soon as a XEP got accepted by council, we also have no good mechanism
to collect pending breaking changes. This leads to premature namespace
bumps, which may be shortly followed by another bump [1].
My current proposal would:
A) distinguish the states where bumps are necessary and unnecessary
B) switch to a (relaxed [2]) "one namespace per XEP" approach
A) addresses the need for a stage where namespace bumps are not strictly
required. And B) makes it easy to collect changes for a new major
version of the protocol, namely in the stage where namespace bumps are
not required, using the stage introduced with A).
B) also fixes the "why isn't this XEP stable yet?" problem. The OMEMO
XEP is experimental for over 12 months and widely deployed. But we can
not (should not?) move it to 'stable'. Why? Because the current XEP is
not the OMEMO version that is widely deployed.
B) also fixes the "omg, I just implemented the wrong version of the XEP"
problem. Assume someone is hacking on a shiny new XMPP client with OMEMO
support. Consider the amount of frustration once the hacker finds out
that the shiny new client can not talk OMEMO with anyone else, because
the client uses a modern OMEMO version, that nobody else implemented yet…
I've seen this situations causing confusion and frustration multiple times.
And I really think we can do better.
- Flow
1: I believe there is a prime example for this. Was it MAM?
2: I see no need to enforce this
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
