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

Hi Brian,

I keep this on the mailing list, hope you do not mind.

On Oct 17, 2012, at 2:50 PM, Brian McColgan wrote:

> Hi Adrian,
> 
> I looked at your site for the API, and had some comments.
> 
> My concern is that the API you developed is a series of wrappers around a lot of complexity in SIP/SIMPLE, and xcap, etc.  That explains the 15kloc of code!  

Indeed. In XMPP, this so called wrapper is defined well enough in the core specification that can be interpreted in the same way by any client or server implementor. SIMPLE lacks this. 

> Not sure why folks are talking about an addr-book and SIP/SIMPLE (or an rls for that matter) in the same breath.  They are NOT the same thing.  If you want to understand why, look at OMA Converged Address Book 1.1 for the reasons why that is the case.

From the perspective of both the UI developer and the end-user, they are 100% the same thing. From a standards perspective they are not, and here is the cause of the problem.

> If we go 'way back' to the days when Rosenberg was involved in SIP/SIMPLE and xcap, the idea was to have an ability to manipulate a (~20 member or smaller) buddy list.  Most people now have networks (contact-lists of 100 people or more).  And the 'social meshing' expands our potential connections well beyond this.  One reason that the watcher scale issue would be exacerbated sooner than later (as pointed out by Houri, et al in his inter-domain scaling analysis on PRS).
> 
> Xcap and indeed (XDM) have gone way beyond that now.  However, the complexity remains.
> 
> What I don't see in the API is a model or approach - based on typical consumption patterns. 
> 
> Presence Access Layer made several assumptions:
>  - a presence aware service knows what indicators they need to fulfill functions (the rest is irrelevant)
>  - each watcher has (per SIMPLE) a view of presence; based on the view the presentity 'permits' the user to see (via presence rules)
>  - that view X the presence aware service = presence context (contextually oriented presence) 
> 
> That model simplifies the interface and strips out the details from a client.  

This model does not simplify but is the very cause of complexity, is the root cause of ending up building clients that do not interoperate with each other under the same account.

> Interop is bandied about a lot, but what isn't clear is whether we are talking 'on the wire interop' or 'coded interop' (I.e. I am coding to an interface that is identical whether I am using an underlying X or Y).  Fill in the blanks on X and Y (X can be XMPP, Y the other flavor).  

By interoperability, I  mean that developer A can develop a SIMPLE client that can be interchanged with a SIMPLE device developed by B. The address book and presence rules should work with both clients same as today I can use several XMPP clients from different vendors  and all work fine with the same contacts list. For example I have an Android mobile device from one vendor and a MacOSX client from another vendor and on XMPP this works. I cannot use them both for my account with SIMPLE as they will both write different data according to their interpretation of SIMPLE standards. The server implementor will also have yet another way of interpreting the data. This triangle cannot be reproduced with any combination of SIMPLE implementations but it can with XMPP.

> I don't view a presence conveyance as an addr-book.  You need a dedicated API - OMA was developing one on Converged Address Book 1.0.  You know the saying - to a carpenter everything is a 'hammer and nail problem'!

I studied OMA years ago and dropped it, as several assumptions made have nothing to do with real world and how the Internet works, is a interpretation that (could have) served closed silo-style Telco infrastructures, and not end-points from public Internet.  Not to mention the complexity of OMA on top of an already complex foundation.

> If that doesn't suit - then to me a RESTful approach may be the way to go.

What do you have in mind, can you give an example?

> 
> It seems however IETF is plowing toward an XMPP/SIP-SIMPLE inter-work solution.  Not sure what that will achieve.
> 
> BR/Brian.
> Sent from my BlackBerry device on the Rogers Wireless Network
> 
> -----Original Message-----
> From: Adrian Georgescu <[email protected]>
> Date: Mon, 15 Oct 2012 15:46:14 
> To: <[email protected]>
> Cc: <[email protected]>; <[email protected]>
> Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or is it
> an 	IETF failure?
> 
> 
> 
> 
> On Oct 15, 2012, at 2:57 PM, Brian McColgan wrote:
> 
> 
> My analysis indicates RLMI doesn't scale, but you/AG allude to an interop issue with buddy lists.  Can you be more specific and outline the issue?
> 
> 
> 
> More specific. In SIP SIMPLE client Presence API we defined Group, Contact and Policy classes each of them with add/delete/update methods and eight notifications in total to manage the address book. Subscribing to Presence for a contact and granting access to our own presence information are booleans that can be set for each contact.  To achieve this simplicity, we had to write about 15K lines of code in a high level programing language.
> 
> 
> We do not have an IETF definition of such address book API, that any programmer would understand, what we have instead are a number of XML payloads, several event packages and xcap applications. Glueing all of them is  up to the developers and they end up in different places as you have heard already from several developers. Secondly, without being able to control the behavior of the server side, there is little chance a generic SIMPLE client would work with any SIMPLE server as the assumption are different and the incapability of the server to support same features used by the client will render the client useless. We could only do this because we were able to develop at the same time both the presence client and presence agent side (OpenSIPS and OpenXCAP). 
> 
> 
> XMPP has this approach where and both server and clients can implement the same addressbook api without running into any interoperability issues.
> 
> 
> Adrian
> 
> 
> 
> 
> 
> 
> In IMS, they are using pre-defined (i.e. Well known) buddy lists - e.g. "rcs" for the list of RCS-capable users. But I don't think this is what you are referring to.
> 
> BR/Brian.
> 
>>  Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or is it an IETF failure?
>>  From: [email protected] <mailto:[email protected]> 
>>  Date: Mon, 15 Oct 2012 08:50:32 +0200
>>  CC: [email protected] <mailto:[email protected]> ; [email protected] <mailto:[email protected]> 
>>  To: [email protected] <mailto:[email protected]> 
>>  
>>  
>>  14 okt 2012 kl. 23:48 skrev "Brian McColgan " <[email protected] <mailto:[email protected]> >:
>>  
>>  > Good luck with that Adrian. As I said 'IETF' doesn't get it.
>>  
>>  Which takes us back to my original issue - can we get IETF to fix SIMPLE?
>>  
>>  /O
>