[jdev] Proposal for a solution to transport rosters

[mikea-jdev at yuri.org.uk]

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.

Thanks

Mike


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 
> 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="user%hotmail.com at msn.host.com" to="user at host.com" 
> 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
> jdev at jabber.org
> https://jabberstudio.org/mailman/listinfo/jdev
>