[Standards] Sending MUC Presence (client to service) to the bare JID
jonas at wielicki.name
Sun Jun 7 15:35:33 UTC 2020
The standard is pretty clear that things like leaving the MUC are supposed to
go to the current occupant JID (muc at domain/nickname) instead of the bare MUC
JID (muc at domain).
However, in aioxmpp, I’m not doing that, but instead sending to muc at domain.
The reason is that this helps protect against race conditions in multi-session
nickname scenarios when one client changes the nickname concurrently to this
client leaving the room:
1. Client A emits leave stanza
2. Client B emits nickname change stanza
3. Service receives nickname change stanza from client B (due to network
latencies for example) and executes nickname change. It sends corresponding
stanzas to client A.
4. Service receives leave stanza from client A, which is now  pointing at a
nickname not associated with the session, which is probably undefined
Now, as I said, [XEP-0045 § 7.14] is rather clear:
> In order to exit a multi-user chat room, an occupant sends a presence stanza
> of type "unavailable" to the <room at service/nick> it is currently using in
> the room.
In practice, OpenFire, ejabberd and Prosody have shown no significant problems
(OpenFire does (did?) not correctly emit the 110 status code in that case)
with aioxmpp’s way of sending the presence to the bare JID instead.
My questions are:
- What do other clients do?
- How do other servers handle that?
- Should we amend the XEP (it being draft, we probably need to do that behind
a disco#info feature) to help clients working around the above race condition?
: This may actually be dependent on the specific multi-session nick
implementation, since that alone is undefined already. Some
implementations may choose to "split" the nickname, others may choose
to "renick" all sessions of the nickname at the same time.
[XEP-0045 § 7.14]: https://xmpp.org/extensions/xep-0045.html#exit
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Standards