[Standards-JIG] Re: Proposal for a solution to transport rosters
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
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.
More information about the Standards