[Standards-JIG] Summary of roster proposal points

Richard Dobson richard at dobson-i.net
Tue Sep 7 08:38:28 UTC 2004


> My two main points are:
> 1) The current situation with transports involves them either breaking
> XMPP by sending <presence type="subscribed"/> before it's requested, or
> having the user manually authorise 100s of contacts. Both of these are
> unacceptable, and this situation needs to be fixed very soon.

Yes and people have already pointed out an immediate solution to your 
problem without needing to invent anything new, JEP-0093 or a bit more 
intelligence in your client, your problem is mainly a UI issue and does not 
stricktly require any new protocol changes to make it a bit nicer.

> 2) A real shared roster groups system needs long discussion to get
> right, my basic idea for a real system certainly needs refinining, and
> the other one that was proposed is no better. The idea with letting
> gateways modify your roster directly is just plain bad

Why? Myself and others have shown that it is your option that is actually 
the bad one and pretty much against jabber philosophy and established 
development practice. You need to properly explain valid reasons for why 
"its just plain bad" because up until now you havent shown anything valid 
that does not have a simple solution.

>, the reason the
> <presence type="subcribed"/> is not allowed by XMPP (before subscribe)
> is to prevent this modification of users' rosters without permission.

Yes it does have permission, you have explicitly granted the remote entity 
restricted access to alter the roster, it is nothing like using subscribed 
as you suggest.

> Lets not bring it back in a new form! If we start using this idea, which
> is really more of a hack than my proposal

No its not a hack of your idea, this idea of allowing remote entities to 
alter your roster remotely has been discussed several times in the past 
before you came along, read the archives.

>, then we're going to have even
> more problems down the line, when servers start disallowing gateway
> access to users' rosters (as they should)

Huh?

> The current issue is a huge one for users. It needs to be solved
> quickly. We cannot wait for a real shared roster groups protocol,
> regardless of how that may turn out to work.
> The only two ways to solve this quickly without too many problems that I
> can see are using JEP0093, and using the import tag extension as I
> described.
> I prefer the import tag extension because it will work with all clients,
> regardless of their support for it, and the presence subscribe packets
> need to be sent anyway, so we may as well use them for this too.

The problem here is many do not agree with your proposal, so if you want to 
solve it now JEP-0093 is your best option, since it is already implemented 
in a few clients, and is not inventing anything new as a "quick fix" as you 
suggest.

> I would also like to reiterate that I do not believe that giving
> subscription to a jabber entity means that I want them to modify my
> roster.

We have already solved that problem, using a simple ACL, do you even read 
the replies to your emails?

> Any other permissions based approach would need client
> modifications anyway,

I have already shown that it doesnt "require" client support as there are 
several ways in which you could edit the ACL list, either a custom protocol, 
XData forms, even an intelligent chat bot could be used, or even a web 
interface, it in no way "requires" any specific support to work.

> so we may as well put it all in the client, rather
> than trying to hack it into the server where it doesn't belong.

Thats the problem here, plently of us dont agree with you, infact we think 
the opposite that it belongs in the server, you have yet to provide any 
credible reasons why it must only be in the client and why its a bad idea to 
have any of it in the server, explain yourself or you risk just being 
ignored.

> The
> client should be the one to manage this because the user has to be
> consulted at some point anyway.

Why exactly, I thought the whole goal of a shared rosters system is that the 
user does not need to be notified when a contact is added, by the sound of 
this statement you just want things as is so that the user is prompted for 
every new subscription to their roster.

> That's not to say a future shared roster
> group protocol wouldn't involve changes to the server, but lets not add
> this hack into the server where it doesn't belong.

Its not a hack as has been already shown, making comments such as this just 
degrades any credibility you might have on this subject.

Richard





More information about the Standards mailing list