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

Mike Albon mikea at yuri.org.uk
Tue Sep 14 13:40:08 UTC 2004


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.

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




More information about the Standards mailing list