Corner cases of presence probes in xmpp

Presence probes is an interesting idea in XMPP - you probe the presence of a contact.
Ofcourse, the presence is divulged only if the policies of the contact's server (handled by the hosting server : not client) allow user to query for the presence : but the basic idea is, you can do a pull of the presence - not just the customery push from the server.
The caveat is that, this is expected to be used by the user's server - not directly by the user.
There are two interesting things w.r.t presence probes which I am not very comfortable with.

The initial presence section in rfc 3921 has a slightly interesting snippet.
It says "Upon receiving initial presence from a client, the user's server MUST do the following if there is not already one or more available resources for the user (if there is already one or more available resources for the user, the server obviously does not need to send the presence probes, since it already possesses the requisite information):"
Now, what is interesting here is that, you cannot really say if a directed presence over S2S is a response to a presence probes, or a directed presence from a remote entity.
Which essentially means that, there can be no reliable caching of presence info on the local server for a remote user even if there are other resources of the same user are online on the server ...
That is, when a specific resource user comes online - it becomes mandatory for correct implementations to send presence probes to all remote contacts in roster with a both/to subscription : irrespective of whether there are other resources of the user online.

Now let us come to the bis verions of the XMPP spec here. If you look at the definition of presence probe, you see see that it is expected to be used by the server on behalf of the user - same as is in rfc 3921.
Now, let us take a look at directed presence.
It talks about using probes "A server SHOULD respond to presence probes from entities to which a user has sent directed presence" ... as a means to find out the current availability of a contact.
The examples below do not really use type='probe' : either a ommision, or the choice of words is unfortunate :-)
Now, this is a very real problem which needs to be tackled - of interconnections between remote entities going down temporarily leaving all subscribers who are expecting a presence push hanging around if the server cant/didnt recieve/send the presence push.
Assuming it is an ommision of type=probe :
The problem is that, we are leveraging the same mechanism to probe for presence and to check for availability (btw, the examples in that section are buggy if I am not wrong).
If it was supposed to be a directed presence stanza without type and status (not really clear in the spec), the problem again is that we are leveraging an entirely different concept (of pushing presence) to retrieve status !
Either way, it is getting retrofitted into existing definitions - and somehow the extension does not really 'feel right' to me.

Alternative ? I dont have an alternative for this :-) The idea as such is good, and this is a problem which has been thrashed out a lot at the standards-jig alias
It should be noted that presence probe/directed presence, etc are not gaurentee'ed a response : they follow an OUT-optional FAIL MEP : so in this case above, probe could also fail ... what about modelling this as a iq query (IN-OUT MEP) with a pre-negotiated timeout ?
Comments:

I am not certain to follow your fist point. Why do you feel there is a need for caching remote users presence on the local server?

The probe is precisely meant to avoid caching and always retrieve the latest state of a remote user. By doing so, you ensure that only a user's home server remains the authority for presence.

That being said, why would you want to differentiate between esponse from probe and directed remote presence. They are exactly the same in nature. Only the trigger is different.

Jean-Louis

Posted by Jean-Louis Seguineau on November 15, 2006 at 01:37 PM IST #

Hi
About first point
The way the initial presence section is framed, it indicates that if you already have a resource online for a node, and another one comes available - you might not need to send a presence probe, but could reuse the presence info from the other resource.
My point is, this is not true - the response to a presence probe and a directed presence are not distinguishable : and so, if we try to eliminate a presence probe for subsequent resources, we would end up with presence leaks : the remote user might be sending directed presence to a specific full jid : not to every resource (current/future) for a user.
Consider it like this :
  1. userA@domainA has userB@domainB in his roster and vice versa.
  2. userA@domainA/res1 comes online, server sends presence probe to domainB.
  3. If there are privacy rules for userB result in an unavailable presence response.
  4. Assume also that, seeing the available presence from userA@domainA/res1, userB sends an explict directed available presence to userA@domainA/res1.
Now, when userA@domainA/res2 comes online : domainA server MUST send a probe again to domainB (which, the spec says, is not necessary).
IMO, remote presence MUST not be cached - on any account on the local server : and must always result in a probe if there is interest in finding out the status of the remote entitity.
Not sure if I am making it any clear here :-)

Regards,
Mridul

Posted by Mridul on November 15, 2006 at 02:56 PM IST #

To clarify, I dont really think anyone caches this now and server always send probes (atleast I do), but the way the spec is authored it seems to indicate that it might be ok to cache it ...
The way we have it, no probes are sent if it is a locally hosted entity (whats the point :-) ), and probes are sent if it is a remotely hosted entity.
Mridul

Posted by Mridul on November 15, 2006 at 03:03 PM IST #

This is definitively clearer. I did not remembered the spec was allowing for \*remote\* presence to be cached

IMO this, as you rightly said, is NOT the proper way to do it. And at least your server and ours does the right thing ;)

Did you raise the point on the standard list?

Jean-Louis

Posted by Jean-Louis Seguineau on November 15, 2006 at 05:32 PM IST #

Post a Comment:
  • HTML Syntax: NOT allowed
About

mridul

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
Bookmarks
Blogroll

No bookmarks in folder