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 <[email protected]> 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.
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
