Subject: [Simple] Trying to summarize discussion on SIMPLE interop

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 24 Oct 2012 19:00:41 +0200

Simple friends ;-)

I am surprised to see very few advocates for the current set of RFCs. It seems like everyone on this list
agrees that SIMPLE failed to deliver interoperability in the current form, that the specifications leave
too much to implementations and that there are undefined areas that needs to be defined in an
IETF document (which may currently be specified elsewhere).

I see that the discussions diverge on a short-term and a long term plan.

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

If there's time in the dispatch meeting for an open discussion, I hope I can participate remotely.

It would be great if we by combining our efforts can get both working standards and interoperable running code,
in true IETF spirit.

Thanks to everyone for your involvement in this discussion. Let's keep it alive and make progress together.

/O

...and don't forget to book SIPit 30 in your calendars. http://www.sipit.net
There's a lot to test - TLS, DTLS/SRTP, MSRP, ICE, GRUU, SIMPLE, Outbound, Identity 
as well as the core SIP tests. SIPit is where we test if we have running code :-)

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Tue, 30 Oct 2012 10:40:16 +0100

Hi Olle,

First, thanks for making some noise :-)

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

> If there's time in the dispatch meeting for an open discussion, I hope I can participate remotely.

Count me in!

> Thanks to everyone for your involvement in this discussion. Let's keep it alive and make progress together.

Cheers,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 30 Oct 2012 12:06:18 +0100

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

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.

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.

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

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.

Just my opinion.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Tue, 30 Oct 2012 12:19:13 +0100

> years to implement all the specs, I would not name it "short-term" at

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.

> implement and how to build basic features such as a working

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

> libxml library. Who will ask them for coding their own libxml-xcap

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

> connection, restarts it with a different IP, etc etc) and it's a

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.

> and the result will be poor for environments different than private or

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 30 Oct 2012 12:49:45 +0100

2012/10/30 Saúl Ibarra Corretgé <[email-masked]>:
> Well, in order to fix a problem you need to understand it first :-)

The issue is when somebody understands the *problem* after years
understanding/implementing the *specs*, and AFAIK this is something
you and me know about, right? ;)

> Seems like we (those posting in this thread) now do.

I also understood the "problem" after more than 6 months reading
SIMPLE and OMA specs and coding thousands lines of code. A spec should
be implementable by an expertised developer in a few months, and with
full knowledge and guarantee about the final result. Problems CAN NOT
appear after building all the stuff by following all the specs.

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

Basic presence, presence authorization and sharing a buddylist is just
easy in XMPP. That's not in SIMPLE, is it?
(I know that advanced presence features in XMPP based on subscriptions
are hard and not well implemented).

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

Take a look to http://tools.ietf.org/html/draft-ietf-simple-simple-07.
It contains ~27 references to RFC's about SIMPLE/XCAP (just for
presence, I discard those related to MSRP and conferences).

Now tell newcomers that they must implement those 27 RFC's plus some
new RFC's that update them.

> And doing something completely new would mean a installed base of 0 devices.

Could you please point me to TWO generic SIP/SIMPLE devices that can
interoperate WELL when managing presence authorizations rules and
buddylists? (two Blink instances is not a valid response). Please, I
mean two devices out of walled gardens.

> What if (years) later we also realize it was not such a good idea?

I do think right now that rescuing SIMPLE (presence) for open
environments is not a good idea. I don't expect I need years for that.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 30 Oct 2012 12:54:35 +0100

> years to implement all the specs, I would not name it "short-term" at

There must be a lot of people with experiences of developing and using the SIMPLE framework on this list.
Any opinions? We need you !!

/O

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Tue, 30 Oct 2012 13:01:38 +0100

> appear after building all the stuff by following all the specs.

That's a lot easier to say than to do. Unless we have a Delorean and have a quick look at the future ;-)

> are hard and not well implemented).

So, as you also said XMPP isn't perfect either. We can learn from it, of course.

> new RFC's that update them.

And your point is? A SIP client implements almost half of the Internet, if you count HTTP, DNS and so on. 100 RFCs are fine if they are clear RFCs.

> mean two devices out of walled gardens.

Due to the broad specs this doesn't seem possible these days, not at least for *every* possible twisted document. That, however, doesn't mean there aren't working solutions with models similar to ours. IIRC CounterPath uses (or used) a md5 hash as the entry ID in resource lists and then put more stuff in a extension.

> environments is not a good idea. I don't expect I need years for that.

I didn't say rescue, I talked about using its foundation to evolve a working "2.0" (if you will) thing.

Regards,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 30 Oct 2012 13:36:50 +0100

> So, as you also said XMPP isn't perfect either. We can learn from it, of course.

Yes, we can learn from XMPP (as opposite to copy/merge/include it
within SIP as many others propose...). The questios is: can we learn
from SIMPLE-presence? Well, IMHO we can learn that it is not a really
suitable/complete solution. Right? We can "complete" it but, can we
make it suitable?

> And your point is? A SIP client implements almost half of the Internet, if you count HTTP, DNS and so on. 100 RFCs are fine if they are clear RFCs.

Do you want to implement a *working* solution that integrates
buddylist management, presence authorization and basic presence status
delivery?:

- http://xmpp.org/rfcs/rfc6120.html
- http://xmpp.org/rfcs/rfc6121.html

And you are done, without patching libxml, without implementing
XML-diff, and without arbitrary modifying remote XML documents in any
custom way.

> Due to the broad specs this doesn't seem possible these days, not at least for *every* possible twisted document. That, however, doesn't mean there aren't working solutions with models similar to o…

So proprietary workarounds to make the stuff to work.

> I didn't say rescue, I talked about using its foundation to evolve a working "2.0" (if you will) thing.

And do you think there is REAL interest on it? who is interested?
people that wrote SIMPLE does not seem to be interested. Real SIMPLE
users (i.e. GSMA) seem already satisfied with existing specs which
they are usd for building Joyn and RCS-e (I hope they use OMA/RCS
specs full of XCAP and XDMS and so on...). Where is the REAL interest
on using SIMPLE current specs for open Internet environments? If
others are not interested I don't think they will be interested when
they realize that they must implement 27 RFC's.

Just my opinion. I could be wrong.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 30 Oct 2012 14:29:46 +0100

2012/10/30 Roy, Radhika R CIV (US) <[email-masked]>:
> Folks:
>
> I do not whether when you talk about SIMPLE and XMPP, do you also talk about
> integration of SIMPLE (or XMPP) with audio and video?
>
> Or, are you saying the following only?
>
> 1. Only SIMPLE-SIMPLE Interworking.
>
> 2. Only SIMPLE-XMPP Interworking.
>
> Please clarify in the mailing list.

The fact is that we are trying to talk about SIMPLE-SIMPLE and not
about XMPP or SIMPLE-XMPP interoperability.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Roy, Radhika R CIV (US)" <[email-masked]>
Date: Tue, 30 Oct 2012 13:21:54 +0000

Folks:

Best regards,
Radhika

---

From: "Roy, Radhika R CIV (US)" <[email-masked]>
Date: Tue, 30 Oct 2012 13:36:56 +0000

Hi, Iñaki:

Great!

It helps a lot because we are using SIMPLE integrating with audio and video, and SIP becomes the key signaling protocol for integration of audio, video, and chat/IM/Presence.

>From this view, it is urgent that we must need to solve all the problems for SIMPLE-SIMPLE interworking as soon as we can.

Of course, we must learn from XMPP-XMPP interworking as much as we can and apply the same for SIMPLE-SIMPLE interworking as fast as we can.

BR/Radhika

-----Original Message-----
From: Iñaki Baz Castillo [mailto:[email-masked]] 
Sent: Tuesday, October 30, 2012 9:30 AM
To: Roy, Radhika R CIV (US)
Cc: Saúl Ibarra Corretgé; Simple WG
Subject: Re: [Simple] Trying to summarize discussion on SIMPLE interop

2012/10/30 Roy, Radhika R CIV (US) <[email-masked]>:
> Folks:
>
> I do not whether when you talk about SIMPLE and XMPP, do you also talk 
> about integration of SIMPLE (or XMPP) with audio and video?
>

The fact is that we are trying to talk about SIMPLE-SIMPLE and not about XMPP or SIMPLE-XMPP interoperability.

Regards.

--
Iñaki Baz Castillo
<[email-masked]>

---

From: Ben Campbell <[email-masked]>
Date: Tue, 30 Oct 2012 09:32:59 -0500

(as chair)

In fact, there have been some parallel discussions about SIMPLE-XMPP interworking. 

Audio and video integration are certainly not off limits if people are interested in discussing them. If they are, starting a separate thread on the subject would help avoid some of the "what are we really talking about" confusion.

Thanks!

Ben.

On Oct 30, 2012, at 8:29 AM, Iñaki Baz Castillo <[email-masked]> wrote:

> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/simple

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 30 Oct 2012 16:08:27 +0100

> Please clarify in the mailing list.

I am trying to focus on SIMPLE-SIMPLE interworking to narrow the scope.

/O