[Standards] presence muc element

Justin Karneges justin-keyword-jabber.093179 at affinix.com
Thu Jun 24 20:33:22 UTC 2010

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.


More information about the Standards mailing list