[jdev] Proposal for a solution to transport rosters
mikea-jdev at yuri.org.uk
mikea-jdev at yuri.org.uk
Mon Sep 6 08:01:29 CDT 2004
Hi James & all others.
What is 'wrong' with using JEP-0093 (jabber:x:roster) after a disco or caps to the client? I am using '93 within my yahoo-transport.
The only change in the logic would be:
1 User registers with msn.host.com
2 Transport does disco or caps comparison to see if '93 is supported, client advertises the jabber:x:disco feature.
3 If '93 is supported then provide a roster exchange list to which the client can decide what to do with (user configurable), or go through old method of sending a subscription for each
(or just sending a '93 anyway which is what I do).
As you are already checking for the registered hostname the logic is easier and a lot of clients already support '93 so you loose nothing in real terms.
Please correct me if I have made a major error in logic.
On Sat, Sep 04, 2004 at 01:23:48PM +1000, James Bunton wrote:
> 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
> * 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)
> jdev mailing list
> jdev at jabber.org
More information about the JDev