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 XML is available here (click "raw" for raw XML): http://git.collabora.co.uk/?p=user/smcv/telepathy-gabble-smcv.git;a=blob;f=docs/decloak.xml;h=656c11cd67b728914df4d82319e438f8842a9729;hb=b04a05234d8569c9852611142bfb3ecb6c1a5822 > > <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). > > <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. > 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. > * 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. > * 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". Any thoughts on this protocol? Regards, Simon
signature.asc
Description: Digital signature
