[Standards-JIG] Roster Subscription Synchronisation

Richard Dobson richard at dobson-i.net
Mon Sep 13 18:07:53 UTC 2004


> If that's all we're trying to do it could work. However, we are not. We 
> are synchronizing subscriptions. Not just sending contacts.

Yes I can see what you are trying to do, I have shown in a previous email 
that JEP-0093 can be made to sync contacts fine, just as this proposal can 
do, so I wont repeat myself yet again on this.

>> There is nothing stopping us using JEP-0093 "jabber:x:roster" tags 
>> wherever we might want to transmit a contact or list of contacts,
>
> Except from JEP-0093 in our case making requirments that go explicitly 
> against what we intend, and us needing additional things not included in 
> that namespace.

Still not convinced anything extra is needed, and as shown by the fact that 
PSA added JEP-0093 (its author) to JEP-0100 (its author) stating that it 
should be used shows it is not against the intended spirit of the spec, so 
you dont need to keep saying its against it because it obviously isnt.

>> You still fail to explain why you actually need a subscription attribute,
>
> Because we are synschronzing the subscription state between the legacy 
> network and jabber (in other words, what you see on your contactlist when 
> you're using jabber). This includes adding, removing of contacts but also 
> one way subscriptions. Tell me how to do that without sending the 
> subscription attribute!!
>
> For example if the subscription state on the legacy network is what in 
> Jabber we call "both" but on your Jabber roster it doesn't exist yet 
> ("none") or is in a different state ("to" or "from") and we want to 
> synschronize this requires that a subscription request is send from 
> transport (using the translated name from the legacy user as the node 
> part) to the user, and then an approval of the user must be send. Also the 
> user should send a subscribtion request to the the transport (same node), 
> and the transport should approve that.
>
> You can imagine the use case for "to", "from" and "none" I hope.

Yes but if you think into how it would work more carefully you should be 
able to see that it simply will not work properly unless the contact in 
question has the equivalent of a "both" subscription on the legacy network, 
ill explain each subscription status in turn below:

"none"
There is no point in communicating contacts with a none status because those 
contacts, as far as MSN in concerned anyway are not in your roster.

"to"
Using your method of syncronising contacts by waiting for that contact on 
the legacy network to subscribe to the jabber users presence means that the 
equivalent of "to" subscriptions on the legacy network will never reach the 
jabber roster as they shouldnt be subscribing to it, so using your method 
all "to" subscriptions will be lost. This is more of a general problem with 
transport contacts but shows were your requirement for a subscription 
attribute falls over.

"from"
There is not all that much point communicating from subscriptions in the 
legacy roster as on MSN anyway these are unlikely to exist anyway, as when 
you delete someone from your contact list it will automatically add them to 
the block list which means they become a "none" subscription equivalent. And 
anyway since from subscriptions will not want to be displayed in the client 
anyway most likely its yet another reason to not bother communicating them 
over.

"both"
This is the only case where it will work correctly.

So as you can see your method of syncronising will not work properly and 
since only both subscriptions will be communicated properly anyway there is 
no point in even having a subscription attribute, not to mention the fact 
that contacts will get lost with this method of syncronisation.

> What exactly is it that you dislike about that approach? Or is is just the 
> meta-data that's added that bothers you?

At the moment its the fact that you are creating a new namespace to 
communicate this meta data when a perfectly usable one exists.

>> the fact that the legacy user is subscribing to your presence along with 
>> this extra info shows it is in the legacy roster, so if you know from 
>> this the contact is already in the legacy roster what is the point in 
>> having a subscription attribute? Again am I missing something here?
>
> Hopefully you see now.

Nope, as I have shown having a subscription is useless, and this method of 
synchronisation will not work correctly anyway.

>> "link it to the presence packet with some kind of unique ID"???? Why 
>> exactly, what do you mean by this? Peter Millard has explained a 
>> perfectly feasible way you can do it,
>
> Which, as shown, does not meet our requirments since it doesn't solve our 
> problems.

No you have not shown that, I can see a JEP-0093 implementation solving 
exactly the same problem you are trying to just in a better way, that will 
actually work and communicate "to" subscriptions which yours as it stands 
will not as far as I can see.

> Clients also support already support subscription requests. In fact I 
> think more clients do than jabber:x:roster ;) It will still work for them, 
> except they won't have the meta-data. This however, would be very trivial 
> to add. Perhaps JEP-0093 can be changed (perhaps in combiniation with a 
> seperate proposal) so that it does work properly.

The fact that all clients support subscriptions is not in disbute, when was 
it? What is in disbute is that for this to help users and stop all the 
hundreds of initial subscription requests James spec requires extra client 
modifications, clients that already support JEP-0093 do not necessarily.

> It's advantage would probably be that you *would* have the meta-data in 
> current clients (but it'll still be a manual affair), but not the proper 
> subscriptions. and JEP-0093 lacks any buisness rules on, for example, what 
> to do when you receive contacts that are already in your roster (which 
> will be the case if you're gonna update JEP-0093 for the purpose of 
> continued synchronization) which could lead to some weird effects on 
> current clients.

Why would it lead to some weird side effects? But yes all that is needed for 
this are the rules for use of JEP-0093 with transports.

> Well, the goal of jabber:x:roster seems to have been the use case of "I 
> have a contact on my roster and want to send it to someone". You could 
> always broaden the scope a bit afterwards, and likely it was done already 
> when the spec was thought up. However, the current state of JEP-0093 
> simply disallows things needed for our proposal, and lacks some of the 
> things we need. Furthermore the wording of the JEP isn't quite in the 
> "spirit" of our proposal; Automated synching of subscription states and 
> exchanging roster items between entities. Don't get me wrong, those topics 
> aren't that far apart, I agree it's somewhat alike. But nothing else in 
> the JEP-0093 convinces I should use it in a case like that. In fact quite 
> the opposite, it only seems to steer away from it.

The fact that PSA the author of both JEP-0093 and JEP-0100 sees nothing 
wrong with using JEP-0093 with transports by incorporating it into JEP-0100 
shows that your concerns over JEP-0093 are entirely unfounded whether you 
choose you believe it or not.

Richard





More information about the Standards mailing list