[Standards] UPDATED: XEP-0276 (Presence Decloaking)

Simon McVittie simon.mcvittie at collabora.co.uk
Tue Jul 17 09:31:51 UTC 2012


On 17/07/12 00:26, Lance Stout wrote:
> The reason value is really just a hint or suggestion

Yes, that was my intention when I wrote the XEP. It seems a bit more
user-friendly if you can hint at the reason for requesting de-cloaking:

    /---------------------------------------\
    | Alice <alice at example.com> is asking   |
    | whether you are currently online, but |
    | is not on your contact list.          |
    | [ Reveal presence ] [ Ignore ]        |
    \---------------------------------------/

("what do I do about that?!") vs.

    /---------------------------------------------\
    | Alice <alice at example.com> wants to          |
    | call you, but is not on your contact list.  |
    | Allowing the call to be started will reveal |
    | that you are currently online.              |
    | [ Reveal presence ] [ Ignore ]              |
    \---------------------------------------------/

("oh, this is just an incoming call from someone I don't know, I know
what to think about that").

The implementation in Telepathy supports either decloaking automatically
(a boolean option, off by default) or decloaking on-request (we signal
the UI to tell it about the decloak request, including the reason
attribute, and the UI can respond by sending directed presence if
desired). I don't think we actually have UI for it in either mode, though.

If I remember correctly, the original motivation was a SIP-to-XMPP
gateway, in which the gateway's virtual XMPP users always responded to
decloak requests, so that you could call arbitrary SIP addresses via
their corresponding XMPP address without adding it to your roster first;
in this case there was no meaningful presence to leak, because the
virtual users behaved as if they were always online anyway (we didn't
implement SIMPLE on the SIP side).

Part of the motivation for decloaking was that in 2010, it wasn't
obvious which of the incompatible dialects of Jingle and ICE-UDP
(Google/various expired XEP drafts/current XEP) would be supported by an
unknown client (perhaps one that pre-dated the then-current XEP, like an
older version of Telepathy). To perform a high-level, user-visible
action ("call Bob") we had to look at disco results and perform one of
several similar protocol actions, depending on the capabilities of Bob's
client.

Now that the Jingle and ICE-UDP XEPs are more widely-implemented, it
might be possible to define a way to initiate a call with a bare JID
using those XEPs (i.e. assume that if Bob's client supports calls at
all, then it supports modern XEP Jingle), and redirect to one particular
resource if Bob answers.

    S



More information about the Standards mailing list