This a proposal for a quick and easy solution to the current issues with transport rosters.
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 gateway * 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 does) * 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 hassle. * 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="[EMAIL PROTECTED]" to="[EMAIL PROTECTED]" type="subscribe"/> <import/> </presence> * 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 available. 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) Comment/Questions? --- James _______________________________________________ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
