[Standards-JIG] Re: Roster Subscription Synchronisation

Richard Dobson richard at dobson-i.net
Sun Sep 12 23:06:47 UTC 2004


>> No it's identical. JEP-0093 can't actually do the Roster Subscription
>> Synchronisation. All it can do is push out contacts, it says nothing 
>> about
>> their subscription status on the legacy network.
>
> That's a typo above. It should be "No it's not identical".
> Sorry for any confusion.

Ah ok

> The syntax is however pretty much identical to the jabber:x:roster. This 
> is
> intentional. Mostly because there's no reason to make it different.

Ok

> The reason that it's better to do this in a presence packet as part of
> subscription is because what I'm trying to fix is actually to do with
> subscription. It makes sense to fix it in the subscription system, where 
> the
> problem lies (that of not being able to synchronise subscriptions between
> legacy systems and jabber).
> There is also the huge benefit that this will work with any client that
> supports subscriptions. Clients supporting roster-subsync will be a lot 
> nicer
> to use, but others will still work.

Yes I can see what you are trying to do, I just disagree with how you are 
trying to do it.

> I know you made a suggestion on how to get that to work with JEP0093, but 
> that
> didn't seem very practical to me. You suggested using a timer. What if the
> user subscribes to the transport, then wanders away for a minute or two to
> wait for it to log in (MSN can take up to 30 seconds to connect and 
> download
> your contact list sometimes).

Yup, and Peter Millard suggested another way, all both require is a little 
more intelligence in the transport that you are building, I can see that you 
are trying to make things far easier on yourself (in building your MSN 
transport), but at the same time placing extra requirements onto clients, 
IMO its far better for you to make things as easy for clients as you can by 
making the transport a little more intelligent so it can support one of the 
methods suggested by myself, Peter and others, these solutions dont 
necessarily require client modifications for these to work although they 
will work more seemlessly if they do, the fact that so many others think 
that JEP-0093 should work just fine shows that you might not necessarily be 
doing things the best way.

But if you wish to continue on with this without listening to these 
perfectly valid points then do so, just be prepared to come up with some 
good reasons as to why you didnt listen to them when the time comes for your 
proposals last call.

Richard





More information about the Standards mailing list