[Standards-JIG] Summary of roster proposal points

James Bunton james at delx.cjb.net
Tue Sep 7 06:58:20 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.

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, the reason the
<presence type="subcribed"/> is not allowed by XMPP (before subscribe)
is to prevent this modification of users' rosters without permission.
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, then we're going to have even
more problems down the line, when servers start disallowing gateway
access to users' rosters (as they should)


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.


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. Any other permissions based approach would need client
modifications anyway, 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. The
client should be the one to manage this because the user has to be
consulted at some point anyway. 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.



More information about the Standards mailing list