[Standards-JIG] Re: Summary of roster proposal points
james at delx.cjb.net
Tue Sep 7 11:24:38 UTC 2004
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 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.
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.
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.
You suggested JEP0093 as a quick solution. I will explain again why I don't
think that it is satisfactory.
* Firstly, if a client does not support the protocol, it will not receive the
contact list at all. This is very bad for users. They won't be able to see
their friends. There is no way to detect if a client supports this protocol,
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)
* 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.
Now for why I think my protocol is better as an interim solution.
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 at
least the user gets their contacts. It is up to the client developers as to
whether they want to fix this UI issue, they do not have to use my proposal,
I just think it would be the easiest solution for now. The great thing is, if
they choose not to use my proposal, nothing bad happens.
For the second point, if the gateway needs to send updates, it can simply send
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 not
even be prompted again.
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
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).
If I have missed anything in my reading of JEP0093 that would help it to work
better for this situation then I'd be very interested to know.
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 are incorrect in saying that there are no protocol changes necessary to
fix the UI issue however. 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.
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, 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)
* 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.
I hope I didn't miss anything here.
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, we can even drop the requirement that the Jabber entity can only
modify roster entries within it's own domain. That actually makes this
proposal useful for things other than gateways, as you can have arbitrary
JIDs as part of the group.
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. 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.
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
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.
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.
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.
More information about the Standards