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/
smime.p7s
Description: S/MIME Cryptographic Signature
