[Standards-JIG] Re: Proposal for a solution to transport rosters

Richard Dobson richard at dobson-i.net
Mon Sep 6 16:01:40 UTC 2004

> No ... but because it can be cleaner implemented if we accept to at
> least implement the changes partially on the client, we should not try
> to just hack it in the server.
> I just said, that we don't have to fear changing the clients to
> "protect" users from the need to update the client, as what we try to do
> ("updating the server") is already the harder part.

Of course but we must also not fear changing the servers too, as I have 
detailed in my last email on this subject I believe that a lot of this 
belongs in the server, im not saying some stuff might not be needed in the 
client, but we must see which bits those are and try and put as much as we 
can do into the server to try and keep our philosophy of simple clients.

> Why do you want to distort what I said that much? I did not say that for
> every new feature we implement we HAVE TO change the client. I just say
> that it can be okay to make additions to client protocols if it leads to
> a cleaner protocol, more security/privacy, or other things like that.

Ok sorry about that I must have misunderstood you, I thought that you were 
also arguing that this roster stuff belongs on the client side simply 
because its possibily difficult to get people to upgrade their servers, 
which is an assumption im sure you can see I do not agree with.

> In the case of transports "pushing" to the roster, we need the user to
> approve the push. Any server side decision on which entities are
> allowed to push items can only be very big hacks as long as the server
> can only guess on the authorization.

Ok sure, which is something I have addressed in my last email, i.e. have a 
simple form a ACL to control the permissions for who can alter what in your 
roster remotely, this allows us to keep all the actual processing and 
management of the roster on the server side while giving control to the 
client, all without unnecessarily complicating the client.

> Sure, we have to avoid changes, that will prevent existing clients to
> use features, that they could use before the change. But I don't think
> we have to fear client changes to implement new features where these new
> features can be implemented cleaner, more secure, with more privacy, or
> ... when we allow the change on the client side.

Sure but again by the same token we must not be afraid to make server level 
changes/additions where needed.

> Implementing the foreign contact list to jabber roster push we are
> implementing a new feature and we don't break any existing functionality
> if we request clients to accept the push. And as Mike already proposed
> in this thread and as I already proposed many times in different threads
> for a long time: jabber:x:roster can be used for pushing roster items -
> which would already be supported by many existing clients. If features
> are missing in jabber:x:roster that we would like to have in a roster
> push protocol, we can extend the existing protocol in a way that old
> clients can get the pushed contact list items and updated clients with
> extended jabber:x:roster support would be able to get the additional
> information that is pushed.

Yes for backwards compatibility and to stop having to accept loads of 
subscriptions when subscribing to a transport using jabber:x:roster will 
reduce this into one dialog and one click rather than tens of dialogs, this 
will certainly helps matters, although I do think in the longer term server 
side remote roster manipulation is the optimal solution that its worth 
starting work on now.

> Your basic assumption is just wrong. How should the server know that the
> user registered a transport? The only thing a server could know is that
> the user sent an iq in the jabber:iq:register namespace to an entity
> with a JID that does not have a user part. - But this does not mean,
> that the user registered a transport with this request. For example
> mu-conference used jabber:iq:register to the conferencing server address
> for registering nicknames or a pub sub server might use this namespace
> as well. But I don't want each conferencing or pub sub server where I
> registered a nick name, a pub sub node, ... to pollute my roster with
> spam entries.

Sure it was just an example method for discussion and as a result of this 
discussion a better solution has come out of it, i.e. a simple ACL 
controlling access to alter the roster.

> I did not reject solutions where the server has to be modifed at all. I
> just said that there is no reason to force the change to be server-only,
> which would have the result that we get a big big hack instead of a
> clean protocol.

Again sorry, from reading your email I read it that you were rejecting 
server side options because they might be hard to get deployed, im all for a 
nice clean protocol, just not a protocol that is client side only, and one 
that seems to have been rushed through as a quick fix (the ultimate in bad 
development practice IMO) and without proper discussion prior.


More information about the Standards mailing list