[jdev] Proposal for a solution to transport rosters

[Justin Karneges]

While this would certainly work, I think a server-side extension would be 
better.  What we'd need is a way to allow a remote domain to modify the 
user's roster directly, but only with the user's permission.  The transports 
could then sync, import, etc, with nicknames, use proper groups...  anything.

There are probably many ways to do what I'm asking for, and I'm not sure what 
the best way would be.

One possible way is to add a new element into the iq:register form to handle 
roster control.  If the user "agrees" to allow roster control, then the 
user's server will see this in the registration iq-set, and can record the 
remote domain in a local list.  Unregistration should also be detected by the 
user's server, so that the domain can be removed from the listing.  If the 
transport is "trusted" (ie, running on the same box as the jabber server), 
then maybe all of this can just be skipped.

Assuming that's out of the way, any domain in the list would then be able to 
send iq-set roster packets to the server on behalf of the user.  The server 
would then send roster-pushes to the clients.

-Justin

On Friday 03 September 2004 8:23 pm, 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