[Standards-JIG] Roster Subscription Synchronisation

Peter Millard pgmillard at gmail.com
Mon Sep 13 16:42:49 UTC 2004


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>
> wrote:
> > 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
packets.

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.



More information about the Standards mailing list