Re: Trying to summarize discussion on SIMPLE interop

Iñaki Baz Castillo <[email protected]> Tue, 30 Oct 2012 12:49:45 +0100
Newsgroups gmane.ietf.simple
Message-ID <CALiegf=qT-iJX9dfJUNGvZv0JSvtCNdoqyAEkz3=cWwYuduSTQ@mail.gmail.com>
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.



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



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



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



> 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 protected]>
_______________________________________________
Simple mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/simple