[Standards-JIG] Re: Proposal for a solution to transport
james at delx.cjb.net
Mon Sep 6 12:32:55 UTC 2004
I hope you don't mind me posting this to Standards-JIG, I think it's relevant
to the discussion.
On Mon, 6 Sep 2004 09:42 pm, you wrote:
> > > 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.
> Of course you would only let it alter or even see the contacts from its own
> domain this is simple common sence. In what cases would to really see that
> a user would subscribe to a transport and not want it to automatically keep
> the roster in sync? In real world usage I dont see many cases where this
> would be a problem, even if it is IMO its more of a client user interface
> issue that a real problem with having this stuff server side, e.g. when you
> subscribe/accept the presence of the transport then the client using disco
> beforehand can easily determine that that JID is a transport and even that
> it supported server side roster sync and could give a warning explaing what
> you are allowing the transport to do.
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.
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.
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.
> > 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
> > users.
> 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.
> > Exactly right. The proposal for a server-side shared list before I
> > didn't like.
> > 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.
> Personally I dont see the actual value in this level of complexity, its far
> better if those sources that you are registering with are simply allowed to
> alter your proper roster, wether its by simply subscribing to a domains
> presence in the case of transports or a slightly more involved control
> protocol allowing a particular JID to alter items in a particular roster
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.
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)
> > 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.
> Doing it this way means that a client has to have support for it for it to
> even see those roster items, its far better to only have one roster and
> allow those remote entities to alter that, having rosters in the way you
> suggest here presents all sorts of problems, and introduces far too much
> unnecessary complexity on the client side, for little real value over just
> allowing remote entities to alter your proper roster.
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
So it's really not that much complexity.
> > 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).
> 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.
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.
> > That's my vision of a *real* shared roster groups protocol. It would be
> > useful
> > for transports, as well as workgroup environments.
> Thats where we differ, my vision of a *real* shared roster groups protocol
> would be to keep client complexity to a minimum and put all the complexity
> we can into the server were it belongs. Also since a client will not
> display its roster any different whether it uses your method from multiple
> sources or the standard single roster I fail to see the actual value it
> brings, since this is the case simply having remote sources manipulate the
> roster is far simpler, more inline with jabber philosophy/standard practice
> and is far better for the end user in the long run, especially in things
> such as mobile clients where complexity needs to be kept to a minimum.
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.
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
> > 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.
> The whole problem with this is is that it is a quick fix solution, which
> before it has even been implemented has been admitted that it will just be
> superceeded anyway, we have done this kind of quick fixing and not properly
> analysing the problem before and been burned, the most notable case is the
> jabber:iq:agents/jabber:iq:browse/disco fiasco where we didnt properly
> consider all the cases and think things through, disco also may have too a
> while to be developed and finalised but we now have a protocol that should
> last the test of time, taking time to develop something (rather than
> rushing something through) as shown with disco gives you a much better
> result in the end, being impatient and just rushing ahead is not the
> solution. Also introducing something as you suggest that is only going to
> be replaced soon just so you can sort your problem now is rather short
> sighted and puts and burden on client developers in the future as they will
> need to support your non-optimal solution for sometime until people stop
> using it.
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).
As for the gateway, when the hypothetical "real" shared roster groups protocol
comes out, it can disco the client and server to see whether it supports it.
Then provide appropriate options in a data forms registration.
> > 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.
> Sorry but personally I hope not as things stand, IMO it is simply not the
> right way, and it is far better to give it some time rather than forcing
> and rushing things through no matter how good intentioned it is.
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.
When a real shared groups protocol comes out the gateways will be the first to
use it. The subscription code is messy.
> > This simple change would make a new MSN convert's life much simpler, and
> > should then make it easier for people to adopt Jabber.
> IMO it could just make things harder due to all sorts of incompatibilities
> this will cause later down the line.
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
More information about the Standards