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...
http://xmpp.org/extensions/inbox/decloak.html 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 >
smime.p7s
Description: S/MIME Cryptographic Signature
