[Standards] presence muc element

Matthew Wild mwild1 at gmail.com
Fri Jun 25 09:55:08 UTC 2010


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,
>> > 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).
>>
>>
> 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
> production.
>

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.

> 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.


> 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?).

> (Stanzas per sec from this is G*(G+N)/300, where G is Google users and N is
> non-Google users, kids. In jdev, as I write, that's G==3 and N==25, hence
> averaging 0.3 stanzas a second - nothing we can't handle, but add in another
> 6 Googlers and it's already reached 1/sec.)
>

You're good! ;)

>> 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.
>
> Yes, also if we ensure servers respond correctly to probes when directed
> presence is involved we can probe in various cases - that said, I know
> M-Link doesn't respond correctly in this case, although we're working on
> that. (I'm curious as to whether other servers do, as well - this is a bis
> thing we've not caught up with yet, AFAIK).
>

No, I don't think we have that either yet - likely for the next release though.

I have a better idea though...
http://matthewwild.co.uk/uploads/gc_pinger.html :)

> As an aside, here, it may be required that clients send unavailable to their
> old nickname after a nick change, as suggested above as a workaround to
> Google, since the server has to track the directed presence in order to send
> unavailable and respond to pings - if the client never sends the unavailable
> to match the directed presence, then various state mismatches could occur.
>

Yes, good point - this would need clarification in XEP-0045 I think.

Matthew



More information about the Standards mailing list