[Standards] Decloaking and Temporary Subscriptions
stpeter at stpeter.im
Thu Jan 21 05:45:27 UTC 2010
On 1/20/10 1:30 PM, Matthew Wild wrote:
> 2010/1/20 Dave Cridland <dave at cridland.net>:
>> Simon McVittie has made a proposal he's called decloaking, which effectively
>> puts a bit of structure around the directed presence used to "back up"
>> various client-client interactions, including Jingle calls and file
>> As part of the discussion, a brief mention was made of an alternate
>> approach, which I'll call Temporary Subscriptions - that is, actual roster
>> subscriptions which are by intent expected to be later removed.
> The actual semantics of temporary subscriptions are still up for
> definition too. As I mentioned in the meeting, I'm thinking that we
> just need a way to send direct presence but with a tag saying to my
> server to keep the remote JID updated as my presence changes (not like
> directed presence behaves now).
> You could include this tag in your presence to MUC rooms for example,
> and the server would automatically send the MUCs your new presence
> when it changes - currently this is sent individually to each MUC room
> by the clients (ick.). Though MUCs want only the presence of a single
> resource (not all, like Jingle does), hmm.
Well, your server could send those interim presence changes right now,
because that's allowed but not required by RFC 3921 (IIRC). This is
something we might want to take up in the XMPP WG.
> Downsides are that this requires server support, especially thinking
> of e.g. gmail.com here. Probably other things I'm missing too.
> The downsides I see to de-cloaking as it stands is that to make it
> secure the user would have to be prompted before revealing status.
> this prompt comes up at several of my clients at the same time, am I
> likely to ok them all before the remote party decides I'm not there,
> or selects the wrong resource?
Doing this via <message/> instead of <presence/>, and using message
mine-ing or a similar technology to retract the decloak requests that
were delivered to the other resources, would at least enable the other
clients to remove those popups at the other resources. Rob and I had
some discussions about <message/> vs. <presence/> for decloaking and I
think it's worth it to continue that discussion.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6820 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards