[Standards] Re: Proposed XMPP Extension: New MUC

For those not paying attention, this was rejected roundly by everyone attending the Council meeting yesterday: https://logs.xmpp.org/council/2026-05-05 The reasons given were: 1) Daniel and Marvin both wanted it split up into small extensions against '45. This is not my preferred approach, but it's a valid enough approach. I think long term we'll run into problems and need a compliance spec to bind the required extensions back into a single spec, or something like that. 2) Stephen said there was no implementation, no plan to implement, and questioned whether it was implementable. Marvin also expressed doubt it could be implemented. I question whether this is a requirement for Experimental, and entirely dispute that the approach cannot be implemented. If the requirement for a ProtoXEP is now that it is a fully polished specification with implementations what on earth is the point in Experimental? We don't even require that for Stable! 3) Marvin also disliked that the XEP described itself as a "discussion point". I actually think this was a misunderstanding of what that term means, but never mind. In order to address these, I have submitted just the addressing/occupancy portion - I believe these two parts are closely interlinked and would be damaged by trying to extract them into two specifications. This should satisfy objection (1). I also knocked out a quick PoC of the server side, which I hope satisfies objection (2), this is in a Draft PR here: https://github.com/igniterealtime/Openfire/pull/3305 - this is done by LLM, from the specification. I really don't like putting this amount of effort (and in this case, cost) into a ProtoXEP submission. This implementation is solely to prove to Stephen and Marvin that it can be implemented, and will not be merged - I fully expect the specification to change as we discuss it. Finally, I stripped the "discussion point" text, to satisfy objection (3). But the XEP remains a discussion point, in as much as people should discuss it (here, ideally), and I'm keen to make changes (including radical ones) that we can build consensus around. One we do have consensus, I'll do a proper implementation with an aim to merging it into Openfire (and Wimsy too). The remaining changes are mostly tidying up, improving references, more examples, etc. Oh, and a way to leave bare jid occupancies, because I forgot that before and it seems important... Dave. On Fri, 24 Apr 2026 at 11:27, Daniel Gultsch <daniel(a)gultsch.de> wrote: