[Standards-JIG] Roster Subscription Synchronisation
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
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
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
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
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
More information about the Standards