per contact presence (was: Re: [Standards-JIG] Re: JEP-126 (Invisibility))

Hernan Tylim htylim at
Wed Apr 12 20:09:41 UTC 2006

Ralph Meijer wrote:

>On Wed, Apr 12, 2006 at 03:40:22PM -0300, Hernan Tylim wrote:
>>I am not a server implementor, and I know that I might be talking 
>>without a solid knowledge, but my opinion is that the current Presence 
>>mechanism is too rigid. To me direct presences shouldn't exist, or in 
>>any case, they should be handled by the user's server and not just 
>>routed and ignored.
>I don't understand this. How is it rigid if you want something removed?
>Also, the fact that it is apparently hard to create a nice UI for
>directed presence, doesn't mean it isn't useful or undesirable.
>Protocol-wise, it is the responsibility of the users' server to not go
>override the directed presence. It isn't rocket-science to implement and
>clearly documented in the RFC.
With rigid I meant that I can currently only use <presence> to change my 
status on a global basis, and that if I want to make it in a per-contact 
basis  I need to use privacy-lists which feels more like a hack than any 
other thing.

1. first block all my contacts that I don't want to affect.
2. change my presence
3. unblock the previous contacts


1. send direct presence to the contacts that I only want.
2. each time my presence will change globally, block the contacts that I 
don't want affected, and unblock them later.

All this would be easier, that is for client implementors, if servers 
would keep track of presences not only as global presences but also in a 
per-contact basis. I don't know if this is already covered in the RFC, 
but if it is please tell me if you know of a server that supports it 
because I am gonna need it very seriously very soon.  :)

The reason why I stepped up in this discussion, which I know it is about 
invisibility, was because my gut feeling is that any mechanism that 
change presence and doesn't allow to do it in a per-contact basis will 
fell short in the medium term future. But of course thats only an opinion.


More information about the Standards mailing list