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="[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 > _______________________________________________ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
