[Standards-JIG] Re: Roster Subscription Synchronisation

Peter Saint-Andre stpeter at jabber.org
Mon Sep 13 19:33:44 UTC 2004

First of all, the client proxy model followed by existing gateways (and 
most fully described in JEP-0100) is a known hack. Optimizing protocols 
around that hack could lead to unintended and undesirable consequences 
unless handled very carefully. The primary purpose of our protocol and 
code development is to build a truly open alternative to the closed IM 
services, not to "interoperate" with them through client proxies. Let's 
not poison our own technologies through efforts to talk with AIM and 
MSN. Jabber technologies do not exist in order to help people chat with 
all their friends on other IM services, and if people really want such 
functionality then I suggest they use Gaim, Trillian, Fire, Adium, or 
some other multi-protocol client. True interoperability needs to happen 
at the level of server-to-server, not client proxy hacks.

That said, there are better and worse ways to follow the client proxy 
model. In earlier days, gateways sent (and most likely still send) 
presence stanzas of type ='subscribed' in order to add people to your 
roster, but that behavior has been deprecated and is explicitly out of 
court according to the XMPP specs. JEP-0100 recommends sending contacts 
to a registered user with JEP-0093. This is a good and straightforward 
use of JEP-0093.

The question is, what about roster synchronization? Sending newly added 
roster items is one thing, but deleting them is quite another and 
JEP-0093 was not designed to solve that problem (in fact all that 
JEP-0093 is define a format for a roster item in a way that is slightly 
different from jabber:iq:roster and not that many clients implement it 
now anyway, even though it is a straightforward and helpful JEP). This 
is essentially the same problem we have in defining shared groups. One 
possible solution is to use the kind of method specified in JEP-0140, 
which relies on the add/edit/delete semantics defined for pubsub in 
JEP-0060. There have been objections to this model because "nothing 
implements pubsub". But nothing implements roster deletions that adhere 
to some changed version of JEP-0093, either. To me, it seems better to 
re-use the protocols we've already defined. If the userbase for a 
certain client really wants roster synchronization, then the relevant 
client and gateway developers can implement something like JEP-0140. The 
other approach is to modify JEP-0093 so that it says something about add 
and delete (recommended, of course, rather than required, since as pgm 
says rosters must be under the control of the user). I prefer the pubsub 
approach because it makes good use of the add/edit/delete semantics 
we've defined, rather than retrofitting them onto jabber:x:roster.


In article <004401c499b6$04f8fa60$6401a8c0 at movsoftware.com>,
 "Stephen Pendleton" <spendleton at movsoftware.com> wrote:

> Wouldn't you need to subscribe/authorize to the service before it could add
> contacts to your roster? I don't see this as a practical problem.
> Initial import of the third party rosters is important but the second most
> important feature of synchronized rosters is keeping them synched. As people
> add and remove new MSN/Yahoo/etc contacts they want to have then
> added/removed from their Jabber client roster as well.
> Almost all the problems I hear from customers who utilize the transports are
> due to the fact that their MSN/Yahoo/etc contacts do not appear when they
> login to the Jabber server with a newly created account. If this problem was
> solved it would certainly increase adoption of Jabber by those people who
> are interested in maintaining third party IM accounts.
> -------------------
> OK, I think here in lies the rub. If we have a protocol for allowing
> services to start mucking around with my roster, what prevents a SPAM
> company from creating a service, and start adding people to my roster and
> sending SPIM from them?? I am VERY opposed to anything that can change my
> roster. 
> Is this a problem of synchronizing rosters something that the community (not
> just the authors of this JEP) is interested in solving?? I think that the
> current state of affairs with transports is not optimal, but from what users
> tell me, the use case they are interested in solving is just import my
> contacts the first time. They typically don't change clients that much. IMO,
> that use case is not something we should be optimizing for.
> pgm.
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> https://jabberstudio.org/mailman/listinfo/standards-jig

More information about the Standards mailing list