[Standards-JIG] Roster Subscription Synchronisation
richard at dobson-i.net
Mon Sep 13 23:45:14 UTC 2004
>>> 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. Still unconvinced subscription states do need to be provided
by this spec, since the states are actually derived from the subscriptions
that are currently there between the transport and the jabber user, IMO they
shouldnt be being communicated in this spec.
> That's exactly what it means When a "none" contact is communicated, that
> it's removed. Since it's in an unsubscribe packets (as required by the
> proposal). When you remove a contact from your roster the server does this
> for you.
Again as Mike shows there is no need for specifying anything to do with
"none" for the reasons you state, as there is a proper standard way of doing
>> 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 your 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.
> 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, 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.
>> 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
>> 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.
>> 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 syncronisation.
> 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 way.
The contact will get lost if the client does not support roster sub sync.
>> 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.
> 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.
More information about the Standards