On 24 June 2016 at 08:35, Georg Lukas <ge...@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 _______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
