[jdev] Proposal for a solution to transport rosters
james at delx.cjb.net
Fri Sep 3 22:23:48 CDT 2004
This a proposal for a quick and easy solution to the current issues with
The current situation is:
* A user with an account on a legacy service will have a legacy contact list
that will need to be synchronised with their Jabber contact list by the
* The current way that gateways do this is illegal according to XMPP. It also
no longer works in Jabberd2s3 (and it shouldn't, it's a security flaw when it
* There are no existing protocols for shared roster groups, and we need a way
for this to work quickly, so that users can see their legacy contacts without
* A user should not have to authorise all their legacy system contacts on
Jabber. They have already authorised them on the legacy service.
My proposal is an extension to the presence subscription packets (allowed by
XMPP) which will work in such a way that existing clients will still function
(the user will just have to authorise all their contacts again), but modified
clients would work securely without bothering the user.
An example flow with a modified client follows:
A user has been using MSN Messenger, and has acquired a large contact list on
this service. The user has heard about Jabber and wants to try it out. They
still want to be able to talk to their MSN friends, so they will use the MSN
transport on their server (host.com)
* User registers with msn.host.com
* The transport obtains the user's MSN contacts from MSN servers and begins
the import process
* The transport sends a series of packets looking like this:
<presence from="user%hotmail.com at msn.host.com" to="user at host.com"
* The user's client notices the import tag, and checks to see if the user's
contact list contains msn.host.com. It does, so the client then prompts the
user in order to double-check that this entity is allowed to send roster
imports to the user's contact list.
* The user gives the affirmative. From now on all presence type=subscribe
packets originating from the msn.host.com domain will be automatically
authorised by the client.
* The effect for the user is that by registering with the MSN gateway, and
answering yes to one prompt, they now have their entire MSN contact list
If the user had been using an existing client, they would need to answer yes
to every subscription request, but they will still receive their contact list
at the end of it. That's the advantage of using this method, any client will
support it, and all can be easily modified.
Rules for the client:
* If the client receives a presence subscription packet with an import tag,
but the originating domain is not on the user's contact list the client MUST
ignore the import tag, and treat the presence packet as normal. (this
prevents arbitrary Jabber users from auto-authorising themselves)
* A client MUST check with the user at least once before auto-importing any
contacts. The client SHOULD remember the user's answer for the duration of
the session and MAY choose to remember the answer forever. (If the latter,
then the transport will be able to transparently keep the user's contact list
in sync, if for example it is modified using another legacy client)
* A client MUST NOT auto-authorise any contacts that do not have an import tag
Rules for the transport:
* The transport SHOULD send a presence packet with an import tag if the user
has already authorised that contact on the legacy service.
* The transport MUST NOT send a presence packet with an import tag in any
other case (eg, when a legacy user requests subscription for the first time)
More information about the JDev