Re: Trying to summarize discussion on SIMPLE interop

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

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?



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

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.




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

So proprietary workarounds to make the stuff to work.




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

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