Re: [Standards] Syncing legacy contact list
On Sat Jun 5 20:23:05 2010, Guus der Kinderen wrote: That would work indeed. I'm not thrilled by the prospect of having to duplicate all legacy rosters in local persistent storage, but at least this way, we can make the XEPs work properly. Should the XEP suggest how roster syncing should take place in more detail than it does now? No. Many years ago, before the dawn of time - okay, last summer - there was much enthusiastic discussion, as I recall, about the concept of a remote roster. What this would do, in effect, is allow a remote fan-out of presence to a distinct roster membership, and that roster would be owned by the remote entity, and managed by it. So, gateways would operate by owning the legacy contacts in the roster, and effectively the client treats it as a sub-roster, incorporating it into the local display. Even cleverererer, the client can cache it using XEP-0237, manipulate it using RFC 3921 core commands, and really, the only special thing is that you'd have to send the controlling entity presence in order to have presence sent onward to those contacts. Of course, by placing the remote entity in your local server roster - the one you have now - this would happen anyway when you send presnece to *that* controlling entity - ie, your account, in your broadcast presence. The entire sync issue then goes away, I think, and the interaction between client, server, and gateway looks a whole heap simpler to my eyes. My understanding is that at least some client and gateway developers are interested in playing about with some experimental code to see how this works out in practise, but it all sounds sane to me. One interesting case is where the remote roster is not a gateway as such, simply an ordinary XMPP account that you've been granted access to, perhaps because you own them both... Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] Syncing legacy contact list
On 6 June 2010 11:51, Dave Cridland d...@cridland.net wrote: On Sat Jun 5 20:23:05 2010, Guus der Kinderen wrote: That would work indeed. I'm not thrilled by the prospect of having to duplicate all legacy rosters in local persistent storage, but at least this way, we can make the XEPs work properly. Should the XEP suggest how roster syncing should take place in more detail than it does now? No. Many years ago, before the dawn of time - okay, last summer - there was much enthusiastic discussion, as I recall, about the concept of a remote roster. What this would do, in effect, is allow a remote fan-out of presence to a distinct roster membership, and that roster would be owned by the remote entity, and managed by it. So, gateways would operate by owning the legacy contacts in the roster, and effectively the client treats it as a sub-roster, incorporating it into the local display. Even cleverererer, the client can cache it using XEP-0237, manipulate it using RFC 3921 core commands, and really, the only special thing is that you'd have to send the controlling entity presence in order to have presence sent onward to those contacts. Of course, by placing the remote entity in your local server roster - the one you have now - this would happen anyway when you send presnece to *that* controlling entity - ie, your account, in your broadcast presence. The entire sync issue then goes away, I think, and the interaction between client, server, and gateway looks a whole heap simpler to my eyes. My understanding is that at least some client and gateway developers are interested in playing about with some experimental code to see how this works out in practise, but it all sounds sane to me. One interesting case is where the remote roster is not a gateway as such, simply an ordinary XMPP account that you've been granted access to, perhaps because you own them both... I was no witness to the rejoice that apparently happened many moons ago, but I like the idea that you're base lining here. The downside is that to get it working, a lot of redesign and implementation needs to happen. Although I'm not opposing that, I would like to see the current XEPs being fixed/improved in a way that doesn't require structural changes. I think the suggestions made by both Brian and myself will make the existing XEPs work as intended, without changing them in a structural way. Low-hanging fruits? Can we simple pick one (or another alternative to the same extend), incorporate that as a guideline in the existing XEPs, and continue work on the sub-roster idea in a parallel effort? Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.netxmpp%3a...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
[Standards] Syncing legacy contact list
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: xmppro...@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: legacyjul...@gateway.example.org legacybenvo...@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 legacyjul...@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: legacyjul...@gateway.example.org legacybenvo...@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. Regards, Guus
Re: [Standards] Syncing legacy contact list
On 5-Jun-2010, at 05:35, Guus der Kinderen wrote: 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 legacyjul...@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: legacyjul...@gateway.example.org legacybenvo...@gateway.example.org Benvolio is still there, even though it was removed from the roster on the legacy domain. This is a general issue with roster item exchange, but soluble. We have our roster item exchange component cache it's latest suggestions in a database so it can detect deletions from the legacy service. IOW, our server remembers that it once sent out adds for both legacyjuliet and legacybenvolio. When romeo logs in again, it sees that only legacyjuliet is in the current legacy roster, but that it previously suggested an add for legacybenvolio, so now it should suggest a removal. -bjc
Re: [Standards] Syncing legacy contact list
On 5 June 2010 19:58, Brian Cully bcu...@gmail.com wrote: On 5-Jun-2010, at 05:35, Guus der Kinderen wrote: 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 legacyjul...@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: legacyjul...@gateway.example.org legacybenvo...@gateway.example.org Benvolio is still there, even though it was removed from the roster on the legacy domain. This is a general issue with roster item exchange, but soluble. We have our roster item exchange component cache it's latest suggestions in a database so it can detect deletions from the legacy service. IOW, our server remembers that it once sent out adds for both legacyjuliet and legacybenvolio. When romeo logs in again, it sees that only legacyjuliet is in the current legacy roster, but that it previously suggested an add for legacybenvolio, so now it should suggest a removal. -bjc That would work indeed. I'm not thrilled by the prospect of having to duplicate all legacy rosters in local persistent storage, but at least this way, we can make the XEPs work properly. Should the XEP suggest how roster syncing should take place in more detail than it does now? - Guus
