[Standards-JIG] Roster Subscription Synchronisation
thoutbeckers at splendo.com
Tue Sep 14 15:33:36 UTC 2004
On Tue, 14 Sep 2004 00:45:14 +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.
> As Mike shows the roster subsync thingy has no business specifying how
> removals should be done, as these should be being handled using standard
> unsubscribe and unsubscribed presence stanzas, so there is no need for
> this spec or a JEP-0093 based spec to specify anything about removal as
> this is already fine.
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.
>> 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"
> 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"/>
> 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
> 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
>>> 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.
> Yes but making implementation of the MSN transport much easier does seem
> to be the primary motivation for this proposal so MSN related stuff is
> relevant to this.
James started this because he is the (Py)MSN transport maintainer. I got
involved with this cause I think roster subscription synchronizing is a
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. 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.
>>> 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)
> But what legacy protocols are actually going to take advantage of this,
> its no use for MSN, would AIM or Yahoo make use of this?
>>> This is the only case where it will work correctly.
>> Sorry, all other cases work too.
> Not cleanly and and not in a backwards compatible way.
"Cleanly" is entirely your interpretation, and again, yes it is backwards
>>> 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
>> 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"?
> But it doesnt, not cleanly and certainly not in a backwards compatible
> 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?
>>> 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.
> If you say so, although you do go away from being subscription related
> when you try to fix the big problem with "to" subscriptions, which does
> seem a rather hackish way and against the spirit of this spec, also this
> information is not related to the presence of a contact so IMO has no
> place being part of a presence related presence stanza, I could be
> persuaded that this stuff could go into a subscription related presence
> stanza but not into a presence related one.
>> Then write up your own proposal, so we can discuss that.
> Id love to but unfortunatelly I wont have the time to do so until around
> november time due to current commitments.
Next time you get into a discussion invest the time you spend on saying
"things don't work" when they do, or "no it's wrong!" 10 times over, into
coming up with your own proposal. You could have had a dozen by now.
>> 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!
> There is no need for any deleting stuff as already shown.
>> 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).
> I am writing it off because as is it will not work correctly in a clean
> way, and because a JEP-0093 solution would do exactly the same job but
> in a more compatible way, it seems clear you are not going to listen to
> the many people here who think it is better to use JEP-0093, I suggest
> you prepare your arguments to why we shouldnt just vote no for this when
> last call for this comes along.
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.
We'll see how any JEP-0093 based proposal will stack up to that, as will,
I assume, the council.
More information about the Standards