It's a common problem to join a muc that already thinks you are joined, and then the presence you send is interpretted as a mere status change rather than a full join. Then you don't get the room roster, history, etc. Kev informs me that the <x xmlns="http://jabber.org/protocol/muc";> element (hereby referred to as "the muc element") is supposed to solve this problem. You include it only on join stanzas, but not on status change stanzas. This way, if a muc sees the element but thought you were already joined, it can do a proper rejoin.
However, this seems to break with servers that replay directed presence. Allegedly gtalk does this. Every 5 minutes, the client's server replays the directed presence to the muc, which includes the muc element, causing the user to constantly rejoin the muc (at least, for those mucs that respect the muc element properly). Some solutions: 1) Servers shouldn't replay directed presence. 2) If presence is replayed, replay only the elements safe to replay. My gut feeling is that directed presence ought to be able to be replayed. This is surely the case with broadcasted presence, which may be replayed many times, even to the same recipient, without any ill effects. I feel we should hold directed presence to a similar standard. IMO, presence should always be considered a continuous state, whether broadcasted or directed, and we should be wary of including any kind of "commandy" elements in presence stanzas like this muc element. Kev additionally informs me that M-Link's muc service may be the only one that performs rejoins properly when receiving the muc element. If indeed few mucs are supporting this, then maybe we have an opportunity to amend this problem in XEP-0045. That is, change the XEP to make it clear that the muc element does not cause rejoins, and possibly look for a different rejoin solution that does not break the presence model. -Justin
