[Standards-JIG] Roster Subscription Synchronisation

Richard Dobson richard at dobson-i.net
Tue Sep 14 19:21:20 UTC 2004


> You like ghost contacts on your roster, I don't.
> You don't care about synching I do. I think we've established that much.
> That's why I am making the proposal and you're not I assume.

Already solved this one im afriad, when the transport contact goes to a none 
subscription status the client simple automatically deleted it, problem 
solved.

> Well it is presence (subscription) related. Subscribe and unsubscribe. And 
> it's in a presence packet. Where are you going here?

In your previous response to the "to" problem you seemed to describe a 
mechanism that would produce stanza's of the following form:

<presence from="bob%hotmail.com at msn.host.com" to="user at host.com">
	    <x xmlns="http://jabber.org/protocol/roster-subsync">
        <item subscription="to"/>
	    </x>
</presence>

Now im sure you can see this is unclean and having the subsync stuff in a 
presence related stanza is inappropriate.

> There is no presence packet without a type attribute.

Urm yes there is, its used to communicate the users current presence.

>> Just because something works doesnt mean its not a "hack", being a hack 
>> means something is somewhere it shouldnt really be in order to solve a 
>> problem, your solution to 4.3 seems to fit this description to a tee.
>
> What's wrong about it? It will ensure that a client always have the 
> ability to see the presence of that user (if it accepts (or even denies 
> the subscription) and then adds the contact, like what is possible in 99% 
> of all client UI's. like the JEP states, a client that does not support 
> roster-subsync SHOULD be warned in advance. The transport can explain 
> this), which is what "to" is about. Yes, it's annoying that this way in 
> your roster it will show the subscription state is "both" and not "to". As 
> a workaround the transport can then unsubscribe again. Now *that* I could 
> see as a hack, and that's part of what this protocol fixes.

This is exactly the problem it can end up creating a "both" subscription 
when all it should ever be doing is communicating that it is a "to" 
subscription, it uses some business rules as a way to work around the fact 
it is the wrong way to do it, even you must admit this is hardly clean or 
truely backwards compatible and could result in significant confusion on the 
part of the user and also can result in the legacy roster subscription 
status being incorrectly altered, you may try to skirt around this issue 
saying its a non issue but it is not its a serious one.

> - include the subscription property (it doesn't belong where you put it in 
> your example, it's not where jabber:iq:roster put's it, the spec we are 
> effectivly using, remember that when you write your own proposal!)

I dont see why it doesnt belong where I put it, it seems perfectly valid to 
me where I placed it, it cleanly separates things out (the meta data and the 
subscription status), this seems perfect especially as you show that the 
meta data is not always relevant e.g:

 <presence to='user at host.com' from='user%hotmail.com at msn.host.com' 
type='subscribe'>
     <x xmlns="http://jabber.org/protocol/roster-subsync" 
subscription="both">
         <x xmlns="jabber:x:roster">
             <item name="Contact Name" jid=user%hotmail.com at msn.host.com>
                 <group>Friends</group>
                 <group>Colleagues</group>
             </item>
         </x>
      </x>
 </presence>

 <presence to='user at host.com' from='user%hotmail.com at msn.host.com' 
type='subscribe'>
     <x xmlns="http://jabber.org/protocol/roster-subsync" 
subscription="both"/>
 </presence>

This seems perfectly clean and clearly separates the subscription status 
from the meta data.

> - change the definition of the JEP giving more room to uses like this.

The JEP doesnt need changing, all you need to do is define your uses in your 
JEP these will superceed anything defined in JEP-0093, no problem.

>> This seems far more logical to me, if you find a clean solution for the 
>> "to" problem (4.3) then I wont be nearly so against this spec,
>
> Great! If we've won our our biggest sceptic that's a big plus.

You havent won me yet :), you have still not solved my concerns.

Richard





More information about the Standards mailing list