Re: Controversial: Have SIMPLE reached is goal? Or is it an IETF failure?

On 10/13/12 2:47 PM, Olle E. Johansson wrote:
>
> 13 okt 2012 kl. 19:29 skrev Hannes Tschofenig <[email protected]>:
>
>> I have been asked many times about the deployment status of SIMPLE in the context of emergency services. I couldn't provide a good answer.
>>
>> Here is the issue that the emergency services folks are facing: the emergency services authorities are currently in the progress to switch to IP-based emergency services networks (which includes IP-based PSAPs).
>>
>> Our story so far (IETF, EENA, NENA, etc.) was that they have to implement a SIP-only based solution and everyone else who wants to send emergency calls to them has to perform the translation from whatever protocol they are using.
>> Note that emergency calls here refers to a multi-media communication (voice, text, real-time text, video, data).
>>
>> While the situation is pretty good for voice for text based communication it is far from clear what the SIMPLE deployment status is.
>>
>> The interworking between SIP-based voice and XMPP text messaging is not standardized either. Does anyone have any information?
> It's going to be hard to translate. We had a workshop on that years ago. The architecture is very different. There are efforts,
> recently in sylkserver, you can play with. I have some presentation on slideshare as "oej" covering the differences as we saw them then.
> If you add xcap and server-side buddy lists it's even harder.

ISTM that while there is difficulty in mapping presence between xmpp and 
sip, there is much less difficulty in mapping IM messages between xmpp 
and msrp. The latter is the part that is needed for emergency services.

	Thanks,
	Paul

>> So, what story should I tell these emergency services folks?
> Good question. Basic SIP MESSAGE doesn't involve much of SIMPLE, but it has it drawbacks. MSRP, as Adrian said, works well.
>
> /O
>
>> Help appreciated.
>>
>> Ciao
>> Hannes
>>
>> PS: Luckily the address book issues is not applicable to emergency services.
>>
>> Sent from my ASUS Pad
>>
>> Adrian Georgescu <[email protected]> wrote:
>>
>>> Hi Olle,
>>>
>>> As a developer I can only concur with your assessment about the address book. In my case, it took four years of development and 15,000 lines of Python code, which is a high level language to assemble what one would call a SIP SIMPLE presence enabled address-book application where each contact is Presence aware. And of course there is no chance to have other SIP clients work with the same model. I had to navigate and connect the dots between countless disparate IETF documents like
>>>
>>> http://sipsimpleclient.com/projects/sipsimpleclient/wiki/SipFeatures#Presence
>>>
>>> This complexity is beyond the reach of regular programmers that do not live deep inside the SIP world. Who has years to waste for such a task? A comparison with what other functionality, like setting up an audio call or a multiparty conference requires in terms of effort, may give a better image of the complexity for doing Presence with SIMPLE.
>>>
>>> http://sipsimpleclient.com/attachments/4405/SDK-LinesOfCode.png
>>>
>>> Complexity aside, on the good side I have discovered that:
>>>
>>> 1. IM, File Transfers and Multiparty chat work very well with MSRP, it is straight forward to implement and is well interoperable
>>> 2. Inter-domain signaling and media works well even to XMPP domains for both Presence, IM and multi-party chat
>>>
>>> What could be considered 'broken' is the lack of a standard model for storing a generic and extensible address-book with presence-rules so that several different clients can work together under the same account without generating conflicting XCAP documents.
>>>
>>> I would not call SIMPLE a failure just because things are complex, as they really are. XMPP is not a walk in the park either when you try to do with it more that it was designed for.  Just look at the forest of incompatible options between same the clients of Google namely Talk, Hangouts and Gmail interfaces, you can recognize same issues as with SIP. Add voice into the equation and you recognize the same complexity as with SIP trying to do Presence. What Google did well is to abstract the address book for all of their own clients so that the problem is well hidden.
>>>
>>> What could be done to make SIMPLE better and achieve its original goal, would be to standardize an XCAP address book application with presence rules built-in that can be interpreted in a single way by all developers.
>>>
>>> Adrian
>>>
>>> On Oct 13, 2012, at 2:31 PM, Olle E. Johansson wrote:
>>>
>>>> Hello,
>>>>
>>>> The SIMPLE workgrup chartar says:
>>>>
>>>> "The IETF has committed to
>>>> producing an interoperable standard for these services compliant to
>>>> the requirements for IM outlined in RFC 2779 (including the security
>>>> and privacy requirements there) and in the Common Profile for Instant
>>>> Messaging (CPIM) specification, developed within the IMPP working
>>>> group."
>>>>
>>>>  From testing various SIP clients with SIMPLE support, I think the IETF is far away from this goal - the "interoperable" part.
>>>>
>>>> I see a mixture of Proprietary, OMA and IETF documents being used in different ways for address books, presence and messaging. It is really hard to get a simple red/green indication  to work across clients using XCAP and PUBLISH/SUBSCRIBE/NOTIFY. Sharing buddy lists across clients is just not working, without loosing a lot of data or creating crashes.
>>>>
>>>> I've tested BRIA, Zoiper, Blink, Jitsi on a Kamailio server. The results scare me. Due to lack of a reference profile (or the existence too many non-compatible reference profiles)  it seems like developers have tried to pick parts from various sources to create a solution that works for networks with their own clients. Most of them follow some sort of standard, but the result does not create any acceptable level of interoperability.
>>>>
>>>> I think a base requirement is
>>>>
>>>> * To be able to use the same buddy list with different clients without loosing data
>>>> * To be able to add friends to the buddy list and see their presence states
>>>>
>>>> I tihnk it's time for the WG to focus on interoperability tests, document these short-comings and find ways to solve them. Otherwise we will end up with a standard that only works in single-vendor installations, which is not what I call "an interoperable standard" as is the goal in the very first paragraph of the charter. If possible invite the OMA to work with us and merge their documents with the IETF standards.
>>>>
>>>> SIPit 30 in February could be a good place for a meeting and practical test, dicussion about what's missing and possibly ways forwards. Reports from such an event could be brought back to the IETF and be the basis for work to reach some level of interoperability.
>>>>
>>>> Right now any multi-vendor solution based on SIMPLE is just not possible to sell, because it won't work. This means that customers that want open standards to be a guarantee of some level of vendor-independence won't get what they want.
>>>>
>>>> We seriously need to fix this and get some running, interoperable code. Or just conclude with the statement "SIMPLE failed, use xmpp instead".
>>>>
>>>> /O
>>>> _______________________________________________
>>>> Simple mailing list
>>>> [email protected]
>>>> https://www.ietf.org/mailman/listinfo/simple
>>>>
>>>
>>> _______________________________________________
>>> Simple mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/simple
>
> _______________________________________________
> Simple mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/simple
>