[Standards-JIG] Re: Roster Subscription Synchronisation
thoutbeckers at splendo.com
Mon Sep 13 22:19:46 UTC 2004
On Mon, 13 Sep 2004 13:33:44 -0600, Peter Saint-Andre <stpeter at jabber.org>
> 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.
The proposal is a generic way of keeping your Jabber roster synchronized
with an external roster. It's not a specific "hack" for a specific legacy
network. Mind you, that "external" roster could even be another Jabber
roster for all I care! Not to mention there are other open networks. Or
what if you have a "buddylist" on a forum somewhere, this would be a nice
way to keep in sync with that.
But let's assume we're talking about the MSN, AIM, ICQ, Yahoo, etc. users.
We want them to switch to Jabber right? Well this make life easier for
them, when they decide to try Jabber. Just like JEP-100 does in a way.
That Jabber doesn't aim to implement brigde all "legacy" features to
Jabber, is also one of the reasons that users still switch back to those
clients. I don't think we should make the experience as horrible as
possible for politcal reasons ;)
> 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.
I don't think PubSub is the right way to go here, because we're not really
publishing anything, and there will always be just one subscriber
(yourself). As for reusing existing specs, that's basically done by using
<item/> from the roster spec. The JEP only describes things like security,
buisness rules, etc.
As I've always stated, it's probably possible to fix JEP-0093 to do
subscription updates. Without a new namespace or actually breaking with
old behaviour, it could lead to some inpredictable results for older
clients. It would also need to add these specific rules about gateways
like there are in the current proposal. It certainly won't be as
"straightforward" as it was, for it's orginal intended use.
And all that said, I still think things regarding presence subscriptions
belong right there with presence subscribtions.
More information about the Standards