On Tue, 12 May 2026 at 14:03, Marvin W. <xmpp@larma.de> wrote:
On Mon, 2026-05-11 at 16:36 +0100, Dave Cridland wrote:


On Mon, 11 May 2026 at 16:13, Marvin W. <xmpp@larma.de> wrote:
If you want to say "hey people, I'm trying to come up with something, but I don't know how and what exactly, let's work on this document under XSF IPR policy", you don't need to make it Experimental. You can just say this and avoid any doubts on whether your XEP is encouraged for Experimental implementations or not. And if you think we need a venue that is explicitly under XSF IPR policy but not ready for experimental implementations yet, then talk to the board.


But... that *is* Experimental... Experimental doesn't mandate implementation, it merely encourages it. And you can implement this, not that it's required, and I have, not that I had to. Experimental doesn't even require implementable.

Experimental encourages implementation in experimental branches, which implies implementability and that the XSF as the publishing entity assumes it's worth investing time it to create such implementations.


Not really. It never has, historically. Lots of XEPs haven't been implemented, at least in any public form, for ages after becoming Experimental. SASL2, for one. XEP-0198 for another. After a while people sometimes pick them up and try them, in which case they're a success. Both were changed quite extensively in Experimental, because they didn't work, or missed features, or had features that weren't actually useful in the end. Sometimes they're not a success, like MIX (though MIX did indeed get implementations, just not meaningful deployments).

The XSF encourages implementation, in XEP-0001, because previously it discouraged it entirely - they were marked purely as discussion items because they'd change in incompatible ways, and implementations didn't interoperate. We fixed that with namespace versioning but XEP-0001 doesn't say either that they have to be implementable, much less that they have to be implemented. Indeed, XEP-0001 might now encourage implementation, but it also caveats that heavily.

In other words, I'm very much aware of both what the text says, and also why it says it.

The only time the XSF expects actual implementation in the standards process is once the XEP reaches Stable, since that is literally the first time it mentions gaining feedback from implementation and deployment.

XEP-0045 and XEP-0060 were both published in entirely different forms to their current state, and were only developed after publication. They were both implemented quite early, but those implementations would have been wildly different. Indeed, they changed after reaching Stable (then Draft) because of feedback from real-world deployments. We're now better at enabling implementation and capturing the feedback during the Experimental phase - and that's good, and was an intentional aim so that Stable (then Draft) would be much more Stable - but that shouldn't mean we shift the entire process left.

What you and Stephen are demanding is essentially higher than the Stable quality gate - feature complete and fully implementable, with several plans to implement and at least one implementation - which is not what the process demands at all, and historically does not match. Experimental XEPs are "works in progress", not "finished", as has been demanded. If we apply the quality gate for Stable to Experimental submissions, then honestly I'm unclear what you think Experimental is for.

Now, you might want your idea of the process to be the one we all follow, but that's not up to Council, it's up to Board. Previously you've said I should go to Board if I want to follow your mistaken notion of the process; I think I must return the favour, and say that if you want the process to exist as you declare it to be, you need to propose a change to XEP-0001 and have Board approve it.

I have somewhat resigned myself to the expectation you'll reject this in any form at this point. Unfortunately, XEP-0001 gives you that right, since it doesn't limit your reasons. However, rejecting it for not being in line with a process that doesn't exist is absolutely and definitively wrong.
 
The Process we have literally doesn't have a stage before Submission. So you're asking, as a Council member, that I should NOT follow our process as documented in XEP-0001?

The process has a phase before submission. It's the research. 

Part of the research is to determine if "the proposed protocol extension is truly needed in order to fill a gap in existing XMPP technologies and protocols". That gap is neither explained in the document itself nor obvious from reading it.
The research may include discussion and those are supposed to happen on exactly this mailing list. Which they are.


Again, you seem to be confusing Experimental, Proposed, and Stable.

You're quoting the Last Call questionnaire for Stable, there, not actually a documented part of the process rather surprisingly. XEP-0001 has this as the "Proposed" step, section 8 in XEP-0001, as opposed to the "Discussion" phase, which is Section 7, while the XEP is Experimental. We've ended up announcing ProtoXEP submissions as "Proposed XMPP Extension", which might be what's confusing you here.

Could you point at XEP-0001 and tell me where in our process we have a research phase before Submission? The word doesn't appear in XEP-0001 at all.

You're claiming a process that doesn't exist.

And then rejecting a XEP submission based on it, which ironically, under the process which does exist, I have no recourse.

This is extremely frustrating.
 
The only thing we would reach by accepting your latest proposal as a XEP is confusion, because people might assume that they are encouraged to implement this in experimental branches.
If you can't wholeheartedly say that people are encouraged to invest their time into creating experimental implementations from your XEP (which I assume because you yourself opted to use an LLM for the implementation rather than investing your time), why do you want to submit it?

Because I want to follow the documented and approved process and get to Section 7.

Dave.