[Standards-JIG] Roster Subscription Synchronisation
thoutbeckers at splendo.com
Tue Sep 14 20:30:25 UTC 2004
On Tue, 14 Sep 2004 20:21:20 +0100, Richard Dobson <richard at dobson-i.net>
>> 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.
> Already solved this one im afriad, when the transport contact goes to a
> none subscription status the client simple automatically deleted it,
> problem solved.
Erm, I don't think it's a wise idea to just delete something when you're
not sure what it is!
>> Well it is presence (subscription) related. Subscribe and unsubscribe.
>> And it's in a presence packet. Where are you going here?
> In your previous response to the "to" problem you seemed to describe a
> mechanism that would produce stanza's of the following form:
> <presence from="bob%hotmail.com at msn.host.com" to="user at host.com">
> <x xmlns="http://jabber.org/protocol/roster-subsync">
> <item subscription="to"/>
> Now im sure you can see this is unclean and having the subsync stuff in
> a presence related stanza is inappropriate.
I think the email you are talking about it this one (it's the earliest
mail on this subject I can find):
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
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.
Then I responed:
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
subscription request. Result: "to"
As you can see I say "<presence/> subscribe request". That would NOT look
like the packet you describe (a presence subscibe request of course has
type="subscribe"). Maybe it was the </> around it that confused you?
Oh well, Even if I have made such a typo... I've described the scenario
correctly many times, and you can see in the JEP how it should be done.
The important part of that post was to make clear the reply to that stanza
(type="unsubsribe" instead of type="subscribed"). You're saying all this
was cause of one little mistake in an email? :D
I admit it would have been a dumb mistake to make by me, but didn't I
re-explain this many times? It's not like this error is in the JEP either?
If you would have posted this right away you could have saved a lot of
time! I hope it's solved now then.
>> There is no presence packet without a type attribute.
> Urm yes there is, its used to communicate the users current presence.
In our proposal I meant of course.
>> 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
> This is exactly the problem it can end up creating a "both" subscription
OK, I'm gonna cut you off right here. I addressed this. Clients supporting
our protocol will NEVER make this a "both" when it should be "to". With
our proposal subscriptions will be exactly in sync! Without it, it's
problematic. THAT is why we need the protocol. STILL, I have suggested a
simple way to get around this. Again, you just ignore what I already wrote.
In fact I find this rather frustrating. Why are you saying it's a "serious
issue" that clients *NOT* supporting our protocol can end up with "both"
instead of "to" when I:
- this has nothing to do with the protocol itself.
- I showed you how you CAN make it a "to", on all clients, all servers,
and very simple.
- you yourself used to say "to" isn't that important!!
>> - 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!)
> I dont see why it doesnt belong where I put it, it seems perfectly valid
> to me where I placed it, it cleanly separates things out (the meta data
> and the subscription status),
Like I said we copy from jabber:iq:roster. So does JEP-0093 by the way.
And that's where it puts the the subscription, this *IS* a re-use issue.
Meta data is the data *inside* the <item/>. If you don't like that go
argue against iq:roster or something.
>> - change the definition of the JEP giving more room to uses like this.
> The JEP doesnt need changing, all you need to do is define your uses in
> your JEP these will superceed anything defined in JEP-0093, no problem.
>>> 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.
> You havent won me yet :), you have still not solved my concerns.
What are they?
It seems you've been calling things "not working" and "a hack" cause you
misread one of my emails or cause it wasn't so clear. Let's call that the
"unclean" concern, that's solved now.
The "backwards compatible" part? Well, I've shown you how to do that. If
you see any way that wouldn't work, share them. Specifics please this
Then you suggest using jabber:x:roster in the presence packet, that's an
issue for the author of that spec not me for now.
Then the mysterious case of the lost contact, I haven't heard back from
you on that so I guess that's solved too.
More information about the Standards