[Standards-JIG] Roster Subscription Synchronisation

Tijl Houtbeckers thoutbeckers at splendo.com
Mon Sep 13 13:17:38 UTC 2004

On Sun, 12 Sep 2004 23:43:47 +0100, Richard Dobson <richard at dobson-i.net>  

>>> If you really want to have the information attached to the presence  
>>> (still the wrong place IMO) in a way that is virtually identical to  
>>> JEP-0093 you should at least use JEP-0093 for this instead of  
>>> inventing your own new protocol element.
>> So you're saying JEP-0093 should be rewritten to use jabber:iq:roster,  
>> since it's virtually identical syntax?
> No im not.

Then why are you saying JEP-0093 should be used? The "virtually identical  
to JEP-0093" part is only the <item/> tag. And in that respect JEP-0093 is  
more "virtually identical" to jabber:iq:roster than to roster-subsync. Yet  
it doesn't use that.

>> The syntax is not exactly identical, and JEP-0093 explicitly requires  
>> something that SHOULD not be used here.
> 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?
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.

Just a few examples from that JEP:

"The 'jabber:x:roster' namespace (which is not to be confused with the  
'jabber:iq:roster' namespace) is used to send roster items from one Jabber  
entity to another. A roster item is sent by adding to the <message/>  
element an <x/> child scoped by the 'jabber:x:roster' namespace."

"Each <item/> element may possess the following attributes:
jid -- The Jabber Identifier of the contact being sent. This attribute is  
name -- A natural-language nickname for the contact. This attribute is  

That's half the JEP already.. and it's all in direct conflict with  

>> So to summerize. We need the item data (particulary the part which  
>> JEP-0093 doesn't have; subscription) in the presence packet.
> 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.

>> in both the protocol spec and also the wording of the JEP,  and that  
>> JEP-0093 is the living proof it's apperently not a crime to copy  over  
>> the <item/> element without reusing an existing namespace, I do not   
>> see what benifit using JEP-0093 will bring.
> That we are not having to copy this yet again when it might not be  
> actually needed? As you can see I am still unconviced yet another copy  
> of this is actually needed.

We are not copying it from JEP-0093, we are copying from jabber:iq:roster.  
Just like JEP-0093 did.

>> The "proper" solution to this problem, is giving <item/> it's own  
>> namespace (since that's the part we want to reuse, not any of the  
>> things JEP-0093 adds). So if reusing existing specs and namespaces is  
>> import to you here, you better post to the XMPP-WG list about that  
>> before it's too late.
> Huh? What does JEP-0093 have to do with the XMPP-WG? Its a JSF spec.

We're not using JEP-0093. We're using something based on the <item/> tag  
in rosters (as defined in XMPP). If you think it's important to reuse  
existing specs, you should argue that <item/> gets it's own namespace, so  
iq:roster, JEP-0093, roster-subsync and any other protocols that might use  
this (disco#items?) can use that namespace. Still most specs, including  
jabber:iq:roster, JEP--0093 and roster-subsync would have their own  
additional requirments so it wouldn't make specs that much clearer or  

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.

More information about the Standards mailing list