[Standards-JIG] Roster Subscription Synchronisation

Richard Dobson 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 
something here?

> 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,

Why?

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

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

Richard





More information about the Standards mailing list