[Standards-JIG] JEP-126 (Invisibility)
stpeter at jabber.org
Mon Apr 10 22:19:18 UTC 2006
-----BEGIN PGP SIGNED MESSAGE-----
Remko Troncon wrote:
> Looking at JEP-126, i'm wondering how practical this is from the client
> implementor's viewpoint. My main problem is that active privacy lists as
> defined in the RFC are to be changed by name only. As far as i can tell,
> this means that if you want to become invisible, a client needs to do
> some complex checking. For the basic case, for example, you first would
> need to check if there is a privacy list 'invisible', and see whether
> this list is what you expect it to be (i.e. a list with a global deny on
> presence-out). If it is, change the active list to that. However, if it
> isn't, what then ? Modify the list ? What if this list is in active use
> ? Make the client come up with a new unique name for an invisible list ?
> That looks like an iterative process of trial and error; and what to do
> afterwards, leave the new list on the server ? Wouldn't that give a huge
> pile of lists in the end ?
> It would have been trivial if blocking communication could be done in a
> 'volatile' way, for example by setting the active list by value (instead
> of by name), or by having some special type of naming scheme for lists
> that the server removes when they aren't used anymore.
I've finally looked at this again.
JEP-0126 recommends to reserve the list names "invisible" and "visible"
to mean exactly what you would expect -- global invisibility and global
visibility. I have no problem changing that recommendation from SHOULD
That doesn't solve the problem of how visibility and invisibility
interact with other privacy lists. For example, let's say I have an
enemy in my roster and I don't want him to see my presence. Now I can't
log in, set my active list to invisible, then change my active list to
visible, because what I really want is visible-but-not-enemy. So I can't
use the stock lists, I need to use specialized lists.
Seemingly it would be simpler to use <presence type='invisible'/> when I
log in and then change to <presence type='visible'/> (per JEP-0018),
because even the latter would still not trigger sending presence to my
enemy if I have a privacy list in force for blocking him. In fact, using
"invisible" and "visible" presence is much simpler from the client
perspective because my client never has to mess with privacy lists to
Therefore I've been looking into resurrecting JEP-0018 and folding it
into rfc3921bis -- yes, that would mean <presence type='invisible'/>
would be a legitimate stanza (again). There are several issues here:
It would be painful to add "invisible" to rfc3921bis, especially since
we deliberately left it out of RFC 3921 and because I really want to
minimize the changes made during the RFC revision process. It could be
done, but I would prefer to avoid it. However, just because it's painful
for me doesn't mean we can't consider it.
Version 0.1 of JEP-0018 originally documented only "invisible" but not
"visible". Version 0.2 of JEP-0018 added documentation for "visible"
presence. See here for the changes:
But not all servers (and even fewer clients) implemented visible. So we
never really had consensus on how invisibility is supposed to work via
the presence stanza. That lack of consensus concerned me then, and it
concerns me now.
JEP-0018 or something like it enables you to set global invisibility or
per-JID invisibility, but not invisibility by roster group. This seems
like a nice feature of the privacy lists (JEP-0126) approach, but I am
not sure how important it is in the real world.
Indeed, it's not clear to me how important any of this is in the real
world since I never used <presence type='invisible'/> when it was more
widely supported. But I may not be a typical end user.
The requirements have never been fully clear to me, thus IMHO the
confusion over <presence type='visible'/> in JEP-0018.
In RFC 3920 and 3921 we tried as much as possible only to document the
core protocols as they existed then. We added things as needed to meet
IETF requirements, but we pulled things out if they were not needed to
meet those requirements. The IETF's requirements have not expanded to
Given the lack of an agreed-upon, widely-implemented, presence-based
protocol for invisibility that we can readily and without controversy
plug into rfc3921bis, I am hesitant to add "invisible" (and "visible"?)
to rfc3921bis. Because we're not going to define values of the presence
'type' attribute in the JSF (changes to the "jabber:client" schema need
to happen in the IETF), we either need to develop that "plug-and-play"
presence invisibility definition or stick with invisibility based on
privacy lists (JEP-0126). Developers complain that privacy lists are
complex compared to the old presence approach. The same is true of SASL
compared to the old jabber:iq:auth approach, TLS compared to the old
SSL-only port approach, etc. While I am sympathetic to nostalgia for the
good old days and I have thought quite a bit about going back to
presence type "invisible", it doesn't seem feasible to me at this point
(especially since it's not clear what we'd be going back to).
Granted, not all server projects have implemented privacy lists yet, so
it's hard for client developers to test. But I think that any problems
with the complexity of privacy lists are probably better addressed by
simplifying privacy lists than by going back to presence type
"invisibile". One option would be to work on a simpler "front-end" (or
set of front ends) to privacy lists, thus making it easier to complete
certain tasks, such as blocking a particular user or going invisible. So
we could do things like this:
<block xmlns='http://jabber.org/protocol/block'>user at host</block>
And the server would update the privacy list(s) accordingly (or just
block communications with the user).
Similarly for invisibility:
I have to think about this some more, but it seems feasible (e.g., I
don't know that we really need presence semantics to set invisibility,
especially since <presence type='invisible'/> feels more like a command
than a true presence stanza, since it's not broadcasted).
Jabber Software Foundation
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards