[Standards] presence muc element
b+jabber at bruce-2010.zerlargal.org
Sat Jun 26 00:04:34 UTC 2010
On Fri, 25 Jun 2010, Matthew Wild wrote:
> On 25 June 2010 10:02, Dave Cridland <dave at cridland.net> wrote:
>> On Thu Jun 24 21:52:22 2010, Matthew Wild wrote:
>>> 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,
>>>> then the presence you send is interpretted as a mere status change
>>>> than a full join. Then you don't get the room roster, history, etc.
>>>> informs me that the <x xmlns="http://jabber.org/protocol/muc"> element
>>>> (hereby referred to as "the muc element") is supposed to solve this
>>>> You include it only on join stanzas, but not on status change stanzas.
>>>> 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).
>> There is, in fact, a workaround in M-Link, too, in as much as it's possible
>> to strip out the XEP-0045 control element on inbound presence from a domain
>> before the processing code ever sees it. I'd be loathe to put that into
> That's not actually possible on its own, unless you know which domains
> are Google and which aren't. Our "workaround" was to detect this based
> on the SRV records for the domain - then we set a flag for that stream
> to say that it repeats presence, and our MUC component disables the
> rejoin logic for stanzas received over that stream. That is some
> workaround, though I don't see why it wouldn't work.
You'd be better off detecting this based on behaviour, rather than
particular strings appearing in the SRV records, as Google's
implementation is probably not the only one doing this. Eg, if user(s)
from domain foo consistently send a directed presence every X minutes over
~30 minutes, assume that the server hosting the domain is broken in this
regard and trigger the workaround mentioned.
>> But don't be coy about this - this is an interop bug, not a mere oddity.
>> While I don't see anything in the spec suggesting that directed presence
>> should be repeated, I admit there's nothing in the spec about it not being
>> repeated either, so we either have a bug in the spec (if Google insist the
>> spec allows them to do this) or a bug in GTalk (if they admit they
>> shouldn't). Either way, it needs resolution.
> Yes, agreed.
I'm actually wondering whether this replay every 5 minutes is from
gtalk-the-service or gtalk-the-embedded-in-gmail-web-interface-client.
>> There's actually a (3), which is "If you replay directed presence, then add
>> a delay".
> This sounds like a good solution, if they really want to carry on
> doing this (does anyone know why they do?).
If it's gtalk-the-embedded-client, then the replays are most likely the
client's keepalive logic simply running through the list of everything
that it has sent a presence to (and resending the exact stanza it sent
originally). If that's the case, then the onus is on
Google to have the client drop the muc element when it stores it for
later use with the periodic keepalive.
More information about the Standards