Roster remoting

But how does Romeo knows “a2ff356” is in fact Juliet? That was the offline comment to my post about XMPP transports addresses. Oviously the built in “name” attribute that is part of the roster management syntax can be used to initialize this information. It could hold Juliet’s address handle in the external network, or a nickname if the networks supports both address and nicknames. But none of the current transport implementation will allow to always force these parameters to their proper values, or allow them to be reset on demand.

Nonetheless, I am toying on this blog with practical ideas and suggestions that can be picked up and build into solutions to enhance the XMPP protocol functionalities. From the discussion thread that followed this question emerged a simple concept: why not let the transport manage its own part of an user’s roster?

Current XMPP servers’ implementations have a very centralized way of managing a user’s roster. This architecture design has led to many protocol extensions to accommodate a transport’s role as an external user proxy. In effect, a transport “impersonates” an XMPP user into a different communication network. It provides the appropriate communication and presence translations, as well as an address handle mapping between the two communication spaces. The main requirement for using a transport is possessing an address handle in the target communication space. An XMPP transport to Gadu-Gadu would require the XMPP user to use a Gadu-Gadu ID in order to be recognised as a proper Gadu-Gadu user. If the XMPP user has used the other communication network before moving to XMPP, it will almost certainly want to carry over its previous contact list. If the XMPP user just wan to use the transport to communicate with a different network, it will certainly want to add new external contacts to its roster.

…what if the transport itself becomes responsible for managing its part of the user's roster?

Every transport to date has been designed around the centralized roster concept. Earlier on, a transport was silently updating the XMPP user’s roster at registration time. More recently, the XMPP protocol has been augmented to cater for the kind of bulk roster addition a transport was likely to produce. Now, imagine for a moment that the transport itself becomes responsible to manage its part of the user’s roster. In effect, the management of MSN users would be done by the MSN transport, the Yahoo! Users roster would be handled by the Yahoo! Transport, etc… In this architecture, the transport is responsible to provide the answer to the initial question. The answer would be easily carried in the name attribute of the roster result. The transport could offer administrative options to allow/prevent users to change the external network nickname and maintain a tight coherence between the XMPP and the external contact list.

In addition, delegating the roster management to the transport would also decrease the overall traffic between the home XMPP server and the transport, providing a specialized XMPP compliant distribution list for presence. An implementation allowing “roster delegation” would have to enforce an adequate level of trust between the transport and the user home server. This trust could result from two different contexts:

• If the transport is a component of an XMPP server, then the trust would result from the configuration of the server and the component.
• If the transport is a remote service provided by a different server, then the trust would be established through Mutual TLS authentication between the transport and the home server.

In the created trust domain, the home server would be able to decide to delegate the roster management to the transport. More generally, it is possible to extend this concept to any service providing a contact list management of some sort. This would extend XMPP using the traditional “simple client, complex server” approach. From a client perspective, nothing has changed. The client issues a roster request to its home server and receives a result. The way the roster is managed is entirely dependant of the server implementation. It is the server’s responsibility to discover “roster delegation” support and to aggregate the various roster parts into a complete roster result. The decision to use delegated roster management can also be coupled with the level of trust provided by the remote service. This would allow a server to opt out using “roster delegation” if the target system does not comply with a defined trust level, or reputation, although it provides the delegation feature.

Technorati Tags: XMPP, Jabber, Interoperability, Addressing, Conversation space, Trust, Antecipate