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

Dave Cridland dave at cridland.net
Thu Jun 11 22:43:45 UTC 2020


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?


On Sun, 7 Jun 2020 at 16:38, Jonas Schäfer <jonas at wielicki.name> wrote:

> 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
> 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
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200611/fa720746/attachment.html>

More information about the Standards mailing list