[Standards] XEP-0045 join when already in MUC

Mathieu Pasquet mathieui at mathieui.net
Fri Jun 24 18:02:52 UTC 2016


On Fri, Jun 24, 2016 at 04:27:22AM +0100, Emmanuel Gil Peyrot wrote:
> 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.
> 

+1 from me as well, I don’t see any significant drawbacks to this, and
it would fix an issue I have been seeing for a very long time.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160624/310c605b/attachment.sig>


More information about the Standards mailing list