[Standards-JIG] Re: proto-JEP: Roster Item Exchange

James Bunton james at delx.cjb.net
Fri Sep 17 08:37:09 UTC 2004

This JEP seems to be pretty much what I thought JEP0093 adapted for this 
purpose would be.

The differences that I can make out between this and roster-subsync are

* There is no way (that I could see) to communicate a subscription of from/to. 
This seems to be inherent in the design of the JEP (see the last paragraph on 
the requirements)

This means that if this protocol is used to import your contact list from a 
gateway's server, it could end up actually changing the contact list while 
importing it (as the client will send presence subscribe & subscribed)

* Rather than specifying the subscription state the client should try to put 
the contact in (as roster-subsync does), this JEP tells the client what 
action they should take.

No real difference here, except that roster-subsync allows more flexibility 
with synchronising roster states (as above)

* This JEP uses a message packet rather than presence.

This means a few things.
All the data gets sent in one stanza (probably not much difference, maybe a 
little cleaner for the importing case)
It won't work with current clients _at all_. This could be remedied by saying 
that clients should advertise their support in disco. That way gateways can 
query for support when synchronising lists, if it's not available, they can 
do it with presence packets. That way you have the same failure case as 
roster-subsync, namely the user has to authorise the contacts manually.

The biggest thing with having everything in a single message packet is that 
when the client requests subscription to all of these contacts, it must 
remember not to display notifications to the user that he/she has been 
granted the authorisation. It will also need to remember to automatically 
grant authorisation to all of those contacts (for when the transport requests 
If clients don't do this then we haven't solved the problem with gateways at 
all, just shuffled it around a little.

I still think all of this would be easier to do with roster-subsync, in 
presence packets. You still need to request authorisation from the user to do 
the auto-synchronising, however the client can remember that on a per-domain 
basis, and that's all it has to remember.
This JEP requires a much more complex state system to be kept, for little 
benefit that I can see. The user interaction will still be the same.

I can however see that this JEP would be beneficial for use in a shared roster 

* The JEP will allow modification of contacts in the roster, eg name, groups 
This is definitely a benefit over roster-subsync, especially since I'm sure 
that clients will allow you to turn off the name changing part =P (that's a 
pet peeve of the MSN client of mine)

With regards to the comment somebody made that only agile clients would use 
roster-subsync, and the slower ones will wait for a more general shared 
contact list solution. Well, I don't think that's a reason to deny the users 
of fast clients a better user experience right now. =)

What I'll end up doing with PyMSNt is implementing roster-subsync for those 
clients that want the problem fixed right now. The implementation is pretty 
much done. All I have to add is the <x/> tag in a few places.
Later when whatever protocol comes out to supersede it as an official JEP, 
I'll implement support for that, and switch between them using disco.

To the writers of such a future protocol, please tell client developers to 
advertise their support for it in disco =)



More information about the Standards mailing list