[Standards-JIG] Re: Summary of roster proposal points
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
> 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
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
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