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

Richard Dobson richard at dobson-i.net
Sun Sep 5 13:45:09 UTC 2004


>> I don't think in practice there's a situation for which a user says "Ok,
>> this transports may subscribe to my presence, but I don't trust it really
>> so I don't grant import capabilities".
>
> True.  My thought was
> import_privileges = server_trusts_transport ? !user_deny : user_approve;
> but maybe being able to deny is overkill.

Yea it does seem to be as you will see in my explaination below.

> Being able to deny untrusted transports is essential, as any entity
> could send such a presence stanza, but that could be signalled by the
> absence of an <import/> element.

I think maqi's point is that you dont need to use your extra authentication 
to deny untrusted transports, all that capability is already built into 
jabber, by denying the transport subscription you are stopping the transport 
modifying your roster, also if you were to allow a transport to modify your 
roster it wouldnt be much of a security problem because the transport would 
only be able to modify contacts that are in its domain, also you would only 
let the transport know about contacts that are in its domain so its not like 
it can even see your whole roster anyway. Also if you want to subscribe to a 
transport but not allow it to modify your roster you should be able to use 
standard XMPP privacy lists to stop the transport making any modifications 
without needing to create a new authentication protocol.

>>> What do you think about this?
>>
>> I think this is too complicated. Also, I don't see the real benefit (or
>> did I misunderstand anything?).
>
> This is more complicated than James' proposal, but on the other hand
> it puts this complication on the server and the transport, instead of
> on the client.  No client modification is necessary, except to approve
> remote transports.  It also avoids a roundtrip, as imported contacts
> don't have to be sent first to the client, and then back to the
> server.

IMO I dont think the server side method is more complicated at all, IMO its 
far simpler and follows the jabber phylosophy of keeping the complexity on 
the server side and out of the client.

I can see that some people are desperate to get something in and working now 
but IMO this is exactly what we shouldnt be doing, we should try to only 
standardise protocols that are going to last, IMO we certainly should not be 
standardising anything that we can already see we will be replacing anyway 
in the not so distant future, its far better to spend our time working on 
the longer term solution and inso doing getting that out in the wild faster 
than if we create a intermediary solution. If people really want something 
that works now that is only going to get replaced anyway then its probably 
best they do it as a non-standardised extension so they can solve their 
problems now without the rest of us having to spend too much time on 
standardising what im sure we can all see is not really the best solution to 
the problem, then once we have standardised the optimal solution they can 
then move to use that.

Richard





More information about the Standards mailing list