[Standards] Syncing legacy contact list

Guus der Kinderen guus.der.kinderen at gmail.com
Sat Jun 5 09:35:12 UTC 2010


XEP-0100 (Gateway Interaction), paragraph 7 states that if legacy roster
items are to be added to the XMPP roster of the entity that registered with
the gateway, Roster Exchange SHOULD be used.

XEP-0144 (Roster Item Exchange), section 7.2 reads:
"(...) In order to maintain synchronization between the user's contact list
on a legacy IM service and the user's Jabber roster, the gateway SHOULD send
roster items with an 'action' attribute of "add", "delete", or "modify" as
appropriate (...)"

I believe that this leaves room for error. As long as the XMPP entity makes
use of the legacy account through the XMPP gateway exclusively, all is well.
If the entity does not, problems might occur, as shown by example below.

For the purpose of this example, I will use a scenario that involves three
users: Romeo, Juliet and Benvolio. All three have accounts on a legacy IM
domain, in which they are "on each-others roster" (whatever that might mean
in the legacy domain). Romeo is the only user that has an account on both an
XMPP and the legacy service:

xmppromeo at example.org - Romeo's XMPP user representation
legacyromeo - Romeo's user representation in the legacy domain
legacyjuliet - Juliet's user representation in the legacy domain
legacybenvolio - Benvolio's user representation in the legacy domain.

Romeo registered with a legacy gateway, available at: gateway.example.org

After Romeo logs in, the gateway initiates a session on his behalf on the
legacy domain. The legacy domain will most likely allow the gateway to
obtain a copy of Romeo's legacy roster representation. Following the
guidelines in XEP-0100 and XEP-0144, the gateway implementation sends Roster
Exchange Addition suggestions for each item on the legacy roster. Romeo's
XMPP happily accepts these suggestions, and the roster items are added to
Romeo's XMPP roster. The changes are thus persisted on the XMPP domain. This
XMPP Roster now includes:

legacyjuliet at gateway.example.org
legacybenvolio at gateway.example.org

Now, Romeo logs out of his XMPP client, logs into a client that connects to
the legacy domain directly, and removes Benvolio from his contact list.
Then, Romeo logs out of the legacy domain, switches back to his XMPP client,
and logs on again.

Again, the gateway will initiate a session on Romeo's behalf to the legacy
domain. The legacy roster representation is obtained, which now includes
Juliet only. A typical gateway representation will send out a roster-add
suggestion for legacyjuliet at gateway.example.org to the XMPP client of Romeo.
As this item already exists on the XMPP roster, it is silently ignored.
Benvolio's representation however, is also still there. Unless the gateway
has either direct access to Romeo's XMPP roster, or obtains somehow the
delta of roster changes on the legacy domain since the last login that the
gateway did (both are unlikely), there's no way that the gateway can
determine that it should send out a Roster Item Deletion suggestion. Romeo's
XMPP roster will continue to include both:

legacyjuliet at gateway.example.org
legacybenvolio at gateway.example.org

Benvolio is still there, even though it was removed from the roster on the
legacy domain.

I have not been able to find a documented solution for this problem. Does
one exist? If not, I would suggest that a paragraph is included in the XEPs
that instruct clients to remove all roster items of which the
domain-identifier matches the domain-identifier of the legacy gateway
component, if the gateway is using Roster Exchange to populate the roster.
This will synchronize the local and legacy roster each time a new session to
the legacy domain is created.

To avoid complexity, I would suggest that the gateway implementation does
not initiate other Roster Exchanges after the initial roster sync. Note that
this does not prevent Roster Exchanges being initiated by a representation
of a legacy user (node at gateway.domain) if the legacy domain happens to
offer such functionality.

I would like to hear your take on this.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20100605/3eaedcda/attachment.html>

More information about the Standards mailing list