[Standards-JIG] Re: Summary of roster proposal points
james at delx.cjb.net
Wed Sep 8 06:45:52 UTC 2004
On Wed, 8 Sep 2004 02:32 am, "Richard Dobson" <richard at dobson-i.net> wrote:
> > Richard, I really wonder if _you're_ listening to anything I'm saying. I
> > would
> > 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
Well, I think that you were just as guilty of the above as I, so I guess we've
both been unclear then. Lets agree to just ask each other to clarify things
nicely from now on.
> > I do read your replies, and I have stated my rebuttals to your points in
> > each
> > case, or conceded in areas where I can see that you're correct. I have
> > also
> > explained exactly why I don't think that waiting for a server-side
> > solution
> > 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 to
> > get working implementations. I am however open to suggestions and to
> > people
> > 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.
After you mentioned that the ACL could be implemented with data forms I
understood what you meant about how the clients would not need modification.
Before then I didn't really see what you meant.
Like I said, perhaps we've both been unclear.
> > 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
> > will
> > 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
> > Now if you disagree with me on how to fix it quickly, that's fine, I am
> > open
> > 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
> > this
> > _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).
> > 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
> > fix
> > 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.
Well I'm sorry for that misunderstanding. I was merely trying to point out
that the server-side solution you were proposing was not ready to be deployed
immediately (I think that somebody was suggesting it be used to solve the
I certainly didn't mean to say that it would never be useful, or worth
implementing. Just that it needed more work.
> > * Secondly, if the client supports the protocol in it's current form,
> > then you
> > 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 a
> > 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
> > just
> > not quite as clean and seamless for the user as simply seeing a
> > subscription
> > 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.
I disagree here. If you use MSN Messenger you have a remarkably clean and
polished experience. I personally dislike many aspects of MSN Messenger
(which I won't get into here), but it's not difficult for users to
understand. I think it should be a priority to make this nice for users, not
just to stop the flood of subscriptions. I would like for the gateways to
work as seamlessly as possible. This is possible with JEP0093 I'm sure, but I
think it's easier with my idea (more about this below).
> Nothing bad happens if you use JEP-0093 either, that too will fall back to
> standard presence subscriptions if done properly.
> 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.
No, I think you're me on misunderstanding this point. There's no way for the
client to know what entities the user has granted permission to on the legacy
service. That's what my proposal was meant to address. Any subscription
requests that are redundant (that is, the user has previously authorised the
contact with the legacy service), are marked by the import tag to alert the
client of this.
By doing this, the client can provide a much better experience for the user.
We could certainly put this tag into JEP0093, but I don't see what benefits
that would have over putting them into the <presence type="subscribe"/>
packet that is already sent anyway.
> > Since the presence subscribe exchange (between client and gateway) needs
> > to
> > take place anyway, I don't see the point in using and requiring support
> > for
> > JEP0093 at all. All the client really needs to know is the JIDs in the
> > legacy
> > contact list, and whether or not the user needs to be prompted to
> > authorise
> > them.
> 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
Ahh, this is what I'm confused about. How would this be implemented? I assume
it starts with the transport sending a JEP0093 packet. How does the transport
know whether or when to follow up with the presence subscribes?
> > 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.
I'm sorry, but I don't understand how it fits perfectly. It does work
perfectly for it's intended purpose (transferring JIDs between users), but I
don't think that it it's current state it can work as seamlessly as my idea.
> 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
I would definitely appreciate you explaining in detail exactly how this would
work. If it indeed can work, I'll implement it in PyMSNt, but how to do it
needs to be documented somewhere, right now it's unclear how JEP0093 can be
made to fit this problem.
That is, it has to work with all clients (even if they don't support JEP0093,
so presence subscribe must be used as a backup), and the client needs to know
which contacts have already been authorised.
I guess you could just specify that the transport MUST NOT send the any
unauthorised contact in a JEP0093 packet, that way the client would be able
to assume that any contacts sent can be added automatically.
> > As you said in your post, this problem is indeed partially a UI issue in
> > the
> > clients. I believe that my proposal provides the easiest way for clients
> > to
> > fix their UI issue. Easier than JEP0093 because all clients already
> > support
> > 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
> > the
> > 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).
See above =P
> > You are incorrect in saying that there are no protocol changes necessary
> > to
> > 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.
I would disagree that I'm really inventing something new. My proposal is
really just a simple extension to the existing Jabber presence system to
provide a little more information to the clients.
> > 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 receives
> > 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 own.
True. Right now that documentation is lacking, JEP0100 simply says use JEP0093
to send the contact list.
> > Now with regard to your suggestion of allowing gateways to send <iq
> > type="set"/> packets to modify your roster. I understand your ideas as
> > follows.
> > * User registers and subscribes to a Jabber entity.
> > * User somehow authorises Jabber entity to have access to contact list,
> > data
> > 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 set
> > 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),
> > and
> > 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
> > concerns
> > about security. As long as step two gets done with proper consultation
> > with
> > the user
> Of course
> >, 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
> > get
> > updated too often it probably wouldn't put too much load on the server
> > either.
> 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.
To be fair, PyMSNt does display a warning that it's experimental every time
somebody uses it. It's not supposed to be in production use yet, although I
don't mind people testing it. =)
> > 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
> > and
> > 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? What
> > 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.
Just curious, what other things could it be used for?
> > This is why I thought it would be simpler to just have the user's main
> > contact
> > 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
> roster manipulation.
Yes. It definitely needs to be flexible as you say. Hopefully we can do that
without providing the user with an overly complicated data form that they
must submit =P
That's always the tricky bit, mixing power & flexibility with ease of use.
> > 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 issues
> > 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.
Once again, I disagree that this is actually a whole new protocol, and the
reason I posted here was to check that their weren't any glaring flaws in it.
If you can see any, other than the fact that we're not using the existing
JEP0093 as part of the solution, please do tell me.
Once again, please do explain exactly how I can use the existing JEP0093
support in clients to make the gateways work as seamlessly as they would with
my proposal. The part I'm most unclear on is what happens when a client
ignores the JEP0093 packet (because it doesn't understand it), and how the
gateway can know to send presence subscribes. If it sends the presence
subscribes and the JEP0093 push at the same time, then there's no point in
sending the JEP0093 at all.
More information about the Standards