[Standards-JIG] Re: Summary of roster proposal points

James Bunton 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 
about rename?).
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 mailing list