[Standards-JIG] Re: Proposal for a solution to transport
james at delx.cjb.net
Mon Sep 6 08:29:25 UTC 2004
X-BeenThere: standards-jig at jabber.org
Reply-To: Jabber protocol discussion list <standards-jig at jabber.org>
List-Id: Jabber protocol discussion list <standards-jig.jabber.org>
<mailto:standards-jig-request at jabber.org?subject=unsubscribe>
List-Post: <mailto:standards-jig at jabber.org>
List-Help: <mailto:standards-jig-request at jabber.org?subject=help>
<mailto:standards-jig-request at jabber.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Sep 2004 08:29:42 -0000
On Sun, 5 Sep 2004 11:45 pm, "Richard Dobson" <richard at dobson-i.net> wrote:
> >> 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
> >>> 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 think that it's necessary to modify the client for this to work properly.
Just because I give subscription to a JID without a user part (eg, host.com)
definitely does _not_ mean that I want it to have write access to my roster.
Yes, even if it only can import contacts from it's own domain.
If we're going to do this on the server, lets do it properly, with client
support too. That's my intention for the long run. But the current situation
is a major user experience flaw. It's a huge put-off to potential Jabber
> 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.
Exactly right. The proposal for a server-side shared list before I didn't
I think it would be great to be able to subscribe to rosters on various
servers. By default you're subscribed to the roster on your Jabber server.
When you register with a gateway, part of the registration process would
involve registering with the roster on that server.
Note that this isn't pubsub. The rosters that you're registered with would
send you iq packets that look just like a normal roster packet from your
server, they would just come from a different place. The client could then
put these contacts in a separate group.
There are obvious issues with this, such as the client having to keep a list
of rosters that it's registered with (to determine what packets to accept and
which to ignore, etc).
That's my vision of a *real* shared roster groups protocol. It would be useful
for transports, as well as workgroup environments.
Back to my current proposal though. It fixes the short-term need, with minimal
effort for both transport and client developers. It does not require server
changes (which must be much more thoroughly tested, and are more disruptive),
and is ready to use right now. More testing would be good however.
I just need to write it up as an informational JEP, and get support in a few
more clients. We have a Psi patch thanks to Remko, which with a little more
testing should be ready for inclusion (please Justin! =), and hopefully we
can get support in the other major clients, such as Exodus, Tkabber, JAJC,
Pandion and probably a few others.
This simple change would make a new MSN convert's life much simpler, and
should then make it easier for people to adopt Jabber.
More information about the Standards