[Standards-JIG] Roster Subscription Synchronisation
richard at dobson-i.net
Sun Sep 12 22:43:47 UTC 2004
>> 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.
> 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.
> Further more, it lacks one of the key properties (subscription).
Why does it require it? See below.
> Even aside from that, much of the wording of JEP-0093 describes a very
> different use than that which we require.
So..? Just because it was originally targetted to another purpose doesnt
mean we can reuse it for something else.
> 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
> As we've shown this is where at least the subscription data should be,
> because we are fixing a presence subsription related problem.
Still fail to understand why the subscription attribute is required.
> Since JEP-0093 in it's current form is unusable (partly cause of that)
> for what we *do* fix with James proposal. Given that JEP-0093 would
> require a major rewrite to fit our requirment,
> 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
> 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
Huh? What does JEP-0093 have to do with the XMPP-WG? Its a JSF spec.
More information about the Standards