Hi,
On Oct 6, 2008, at 3:52 PM, Peter Saint-Andre wrote:
While reviewing XEP-0186 just now, I noticed that when a resource goes
invisible, its server must send presence of type unavailable from that
resource. As far as I can see, when a contact's server receives
unavailable presence from the user (and if the user+contact have a
two-way presence subscription), it will stop sending presence
updates to
the user (if that was the last online resource for the user). This
somewhat defeats the purpose of invisibility, no?
Depends. It defeats the purpose of lurkers, who want to keep seeing
the others online without revealing their own presence. But if you
want to be online to talk to XMPP-based services but skip Instant
Messaging, I think its ok.
I assume that if you are really interested on getting presence updates
from a particular contact, you would send him a directed presence and
become visible just for him.
Anyway, in a federated network, I don't see a way to do better than
this. If we had a server-2-server protocol for "hey, i'm invisible but
keep sending those presences", you would be leaking the presence anyway.
I'm fine with this XEP as it stands.
One nit: third security consideration, about last activity - replying
<service-unavailable /> is a information leak. The proper reply would
be to reply with the time of invisible request.
The implication is
that the user's information about the presence of its contacts will
soon
become stale. But I suppose that's one price you pay for invisibility,
Right now, I don't see a workaround that would work in a federated
network without presence leaks.
I can see a smart server having a better behavior for local users, but
that's an extension of the server. I think we should allow for servers
to keep broadcasting the presence of local users, but say that for
external domains, presence will become stale. Basically, leave the
door open for invisible with local presences for corporate
deployments, but warn that it wont work across the federated network.
which I continue to think is a stupid concept anyway. :)
Personally I don't care about invisibility. But some of my clients
need/want it in a corporate environment...
I do see value on selected availability via privacy lists: I want to
be online for a certain group of people, not the full roster. But I'm
already covered by the current RFCs.
Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: [EMAIL PROTECTED]
Use XMPP!
