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