[Standards] Client-Generated Presence Probes
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.
Jabber: darco at deepdarc.com
eMail: darco at deepdarc.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards