[Standards-JIG] Re: Proposal for a solution to transport rosters
m at tthias.net
Mon Sep 6 15:27:23 UTC 2004
Richard Dobson schrieb am 2004-09-06 12:01:06:
> Just because the clients might be able to be updated and deployed more
> quickly doesnt mean it is the right place to put this logic.
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.
> No it doesnt mean that new features need to be implemented in the server,
> but being that one of jabbers guiding principles is to keep as much of the
> complex stuff in the server as possible, and that it has been shown that it
> is a perfectly viable option it does seem to be a choice that is far more
> inline which jabber phylosophy. IMO anything which can be implemented in
> the server rather than the client should be concidered as the preferable
> choice, the perception that it might take longer to deploy is no reason to
> discount it as the right choice. If we followed this line of reasoning then
> stuff like pubsub should really be an entirely client side system, with the
> client hosting all of the pubsub logic instead of servers, since pubsub
> servers will quite possibly take a while before they are widely deployed
> enough for clients to be able to reliably use them without creating a
> single point of failure by at the moment clients having to use central
> servers rather than pubsub servers deployed alongside every jabber server.
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.
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.
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.
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.
> Why would the server need to know which entities are transports? The way
> the method would work would be as follows:
> T = Transport
> S = Jabber server
> 1) User registers with a transport that supports the server modification of
> the roster.
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
> We might want to make a more extensive authentication system than simple
> presence subscription checking for allowing remote roster manipulation, but
> even if we do doing as much server side as possible should be our primary
> goal here, not simply rejecting a server side solution solely because it
> might take longer to deploy than a client side solution.
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
Fon: +49-(0)70 0770 07770 http://web.amessage.info
HAM: DB1MW xmpp:mawis at amessage.info
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: Digital signature
More information about the Standards