[Standards] XEP-0045 join when already in MUC
quae at daurnimator.com
Fri Jun 24 02:05:46 UTC 2016
On 24 June 2016 at 08:35, Georg Lukas <georg at op-co.de> wrote:
> 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'
> 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)
More information about the Standards