[Standards-JIG] Roster Subscription Synchronisation JEP revision 0.3
richard at dobson-i.net
Tue Sep 14 11:22:01 UTC 2004
All of this shows you do not understand how subscriptions should really be
being handled by the transport and the client, the transport should be
maintaining the current status of things the jabber user is currently
subscribed to and be comparing this to what the status of the MSN contact
lists when the user logs into MSN then sending the apropriate
subscribe/unsub/JEP-0093 etc stanza's.
Also with regards to your spec, as I noted your spec cannot handle "to"
subscription statuses without a big hack and your description in 4.3 is
completely wrong and would never work, because a "to" status on the legacy
roster means you are subscribed to it, but you show in example 1 the legacy
contact subscribing to the users presence which would make it a "from" and
once the user subscribed into a "both", which is completely wrong as it
should only be a "to". The way you describe it will not work at all if the
client doesnt support your spec and will completely break it, and is overall
the completely wrong way to do this, its an even worse hack than Tiji
In section 4.5 specifying your namespace on that unsubscribe is completely
pointless as unsubscribing msn contact will automatically result in a "to"
subscription status, ditto in section 4.6, 4.8, 4.9.
4.7 yet again there is no need to express the subscription state in the
remote roster as sending "unsubscribe" and "unsubscribed" will automatically
result in an effective "none" and the contact being removed.
Overall I think you are completely confused as to how you should really be
implementing all of the subscription syncronisation as you do it completely
wrongly in places, and lots of it is pointless effort, subscription states
should only ever be expressed by what subscriptions are currently in place.
Most of what you try to do can be handled perfectly fine just using normal
presence subscription/unsub etc requests without your namespace even being
there, so in those cases that namespace is simply a waste of bandwidth as it
does nothing, these cases are, 4.5, 4.6, 4.7, 4.8, 4.9.
The following cases can all be handled better and more compatibly just using
a JEP-0093 stanza, 4.1, 4.2 (to express what you are subscribed to, once the
user is subscribed to the contact beforehand using a JEP-0093 stanza the
reverse subscription from the msn contact to complete the "both" can be
accepted automatically), 4.3.
In case 4.4 the user should be being prompted that the user wishes to
subscribe, this can be accomplished using standard presence subscription
symantics and does not need to be automatically syncronised as this case of
going from "none" to "from" is only likely to happen when a user requests a
subscription during the session at which time the user must be prompted in
any case so there is no need to send your namespace as standard presence
handling symantics apply.
Cases 4.10 and 4.11 are very unlikely status change scenarios and are more
logically catered for by moving in 4.10 from "from" to "none" then to "to",
i.e. 4.8 then 4.3, and in the case of 4.11 using 4.9 then 4.4.
So as I show we dont need to use your spec to cover the use cases, infact a
lot of the use cases you cover are handled by the standard presence
symantics anyway in which case your additional element serves no purpose on
those and thus shouldnt be there.
----- Original Message -----
From: "James Bunton" <james at delx.cjb.net>
To: <standards-jig at jabber.org>
Sent: Tuesday, September 14, 2004 11:23 AM
Subject: [Standards-JIG] Roster Subscription Synchronisation JEP revision
> Ok. I've put up a new version that will hopefully make it clear to
> why JEP0093 will not solve the problem I'm trying to solve.
> Get it at http://msn-transport.jabberstudio.org (scroll down to the
> There are a whole lot of use cases documented there, I think JEP0093 can
> a couple of them, but not all of them. Basically what's documented is any
> change in subscription that may happen when a user uses another client to
> manage their contact list. (none->to, none->from, none->to, none->both,
> so on).
> It is impossible for JEP0093 to handle all this in it's current state, and
> my opinion it shouldn't even try! It was designed to send contacts between
> Jabber entities, not to handle subscriptions at all.
> This JEP provides a complete solution for gateways to synchronise legacy
> There's a client cheat sheet in the JEP, but it doesn't show up properly
> browsers, so I've put it in a separate HTML file to view. It shows how
> this is for clients to implement. Really it's what I do whenever I use MSN
> Messenger and change my contact list, and then come back to Jabber. It's
> documented formally.
> For non-compliant clients, things will still work just as they do now,
> the user will have to manually reauthorise contacts.
> Btw, there were a lot of use cases there, so I probably made some mistakes
> with some of the technicalities. I'd appreciate it if anybody could read
> through and make sure they all work.
> Standards-JIG mailing list
> Standards-JIG at jabber.org
More information about the Standards