[Standards] XEP-0045 join when already in MUC

Emmanuel Gil Peyrot linkmauve at linkmauve.fr
Fri Jun 24 03:27:22 UTC 2016


On Fri, Jun 24, 2016 at 12:05:46PM +1000, Daurnimator wrote:
> On 24 June 2016 at 08:35, Georg Lukas <georg at op-co.de> wrote:
> > Hi,
> >
> > TL;DR: whenever a client (re)sends a join, the MUC service should return
> > everything a newly joining client needs to know.
> >
> > According to XEP-0045, an initial join presence needs to contain an 'x'
> > element with 'http://jabber.org/protocol/muc' namespace (§7.2.2),
> > whereas a regular presence update to the MUC does not (§7.7).
> >
> > In §7.2.3 it follows up then with "If the service is able to add the
> > user to the room, it MUST send presence from all the existing
> > participants' occupant JIDs to the new occupant's full JID, ..."
> >
> > I would like to propose the following add-on clarification:
> >
> > "The service MUST send to the client everything that would be sent on a
> > join even if the user already is joined to the MUC with the same full
> > JID. This is required because a client (or the user's server) might have
> > been restarted without informing the MUC by means of an 'unavailable'
> > presence."
> >
> > I was told that this behavior is already implemented in prosody-trunk
> > (though not in older versions) and that the sky hasn't fallen down yet.
> >
> > When on mobile data, I often see a join only answered by a reflection of
> > my own presence, without a list of other participants and without a room
> > subject (I'm running prosody stable). This happens because the MUC
> > assumes that I'm still inside and only want to update my status.
> >
> > Without the proposed change, there is no way for a client to reliably
> > sync a MUC - the only indication for a failed join is that no room
> > subject is received, and sending the subject is a SHALL, not a MUST
> > (§7.2.16). And even if the client could rely on a subject being sent on
> > a proper join, it would have to setup a timeout (the subject comes after
> > the reflected presence), and then to leave and re-join the MUC if no
> > subject is received.
> >
> > The only semi-acceptable workaround that comes to my mind is to prepend
> > each join with a directed presence-unavailable to the MUC to enforce a
> > clean state.
> 
> The trouble is that this conflicts with the groupchat 1.0 protocol
> (which is also part of the muc spec)
> https://xmpp.org/extensions/xep-0045.html#enter-gc

Actually no, they don’t conflict, this section basically says it’s
possible to enter a groupchat 1.0 room without any <{muc}x/> in the
presence, while Ge0rG’s proposal is to make <{muc}x/> a join-or-rejoin
trigger, both describing two different stanzas for joining the room.

The x-less join presence keeps meaning both a presence update in MUC
and a join-or-presence-update in groupchat 1.0, even though I only know
of a single server still implementing that part of the XEP.

Overall this change means that people will no longer wonder why they
don’t see anyone else after having joined a MUC when the server-side
still thinks they were already present, so this clarification would be
very welcome.  +1 from me.

> _______________________________________________
> Standards mailing list
> Info: http://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________

-- 
Emmanuel Gil Peyrot


More information about the Standards mailing list