[Standards-JIG] Re: Summary of roster proposal points
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
>> 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
>> suggesting. The only JIDs allowed to touch your roster would be those
>> 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
> whether an entity can modify your roster. It means the server has to look
> 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
> 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
> 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
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
> 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
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
> going to happen quickly. This is a big issue for new users, and I (as well
> 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
> their roster to start off with. It's a very bad first impression that can
> 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
> at any time (likely when the real shared roster groups protocol comes
> 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