[standards-jig] gateway handling of legacy contact lists

Paul Curtis pcurtis at terrapin.com
Tue Dec 16 02:05:19 UTC 2003

On Monday, December 15, 2003, at 08:05  PM, Matthias Wimmer wrote:

> Hi Paul!
> It is not reliable, as these "wrong" presence packets are already
> dropped by jabberd2 and I am not sure how all the other servers, that
> already exist, handle this.
> I think one thing we have to learn even more with XMPP getting an
> official standard is, that there are not just multiple clients, but
> multiple server implementations as well.

I know this. And as of right now, the presence packets with type 
subscribed are ignored by jabberd2.

>> The syncing of rosters between legacy and jabber systems should be
>> handled by the transport as much as possible. That was why I commented
>> on Joe's suggestion of the transport keeping the last know list of
>> legacy contacts.
> 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. We
> already have different server implementations too.
> Handling this between the transport and the client gives the client 
> much
> more power in defining its way how to handle contacts on other IM
> networks while still making it possible to handle them as normal Jabber
> contacts. If a user does not like the way its client is handling the
> import he may change the client, but he cannot change the server
> software.
> Maybe it can be handled in cooperation of all three entities, the
> transport, the server and the client. 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.

I agree, and XMPP specifies this. However, the users have requested 
this roster synchronization, so I added it. It does not work on 
jabberd2. Now the question will be .... how does the transport 
communicate the contact list from the legacy IM system? Right now, we 
do not have a way to do this. It will require a different mechanism to 
accomplish this, and should be an optional item that the user can 
select or not. It does, however, add another step in the registration 
process for a transport as well as further steps when the two rosters 
are no longer in sync.

More thought is needed .... and any suggestions would be welcome. 
Especially from the client developers, as they will be the ones who 
will have to implement any changes in transport roster handling.


More information about the Standards mailing list