On Fri Jun 25 10:55:08 2010, Matthew Wild wrote:
On 25 June 2010 10:02, Dave Cridland <[email protected]> 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
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.
Oh, ouch. Yes, I can see why you don't deploy that.
> 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.
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
unavailable
> 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.
--
Dave Cridland - mailto:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
