Hey, Really quick thought, but the server's automatic unavailable will still go to the full jid, since that's where the directed presence goes. So sending to the bare jid only helps in an explicit leave, and not an implicit one due to going offline - which I suspect is the majority of cases.
That said, shared nicknames and changing nicknames really don't go well together at any time, do they? Dave. On Sun, 7 Jun 2020 at 16:38, Jonas Schäfer <[email protected]> wrote: > 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 > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
