On 24 June 2016 at 16:55, Kevin Smith <kevin.sm...@isode.com> wrote: > >> On 23 Jun 2016, at 23: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 think you’re claiming (and I think I agree) that the proposed text is > repeating the existing rule in more obvious terms. The implication of this > being that this wouldn’t need any sort of namespace bump or the suchlike. > > For what it’s worth, M-Link has had this behaviour since more or less the > year dot, and the only downside I can recall seeing in that time is that > Google had a bug where they repeated presence periodically, causing continual > rejoins.
I think the key point here is that the *client* gets to see all the things they normally would when joining. For the other occupants in the room they may see just a presence update, or if the presence is the same: nothing. _______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
