[Standards-JIG] Roster Subscription Synchronisation

Richard Dobson 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 
> roster-subsync.

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 
> stanza.

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.

Richard





More information about the Standards mailing list