[Standards-JIG] Roster Subscription Synchronisation

Richard Dobson richard at dobson-i.net
Tue Sep 14 16:22:15 UTC 2004

> Turns out this not true. It makes sense when you think about. In Jabber, 
> when someone else deletes you from there roster, they shouldn't 
> automatically dissappear from yours. This is the difference between 
> "remove" and "none". You can't send <presence type="remove"/>, but it *is* 
> used in <item susbscription="remove">. In short, item is the place for 
> removal, not presence.

Ah yes you are right on this one, but I still dont see any need for remove, 
if the contact is on the transport and its subscription status changes to 
"none" due to a "unsubscribe" and "unsubscribed" being sent it makes sence 
for the client to intelligently just remove the item from its roster 
automatically without needing to be told to do so with the "remove".

>> Using a <presence/> packet seems just a big hack to me,
> It's not a hack. It's a mechanism that ensures the client will always end 
> up with type="to". If the clients supports roster-subsync right away, if 
> it doesn't the transport can just send <presence type="unsubribe"/>

Its a mechanism that is a complete hack as you want subscription related 
information to be carried within a presence related stanza, thats why it is 
indeed a hack.

>> as the whole premise of this spec is that it is overloading the 
>> mechanisms to do with subscription, sending out a presence stanza 
>> without a type attribute
> ???

Well the whole goal of this proposal seems to be to extend the subscription 
functions of the presence stanza, since sending a presence stanza without a 
type attribute means it is presence related and not subscription related, 
subscription related stuff (i.e. your roster subsync stuff) has no business 
being inside a presence related stanza since it is presence related and not 
subscription related.

>> is just specifying the presence and has nothing to do with the 
>> subscription itself, doing it as you describe is not shown in the 
>> document previously linked to in this thread, and also seems completely 
>> against the spirit of what it is trying to accomplish.
> You'll have to come up with some argumentation here of what you're trying 
> to say.

See above, it seems plain enough to me.

> James started this because he is the (Py)MSN transport maintainer. I got 
> involved with this cause I think roster subscription synchronizing is a 
> good concept.

I didnt say it wasnt, as you should be able to tell I think its a good 
concept too, I just think that you guys are going about it all the wrong 
way, I do not seem to be the only one who feels this way either, quite a few 
of us have shown that a JEP-0093 based solution fits what the real goals 
should be just fine, you just dont want to believe it.

> If you don't agree with the concept than tell us why that is wrong. Don't 
> call every thing "not working" when it does work and don't call it a 
> "hack" when it does work.

Just because something works doesnt mean its not a "hack", being a hack 
means something is somewhere it shouldnt really be in order to solve a 
problem, your solution to 4.3 seems to fit this description to a tee.

> Also don't come up with ghost stories about  "primary motivations" cause 
> you disagree with the concept yet seem unable  to come up with a proposal 
> yourself.

Myself and others have already come up with proposals, and I will have time 
to document this in a more formal manor around november time unless someone 
else wants to take the reigns on the JEP-0093 solution before then.

> "Cleanly" is entirely your interpretation, and again, yes it is backwards 
> compatible.

No it isnt use case 4.3 clearly is not backwards compatible in any way shape 
or form, neither is your solution to the same problem (yours still results 
in those contacts being lost, 4.3 creates a completely erronerous 
subscription), backwards compatible doesnt mean it just doesnt do it or does 
it wrongly, JEP-0093 is backwards compatible because it will do stuff 
correctly in at least some clients prior to your spec coming out.

>> The contact will get lost if the client does not support roster sub sync.
> How Richard? How?
> It's ironic though.. the only thing you *do* propose (which you didn't 
> even come up with, at least Mike had the decency of suggesting this rather 
> than just assuming he was right) something contacts *don't* get lost when 
> they *should*. Maybe you got the two mixed up eh?

No I am not mixed up, it seems you are, 4.3 and your differing solution to 
4.3 will result in either erroneous subscriptions being setup or in your 
case the contact being completely lost (if the client doesnt support roster 
sub sync), I dont see whats so hard to understand about that, please explain 
to me how the contacts will get into the roster if it doesnt support your 
solution to 4.3, as it stands I dont see how that can.

> I've listed those a dozen times yet you don't seem to remember them.
> This solution is the most simple and easy to implement (as we'll see when 
> the spec is frozen and James will have it implemented, I think at least 
> some client authors will pick up on this.). It places presence 
> subscription related information in the presence packet where it belongs. 
> It's a "full" solution that supports synchronization of all states, 
> "both", "to", "from", "none" and "remove" (wait for the new rev. for more 
> details on that). Further more it *will* work with *each* and *every* 
> existing clients (just no meta-data), thus is backwards compatible and 
> removes the need for the "hack" currently in use.

But it doesnt work in a backwards compatible way certainly in the case of 
use case 4.3, as it stands if a client does not support this spec it will 
cause an erroneous subscription to be setup which will be very confusing for 
the end user, and in your solution the contact will just be completely lost, 
please explain why this isnt a correct interpretation.

Also if you really want to do the meta data at least use JEP-0093 for that 

<presence to='user at host.com' from='user%hotmail.com at msn.host.com' 
    <x xmlns="http://jabber.org/protocol/roster-subsync" 
        <x xmlns="jabber:x:roster">
            <item name="Contact Name">

This seems far more logical to me, if you find a clean solution for the "to" 
problem (4.3) then I wont be nearly so against this spec, I just dont see 
how you are going to solve this in a backwards compatible and clean way, 
i.e. not working wrongly in clients that dont support this (current 4.3) and 
not adding subscription information to a presence stanza that is related to 
presence (which is not a clean way as already explained).


More information about the Standards mailing list