[Standards-JIG] Re: proto-JEP: Roster Item Exchange
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
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