[Standards] Client-Generated Presence Probes

Robert Quattlebaum darco at deepdarc.com
Mon Dec 15 23:08:00 UTC 2008

Currently, according to RFC3921, the behavior of a server when it  
receives an unaddressed presence stanza of type 'probe' is undefined.

I propose that the following behavior be generally accepted as correct  
(and possibly codified in RFC3921 and/or an XEP):

When the server receives an unaddressed presence probe from a client,  
the server MUST forward that presence probe to all contacts that user  
is subscribed to on the client's behalf.

Now... I know what you are thinking. Why is this a good idea? Why  
would a client ever need to send a presence probe?

Presence probes are useful to force a refresh of your presence state  
if you were previously ignoring presence (say, via a privacy list  
which blocks incoming presence).

Blocking incoming presence is useful in mobile environments when  
interest in other's presence is only necessary in very limited  
contexts. Receiving  and handling presence stanzas when they aren't  
being used wastes power, so it is a good idea to not have them be sent  
at all. The problem then comes what do you do when you want to  
actually view presence in a roster?

Turning off the privacy list and sending a single presence probe makes  
the most sense, but handling unaddressed presence probes are currently  
not widely supported. In fact, Openfire will actually kill the client  
connection, due to an unhanded exception.  In the absence of this  
functionality on the server side, the client is reduced to sending a  
presence probe to each individual on their contact list.

Additionally, a service discovery feature may need to be created to  
allow servers to advertise that they support this behavior correctly.


Robert Quattlebaum
Jabber: darco at deepdarc.com
eMail:  darco at deepdarc.com
www:    http://www.deepdarc.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20081215/ac3fad3e/attachment.html>

More information about the Standards mailing list