[jdev] XEP-0100 and roster/legacy contact list sync

[Peter Saint-Andre]

Massimiliano Mirra wrote:
>>> I thought such forwarding of roster actions to be somewhat innovative,
>>> but of course it turns out it's been already described and in a better
>>> way: http://antecipate.blogspot.com/2006/06/roster-remoting.html
>>>
>>> I'm curious as to whether this has been considered by transport and
>>> server authors.  The fact that it's transparent to the client looks
>>> attractive.
>> I like that this is:
>>
>> 1. transparent to the client
>>
>> 2. a matter for the server and transport
>>
>> We might want to write this up in a spec at some point, for example to
>> document some of the error handling (what if the user is not registered
>> with the gateway, etc.).
> 
> I ended up having component and server converse in XMPP despite them
> being in the same process space (seems more elegant), but as I said it
> was a pretty limited scenario and there wereg no trust concerns.  But
> while writing it I started wondering how it would work in the real
> world.  A server would either have to intercept <query
> xmlns='jabber:iq:register'/> to transports and deduce trust, or look
> for <item jid={transport} subscription='both'/> in the user's roster,
> and in both cases I can imagine disco/info packets going out to
> possibly many uninterested parties to ascertain whether they're
> transports or not.  Maybe there's a sane way around the corner but I
> can't see one at the moment.

Well, a smart transport should share presence with the client and then
you can include entity capabilities information. No need to do disco at
that point. :)

Peter

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://www.jabber.org/jdev/attachments/20071204/b6346834/attachment-0002.bin>