[Standards] presence muc element
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).
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