Hello, 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: [email protected] - 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: [email protected] [email protected] 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 [email protected] 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: [email protected] [email protected] 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. Regards, Guus
