[Standards] presence muc element
dave at cridland.net
Fri Jun 25 11:29:26 UTC 2010
On Fri Jun 25 10:55:08 2010, Matthew Wild wrote:
> On 25 June 2010 10:02, Dave Cridland <dave at cridland.net> wrote:
> > 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
> are Google and which aren't. Our "workaround" was to detect this
> on the SRV records for the domain - then we set a flag for that
> 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.
Oh, ouch. Yes, I can see why you don't deploy that.
> > Yes, also if we ensure servers respond correctly to probes when
> > presence is involved we can probe in various cases - that said, I
> > 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.
Probably likewise. I have not yet figured out all the various failure
cases, nor what the behavious in the wild actually is. I supect some
judicious id tracking would solve most problems, but still.
> I have a better idea though...
> http://matthewwild.co.uk/uploads/gc_pinger.html :)
Yes... I did contemplate using ping, or disco#info, but it's not
clear this is ideal either.
> > 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
> > to match the directed presence, then various state mismatches
> could occur.
> Yes, good point - this would need clarification in XEP-0045 I think.
Yes, it would, it's a change to the wire protocol.
The issue exists in RFC 3921 based systems, it's more acute in the
~bis systems because of increased tracking requirements, I think.
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards