[Standards] Client-Generated Presence Probes
darco at deepdarc.com
Tue Dec 16 17:16:18 UTC 2008
On Dec 15, 2008, at 7:03 PM, Justin Karneges wrote:
> On Monday 15 December 2008 15:08:00 Robert Quattlebaum wrote:
>> 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).
> It should really be the server's job to handle this problem. As
> soon as you
> stop ignoring some presence, a well-designed server should
> automatically get
> you that presence.
Is this behavior that you are describing defined anywhere? This sounds
like completely new behavior. It also sounds like it would be
significantly more work to implement than what I am describing,
considering how complex privacy lists are.
> Today, you generally need to probe contacts that you unblock. It's
> nice that
> this works (as opposed to being SOL), but in my opinion it's a total
Sending a bunch of probes, one for each subscription, sounds like a
Sending a single probe and letting the server forward that to who you
are subscribed to sounds like reasonable behavior, IMHO.
It seems like we already have the vocabulary for the client to express
its needs to the server, we just need the server to know what to do.
To do that we need for everyone to generally agree on what should be
the correct behavior of the server when it receives an unaddressed
>> 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
>> 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
>> the most sense, but handling unaddressed presence probes are
>> not widely supported.
> In a perfect world, you'd just turn off the privacy list and be
> done. But, in
> an imperfect one you have to probe all of your contacts. That, or try
> rebroadcasting your own presence, which in turn may cause some
> servers to
Rebroadcasting the client's presence doesn't really do what we want in
> I agree there's a problem that needs to be made better. Let's just
> do it the
> right way then.
The trick is that if we are going to change the behavior, we need it
to be simple enough that server implementors will actually consider
Jabber: darco at deepdarc.com
eMail: darco at deepdarc.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards