[Standards-JIG] Roster Subscription Synchronisation
thoutbeckers at splendo.com
Mon Sep 13 16:19:05 UTC 2004
On Mon, 13 Sep 2004 15:30:37 +0100, Richard Dobson <richard at dobson-i.net>
>>> But what I am trying to show is that JEP-0093 can be used, without
>>> anything being added to it.
>> In our case, that's about the only thing we have in common with
>> JEP-0093, so why use JEP-0093?
> Because JEP-0093 provides an existing way of representing a contact or
> list of contacts that can be transmitted between to jabber entities,
> this is effectively what you are trying to do, i.e. transmit a contact
> or list of contacts between two jabber entities, the user and the
> transport, it seems a perfect match to me, and several others too, ive
> counted at least four of us that feel this way.
If that's all we're trying to do it could work. However, we are not. We
are synchronizing subscriptions. Not just sending contacts.
>> If you can show us a proposal that uses JEP-0093 *and* solves the
>> problems we are solving, without going against what JEP-0093 defines
>> (or include a proposal for changes to JEP-0093), then of course it's
>> worth considering! I'd be nice if it has a fallback mechanism for
>> clients that don't support JEP-0093 (and whatever you're gonna propose
>> with it) too.
> There is nothing stopping us using JEP-0093 "jabber:x:roster" tags
> wherever we might want to transmit a contact or list of contacts,
Except from JEP-0093 in our case making requirments that go explicitly
against what we intend, and us needing additional things not included in
> this is IMO what it is really intended for, not only to be ever used in
> message stanza's,
Then the JEP shouldn't state it's meant for message stanzas.
> even JEP-0100 already says that JEP-0093 should be used for transmitting
> the contacts between the transport and the user, so it is definately not
> in conflict with the objective here, and should be explicitly being used.
That's JEP-100's problem as far as I'm concerned. Sending some JEP-0093
data in a message does not solve the problem we have. JEP-100 could
ofcourse be adapted to recommend this new approach when the JEP is
finished. JEp-100 is still experimental itself.
>> That's half the JEP already.. and it's all in direct conflict with
> No the spirit of the JEP is in no way in direct conflict, this is just
> the original foreseen use for "jabber:x:roster", there is nothing
> stopping us from using it in something which it is directly suited to,
> which in this case it is IMO. Are you saying we cannot use our specs for
> different uses in future if they easily apply to them?.
Then make a proposal to update JEP-0093 so it solves the same problem we
solve, or that it can be used in our solution, in both usage (what is
allowed) and definiton.
We've choosen a different route, because we think presence subscription
synchronization is best handeled in a <presence/> stanza since that is
where presence subscriptions take place. (If you remember how this got
started, James original proposal didn't contain any meta-data at all) For
convienance, some meta-data is added. Putting that in a different stanza
would only complicate matters (they'd have to be linked together), and I
still haven't heard a good reason for NOT putting it right there.
>>> Why? I still fail to understand why this information is required, as
>>> far as I can see the fact that you are being subscribed to shows it is
>>> in the legacy roster, so what value is the subscription attribute? Am
>>> I missing something here?
>> The first thing the protocol is meant for is to synchronize
>> subscriptions between the legacy network and the jabber network. As you
>> know presence subscriptions in Jabber are request through the
>> <presence/> stanza. The problem is, that when you are subscribed to
>> someone on the legacy network, but you aren't yet on your Jabber roster
>> (which is the case during the initial "import" and if you use the
>> legacy client inbetween using the jabber<->legacy gateway), the
>> <presence/> stanza the gateway sends isn't really a request. Rather
>> it's informing the client that such an equivalent request was send and
>> approved on the legacy network, and thus that procedure should be
>> repeated on the Jabber network to have the Jabber roster reflect that
>> of the of the roster you keep on the legacy network. That goes for
>> subscription types of "none" and "both", but also "to" and "from" for
>> networks that support this (for example, imagine a jabber<->jabber
>> transport if you will).
>> So what we need is something in the <presence/> stanza to tell the
>> client that this is a different type of request than a normal request.
>> Clients *could* still decide to not approve it, and transports *could*
>> take that into account (for example by changing the roster on the
>> legacy network to reflect that) but if all you want it to keep the
>> subscriptions of your jabber roster in sync with the legacy network,
>> this will provide an easy way to do that.
>> The second thing the protocol does is provide some intial roster
>> meta-data (nickname, groups) that was used on the legacy network for
>> making a new subscription. I suppose you could put this in a <message/>
>> stanza, somehow using JEP-0093 (if you change the wording in that JEP)
>> but you'd still have to link it to the presence packet with some kind
>> of unique ID or something, complicating things for client developers.
>> And I haven't heard a reason yet why such information wouldn't be
>> allowed in a presence stanza.
> You still fail to explain why you actually need a subscription attribute,
Because we are synschronzing the subscription state between the legacy
network and jabber (in other words, what you see on your contactlist when
you're using jabber). This includes adding, removing of contacts but also
one way subscriptions. Tell me how to do that without sending the
For example if the subscription state on the legacy network is what in
Jabber we call "both" but on your Jabber roster it doesn't exist yet
("none") or is in a different state ("to" or "from") and we want to
synschronize this requires that a subscription request is send from
transport (using the translated name from the legacy user as the node
part) to the user, and then an approval of the user must be send. Also the
user should send a subscribtion request to the the transport (same node),
and the transport should approve that.
You can imagine the use case for "to", "from" and "none" I hope.
Now, this would all work perfectly already, if you have a smart user who
has memorized his roster and the state all his contacts are in, and then
manually handles each subscription request accordingly. But we want to
make it a little easier. Since a presence subscription request (subscribe)
or retraction (unsubsribe) is already send anyway, and the transport knows
exactly what the subscription state on the legacy network is, we might as
well put it in the stanza! Then this can happen automatically.
What exactly is it that you dislike about that approach? Or is is just the
meta-data that's added that bothers you?
> the fact that the legacy user is subscribing to your presence along with
> this extra info shows it is in the legacy roster, so if you know from
> this the contact is already in the legacy roster what is the point in
> having a subscription attribute? Again am I missing something here?
Hopefully you see now.
> "link it to the presence packet with some kind of unique ID"???? Why
> exactly, what do you mean by this? Peter Millard has explained a
> perfectly feasible way you can do it,
Which, as shown, does not meet our requirments since it doesn't solve our
> which I can see is slightly harder to implement than this solution on
> the part of the transport, which is why you want to try and do it in a
> different way that is a bit easier to implement, but inso doing you are
> placing requirements on the client that you neednt do if you just put a
> bit more work into the transport. The solution myself, Peter and others
> have suggested does not need any such client support since if they
> already support "jabber:x:roster"
Clients also support already support subscription requests. In fact I
think more clients do than jabber:x:roster ;) It will still work for them,
except they won't have the meta-data. This however, would be very trivial
to add. Perhaps JEP-0093 can be changed (perhaps in combiniation with a
seperate proposal) so that it does work properly.
It's advantage would probably be that you *would* have the meta-data in
current clients (but it'll still be a manual affair), but not the proper
subscriptions. and JEP-0093 lacks any buisness rules on, for example, what
to do when you receive contacts that are already in your roster (which
will be the case if you're gonna update JEP-0093 for the purpose of
continued synchronization) which could lead to some weird effects on
I can imagine JEP-0093 could fixed some ways to also tackle this problem.
I don't see how it could be done much better than the current proposal
regarding backwards compatibility. I don't believe you can make a solution
more elegant and simple with it than currently proposed, which is why I've
choosen to support this approach. As long as there is no counter proposal,
I see no reason to change that.
> which quite a few clients already do it will work better than it does
> currently pretty much out of the box without requiring client
> modifications. I am still very confused as to why you want to continue
> with how you want to do it when quite a few others have shown a better
> and more compatible way,
Let them show their proposal in a way that fixes my problems and I'll
consider them. Till then, there's a proposal on the table that *does* fix
> but it seems that we will not change your minds, all I can suggest is
> that you prepare some proper reasons as you why you didnt listen to the
> rest of us that are going to stop us from voting no to your proposal by
> the time its last call comes along, because as things stand I can see
> that a number are likely to do so.
I've made one contribution to this thread early on, explaining the problem
of synchronizing subscriptions. There were exactly 0 replies to that. I've
then talked with James about putting this in a JEP, and after the first
version of his JEP I've worked with him on more clearly defining the
Since then (all my other postings on the topic are after that) you've been
the only one to respond to that specific issue, but mainly cause you
didn't seem to grasp why it's important. That's not a reason to change my
mind, rather I've tried to explain to you why, which hopefully worked this
time. For the rest, noone has tried to change my mind, and I'll gladly
listen to anyone who wants to give that a try.
As for when it comes to a vote, I assume the council will read the JEP,
discuss it, and then decide. If they vote no, then I assume they'll give
their motivation for that. Since none of the proposals made in this thread
so far fix all the issues that are addressed by the JEP, I don't expect
their motivation to be "look at the thread on SJIG, we told you all this
>> There is no point in using the namespace of a "copy", that has it's own
>> additional requirments and definition because it's designed for a
>> different goal.
> But that the thing, I am not convinced it is different at all, the most
> basic goal of JEP-0093 is to provide the ability for two entities to
> pass details of a contact or list of contacts between each other, which
> as far as I can see is exactly what you guys are trying to do, so they
> do infact have the same basic goal.
Well, the goal of jabber:x:roster seems to have been the use case of "I
have a contact on my roster and want to send it to someone". You could
always broaden the scope a bit afterwards, and likely it was done already
when the spec was thought up. However, the current state of JEP-0093
simply disallows things needed for our proposal, and lacks some of the
things we need. Furthermore the wording of the JEP isn't quite in the
"spirit" of our proposal; Automated synching of subscription states and
exchanging roster items between entities. Don't get me wrong, those topics
aren't that far apart, I agree it's somewhat alike. But nothing else in
the JEP-0093 convinces I should use it in a case like that. In fact quite
the opposite, it only seems to steer away from it.
But I don't think it's a good idea to change JEP-0093 just for this. The
potential for reuse is very limited. Any changes to accomodate these
issues would have the disadvantage of making JEP-0093 itself more complex.
I guess it's an issue we'd have to take up with the author of JEP-0093 if
you want to see the JEP-0093 namespace used in our current proposal. That
is, if you're not still against the very idea of our proposal.
I'm not sure who the author is, it lists PSA but since it's a historical
JEP I assume he only documented it. (Maybe it was Jer himself?). But I do
believe PSA is involved with Shared Rosters or something simulair and
they're considering using JEP-0093 as well. Assuming they'll have to make
changes to JEP-0093 too, it might be worth changing JEP-0093 and using it
More information about the Standards