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

Richard Dobson richard at dobson-i.net
Tue Sep 7 09:08:53 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.

This has already been suggested i.e. having a simple ACL to control access 
to remote modifications of the roster.

> However that requires modifying the clients anyway

No it doesnt, as already shown there are plently of ways to manipulate the 
ACL without needing specific client support, i.e. XData forms, web 
interface, even a chat bot could do it, in no way is specific client support 
required, if this is your only argument in favor of doing it in the client 
then its a false one.

>, and extensive
> modifications to transports, as well as modifications to the server. It 
> still
> isn't "the right way" to do it either.

You have yet to prove or show why is isnt the right way, infact we have 
shown the reverse that server based solutions are really infact "the right 
way" of doing it.

> 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.

This is already done using mod_groups I believe, although this only works 
for users of the same server (fine for organisations), I can see that it 
might not be optimal in some ways to have the roster stored in multiple 
places, but it is infact the best choice since it helps keep things simple 
for the server and client, doesnt loose some of the users contacts if there 
are connectivity problems between the server and the transport (or whatever 
is modifying the contacts), storing copies of the contacts is no real 
problem in this day and age since storage is so cheap, and since it makes 
things far more reliable as far as the end users experience goes.

> It will save on server load

Not all that much really, plus it is creating more single points of failure 
which is bad and uncessessary.

>, 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).

There is nothing stopping anyone developing something to allow you do 
download subsets of your main roster, we dont need your proposal for that, 
infact your proposal limits our possibilities for the control of the 
subsets, a protocol for downloading subsets from your own server would be 
the far better choice, although since no one seem to have proposed one yet 
does show that there isnt much demand for this functionality anyway which 
makes your point moot (even if there was lots of demand your way is 
certainly not the best way).

> I think we can all agree that to do this properly it needs to be discussed
> thoroughly.

Yes of course, but you do not seem to want to give it that time as you just 
want to push out your spec as a quick fix right now when other solutions 
already exist.

> That's why I made my proposal, to fix the current problem for
> users (and it is a big problem)

We are not disbuting that it is a big problem, we are disbuting your 
approach to this problem.

>, in the simplest and most efficient way
> possible.

No its not the simplest or most efficent way, the simplest way to do it is 
to use JEP-0093, the most efficent way is to use a server side solution.

> It only requires a relatively small change to clients, and a very
> small change to gateways, and provides _huge_ benefits for users.

It is a not a small change compared to the fact its not needed in the first 
place, many clients already have JEP-0093 support and a server side solution 
wouldnt require any specific support.

> 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.

Mess up their roster? What bad impression? If we understand exactly what the 
users are doing wrong then this helps us design better user interfaces to 
solve these problems, I am still convinced this is where the real problem 
lies, in that a lot of clients are not designed with a dumb end user in mind 
and require reasonable technical knowledge to operate them, some are better 
than others, but IMO this is where are real problem is and where it needs to 
be fixed, no new protocol is needed for that, as it already exists, its just 
a matter of desiging the interface to wrap this protocol in the best way 
possible that prevents confusing users.

> 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.

Whats the point of dropping it when you dont really need it in the first 

> 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.

They wont have the UI problem because that is a client side problem not 
strictly the transports, the only way the transport needs to be altered is 
to add support for JEP-0093, and then clients need to be altered in such a 
way as to make it much easier for end users to understand.


More information about the Standards mailing list