[Standards-JIG] Roster Subscription Synchronisation

Richard Dobson richard at dobson-i.net
Wed Sep 15 08:45:53 UTC 2004

>> In what cases wouldnt a "none" mean the legacy contact has been removed
>> from the legacy roster?

> If your transport were transporting to Jabber (unlikely, sure, but just an
> example,) the user on the other end might have simply unsubscribed from 
> you,
> and revoked your subscription, but not removed the roster item.  Of 
> course,
> nothing really says that the legacy IM services won't have this feature as
> well, it's just sheer luck that all the major ones oversimplify the 
> process.

It might be sheer luck but if all the legacy services work this way, which 
no one has yet tried to disprove then it is a perfectly logical thing to do, 
as far as I can see it if the contact is in the legacy roster at all the 
subscription will be something other than "none", and will only become a 
subscription of "none" when it is somehow removed from that legacy roster as 
well as no longer being subscribed by the other side, so you might as well 
then use this as a way of cleaning out the possible "ghost" contacts, I 
would think even for normal jabber users clients should really be prompting 
if they arnt already when a contact goes to "none" if they want it removed, 
since it is of no real use to them anymore at this point, even "to" status 
contacts should probably be being hidden from the main contact display by 
default and either shown on request or shown in a way similar to how msn 
shows its allowed list.

>> Now as you say at stage 3 the transport could reply with an unsubscribe 
>> and
>> it would return the subscription to "to", but all this interaction is
>> hardly intuitive and has a big potensial of seriously confusing the end
>> user, IMO the transport should only ever be sending a "subscribe" to the
>> jabber user if the legacy user is actually subscribing to the users
>> presence, sending this falsified subscription IMO is a hack and is 
>> unclean
>> (a clean solution would be one that transmitted the "to" info without
>> needing to make any falsified subscriptions as you seem to want to) as it
>> is not really intending to subscribe to the users presence and so is the
>> wrong way to do it.

> Maybe this information shouldn't even be going all the way to the user, 
> but
> the user should be setting some security rules on the server, and the 
> server
> should be automatically handling all this on the behalf of the user.

Yes this is the ideal solution that a server based sync system does all this 
stuff all automatically for the user once they have authorised it to do so, 
but the people involved with this spec want something now and do not want to 
wait for what even they admit is the better approach of a server based 

> That way, when the subscription changes, the roster update would get 
> pushed
> to the user just as if another resource were logged in.  No presence flies
> around, then, or at least not to the user.  But maybe if it were the 
> server
> handling it, client backwards compatibility would no longer be an issue, 
> and
> we could use simpler <iq/> packets to do the exchange.

Exactly this sort of server based solution is what I originally argued for 
early in this course of discussion (along with others), but again the people 
involved with this spec do not want to wait for this better and fully 
backwards compatible solution to come along. But yes I agree too that it is 
the far better long term solution (even the people involved in this spec 
admitted that).


More information about the Standards mailing list