[Standards-JIG] Roster Subscription Synchronisation
thoutbeckers at splendo.com
Mon Sep 13 20:09:18 UTC 2004
On Mon, 13 Sep 2004 10:42:49 -0600, Peter Millard <pgmillard at gmail.com>
> On Mon, 13 Sep 2004 18:19:05 +0200, Tijl Houtbeckers
> <thoutbeckers at splendo.com> wrote:
>> On Mon, 13 Sep 2004 15:30:37 +0100, Richard Dobson
>> <richard at dobson-i.net>
>> > Because JEP-0093 provides an existing way of representing a contact or
>> > list of contacts that can be transmitted between to jabber entities,
>> > this is effectively what you are trying to do, i.e. transmit a contact
>> > or list of contacts between two jabber entities, the user and the
>> > transport, it seems a perfect match to me, and several others too, ive
>> > counted at least four of us that feel this way.
>> If that's all we're trying to do it could work. However, we are not. We
>> are synchronizing subscriptions. Not just sending contacts.
> 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. It's a privacy issue. I'm NOT opposed to having a
> service send me things/contacts/people that I MAY want to subscribe
> to. This is why the verbiage in the XMPP specs is the way it is. We
> need to be EXTREMELY careful about exposing any protocols which allow
> folks/services to influence rosters. Control of who/what I subscribe
> to should always be at the user's discretion. This is why I REALLY
> don't like having a transport send me any kind of subscription
Have you read the proposal?
"If the client receives a presence subscription packet with an
roster-subsync tag, but the originating domain is not authorised on the
user's contact list, the client MUST ignore the roster-subsync tag, and
treat the presence packet as normal. This prevents arbitrary Jabber users
from auto-authorising themselves."
Further more a client can ask for permission from the user on a
once-per-session basis, or even for every contact for the most paranoid
amongst us. (a Yes/No/Always/Never dialog would provide both) Yes you have
to trust the transport that you added in your roster. For that matter, if
you don't trust your transport the transport itself could send you spim :)
> 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.
My roster is full with "ghost" transport contacts. I find this very
annoying. This is particulary intresting for people who still switch
between Jabber and legacy networks. For example, using jabber on your
mobile, and the official client (or a multiprotcol client like GAIM) at
home. Or people who use different clients at home or at work. etc.
The use-case right now has been brought on mostly for MSN, so there the
inserting ("both") and removal ("none") are most intresting, but gateways
can do more than just MSN.
Of course users right now are most intrested in solving the initial import
(which this proposal does), and I don't think most will be content with
"just" JEP-0093 (prefering a more automated solution). It doesn't mean
they won't like it that when they delete a contact on a legacy network
they don't have to do it again in Jabber.
Keeping your Jabber roster in the same state as your legacy roster sounds
like a usefull feature to me. As you can see, it's not a very complicated
thing to implement either. Why not document such a technology in an
> typically don't change clients that much. IMO, that use case is not
> something we should be optimizing for.
This solves the "initial import" just as well as any other solution I've
heard so far, and I doubt it will take more than a few lines of code. The
only benefit I've heard so far for sticking to JEP-0093 is some form of
backwards compatibility for client that support jabber:x:roster already.
Though if you use an "upgraded" JEP-0093 (in the <message/> stanza) for
synchronization it could give some weird results for those clients.
More information about the Standards