[Standards] presence muc element
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
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.
> 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...
> 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.
More information about the Standards