[Standards-JIG] Re: Proposal for a solution to transport rosters
richard at dobson-i.net
Mon Sep 6 11:01:06 UTC 2004
> I even expect that modifying clients will take effect much sooner. By
> modifying the server you have to convince each server administrator to
> update the server software and you have to implement the feature to
> different server implementations as well.
> With a client modification it is only the user, that want's the feature,
> that has to update his client. If the user wants the feature he will be
> for sure willing to update his client, much more likely than the server
> administrator will update his server.
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. As far as
servers being updated goes I would think that in actuality if a new version
of the servers and transports came out tommorrow with this functionaility
that server admins would deploy it quite quickly, they already have to keep
updating their transports to keep them working, and im sure they would love
anything which makes life easier for their users using the transports. The
only people I would see not deploying this so quickly is probably businesses
using jabber internally for messaging, but in those situations I doubt they
even allow transports anyway.
> Jabber's concept of isolating the proprietary IM protocols from the
> clients means, that a client does not have to be updated, if AOL, MSN,
> Yahoo, ... are changing their protocols ... it does _not_ mean that we
> have to implement _new_ features in a way that clients don't have to be
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.
>> > The user needs to give permission for the roster import to go ahead
>> Typically, a user already expresses his trust in a transport as soon as
>> acks the transport's subscription request. Even in the case the user
>> accidentally accepted a subscription request of a malicious server, the
>> real damage this server can do then is about zero as it only can
>> insert/remove contacts with the malicious server's host JID part. There
>> are simpler ways to annoy Jabber users ;-).
> You should know that the server does not know which entities on the
> Jabber network are transports and even more it does not know which
> transports a user has registered. Even if the server would intercept
> jabber:iq:register queries it can not know, that the entity is a
> transport and the user registered with it. E.g. it could also be that
> the user send a jabber:iq:register query to a conferencing server to
> just register a nickname there.
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
2) Transport subscribes to the users presence
3) User accepts or denys presence subscription (if the user accepts then we
proceed to step 4 if denyed this is the end)
4) Transport uses the standard jabber:iq:roster protocol to remotely request
the roster items it is allowed to control
5) Users jabber server responds to remote roster request only with items
which match the transports domain, and only if the user has accepted a
presence subscription from that domain. e.g.
T: <iq type="get" id="1" to="user at server.com" from="msn.server.com">
S: <iq type="result" id="1" to="msn.server.com" from="user at server.com">
<item name="Romeo" jid="romeo at msn.server.com"/>
<item name="Juliet" jid="juliet at msn.server.com"/>
Notice how only contacts matching the domain msn.server.com are returned, so
the only damage that could be done to the users roster is that that domain
can only modify items in its own domain.
6) Transport wants to add a contact to the users roster, the transport uses
standard roster protocols to do this.
7) The jabber server received the add request and makes sure that the user
has accepted presence from msn.server.com, the server also makes sure that
the jid of the contact the transport is attempting to add matches the domain
of the transport, the same rules apply when modifying or removing items from
Overall this method means that clients do not need to be altered and helps
keep them more simple (which IMO is a good thing), this method reuses
existing protocols without needing to reinvent something new, allows
transport rosters to always stay in perfect sync, keeps all this logic on
the server side which was last I heard one of jabbers primary goals.
It does have some security considerations but with the restrictions
presented above the only real damage a transport could do was to its own
items in your roster, and if something did happen that you didnt like you
just unsubscribe from the presence of the transport/server and maybe even
block it using privacy lists.
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.
More information about the Standards