[Standards-JIG] Roster Subscription Synchronisation

Richard Dobson richard at dobson-i.net
Wed Sep 15 00:09:42 UTC 2004


> Erm, I don't think it's a wise idea to just delete something when you're 
> not sure what it is!

In what cases wouldnt a "none" mean the legacy contact has been removed from 
the legacy roster?

>> This is exactly the problem it can end up creating a "both" subscription
>
> OK, I'm gonna cut you off right here. I addressed this. Clients supporting 
> our protocol will NEVER make this a "both" when it should be "to". With 
> our proposal subscriptions will be exactly in sync! Without it, it's 
> problematic. THAT is why we need the protocol. STILL, I have suggested a 
> simple way to get around this. Again, you just ignore what I already 
> wrote.

I did not ignore what you wrote, infact I pointed out why what you are 
trying to do doesnt really make sence and can cause problems if the client 
does not support your spec. IMO making a false subscription to try and 
communicate a subscription meaning the reverse doesnt make sence and thus is 
wrong and some other method should be found to transmit the "to" 
subscriptions, such as using JEP-0093.

> In fact I find this rather frustrating. Why are you saying it's a "serious 
> issue" that clients *NOT* supporting our protocol can end up with "both" 
> instead of "to" when I:

Because if a client does not support the spec when it received this false 
subscription it would likely do the following:

1) Prompt the user saying the legacy contact wants to subscribe to the users 
presence, the dialog will also likely have a check box asking if the user 
would also like to subscribe to that users presence.
2) The user clicks accept with the check box checked, this sends a 
"subscribed" and a "subscribe".
3) The transport receives these subscriptions and as a result alters the 
legacy roster as instructed to be a "both" subscription and accepts the 
users "subscribe".
4) A "both" subscription has been setup on both sides.

Now as you say at stage 3 the transport could reply with an unsubscribe and 
it would return the subscription to "to", but all this interaction is hardly 
intuitive and has a big potensial of seriously confusing the end user, IMO 
the transport should only ever be sending a "subscribe" to the jabber user 
if the legacy user is actually subscribing to the users presence, sending 
this falsified subscription IMO is a hack and is unclean (a clean solution 
would be one that transmitted the "to" info without needing to make any 
falsified subscriptions as you seem to want to) as it is not really 
intending to subscribe to the users presence and so is the wrong way to do 
it.

In a client there is also the possibility that the user does not opt to 
subscribe to the legacy contacts presence but just accepts the presence 
subscription, this is all confusing for the end user and once they have 
accepted the subscription the transport will just unsubscribe from it again, 
very confusing, isnt the goal of this spec to make things less confusing for 
the end user, not create possibilities of extra confusion.

> - this has nothing to do with the protocol itself.
> - I showed you how you CAN make it a "to", on all clients, all servers, 
> and very simple.

Yes but again just because it works according to a set of business rules 
doesnt make it the right way, certainly since it is falsifying subscriptions 
to get around the problem of getting "to" subscriptions to the jabber user.

> Like I said we copy from jabber:iq:roster. So does JEP-0093 by the way. 
> And that's where it puts the the subscription, this *IS* a re-use issue. 
> Meta data is the data *inside* the <item/>. If you don't like that go 
> argue against iq:roster or something.

I never said anything about jabber:iq:roster, I was talking about JEP-0093, 
the subscription attribute in this spec appears to me to be intrinsically 
related to the top level subsync namespace, and the meta data appears to be 
an add on, thus the separation.

> It seems you've been calling things "not working" and "a hack" cause you 
> misread one of my emails or cause it wasn't so clear. Let's call that the 
> "unclean" concern, that's solved now.

The unclean and hack stuff is detailed above.

> The "backwards compatible" part? Well, I've shown you how to do that. If 
> you see any way that wouldn't work, share them. Specifics please this 
> time!!

I have above, it does not work in a fully backwards compatible way as it 
requires users to know to perform a specific series of evens when they 
receive a subscription from the legacy user, if they slightly deviate from 
that it doesnt work correctly, also the fact that it is making a false 
subscription that is immediately retracted is confusing in and of itself, 
this is hardly clean and user friendly behaviour, not to mention the fact it 
shouldnt be making false subscriptions anyway just to communicate a bit of 
information, certainly in this use case anyway using JEP-0093 is a far more 
clean and user friendly solution to the problem, why not follow what I 
suggested to James and am yet to recieve a reply on and use each method 
where it best fits, i.e. a hybrid of your method and using JEP-0093, using 
both covers all user cases in a far cleaner and more user friendly way, read 
the email I sent in response to James.

> Then you suggest using jabber:x:roster in the presence packet, that's an 
> issue for the author of that spec not me for now.

Why, the way JEPs work is that newer JEPs can add business 
logic/functionality to existing specs, so thus nothing should need to be 
changed in JEP-0093, all you need to do is specify your usage of JEP-0093 
which will superceed things in JEP-0093 that restrict it to only message 
stanzas, this is entirely in your court not the court of the author of 
JEP-0093.

Richard





More information about the Standards mailing list