[Standards] XEP-0126 invisibility interpretation

Andreas Monitzer jig at monitzer.com
Fri Feb 16 14:04:29 UTC 2007


On Feb 14, 2007, at 22:01, Mickaël Rémond wrote:

> Le 13 févr. 07 à 23:17, Peter Saint-Andre a écrit :
>
>> Maybe we can take some time at FOSDEM / DevCon to discuss  
>> XEP-0186. :)
>
> Yes, very good idea.
>
> I am not totally sure that invisibility is a misuse of privacy  
> list. The good thing, that I do not see addressed here is being  
> visible for some people and invisible for others.

The problem is that the client has to automatically fiddle around  
with a setting the user has configured. You'd have to analyze the  
privacy list, and add a few rules without interfering with the  
existing settings.
When the user becomes visible again, the application has to figure  
out again how to remove those settings without accidentally removing  
any rule the user had before going invisible. You need a very good AI  
implementation to figure that out.
Additionally, when the application crashes while being invisible,  
there's junk left behind nobody is responsible for.

> Yes, I have seen that directed presence are delivered. That's  
> client side behaviour and one thing that might be hard to manage is  
> the case when new contact become available. They probe you and will  
> see you offline, but if in your client side policy they were  
> supposed to see you, the client must react to their available  
> presence by sending a directed presence.

Maybe XEP-0186 should be extended to handle ICQ-style visible/ 
invisible-lists.

> What I am trying akwardly to say here, is that from the client  
> point of view, it is not 'fire your presence packets and forget',  
> but rather, keep track of all your contact presence and react  
> accordingly.

Still much better than having to rewrite human-generated rules.


andy




More information about the Standards mailing list