[standards-jig] gateway handling of legacy contact lists

Joe Hildebrand JHildebrand at jabber.com
Mon Dec 15 23:43:12 UTC 2003


> On Mon, 15 Dec 2003, Joe Hildebrand wrote:
> 
> > Unfortunately, all of the transport-modifies-the-users-roster stuff 
> > will only work if you are using a transport on your own server. 
> > There's no way we should allow a transport running on a 
> remote domain 
> > to have direct access to the user's roster.
> 
> I don't know what you are referring to here.

OK, maybe I need to be more concrete then.  From my foo at jabber.org account,
I register with a gateway at msn.amessage.de.  Jabber.org creates a S2S like
to msn.amessage.de, dialback ensues, and now my register iq goes to
amessage.de.  msn.message.de allows my request, logs me in to MSN, and now
has to do roster munging.  If we say that msn.message.de does a roster fetch
to foo at jabber.org, I have a real problem with that, particularly since the
gateway will end up seeing all of foo's contacts, not just the ones that
have to do with the gateway.

> Obviously, the current situation with jabberd 1.4's presence 
> type=subscribed flaw is that contact pushing is possible.
> 
> With properly implemented XMPP, pushing is not possible 
> (which perhaps is a good thing).
> 
> Perhaps it would be a good thing to write a server module 
> that implements some extensions to support transports 
> (getting/setting/modifying the roster). Security is no 
> problem as only transports the user has registered with can 
> be allowed to get/set "their" contacts (and nothing else).

I expect this will be harder to get right than you figure.  I'd start with a
different namespace than jabber:iq:roster, since many servers are (rightly)
picky about allowing those outside their trust boundary.

> Perhaps I'll start working on such a module if time permits.

Ok.  Prototyping might be a good way to come up with some protocol that we
can all use.

-- 
Joe Hildebrand




More information about the Standards mailing list