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

Richard Dobson richard at dobson-i.net
Mon Sep 6 15:12:15 UTC 2004

> A very simple case is if I subscribed to the weather agent on some random
> server. I'm ok with it sending me presences, and with it receiving mine. 
> But
> I definitely don't want it touching my contact list.

Thats fine the only time the weather bot would be able to alter your roster 
is if the weather bot had a JID of weather.bot.com, and even then the bot 
would only be allowed to alter JID's with the format of user at weather.bot.com 
(it cannot alter its own subscription of weather.bot.com), this is hardly a 
good example as it shows there is no real security problem here, also most 
bots ive seen have JID's of the format bot at server.com anyway so yet again 
its no problem.

> The same for the Edgar bot (it sends notifications of new webforum 
> messages).
> Once again I don't mind it seeing my presence, but I don't want it 
> changing
> my contact list.

It cant if its a normal bot.

> Allowing a Jabber entity to subscribe to your presence does _not_ imply 
> that
> you trust them to add something to your roster. And saying that the client
> could have a warning is silly, this should be secure as part of the 
> protocol.
> We shouldn't hijack presence subscriptions.

Its not silly at all, its simple, you have already shown trust in that 
entitity by subscribing to them, but anyway you are blowing this slight 
security concern out of all proportion, it can easily be mitigated by a 
slightly more involved protocol which could be as simple as an ACL. This 
slight problem is hardly a real reason to goto an all client solution 
without any server side support.

>> Sure im not saying that there cant be any user interface aspects to this
>> just that it is far better from the start to design it so that as much as
>> possible is done server side, and that it doesnt require support from the
>> client in order for remote roster sync to operate, there is no reason we
>> cant have stuff as I discuss above or even a more involved method of 
>> access
>> control to modify the roster, what I am trying to get at is that for 
>> roster
>> sync to work it shouldnt require client support and all that logic should
>> certainly not be placed in the client, the client support should be 
>> limited
>> to more of a command and control, not actually performing the sync 
>> itself.

> The client isn't. All it's doing is auto-accepting presence packets. 
> That's
> hardly a lot of logic. It has to know how to accept presence subscriptions
> anyway. This is just providing a hint to allow it to do it automatically.

Of course the client is handling the roster sync itself in your method, this 
is the whole purpose of your protocol is it not, to manually handle these 
rosters 100% client side??.

> Well, for a start it means that the roster isn't being stored more times 
> than
> it has to be. You wouldn't even have to sync your contact list with a 
> legacy
> service with this protocol. The gateway would just translate the MSN 
> roster
> push into a Jabber roster push.

Dont remote roster pushes get blocked as a security precaution by most 
jabber servers? If they dont they probably should be, this means your 
protocol will probably not work without server modifications. Also your 
protocol means people will have to add contacts to their roster which 
represent the sources of the roster updates just as you do now with 
transports, otherwise the roster providers will not know if you are online 
to send pushes to.

> For workgroup environments it means that you can change the shared roster
> group without having to perform a roster set on every client (regardless 
> of
> whether it's done automatically, it's sub-optimal)

Its not sub-optimal at all, infact its exactly the same, when you use your 
protocol it will send exactly the same roster set to the users as if it was 
doing the server side sync stuff which IMO would be much better.

> It doesn't introduce too much complexity into the client. The client 
> already
> understands the roster push packets (it receives them from the server 
> right
> now), it just has to learn to accept from from different sources, namely
> those that it has registered with. It also has to learn how to register 
> for
> the roster, but that could be done with jabber:iq:register, or the data 
> forms
> JEP.
> So it's really not that much complexity.

Yes it is, it is far more added complexity than it not being there at all.

>> Exactly, this shouldnt be the job of the clients, thats the servers job.
> Like I said, it is just a vague outline. But the client definitely needs 
> to be
> modified to get shared rosters to work.

As I have shown the client definately does not have to be altered for it to 
actually work, since virtually all the "work" will be being done by the 
server on its behalf.

> The other major disadvantage of the gateway subscription means modifying 
> your
> roster as a real shared roster implementation is that you can't have
> arbitrary JIDs on your contact list. Say I want to subscribe to a JDEV 
> shared
> group. That would have JIDs from all over the place, so
> jdev-component.jabber.org wouldn't be able to import them into my list 
> with
> the protocol you described.

It certainly could, using a simple ACL as outlined previously with the 
server side mechanism could easily allow for arbitrary JID, you could have 
various classes of ACL including one that allowed an entity to manage a 
particular group in the roster, managing this ACL does need client support 
(although a web interface to manage the ACL could be created, which would 
negate the requirement for any client side support) but once the ACL is 
setup you no longer need any client support for ongoing day to day 
management of the roster items as that will be done automatically by the 
server. So for people that use multiple clients some which might not support 
management of the ACL the ones that dont support ACL management are not 
hampered as roster updates will just happen, whereas your solution does not 
work at all without client support.

> I've already responded to most of this above. Except for the mobile 
> clients
> issue. I really don't think it's that much extra complexity, even for a
> mobile client (which needs to understand roster pushes anyway).
> Indeed you could even add an protocol to allow the user to select which
> contact lists they wished to retrieve. That would have great benefits for
> mobile users, and is another thing that wouldn't work with your idea.

Why wouldnt a protocol that allowed you to select subsets of users work with 
the server side syncing??? IMO it is far more likely to work than your 
solution as doing subsets would require the server doing it whereas your 
proposal is entirely client based. Also understanding roster pushes is very 
different in terms of complexity to your proposal, your proposal requires 
all sorts of extra client side stuff to be implemented in a secure fashion 
which is far removed from simply understanding roster pushes.

> The thing is, this requires a lot of thought to do properly, about both 
> the
> roster system in clients and servers. Which brings me to the next point
> again.

Yes exactly my point we shouldnt be rushing through solutions as quick fixes 
to immediate problems, we need to take time to think it through properly.

> The great thing about the roster-import proposal is that it doesn't need
> client support at all! If the clients don't support it, then the situation
> remains status quo. If the clients do support the proposal (which is 
> mostly
> just hints), then they give a better user experience.
> It's no big deal if a client drops support at any time, it just means that
> some old gateways will be a pain to use again. But they would've been a 
> pain
> to use anyway (because they haven't updated to the new protocol).

The server side mechanism doesnt require client side support either, but the 
difference here is that without client support your proposal doesnt work, 
whereas server side will continue to work just fine.

> Yeah, but like I said above, it doesn't matter, because it's basically an
> extension of the current system that clients can ignore if they want, or
> listen to if they want to provide a better user experience.

Yes but the problem here is that is then forcing developers of transports 
who want to be as compatible as possible to implement both mechanisms.

> When a real shared groups protocol comes out the gateways will be the 
> first to
> use it. The subscription code is messy.

The subscription authorisation as I have admitted might not be the best way 
in the long run, but again this is hardly a reason to discount a server side 
solution, since as I have shown a simple ACL can easily solve it, without 
needing all the complexity to the client you seem adament must be done.

> What incompatibilities? Like I said, this proposal doesn't cause any. If 
> the
> clients ignore it, they just receive a flood of subscription messages 
> (like
> before).

The incompatibilities of clients/transports supporting one or other of the 
protocols, including people who just dont bother to upgrade.


More information about the Standards mailing list