[Standards] UPDATED: XEP-0186 (Invisible Command)

Mridul Muralidharan mridul at sun.com
Mon Sep 10 19:34:25 UTC 2007

Peter Saint-Andre wrote:
> Mridul Muralidharan wrote:
>> XMPP Extensions Editor wrote:
>>> Version 0.6 of XEP-0186 (Invisible Command) has been released.
>>> Abstract: This document specifies an XMPP-compatible protocol for user
>>> invisibility.
>>> Changelog: Clarified that this specification is intended to supersede
>>> XEP-0018 and XEP-0126; added several additional examples. (psa)
>>> Diff:
>>> http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0186.xml?r1=489&r2=1204
>>> URL: http://www.xmpp.org/extensions/xep-0186.html
>> We have so many specs for invisibility (and similar) feature - privacy
>> lists, block lists, the various invisiblity specs.
> So many? Let's not exaggerate. I see three (block lists do not provide
> invisibility):

Deny presence-out can be simulated by blocking lists using 
wildcards/lists - but you are right, that is not in the spec.

> 1. XEP-0018, i.e., <presence type='invisible'/> -- we know this is is
> evil (at the least, it would not pass muster in the IETF).
> 2. XEP-0186, i.e., a small, focused command for toggling invisibility.
> 3. XEP-0016, i.e., privacy lists -- these can be used to provide
> invisibility, but that seems like a heavy weapon for such a small feature.

I remember another spec which used iq - cant seem to find it though.

>> Isn't this spec, for example, just special casing presence-out:deny ?
>> "
>> <iq type='set' id='invisible'>
>> <query xmlns='jabber:iq:privacy'>
>>   <list name='invisible-all'>
>>     <item action='deny' order='1'>
>>       <presence-out/>
>>     </item>
>>   </list>
>> </query>
>> </iq>
>> "
> Yes it is. But then you need access to a server and client that support
> privacy lists. And you need to fiddle with your privacy lists all the
> time to add and subtract invisibility, which it seems to me introduces
> the possibility of messing up the definitions (not to mention the
> bandwidth usage). A small, focused command seems more useful to me.

In our client for example, there is a 'invisible to all' list which just 
does the above - invisibility actually gets shown in the ui as though it 
was a presence status.
For more complex and custom privacy lists, there is ui - but the simple 
static stuff does not require any editing of lists.

> (Oh, that makes me realize: we could also do this via XEP-0050!)
>> Either we should have a proliferation of small specs which implement
>> subset's of functionality required, or have something like privacy list
>> which handles all cases (maybe something better designed if that is a
>> concern ?) - having both together means neither server, not client can
>> rely on support of these (unless they implement all).
> MUC and presence are just subsets of pubsub, too, you know. :)
> Really I don't have strong feelings about this. People were complaining
> about privacy lists being so complex, so I wrote XEP-0186. If people
> don't think we need it, that's fine with me, because personally I think
> invisibility is a silly feature and I never use it. :)

We just end up with multiple ways of doing the same thing. So either we 
fix what is wrong with privacy lists (now that it is not in the rfc), or 
deprecate it altogether and come up with a good alternative (we are 
seeing more adoption of privacy lists at server side iirc).

pubsub is complex too - but we do not necessarily come up with 
alternatives to it (and yes, pep does not count :) it uses pubsub, not 
replace it like this spec does).

- Mridul

> Peter

More information about the Standards mailing list