[Standards] Client-Generated Presence Probes

Robert Quattlebaum 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  
> hack.

Sending a bunch of probes, one for each subscription, sounds like a  
hack.
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  
presence probe.

>> 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 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
> reprobe.

Rebroadcasting the client's presence doesn't really do what we want in  
this case.

> 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  
implementing it.

__________________
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/20081216/4d791a97/attachment.html>


More information about the Standards mailing list