[Standards-JIG] Roster block importing and synchronisation using JEP-0093

Tijl Houtbeckers thoutbeckers at splendo.com
Tue Sep 14 18:04:34 UTC 2004


Hi Mike,

On Tue, 14 Sep 2004 14:40:08 +0100, Mike Albon <mikea at yuri.org.uk> wrote:

> Hi All,
>
> This is my first stab at demonstrating the full case for using JEP-0093
> for roster importing and syncronisation during the period of transition
> from a legacy client to a jabber client.

I realise I'm pointing this out to you twice now, and the first reply to  
both our post refering to this issue wasn't till *after* you posted this  
so it was impossible for you to incorporate this into your proposal, but  
for people who didn't read that I'll say it again.

A gateway can't use presence packets to remove someone from the clients  
roster. It can only set the subscription state to "none". This is because  
in Jabber presence subscription related task are done in the presence  
stanza, and roster related stuff with jabber:iq:roster infoqueries. The  
only exception to this is when you remove a contact from your roster, then  
the *server* will make sure the subscription state of that contact will be  
set to "none".

Excisting clients would need to be modified to remove "none" contacts.  
However, I'd want that for my legacy contacts (after all this means I  
already *have* removed them!), not Jabber contacts. So you'd need to  
specify security rules for clients, to check for which contacts to do this  
and which ones they should not. Or just accept that you'll have "ghosts"  
in your list.

Furthermore, I have a security concern. What happens I have someone  
subscribed to my legacy contact? Currently, the transport forces you  
through the "subscribed"-hack to have it shown in your roster that someone  
subscribes to your status. But in your proposal you state that it's  
allowed to not to add a contact that's send to you by JEP-0093. The  
*least* a transport concerned with the user's security should do is keep  
trying to ask for a subscription to the user each time the user logs in.  
For every legacy contact in the user's legacy roster there should be at  
least a "from" subscription to the user.

This a concern because else you might have a user who can see your  
presence, without you knowing it or having any way to find out about it.

Also, JEP-0093 doesn't define what a client should do if it chooses not to  
"accept" a contact/item in the list. I assume it does nothing, rather then  
send unsubscribe and unsubscribed presence stanzas to it. Do you really  
want people to know you rejected to put them on your list?

> It is understood that a barrier of entry to Jabber for a lot of users
> with large rosters is the time taken and number of dialogues required to
> register to a new service.
>
> As in JEP-0100 the user registers with the service and when the contact
> list stage is reached we can follow this proposal. Currently JEP-0100
> states:
>
> Some legacy services maintain server-side contact lists, which are sent
> to the gateway when it logs in to the legacy service on behalf of the
> user. The gateway MAY initiate adding of the legacy contact list items
> to the user's Jabber roster. Some existing gateways do this by sending a
> presence stanza of type "subscribed" from the legacy contact's JID
> (e.g., <LegacyUser at gateway.jabberserver.com>) to the Jabber user;
> unfortunately, this behavior violates the presence stanza handling rules
> specified in XMPP IM. Therefore, a gateway SHOULD instead send the
> legacy contact list items to the Jabber User via the Roster Item
> Exchange [9] protocol.
>
> I suggest adding the sub-heading Registration under the Contact Lists
> section:
>
>
> Primary Flow
>
> 1.	The Gateway sends a Service Discovery [2] request to the client to
> discover support for Roster Item Exchange:
>
> <iq type='get'
>     to='romeo at montague.net/orchard'
>     from='aim.shakespeare.lit'
>     id='gatedisco1'>
>   <query xmlns='http://jabber.org/protocol/disco#info'/>
> </iq>
>
> 2.	The client returns identity information:
>
> <iq type='result'
>     to='aim.shakespeare.lit'
>     from='romeo at montague.net/orchard'
>     id='gatedisco1'>
>   <query xmlns='http://jabber.org/protocol/disco#info'>
>     <identity category='client'
>               type='pc'
>               name='Bard IM'/>
>     ...
>     <feature var='jabber:x:roster'/>
>     ...
>   </query>
> </iq>
>
> 3.	Using the Roster Item Exchange [9] protocol to send the existing
> legacy roster to the client.
>
>
> <message to='romeo at montague.net/orchard' from='aim.shakespeare.lit'
> id='gateroster1'>
>    <subject>Items from Legacy AIM roster</subject>
>    <body>This message contains items from the Legacy AIM roster</body>
>    <x xmlns='jabber:x:roster'>
>       <item jid='mercutio at aim.shakespeare.lit'
>        name='Mercutio'>
>          <group>Family</group>
>       </item>
>       <item jid='benvolio at aim.shakespeare.lit'
>        name='Benvolio'>
>          <group>Family</group>
>       </item>
>       <item jid='rosaline at aim.shakespeare.lit'
>        name='Rosaline'>
>          <group>Desired</group>
>       </item>
>       <item jid='balthasar at aim.shakespeare.lit'
>        name='Balthasar'>
>          <group>Household</group>
>       </item>
>    </x>
> </message>
>
> 4. 	The subscription request is sent from the client to the gateway.
>
> Unlike existing transports the client sends a subscription to the
> transport. Other than the main subscription to the transport itself, the
> transport will need to subscribe from each user as well. The JEP-0093
> roster then provides a lookup table for the legacy roster which can be
> said to be pre-accepted, i.e. the client doesn't need to prompt these
> items.
>
> In this case when the client can then present the whole legacy roster
> and can provide a mechanism to either accept or deny and then send
> subscribe messages to the transport. (Which can be done in 3 messages
> using JEP-0033).
>
> So assuming that the client wishes to import all the items except
> Mercutio:
>
> <presence to='benvolio at aim.shakespeare.net'
>  from='romeo at shakespeare.lit/orchard'
>  type='subscribe' />
>
>
> <presence to='rosaline at aim.shakespeare.net'
>  from='romeo at shakespeare.lit/orchard'
>  type='subscribe' />
>
>
> <presence to='balthasar at aim.shakespeare.net'
>  from='romeo at shakespeare.lit/orchard'
>  type='subscribe' />
>
>
> <presence to='mercutio at aim.shakespeare.net'
>  from='romeo at shakespeare.lit/orchard'
>  type='unsubscribed' />
>
> <presence to='mercutio at aim.shakespeare.net'
>  from='romeo at shakespeare.lit/orchard'
>  type='unsubscribe' />
>
>
> 5. 	The server responds to the subscription requests, and subscribes to
> their presence.
>
> <presence from='benvolio at aim.shakespeare.net'
>  to='romeo at shakespeare.lit/orchard'
>  type='subscribed' />
> <presence from='benvolio at aim.shakespeare.net'
>  to='romeo at shakespeare.lit/orchard'
>  type='subscribe' />
>
>
> <presence from='rosaline at aim.shakespeare.net'
>  to='romeo at shakespeare.lit/orchard'
>  type='subscribed' />
> <presence from='rosaline at aim.shakespeare.net'
>  to='romeo at shakespeare.lit/orchard'
>  type='subscribe' />
> ...
> <presence from='mercutio at aim.shakespeare.net'
>  to='romeo at shakespeare.lit/orchard'
>  type='unsubscribed' />
>
> 6. 	The client acknowledges the subscriptions.
>
>
> <presence to='benvolio at aim.shakespeare.net'
>  from='romeo at shakespeare.lit/orchard'
>  type='subscribed' />
> ...
>
> 7. 	End use case
>
>
> Alternative Flow
>
>
> 1.	The Gateway sends a Service Discovery [2] request to the client to
> discover support for Roster Item Exchange:
>
> <iq type='get'
>     to='romeo at montague.net/orchard'
>     from='aim.shakespeare.lit'
>     id='gatedisco1'>
>   <query xmlns='http://jabber.org/protocol/disco#info'/>
> </iq>
>
> 2.	The client returns identity information:
>
> <iq type='result'
>     to='aim.shakespeare.lit'
>     from='romeo at montague.net/orchard'
>     id='gatedisco1'>
>   <query xmlns='http://jabber.org/protocol/disco#info'>
>     <identity category='client'
>               type='pc'
>               name='Bard IM'/>
>     ...
>   </query>
> </iq>
>
> 3.	The client doesn't have jabber:x:roster advertised. The add user case  
> is used for all roster items.
>
> 4. 	End use case
>
>
> Under the sub-heading Post Registration roster updating:
>
> Once a user has registered to a Gateway there are only two use cases
> which are applicable for changed items:
> 	An item has been added to the roster
> 	An item has been removed from the roster
>
> Group management done on the legacy service is currently not in scope as
> the Gateway will not know any changes that have been made in the XMPP
> client.
>
> An item is added to the roster in-between sessions:
>
> Use the case register case, but change the messages. The client on
> recipt from a service (discovered by disco) can then also use the same
> process. All pending subscriptions are handled normally.
>
> An item has been removed from the roster in-between sessions:
>
> Use the unsubscribe contact case as previously described.
>
> Any comments or feedback, especially from client authors gratefully
> received.
>
> Regards
>
> Mike
>
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> https://jabberstudio.org/mailman/listinfo/standards-jig
>





More information about the Standards mailing list