On 02/01/2010 12:03 PM, Matthew Wild wrote:
Which presence do you expect the server to send in this condition?
As I said, the unavailable presence:
http://tools.ietf.org/html/draft-ietf-xmpp-3921bis-03#section-4.6.2
Matthew
Thanks for the URL, but I think you're still missing the point.
I assume your intention is not to suggest that the server should a)
always reply "unavailable" -- even when the user is available, or b)
have no response in the case that the user is available, but it seems
you're forgetting the positive case.
I'll also point out that typically servers only track the folks you've
sent presence to as long as your session is active (why would it need
to do so after you've logged off?) -- so this isn't really a solution.
Consider the following use case:
- user1 at flaky-server.com/Mobile
(short handing this as
'user1/Mobile' later) joins the MUC room jdev at conference.jabber.org
- flaky-server.com's session manager dutifully tracks that
user1/Mobile has sent presence to jdev at conference.jabber.org.
- An unfortunate deref of NULL in flaky-server.com's S2S causes it
to crash.
- user1's battery dies -- killing his session in the process.
- flaky-server.com's session manager sends the appropriate
unavailable, but that S2S instance is still down.
- flaky-server.com's admin gets the S2S instance back up.
- jdev at conference.jabber.org
gets some indication that the
connection to flaky-server.com comes back online and decides to probe
for the "ghost".
- flaky-server.com's session manager has no record of
jdev at conference.jabber.org
in user1/Mobile's roster silently drops the
probe.
http://tools.ietf.org/html/draft-saintandre-rfc3921bis-08#section-11
Now you could argue that in #8 the server might want to respond, but I
personally would err on the side of trying to protect the server from
dictionary attacks by not responding.
Cheers,
Ben
|