Hi everyone, The standard is pretty clear that things like leaving the MUC are supposed to go to the current occupant JID (muc@domain/nickname) instead of the bare MUC JID (muc@domain).
However, in aioxmpp, I’m not doing that, but instead sending to muc@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@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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
