Re: Trying to summarize discussion on SIMPLE interop

On Oct 30, 2012, at 12:06 PM, Iñaki Baz Castillo wrote:

> 2012/10/30 Saúl Ibarra Corretgé <[email protected]>:
>>> The short-term plan is to focus on the existing set of recommendations in RFCs and try to find out
>>> which implementation guidelines and maybe extra set of documents that are needed to get a
>>> baseline interoperability in handling of a simple buddy list, presence involving multiple devices
>>> and presence authorization. There seems to be an agreement that MSRP based chat works.
>>> 
>>> The long-term plan is to spend time on developing something that would be much easier to implement,
>>> not require 18 (or more) subscriptions with states and be easier to interoperate with XMPP.
>>> 
>>> I personally would like to focus on the short term plan for now. I want agreement on a
>>> set of implementation guidelines so we can get the available softphones (and hardphones
>>> that implement SIMPLE) to interoperate using standard open source servers like OpenSIPS,
>>> OpenXCAP and Kamailio (and possibly others). If it's not possible, well, then at least we tried to
>>> fix it and we can divert attention on either XMPP or developing a SIMPLE--.
>>> 
>> 
>> I agree. We (kind of) took this approach and managed to build something that works, so it's doable. It would be great if we could put together some recommendations / specifications for these items you highlighted: a buddy list, multi-device presence and authorization.
> 
> 
> The "short-term" plan looks no so "short" for me (taking into account
> that AG, really experts in this area has required years of work to
> make all the SIMPLE/XCAP stuff to work). If the short-term plan
> requires that a developer team starting with SIMPLE must work over 2-3
> years to implement all the specs, I would not name it "short-term" at
> all.

Well, in order to fix a problem you need to understand it first :-) Seems like we (those posting in this thread) now do. Server side capability was implemented years ago and somehow nobody had issues with it, now that we could finally see how the client side feels like we discovered that are actually worse that it seemed.

> 
> In the other side, implementing XMPP is 100 times easier, more
> feasible and more robust than implementing current SIMPLE/XCAP specs
> plus the suggested "extra layer" for properly defining what exactly to
> implement and how to build basic features such as a working
> addressbook.
> 

XMPP is not 100 times easier. Have a look at how basic presence is done and how PEP relates to it.

> And remember: XCAP is not XPath 1.0 compliant (since XCAP introduces
> the concept of "default document namespace" to save ~20 bytes in a
> HTTP request) which means that developers cannot use the well known
> libxml library. Who will ask them for coding their own libxml-xcap
> library? (not me).
> 

And who said that it can't be relaxed? RFCs update other RFCs all the time.

> And one more thing: As I noted in previous mails, SIMPLE model fits
> very bad in the modern Internet environments (smartphones). SIMPLE
> requires mantaining dozens of SIP dialogs (subscriptions) and
> mantaining a dialog in a smartphone is a bad idea (it looses the
> connection, restarts it with a different IP, etc etc) and it's a
> battery overkill.
> 

Keeping a TCP socket is not costly at all. Mobile operating systems are built to do it efficiently. If the connection breaks the client should restart it. Same goes for the IP change. Yes, I know TCP is not particularly nice for mobiles, that's probably why Google uses pseudo-TCP and Facebook uses MQTT, but I think that's not the point here.

> So, honestly, if I new effort is desired I strongly doubt that the way
> to go is rescuing SIMPLE specs. The effort will be giant for newcomers
> and the result will be poor for environments different than private or
> fixed networks.
> 

And doing something completely new would mean a installed base of 0 devices. What if (years) later we also realize it was not such a good idea?

--
Saúl Ibarra Corretgé
AG Projects