[standards-jig] gateway handling of legacy contact lists

maqi at jabberstudio.org maqi at jabberstudio.org
Tue Dec 16 10:53:04 UTC 2003

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

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


More information about the Standards mailing list