[Standards] Sending MUC Presence (client to service) to the bare JID

Jonas Schäfer jonas at wielicki.name
Sun Jun 7 15:35:33 UTC 2020


Hi everyone,

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 [1] pointing at a 
nickname not associated with the session, which is probably undefined 
behaviour.


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?


kind regards,
Jonas


   [1]: 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...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200607/1408498b/attachment.sig>


More information about the Standards mailing list