[Standards-JIG] Re: Roster Subscription Synchronisation JEP revision 0.3
james at delx.cjb.net
Tue Sep 14 12:24:41 UTC 2004
Thanks for the feedback.
Richard Dobson wrote:
> All of this shows you do not understand how subscriptions should really be
> being handled by the transport and the client, the transport should be
> maintaining the current status of things the jabber user is currently
> subscribed to and be comparing this to what the status of the MSN contact
> lists when the user logs into MSN then sending the apropriate
> subscribe/unsub/JEP-0093 etc stanza's.
> Also with regards to your spec, as I noted your spec cannot handle "to"
> subscription statuses without a big hack
Yup. That's the only way to do it because <presence type="subscribed"/> is
disallowed by XMPP, as it should be. =)
> and your description in 4.3 is
> completely wrong and would never work, because a "to" status on the legacy
> roster means you are subscribed to it, but you show in example 1 the legacy
> contact subscribing to the users presence which would make it a "from" and
> once the user subscribed into a "both", which is completely wrong as it
> should only be a "to".
It won't be a 'both' as far as I can tell.
The legacy user 'requests' subscription, the subscription attribute of 'to'
lets the client know to deny the subscription, but to request it's own, with
is then accepted by the gateway.
> The way you describe it will not work at all if the
> client doesnt support your spec and will completely break it, and is overall
> the completely wrong way to do this, its an even worse hack than Tiji
There's no better way to do this that I can think of. JEP0093 certainly can't.
If the client doesn't support the spec, the user will just have to know to
reject the subscription request, and to make their own subscription request.
If they do accept the subscription request, it means the other user will be
able to see their status, but they know this because they accepted it's
In this case the subscription request by the gateway is just a fake to get the
contact onto the user's list. It would be ideal to send a presence subscribed
from the very beginning to solve this use case, but we can't (I'm not saying
that we should be able to btw =P)
> In section 4.5 specifying your namespace on that unsubscribe is completely
> pointless as unsubscribing msn contact will automatically result in a "to"
> subscription status, ditto in section 4.6, 4.8, 4.9.
> 4.7 yet again there is no need to express the subscription state in the
> remote roster as sending "unsubscribe" and "unsubscribed" will automatically
> result in an effective "none" and the contact being removed.
Yeah, I knew that a couple of these would be unnecessary. Mostly I had just
copy/pasted the stanza, and I hadn't gone through and checked exactly which
ones yet. Thanks, I'll go and fix those. I'm still going to leave them in the
JEP for completeness though.
But that just shows how simple it is for clients to implement, half of it
means they don't have to do anything at all.
> Overall I think you are completely confused as to how you should really be
> implementing all of the subscription syncronisation as you do it completely
> wrongly in places, and lots of it is pointless effort, subscription states
> should only ever be expressed by what subscriptions are currently in place.
I don't know what you mean here. The whole point of synchronising the
subscription is to update the subscription from what it was the last time the
gateway was used, to what it is now the gateway is being used again.
Sometimes there will be no changes, sometimes there will be changes that do
not require my JEP (like when a contact requests authorisation), other times
there will be changes that require my JEP (when the user uses a different
client in between Jabber sessions).
> Most of what you try to do can be handled perfectly fine just using normal
> presence subscription/unsub etc requests without your namespace even being
> there, so in those cases that namespace is simply a waste of bandwidth as it
> does nothing, these cases are, 4.5, 4.6, 4.7, 4.8, 4.9.
For 4.5 and 4.6 I agree with you, the namespace isn't doing anything other
than letting clients know that this is something they shouldn't bring to the
attention of the user. Some clients do notify users about presence
unsubscribe[d] events, so this would let them know that they shouldn't (the
user has presumably already been told by the legacy client they used when the
However 4.7, 4.8, 4.9 are actually about removal of contacts. That does
require extra interaction from clients, and the namespace is there to flag to
them that they should do something (namely delete the contact from their
roster). Having a subscription of 'none' does not actually remove the contact
from the user's roster. It needs to be done explicitly with an iq set.
> The following cases can all be handled better and more compatibly just using
> a JEP-0093 stanza, 4.1, 4.2 (to express what you are subscribed to, once the
> user is subscribed to the contact beforehand using a JEP-0093 stanza the
> reverse subscription from the msn contact to complete the "both" can be
> accepted automatically), 4.3.
In the case of 4.3 there is no way that the existing JEP0093 can handle this
exactly. How will it be able to differentiate between 4.2 & 4.3?
> In case 4.4 the user should be being prompted that the user wishes to
> subscribe, this can be accomplished using standard presence subscription
> symantics and does not need to be automatically syncronised as this case of
> going from "none" to "from" is only likely to happen when a user requests a
> subscription during the session at which time the user must be prompted in
> any case so there is no need to send your namespace as standard presence
> handling symantics apply.
No, the user shouldn't be prompted. The point of all of these use cases is to
synchronise the legacy & Jabber list contacts & subscriptions after the user
has used a client other than the gateway to access the legacy service.
Standard presence handling semantics only apply here if the contact requests
authorisation, and it has yet to be granted. This use case is about what
happens when you explicitly grant authorisation to a contact using another
Check the first two business rules for transports:
* The transport MUST send a presence packet with an roster-subsync tag for any
subscription modifications based on changes made to the legacy contact list
by a client other than the transport itself.
* The transport MUST NOT send a presence packet with an roster-subsync tag in
any other case (eg, when a legacy user requests subscription for the first
> Cases 4.10 and 4.11 are very unlikely status change scenarios and are more
> logically catered for by moving in 4.10 from "from" to "none" then to "to",
> i.e. 4.8 then 4.3, and in the case of 4.11 using 4.9 then 4.4.
Yes, and that's actually how I created them =)
They're just documented there for completeness.
> So as I show we dont need to use your spec to cover the use cases, infact a
> lot of the use cases you cover are handled by the standard presence
> symantics anyway in which case your additional element serves no purpose on
> those and thus shouldnt be there.
You seem to have missed the point on some of the most important use cases.
4.2 & 4.3 can almost be done with JEP0093, but not quite as cleanly as they
would with this JEP.
4.4 is similar to 4.2 & 4.3, however it definitely cannot be done with the
4.7, 4.8, 4.9 without this JEP would leave you with 'ghost' contacts on your
list, that you have removed using another client, but that still appear in
More information about the Standards