11 May
2026
11 May
'26
3:17 p.m.
On Mon, 11 May 2026 at 14:38, Marvin W. via Standards <standards(a)xmpp.org>
wrote:
I'd like to point out that your new ProtoXEP PR is
not exactly only the
extraction of the previous proposals addressing and occupancy portion, it
does include new parts that the previous proposal lacked. Notably it does
introduce some new wire protocol parts (specifically the <part/> element).
The fact that you created (or had an LLM create) an implementation of what
is currently described doesn't really change anything with regards to if it
can be implemented, if that implementation is simply useless in practice.
As I had also written on GitHub, your new proposal still completely ignores
addressing on messages (you know, the thing we primarily use MUCs for),
which still has problems unsolved in practice. I don't know Openfire well,
but from what I understood, the implementation will simply keep messages
for muc2 occupants as is, meaning they still have the nickname in the
resource and occupant-id in the message payload.
I think it's fairly obvious that if addressing of occupants changes, then
the addressing of messages as well as presence changes. The addressing of
iq stanzas will also change. If the implementation is wrong on that front,
then the implementation is wrong. Again, implementation isn't required for
Experimental (or even Stable!), according to XEP-0001.
I have absolutely no doubt that the ProtoXEP is not at the quality gate
we'd require for Stable, but I would like to actually bring it into the XSF
and work on it with the rest of the participants in this SIG, under the
XSF's IPR policy.
Beside that I disagree that those two things,
addressing and occupancy,
are closely interlinked. The whole bare jid occupancy session part as
described works equally fine with the old addressing scheme. From what I
understand, the main thing that's different with the new addressing scheme
is where nickname and where occupant id are to be found in the stanzas.
I think bare jid occupancy is sufficiently embedded into the concept that
it's hard to remove, or at least hard to add in cleanly later. It doesn't
work "equally fine" with XEP-0045, which is why there's a bunch of
compatibility requirements around that exact case (ones you've commented
about on the PR).
As MattJ has noted, XEP-0045's increasingly patchwork nature is
problematic, and I was hoping not to replicate that.
Dave.