[Standards] Enabling Jingle calls to non-subscribed JIDs with directed presence

Peter Saint-Andre stpeter at stpeter.im
Wed Jan 13 19:42:29 UTC 2010


On 1/13/10 12:05 PM, Simon McVittie wrote:
> On Tue, 05 Jan 2010 at 17:28:15 +0000, Simon McVittie wrote:
>> I'm trying to pick up some earlier work on making Jingle calls work
>> for JIDs to which the caller isn't subscribed.
> 
> I've written up the proposed API as a proto-XEP and submitted it to
> the registrar:
> 
> http://people.collabora.co.uk/~smcv/decloak.html

Thanks for writing that up.

>>> <presence from='peter at jabber.org/foo' to='paul at
>>> jabber.org'> <c xmlns='http://jabber.org/protocol/caps' 
>>> hash='sha-1' node='http://psi-im.org' 
>>> ver='q07IKJEyjvHSyhy//CH0CxmKi8w='/> <decloak
>>> xmlns='urn:xmpp:decloak'/> </presence>
> 
> This is essentially what I've done. For the moment my proto-XEP uses
> a vendor-specific XML namespace, because I developed it alongside a
> test implementation (telepathy-gabble).

Sure thing. :)

>>> <presence from='paul at jabber.org/bar' to='peter at
>>> jabber.org'> <c xmlns='http://jabber.org/protocol/caps' 
>>> hash='sha-1' node='http://www.chatopus.com' 
>>> ver='zHyEOgxTrkpSdGcQKH8EFPLsriY='/> <decloak
>>> xmlns='urn:xmpp:decloak'/> </presence>
> 
> To avoid infinite loops (or having to do complex state-tracking to
> prevent them), the reply is just directed presence - it omits the
> <decloak/> element.

Sensible.

>> However, it was pointed out in August 2008 that GTalk (at the time)
>> would only let <presence type='subscribe'> packets through to its
>> users, so the de-cloak request might have to look more like
>> this[3]:
>> 
>>> <presence type='subscribe'> <temporary/> </presence>
> 
> I haven't done this; discussing with my colleagues, we decided that
> if GTalk explicitly wants to suppress communication from unapproved
> entities to its users, we should respect that.

I agree.

>> * After asking for directed presence, how do we tell whether
>> there'll ever be a response? An arbitrary timeout seems like the
>> only useful answer...
> 
> My test implementation just waits 5 seconds.

That also seems sensible.

>> * If Bob has configured his client to make this work "silently",
>> then Alice can determine that Bob has a client logged in, which
>> client it is, and its resource name (but not whether it is
>> available/away/dnd/..., and no "rich presence" like geolocation,
>> avatar, etc.) - a (user-configurable) presence leak
> 
> My test implementation signals to the UI that Alice has done this.
> I'm not sure what a UI would usefully do with this information, but
> it's there.
> 
> Another potential pitfall is highlighted by the proto-XEP: suppose
> Tybalt has two resources, /library (dnd, 'researching') and /garden 
> (xa, 'gone to the library'). If Juliet tries to call Tybalt and sends
> a successful decloak request, Tybalt's two resources will reply in an
> arbitrary order, and Juliet will probbaly call whichever one answered
> first; even if she waits for an arbitrary time, say 5 seconds, in the
> hope of getting more replies, gets the second presence, *then* calls,
> she can't know which of /garden and /library is "more available".

I think the session establishment implications of decloaking are outside
the scope of this proposal. There's all sorts of messiness here and we
don't need to address that in the decloaking spec.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6820 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20100113/a61ae358/attachment.bin>


More information about the Standards mailing list