[Standards-JIG] Re: JEP-126 (Invisibility)
jean-louis.seguineau at laposte.net
Wed Apr 12 16:43:34 UTC 2006
Maybe we sometime need to get away from the 'tradition' ;)
What I'm saying is that many other 'presence' protocols offer an 'appear
offline' state which is distinct from the open/available or
closed/unavailable presence type, and is rendered as such in the client.
This is a different scenario from not allowing presence to be broadcasted to
If 'invisible' is a presence state, then it must be interpreted as such by
the client rendering/process.
If 'invisible' is a presence broadcast option, then it must be handled by a
In both cases, if this is defined in the RFC, implementation will have to be
I am not judging the validity of one scenario over the other, as certain
applications may require different approaches. In the end, we may have to
cater for both scenarios, don't you think?
Date: Wed, 12 Apr 2006 09:23:16 -0600
From: Peter Saint-Andre <stpeter at jabber.org>
Subject: Re: [Standards-JIG] Re: JEP-126 (Invisibility)
To: Jabber protocol discussion list <standards-jig at jabber.org>
Message-ID: <443D1B64.5040807 at jabber.org>
Content-Type: text/plain; charset="iso-8859-1"
-----BEGIN PGP SIGNED MESSAGE-----
Jean-Louis Seguineau wrote:
> What about linking the 'invisible' behavior to the presence <show/>
> rather than the type attribute. Isn't invisibility linked to the way the
> presence is presented to the end user?
That's an intriguing suggestion.
The traditional approach to invisibility has been to stop presence
broadcasts at my server, so they would never get to your server (let
alone your client). Once presence gets to your client, it may be shown
to you (if your client doesn't understand <show>invisible</show>) or you
may be able to pull it off the stream (via XML debug or whatever). So at
that point my presence is leaked.
Jabber Software Foundation
More information about the Standards