[Standards-JIG] Roster Subscription Synchronisation
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
>> 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
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
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'
<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