[standards-jig] gateway handling of legacy contact lists
JHildebrand at jabber.com
Tue Dec 16 20:23:45 UTC 2003
Imagine my knowing that your server implements these extensions, running a
service on a server of mine purporting to be a gateway, and modifying your
roster without your permission.
In an S2S world, how do you do the authentication and authorization? How
does the user delegate this authority? Is it authority to change your whole
roster, or just a portion of it that the gateway owns? If it's just a
portion, how do you denote that?
> -----Original Message-----
> From: maqi at jabberstudio.org [mailto:maqi at jabberstudio.org]
> Sent: Tuesday, December 16, 2003 3:53 AM
> To: standards-jig at jabber.org
> Subject: Re: [standards-jig] gateway handling of legacy contact lists
> On Tue, 16 Dec 2003, Matthias Wimmer wrote:
> > To say that transports should handle this in cooperation with the
> > servers, as this does not require to change all the clients
> out there
> > is wrong.
> I don't think so.
> I don't see benefit in clients modified to handle
> (yet-to-be-defined) roster change requests issued by
> transports. In fact, if we want this, we can stay with the
> standard XMPP s10n mechanism ("push" a contact by using
> presence type=subscribe [*subscribe*, not "subscribed"]) or
> use jabber:x:roster.
> Can you give an example what benefits client-side support could offer?
> Server-side transport support gives REAL benefit both for the
> user (as he gets simple and robust legacy contacts handling)
> and the transport developer (as the transport's code will get
> simpler). Of course, there should be a fallback in case the
> server does not support the transport roster handling extensions.
> > But I don't think that the server and transport should
> change anything
> > on the roster without explicit permission of the user and
> his client.
> Any reason for that? I don't know anybody NOT wanting his ICQ/AIM/...
> contact list auto-imported into Jabber. And I can hardly
> think of anyone NOT wanting to have his Jabber roster
> representation of his legacy contact list in sync with the
> legacy service (in case one uses only the legacy service for
> some reason and for example deletes or adds some contacts).
> Imagine using two Jabber clients at different locations. You
> certainly don't want client2 asking whether it should sync
> with the changes of the roster you made some hours ago using
> client1. And this is exactly the same situation.
> Standards-JIG mailing list
> Standards-JIG at jabber.org
More information about the Standards