[Standards-JIG] Roster Subscription Synchronisation
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
More information about the Standards