Re: Trying to summarize discussion on SIMPLE interop

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

> 2012/10/30 Saúl Ibarra Corretgé <[email protected]>:
>>> 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 :-)
> 
> 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.
> 

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

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

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

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

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

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.

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

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