[Standards-JIG] Roster Subscription Synchronisation

Tijl Houtbeckers thoutbeckers at splendo.com
Mon Sep 13 21:16:29 UTC 2004

On Mon, 13 Sep 2004 19:07:53 +0100, Richard Dobson <richard at dobson-i.net>  

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

Well I haven't seen this. Adding new contacts, yes. Nothing about removal  
or any of the other subscription states.

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

See above..
Just the fact that PSA mentions it in an expirimental JEP doesn't mean it  
solves any problems either, nor is it a reason for me to kill of  
(potentially better) solutions.

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

That's exactly what it means When a "none" contact is communicated, that  
it's removed. Since it's in an unsubscribe packets (as required by the  
proposal). When you remove a contact from your roster the server does this  
for you.

> "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.

Transport send a <presence/> subscribe request with the <item/> info  
telling the state on the network is "to". Client sends back a <presence/>  
stanza with type="unsubscribed", the normal way of denying a presence  
subscription request as defined in XMPP. Client then follows up with it's  
own subscription request. Result: "to"

> "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,

Fortunalty the world goes beyond just Microsoft.

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

As far as I know a from description is always in your roster in Jabber, so  
why shouldn't it when we're dealing with another network? This way you  
know when someone is subscribed to you, and you can remove that when you  
want. (It would be a security hole not to have this)

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

Sorry, all other cases work too.

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

Well as you see it will work just fine (I almost feel like I have to  
apologize for that!), what do you mean with "contact will get lost"?

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

Not for what we do. Even if you fix that, the logical place to me still is  
the presence packet, since that's where you deal with subscriptions.

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

Well it will work (sheesh), and I've shown why it's not useless. In fact,  
I wish I had it right now as a *user* of Jabber, so that means it's  
usefull to at least one person okay? And then I'm not even telling you how  
many times I've been in need for this as a developer. Part of the need so  
far has also been surpressed by the "hack" available and in use now, but  
even that hack only fills part of what we're doing here.

>>> "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.

Then write up your own proposal, so we can discuss that.

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

They do for synchronizing. Not all clients support JEP-0093 and when they  
do if you use it for synchronzing (eg by putting the subscription tag in  
the item) it can lead to weird results for clients that aren't updated for  
that. For example, user deletes a contact. So I assume you plan sending  
some sort of JEP-0093 packet, with a tag or the subscription property  
indicating it should be deleted. In a "plain" JEP-0093 implementation that  
could appear to the user like the transport wants you to add a contact!

Also I don't see how you're going to cover "from" here (it'd help if  
you're gonna make a proposal), unless you plan on sending a JEP-0093  
packet first, and then the JID or something, to auto approve it later. Or  
maybe I'm the one missing something here.

As for the whole backwards compatibility issue in general, it reminds me  
of the IBB streams discussion. There at first it was me argueing that  
backwards compatibility should be taken into account (it requires servers  
to support AMP to work properly). But I had to agree eventually that a  
good standard is more important than that. What one of the unacceptable  
issues was? Well <iq/> didn't seem like the right place for raw data,  
that's why it was put into <message/>. Guess which place I think is best  
for things related to presence subscriptions?

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

For what I mean see my reply to PGM.
Avoiding those side-effect could require a new namespace.
I said, and say, could, cause I still haven't seen your counter-proposal.

>> 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, as you can see you've been rather quick to write of how this  
works. I'm afraid one little line in JEP-100 doesn't makes it a matter of  
faith (even if it is Saint Peter we are talking about here).

More information about the Standards mailing list