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

Peter Saint-Andre stpeter at stpeter.im
Mon Sep 10 19:27:32 UTC 2007

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

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.

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

(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. :)


Peter Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070910/31554b45/attachment.bin>

More information about the Standards mailing list