[Standards-JIG] Roster Subscription Synchronisation
richard at dobson-i.net
Mon Sep 13 14:30:37 UTC 2004
>> 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 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, this is IMO what it
is really intended for, not only to be ever used in message stanza's, 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 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?.
>> 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
You still fail to explain why you actually need a subscription attribute,
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?
"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 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" 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, 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.
> 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.
More information about the Standards