15 May
2026
15 May
'26
5:58 p.m.
On Fri, 15 May 2026 at 11:51, Marvin W. via Standards <standards(a)xmpp.org>
wrote:
I feel the proposed use of Proposed is a little weird
here. Right now,
Proposed only really means "Last Call issued". I know that we do have 5
XEPs in Proposed state right now (3 of which had their last call more than
a year ago) and those should probably either be moved to Stable or back to
Experimental soonish. I personally would rather get rid of this state
entirely, as it really isn't a state that has any meaning.
I've not actually changed Proposed as much as you might think. I still have
it entered as the XEP reaches its first Last Call, it can still bounce back
to Experimental or move to Stable.
The differences between my proposal and the current documented state are:
* A timer that flips it back to Experimental automatically, irrespective of
activity.
* A Last Call doesn't immediately lead to a Council vote to advance or
bounce back.
In practice, the latter part often happens anyway - I've known several XEPs
that get multiple Last Calls. It seems fine, especially when the Last Call
generated a reasonable amount of contention and resultant changes.
Codifying that seems like a positive move.
And the timer is to stop the stuck-state cases we see. If a XEP is stuck in
Proposed, it should - I feel - get bounced back to Experimental.
The other changes are in presentation, really. The Council vote on allowing
a Last Call always seemed to me to be a formality, whereas this gives it a
bit more meaning.
In my mind the current Experimental state is somewhat
similar to a
wg-adopted I-D in IETF: it's no longer a personal endeavor of an
individual, but rather something we work on together to improve. I don't
support the notion of individual I-D being an Experimental XEP, because we
do give significant exposure to Experimental XEPs. I'm not saying that
everything that is Experimental right now meets this bar and I would argue
that is actually a problem: We do have a bunch of "dead" XEPs where the
author at some point wrote some stuff down without hugely consulting if
that's actually what people - including themselves - want or need, and so
they eventually abandon those XEPs themselves - typically without
officially retracting it. Those XEPs add to the fact that people always
complain about the hundreds of XEPs and uncertainty what to actually
implement.
Yes, I also suggested not including Experimental in the "default list"
of
XEPs at https://www.xmpp.org/extensions/ - I think that also might get
encourage people to work to advance the stuff they care about.
So in line with your proposal, here's my
suggestion:
- Make what is currently Inbox/ProtoXEP a proper own state:
- No requirements, no number assigned, but visible and published on XSF
websites if you know the link. Updates announced to standards list.
- Introduce also some rule for naming so that there is no collision on
names: like the IETF, have each inbox specification (file) name prefixed
with the author name.
- When a XEP is moved from inbox to regular and gets a number assigned,
keep a redirect in the inbox.
- XEPs are proposed to Council not by adding it to the Inbox, but by
explicit email
I think there seems to be consensus around that - though I'd quite like a
list to be available, just not in the default list. But that may just be me.
- Rename Experimental because the name is bad. I would
suggest something
like "Adopted", but I leave that to a native speaker. We can also reuse the
term Proposed here, but given at has an entirely different meaning, that
seems odd.
- Maybe add some clarification wording that this means that both Council
and the author considers this XEP to be worth to work on by the wider
community (either by suggesting changes to the XEP or through experimental
implementations)
I worry this is a left shift. But also, that is very close what I was
trying to suggest as Experimental... The only difference is s/both Council
and the author considers/Council believes the community considers/ I think.
But I would put that as the Inbox/ProtoXEP gate, anyway. If you're going to
work on a XEP on your own, there's no point involving the XSF at all.
If you're going to work on a XEP with others, it ought to be within the
XSF's process (and IPR, etc).
Prevents the AI (and other) slop.
- Stop using the Proposed state completely OR be more
rigid to move XEPs
back to Experimental if they are not moved to Stable.
- Lower the bar for Stable (doesn't strictly need to be fully implemented
if there is consensus that the stuff should work and be fine)
That's not actually a change to Stable, according to the documentation, is
it?
- Move things to Final when we agree we don't want
to do any changes to it
that are not backwards compatible and also the requirements from XEP-0001
are fulfilled (2 implementations, 6 months without changes).
That's also no change, of course, but I think it's not intended to be.
Does that make sense?
Marvin
Side note: I feel that IPR related concerns could be largely addressed by
a Note Well or other explicit wording that the Standards mailing list and
XSF Wiki are covered by the IPR policy and wouldn't strictly need changes
to the standards process, but I agree that having a somewhat reasonable
equivalent to IETFs individual I-D still makes sense.
I have to admit I'm unclear on where a "click-through" copyright assignment
can work. I think it does work for ProtoXEP submission because there is a
clear quid pro quo (I give you the copyright in this exact doc, the XSF
agrees to publish it and make it available).
This isn't helped by the UK and US laws being quite different, here, to
those of most of Western Europe. (the UK and US *do* allow a click-through
copyright assignment of future work, I think, whereas Germany, Spain,
France and Italy seem not to)
Looking at the other thread, I think we might need something much firmer -
or, alternatively, we need to change our IPR policy to be licence and not
assignment.
Dave.