[Standards-JIG] Roster Subscription Synchronisation
thoutbeckers at splendo.com
Tue Sep 14 17:30:16 UTC 2004
On Tue, 14 Sep 2004 17:22:15 +0100, Richard Dobson <richard at dobson-i.net>
>> 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
You like ghost contacts on your roster, I don't.
You don't care about synching I do. I think we've established that much.
That's why I am making the proposal and you're not I assume.
>>> 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
> 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.
Well it is presence (subscription) related. Subscribe and unsubscribe. And
it's in a presence packet. Where are you going here?
> 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.
There is no presence packet without a type attribute.
> See above, it seems plain enough to me.
Kindly point out the presence packet without a type attribute so we can
>> 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.
Noone has shown such a thing, execpt Mike did. Unfortunatly before I could
correct the assumptions he and I prelimary made about presence and roster.
I would love to see it though, I have some ideas how to do it myself, but
from all my ideas I like the current one I back most. If someone will come
with an actual proposal I will argue why the current one is better, unless
they come up with something I didn't think of yet. None of that I've seen
here so far and certainly not from you.
>> 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.
What's wrong about it? It will ensure that a client always have the
ability to see the presence of that user (if it accepts (or even denies
the subscription) and then adds the contact, like what is possible in 99%
of all client UI's. like the JEP states, a client that does not support
roster-subsync SHOULD be warned in advance. The transport can explain
this), which is what "to" is about. Yes, it's annoying that this way in
your roster it will show the subscription state is "both" and not "to". As
a workaround the transport can then unsubscribe again. Now *that* I could
see as a hack, and that's part of what this protocol fixes.
>> 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,
No Richard, shouting "JEP-0093!" a couple of time does not count as a
proposal. Mike made a proposal, which I will respond to.
> 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.
Well, I haven't seen a valid reason from you not to go ahead with this.
You're free to come up with a counter-proposal whenever you feel like, but
the world doesn't stop just for you.
>> "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,
You still haven't shown why.
> 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.
Our proposal is backwards compatible. Show us where it goes wrong (you
really haven't done this yet). For that matter, show us how JEP-0093 will
do it right.
>>> The contact will get lost if the client does not support roster sub
>> 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
Let's suppose a client doesn't support roster-subsync. It get's the
- when it accepts it, and makes a "counter" subscription the contact is
not lost (the transport COULD unsubscribe itself).
- when it doesn't accept the contact and make a counter subscription
(roster-subsync behaviour) the contact is not lost.
- When it doesn't accept the contacts and it doesn't make a "counter"
subscription (in other words the client completly ignores everything) the
contact is lost... at least on the clients side!
Because when the next time the clients logs in and the transport can
choose to make a new attempt. Maybe the user will accept it then. Maybe
the user logs in with a client supporting roster-subsync the next time.
Maybe that's what the transport would do.. if the contact is "lost" the
first time cause the user refuses to add it (even after a potentially
helpfull message from the transport) it can wait till the client logs in
with something that *does* support roster-subsync. It's only as lost as
you want it to be.
For all I care it can send a JEP-0093, try and use the Jabberd 1.4 hack..
none of these are recommended by our proposal. If we could sync the
subscriptions correctly using existing methods, conforming to standards,
without using "hacks", working with every known server and client
outthere, we wouldn't be discussing this here.
But our proposal *does* leave room for a solution that will work in that
way, it just requires the correct user interaction (accepting and
"counter" subscribing every subscription you get from the transport), and
1 not so clean -but standards compliant and backwards compatible with
every client and server- method for the "to" scenario (if a "both"
subscription is created, as can be expected, it will be reverted to a
"to"). This "clean hack" however is NOT part of our protocol (which is all
clean!)! It's just *one* way of working with clients that don't support
support our protocol and it *happens* to fully be compatible (even without
disco support in clients) with our protocol! If you prefer the "send
intial list of contacts with JEP-0093" method for clients that support
that, you're free to do the extra work. If you want to do the dirty
subscribed hack.. I'd urge you not to, but feel free. Manipulate the
roster on the server for all I care. It's not part of our proposal.
- when ??? the contact is lost. <-- please fill in your use case here.
What happens if you send a contact by JEP-0093 and the user chooses to
ignore it? This is, at least in Mike's proposal allowed behaviour. Where's
the contact now? The transport can't send it again, because the behaviour
of the client was correct according to the proposal.
>> 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
> Also if you really want to do the meta data at least use JEP-0093 for
> that e.g.
> <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">
I've talked about this with you before. As I said then(!), I'm not(!!)
opposed to wrapping the meta data in a jabber:x:roster thing like this.
We'll just need to change jabber:x:roster to:
- allow to be attached to a presence stanza
- not REQUIRE the jid attribute.
- include the subscription property (it doesn't belong where you put it in
your example, it's not where jabber:iq:roster put's it, the spec we are
effectivly using, remember that when you write your own proposal!)
- change the definition of the JEP giving more room to uses like this.
I said that was probably a lot of work for little gain, but yes it can be
done. We need input on this from the rest of the community and the author
of the spec I think. I wonder if PSA is still reading all this..
> 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,
Great! If we've won our our biggest sceptic that's a big plus.
> 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).
You'll still need to point me to that one. As far as I know we only use
subscribe (4.3 uses that), unsubscribe and unsubscribed. And always have
for that matter. Those are all related exclusivly to subscription.
More information about the Standards