[Standards-JIG] Re: Summary of roster proposal points
richard at dobson-i.net
Tue Sep 7 12:34:01 UTC 2004
> Richard, I really wonder if _you're_ listening to anything I'm saying. I
> also appreciate you taking a less confrontational response to my posts, in
> return I will try to do the same.
I am listening to your replies, from my perspective it is you who have not
really been listening to mine, I would greatly prefer it for this to be less
confrontational but you were bringing this on yourself, because you were not
adequatly explaining your assumptions and then stating them as fact, as well
as continuting to argue points that had already been rebutted.
> I do read your replies, and I have stated my rebuttals to your points in
> case, or conceded in areas where I can see that you're correct. I have
> explained exactly why I don't think that waiting for a server-side
> is acceptable, however the solution may eventually function is irrelevant,
> because it's going to take a long while to get the protocol drafted, and
> get working implementations. I am however open to suggestions and to
> pointing out to me where I am wrong.
Yes and we have pointed out where you were wrong, it just seems that you
either ignored previous messages, which was evidenced by you continuing to
go on about how using a subscription to the transport is not enough of an
authorisation when a solution of using ACL's had already been presented, as
well as you continuing to state that client side modifications were required
for ACLs when this also was shown to be wrong.
> You acknowledged that there is a problem. I think it needs to be fixed
> quickly, and I believe that my proposal provides the best way to do that
> right now. You may disagree with me that it needs to be fixed quickly, I
> reply that users need this to work now. It is a huge impediment to the
> adoption of Jabber. I can't really say anything else on this point, apart
> from stress that it's important that this is fixed soon.
I didnt say it didnt need to be fixed quickly, what I stated was that we
shouldnt be quick fixing it with something new where something which already
exists will solve it and be a perfectly sufficent stop gap (JEP-0093).
> Now if you disagree with me on how to fix it quickly, that's fine, I am
> to suggestions, which is why I posted here in the first place. I will say
> right now I don't think that modifying the server is a good way to solve
> _quickly_, even though is the way to solve it properly, in the long run.
Ok good now you admit the server side solution is the best long term
solution, that is exactly what I have been arguing for which you were
arguing against and completely discounting the server side option from what
you were writing in your messages (at least how I read them).
> You suggested JEP0093 as a quick solution. I will explain again why I
> think that it is satisfactory.
Not just me, infact Matthias as well as others suggested JEP-0093 before
even I did.
> * Firstly, if a client does not support the protocol, it will not receive
> contact list at all. This is very bad for users.
Its not bad, its no different from your proposal, if clients dont support
your proposal they will just fall back to accepting all the presence
subscriptions, just as they would using JEP-0093.
> They won't be able to see
> their friends. There is no way to detect if a client supports this
Ok the fact you cant detect support for it might be a problem, but that
doesnt mean you need to invent a new spec because of it, all that needs to
be done is fix this deficency in JEP-0093 using disco. But even if you dont
know someone supports it you can just send them the list anyway, and if the
transport is coded correctly it will use presence subscribes anyway.
> which means that some other method of pushing the roster is needed anyway
> (namely sending <presence type="subscribe"/>, note that I have already
> explained why a server side solution is not valid, this is an attempt to
> the problem quickly)
You didnt explain that you were discounting the server side option because
you want to fix it quickly, from your messages you seemed to be discounting
it entirely, even tho I pointed out it was the best long term option several
times you still said it was rubbish and not the right way, without
attempting to adequatly explain why.
> * Secondly, if the client supports the protocol in it's current form, then
> still have the problem that the gateway may need to send updates to the
> roster occasionally. It means the user will receive these roster pushes as
> message packet whenever they change their contact list in another program
> (which for some people is often). I know this isn't a huge problem, it's
> not quite as clean and seamless for the user as simply seeing a
> request when somebody needs to be authorised, and seeing any already
> authorised contacts already on their list.
This is no real problem, it might not be perfectly clean but all this needs
to do is stop the flood of contacts you get when you register with a
transport (the real problem here), making it absolutely clean should be the
goal of the proper long term server side protocol, no need for it to be
solved immediately since its not much of a problem anyway.
> With regards to the first point above, if the client doesn't support
> roster-import, it will fall back to the situation now (which is bad), but
> least the user gets their contacts. It is up to the client developers as
> whether they want to fix this UI issue, they do not have to use my
> I just think it would be the easiest solution for now. The great thing is,
> they choose not to use my proposal, nothing bad happens.
Nothing bad happens if you use JEP-0093 either, that too will fall back to
standard presence subscriptions if done properly.
> For the second point, if the gateway needs to send updates, it can simply
> a roster import packet for each new contact that has been authorised since
> the last use of the transport. Depending on whether the client decides to
> remember if the user gave permission to that Jabber entity, the user may
> even be prompted again.
Remembering the entities it gave permission to and auto accepting presence's
is an entirely client side UI issue, this has nothing much to do with the
protocol, this can be done just as well with JEP-0093 as it can with your
proposal, strictly it doesnt even need either protocol if the client is
remembering what it has given permission to and then just auto accepting
presence subscriptions depending on this, this is all a UI issue, no new
protocol should be needed.
> Since the presence subscribe exchange (between client and gateway) needs
> take place anyway, I don't see the point in using and requiring support
> JEP0093 at all. All the client really needs to know is the JIDs in the
> contact list, and whether or not the user needs to be prompted to
Yes it does need to take place anyway, but if the contacts are already added
to the contact list using JEP-0093 there is no need to prompt the user at
all (that is the point of using JEP-0093, so you can get the full list of
contacts to add before the presence subscribes, so once they are added the
user no longer needs to be prompted when the subscriptions arrive).
> JEP0093 could be made to solve this, but that was not it's purpose, and it
> shows, it doesn't fit the problem well (as I have described above).
But as I show it does fit perfectly.
> If I have missed anything in my reading of JEP0093 that would help it to
> better for this situation then I'd be very interested to know.
There you go, if you still cannot see how it can work together then I
suggest you email me off list (as well as anyone else who would like more
> As you said in your post, this problem is indeed partially a UI issue in
> clients. I believe that my proposal provides the easiest way for clients
> fix their UI issue. Easier than JEP0093 because all clients already
> presence subscription (well they should anyway :), and it's not a very
> difficult modification to auto-authorise contacts with the import tag (of
> course with the security checks described in my proposal), plus you get
> huge advantage that clients that don't know about the extension will still
> function, albeit with a worse user experience, but still better than not
> receiving your contact list at all.
You stating that you will not receive the contact list at all if you dont
support JEP-0093 shows that you dont quite understand how it would work,
again I suggest you email me offlist (unless anyone else is interested).
> You are incorrect in saying that there are no protocol changes necessary
> fix the UI issue however.
Sorry but im not, as I have shown and as others have tried to explain to you
(which thus far you do not seem to understand) JEP-0093 can accomplish the
majority of what you are trying to do without inventing something new and
rushing it out as you suggest.
> The client somehow needs to be told which contacts
> are already authorised on the legacy service, and which aren't. Even if we
> simply send a JEP0093 packet at the beginning of each session with all the
> currently authorised users, and send presence subscriptions for everybody
> else, that still needs to be documented somewhere as a protocol (probably
> JEP0100), and it still does not fix all of the problems I described above,
> most notably that if a client does not support it, then the client
> no roster at all.
Yup usage of JEP-0093 in the fashion I describe would be best in JEP-0100,
remember JEP-0100 is not really describing a new protocol, it is just
telling a developer how other existing protocols fit together where you are
trying to work with rosters, its really a usage guide, not a protocol of its
> Now with regard to your suggestion of allowing gateways to send <iq
> type="set"/> packets to modify your roster. I understand your ideas as
> * User registers and subscribes to a Jabber entity.
> * User somehow authorises Jabber entity to have access to contact list,
> forms, chatbot, etc. Hopefully something not too complicated to support in
> the client. I don't think we have a coherent idea of what this step will
> actually involve yet (feel free to correct me here)
Thats correct so far, also please note this is not just my idea, this is an
idea that has been discussed multiple times in the past, and plently of
people have been thinking about.
> * Whenever the Jabber entity needs to update the users' roster it sends iq
> packets to the user's JID, which are intercepted by the user's server,
> interpreted to update the user's roster file (on mysql, xdb spool, etc),
> then pushed out the user's client using the normal means.
> Note that this has been modified from it's original form to fix my
> about security. As long as step two gets done with proper consultation
> the user
>, we can even drop the requirement that the Jabber entity can only
> modify roster entries within it's own domain.
Yes just as I suggested in one of my previous emails, using some kind of ACL
we can define more complex permission than just contacts in a certain domain
as I said, other ways might be only in a certain group etc etc.
> That actually makes this
> proposal useful for things other than gateways, as you can have arbitrary
> JIDs as part of the group.
Yep just as I have already said.
> You also may well be right that it's ok to have the shared groups stored
> multiple times, in each users' roster. Provided the shared group didn't
> updated too often it probably wouldn't put too much load on the server
Yup the only load it will add is at the time contacts are edited, and as I
showed storage space doesnt really matter these days, and there are ways to
reduce the requirements down even further than just adding more space.
> Although as a bug in my PyMSNt showed, sending a few roster sets for
> every user can quickly add up for big servers like jabber.org.
Yes it might, but thats a bug, and there are ways to protect against such
things, like simply blocking such buggy software.
> The killer for me is that step two will actually require quite a bit of
> thought and work to design and implement properly. It involves the user
> his/her Jabber server exchanging information about just how much access to
> the user's contact list the Jabber entity may have (only for the domain of
> the entity? for arbitrary JIDs? Will have permission to remove contacts?
> about rename?).
Yes but such an ACL system would be useful I would think with other
protocols, making the ACL more of a generic ACL system where roster editing
rights is just one of the many resources it could manage access to, IMO work
on such a system would be very benefical to jabber.
> This is why I thought it would be simpler to just have the user's main
> list separate from the shared ones. Although depending on how step two in
> your idea is implemented, that may or may not be necessary, and your ideas
> could work just as well with a clearer picture of how they work.
Your idea of separate lists in interesting but IMO is not really needed and
certainly as far as transports is concerned is not really the right way to
go about it. But yes the real issue is the ACL mechanism here, that we make
it as extensible as possible and try to solve all of our needs for remote
> My main point, which I hope you will agree with me on, is that there is no
> server side roster group system that will be ready in the near future. It
> needs to be discussed fully, and go through a proper process of testing.
Yes of course this is something I have said repeatedly.
> In the mean time there is a need to be fill the inadequacy in the Jabber
> protocol for handling transport user subscriptions. I have already stated
> above why I think that JEP0093 is inadequate for this. It could indeed be
>made to fit this purpose, I do not dispute that, but I think that my simple
> extension to the presence subscription system (which is what is failing to
> meet this need) fixes the problem in a cleaner fashion, with no real
> apart from a lack of extensibility.
And I have shown that you dont seem to quite understand how JEP-0093 can be
perfectly fine to solve this immediate problem without going and inventing
some new protocol in a rushed way, IMO in protocol design if something that
already exists can fit the purpose it must be used, rushing through
something new is almost always a bad decision.
More information about the Standards