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

Peter Saint-Andre stpeter at stpeter.im
Mon Jan 18 02:54:28 UTC 2010

FYI, I've made a some edits to this proposal to align it a bit more
closely with our original discussions at XMPP Summit #5...


On 1/13/10 12:42 PM, Peter Saint-Andre wrote:
> 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

-------------- 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/20100117/5c8a9bb0/attachment.bin>

More information about the Standards mailing list