[Standards-JIG] Re: Summary of roster proposal points

James Bunton james at delx.cjb.net
Tue Sep 7 08:00:33 UTC 2004

> The user would have granted access to the remote entity.  This is no better
> or worse, security-wise, than your proposal.  The reason doing it through
> the server is the "right" way, is because it centralizes the permissions,
> and doesn't change any of the roster handling rules from a client
> perspective. 

> Allowing any subscribed JID to modify your roster is totally not what I was 
> suggesting.  The only JIDs allowed to touch your roster would be those that 
> you've explicitly granted permission to do so, via a specific element in 
> iq:register (like <grant-roster-permission/> or something).

That's a much better idea than just using the subscription status to decide 
whether an entity can modify your roster. It means the server has to look out 
for that tag, but I guess that's not too much of a hardship.

However that requires modifying the clients anyway, and extensive 
modifications to transports, as well as modifications to the server. It still 
isn't "the right way" to do it either.

I don't think having the shared roster groups stored individually for each 
user is a good idea (Thinking of more than just transports here). Since 
they're shared groups, why not just store them in one place and push them out 
to each client when they log on. It will save on server load, as well as 
allowing greater control for the clients, they could for example choose to 
only download specific contact lists (perhaps by only sending presence to 
certain entities).

I think we can all agree that to do this properly it needs to be discussed 
thoroughly. That's why I made my proposal, to fix the current problem for 
users (and it is a big problem), in the simplest and most efficient way 
possible. It only requires a relatively small change to clients, and a very 
small change to gateways, and provides _huge_ benefits for users.

I know that people would like to get this right the first time, but it's not 
going to happen quickly. This is a big issue for new users, and I (as well as 
others) are reluctant to suggest new users try Jabber because of it. I 
usually still suggest it, but I hang around to make sure they don't mess up 
their roster to start off with. It's a very bad first impression that can be 
fixed easily.

The other great thing about my proposal is that support for it can be dropped 
at any time (likely when the real shared roster groups protocol comes out), 
without any problems. It just means that users with old gateways will have 
the same old UI problem again. But then again, there's not much point 
dropping support for it, and gateways are frequently updated anyway.



More information about the Standards mailing list