[Standards-JIG] Roster Subscription Synchronisation JEP revision 0.3

Richard Dobson 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 
suggestion.

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.

Richard

 ----- 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 
0.3


> Ok. I've put up a new version that will hopefully make it clear to 
> everybody
> why JEP0093 will not solve the problem I'm trying to solve.
> Get it at http://msn-transport.jabberstudio.org (scroll down to the 
> bottom).
>
> There are a whole lot of use cases documented there, I think JEP0093 can 
> meet
> 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, 
> and
> so on).
>
> It is impossible for JEP0093 to handle all this in it's current state, and 
> in
> 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
> rosters.
>
> There's a client cheat sheet in the JEP, but it doesn't show up properly 
> in
> browsers, so I've put it in a separate HTML file to view. It shows how 
> simple
> 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 
> just
> documented formally.
>
> For non-compliant clients, things will still work just as they do now, 
> except
> 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.
>
> ---
>
> James
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> https://jabberstudio.org/mailman/listinfo/standards-jig
> 





More information about the Standards mailing list