[Standards-JIG] Re: Roster Subscription Synchronisation JEPrevision 0.3
richard at dobson-i.net
Tue Sep 14 16:54:53 UTC 2004
> Yup. That's the only way to do it because <presence type="subscribed"/> is
> disallowed by XMPP, as it should be. =)
Yup using "subscribed" should of course be disallowed.
>> and your description in 4.3 is
>> completely wrong and would never work, because a "to" status on the
>> roster means you are subscribed to it, but you show in example 1 the
>> contact subscribing to the users presence which would make it a "from"
>> 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
> lets the client know to deny the subscription, but to request it's own,
> is then accepted by the gateway.
I can see how you are trying to solve it, but its simply the wrong way, if
it is a "to" subscription the legacy contact should never subscribe to the
jabber user as its a "to" subscription and not a "from" or "both", even
though you reject it later on, aside from it being wrong if a client does
not support your spec it will not automatically reject it and it will
confuse the user and they will likely accept the subscription turning the
legacy subscription into a "from" and then a "both" if the jabber user
subsequantly subscribes to the presence of that user (as most jabber clients
will prompt the user to do), this is not backwards compatible behaviour
which is bad and goes against your statement saying it is backwards
>> The way you describe it will not work at all if the
>> client doesnt support your spec and will completely break it, and is
>> 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
I cant think of a better way you could do it other than using JEP-0093,
JEP-0093 certainly can work in this particular case as it would be used to
give the jabber user a list of contacts with either a "both" or "to"
subscription, i.e. the contacts the jabber user should be subscribing to so
a JEP-0093 solution certainly can work.
> 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
> If they do accept the subscription request, it means the other user will
> able to see their status, but they know this because they accepted it's
This is hardly backwards compatible or user friendly behaviour even you must
> In this case the subscription request by the gateway is just a fake to get
> contact onto the user's list. It would be ideal to send a presence
> from the very beginning to solve this use case, but we can't (I'm not
> that we should be able to btw =P)
Just use JEP-0093, if you think it through properly you should be able to
see it solves this particular use case perfectly :)
>> In section 4.5 specifying your namespace on that unsubscribe is
>> pointless as unsubscribing msn contact will automatically result in a
>> 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
>> result in an effective "none" and the contact being removed.
> Yeah, I knew that a couple of these would be unnecessary. Mostly I had
> copy/pasted the stanza, and I hadn't gone through and checked exactly
> ones yet. Thanks, I'll go and fix those.
> I'm still going to leave them in the
> JEP for completeness though.
Are you going to remove your namespace from these then?
> 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.
Yea, but the same can be said for the JEP-0093 solution, all the stuff that
already works for your spec also is already done for the JEP-0093 spec, so
please do not continue to say that it cannot do it because it doesnt cover
all the use cases, because it doesnt have to as shown by this.
>> Most of what you try to do can be handled perfectly fine just using
>> presence subscription/unsub etc requests without your namespace even
>> there, so in those cases that namespace is simply a waste of bandwidth as
>> 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
> attention of the user. Some clients do notify users about presence
> unsubscribe[d] events, so this would let them know that they shouldn't
> user has presumably already been told by the legacy client they used when
> change occured).
IMO this is not of enough value to be worth putting it in.
>> The following cases can all be handled better and more compatibly just
>> a JEP-0093 stanza, 4.1, 4.2 (to express what you are subscribed to, once
>> 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
> exactly. How will it be able to differentiate between 4.2 & 4.3?
As far as JEP-0093 goes it doesnt need to differentiate between 4.2 & 4.3
since JEP-0093 is there to provide a list of contacts the user should be
>> Cases 4.10 and 4.11 are very unlikely status change scenarios and are
>> logically catered for by moving in 4.10 from "from" to "none" then 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.
Ok, it might be better to document these saying to do 4.9 and then 4.4 etc
to make it simpler to follow.
>> So as I show we dont need to use your spec to cover the use cases, infact
>> lot of the use cases you cover are handled by the standard presence
>> symantics anyway in which case your additional element serves no purpose
>> 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
> would with this JEP.
4.2 and 4.3 and be done completely cleanly, 4.3 even more so, your spec as
it stands does this in im sure even you have to admit a far from clean way.
> 4.4 is similar to 4.2 & 4.3, however it definitely cannot be done with the
> existing JEP0093.
Yes you may have a point about 4.4, maybe what we really need here is more
of a combination of the two methods where they fit the best, JEP-0093 fits
best in 4.1, 4.2, 4.3, your method fits best in case 4.4 and standard
subscription symantics handle 4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 4.11.
> 4.7, 4.8, 4.9 without this JEP would leave you with 'ghost' contacts on
> list, that you have removed using another client, but that still appear in
All 4.7, 4.8 and 4.9 need is a simple bit of intelligence that contacts that
turn into "none" on the transport need to be automatically removed, you
already know about what is the transport so you can only accept updates from
the transport, this kind of logic is not much of a stretch.
More information about the Standards