[Standards] presence muc element
mwild1 at gmail.com
Thu Jun 24 20:52:22 UTC 2010
On 24 June 2010 21:33, Justin Karneges
<justin-keyword-jabber.093179 at affinix.com> wrote:
> 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.
Yes, Prosody has had this code since the early days, however we
currently have it commented out due to Google Talk's issues. Gajim
also included the element on nick changes, but we ensured this was
fixed, and added a workaround for it.
But there's little way we can work around Google's oddity (well
technically there is, but none I'd be happy with releasing).
> 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.
I don't see that randomly re-sending join requests shouldn't result in
multiple joins to a room. Broadcasted presence is a different case, it
is more of a "state" than an instruction.
> 2) If presence is replayed, replay only the elements safe to replay.
That requires the server to know which elements those are - MUC
obviously isn't, but what's to say more won't come along? (e.g.
temporary presence subscriptions).
> 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.
Agreed, but what's done is done, and without using presence for MUC we
wouldn't have the unavailable on disconnect.
> Kev additionally informs me that M-Link's muc service may be the only one that
> performs rejoins properly when receiving the muc element.
It wasn't the first, but it likely is the only one at the moment. I
didn't consider it acceptable to release logic that is broken with one
of the largest XMPP deployments on the internet, so as I said, we
removed it from Prosody with a view to re-adding it if/when Google
finally cleaned up their act.
> 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.
That would be fine, we can update our code easily, and would be glad
to see it back in action. However the issue can be solved more
generally by implementing XEP-0198 for s2s, and logic to make
unavailable any remote users when it's detected that their server has
crashed. This is my current goal.
More information about the Standards