[Standards] Re: Proposed XMPP Extension: New MUC

On Tue, 12 May 2026 at 14:03, Marvin W. <xmpp(a)larma.de> wrote: 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. 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. Because I want to follow the documented and approved process and get to Section 7. Dave.