Subject: Re: [Simple] Controversial: Have SIMPLE reached is goal? Or is it an IETF failure?

From: Adrian Georgescu <[email-masked]>
Date: Mon, 15 Oct 2012 17:46:14 +0200

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-masked]
> > Date: Mon, 15 Oct 2012 08:50:32 +0200
> > CC: [email-masked]; [email-masked]
> > To: [email-masked]
> > 
> > 
> > 14 okt 2012 kl. 23:48 skrev "Brian McColgan " <[email-masked]>:
> > 
> > > 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

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 16 Oct 2012 16:49:33 +0200

Any other thoughts in regards to SIMPLE?

Is it a failure or not?

Do we have a chance of fixing this within the IETF?

Is anyone interested in fixing it so we actually reach the WG goal of interoperability?

/O

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Wed, 17 Oct 2012 10:26:01 +0200

Hi,

> Is anyone interested in fixing it so we actually reach the WG goal of interoperability?

IMHO there are 2 key factors to solve this: a data model for presence, and a data model for an addressbook.

A data model for presence. 

Currently PIDF allows us to express presence segmented into tuples and then there is the person element. The tuple elements only have basic status, whereas person can be extended with RPID activities such as 'busy'. The fact that presence can be segmented into tuples yet there is a global state which affects all makes interpreting documents really complicated. Not to mention the fact that if several devices want to modify the person element they'll need to agree on the ID for that element or they'll just be overriding each other.

I see 2 different possible presence models: one where the state belongs to the physical person, and there is a single presence state across all devices (like Skype, for example) and one where the presence belongs exclusively to the device and recipients of multiple presence states will examine them and take action (like XMPP).

Since we now have means to do per-device things thanks to GRUU, I lean towards the second approach. Of course this makes interoperability with XMPP pretty straightforward.

A data model for an addressbook.

The current specs where defined with elements called 'resources', which have a single URI, yet any addressbook allows us to specify multiple numbers for the same person, so modeling an addressbook like application is not straightforward.

On top of that, if I want to do the simple operation of adding a buddy with both ways presence, I need to modify 3 XCAP documents: pres-rules, resource-lists and rls-services. There is no way to do this in an atomic way, which lead to complex code.

OMA specs do help here, by using external references both from pres-rules and rls-services to resource-lists adding a buddy implies modifying a single document, which is atomic.

I'm probably forgetting a ton of details, but this 2 big things are the first that come to mind. It would be great if there is interest in trying to find a way around these and making a working model, count me in for that :-)

Regards,

--
Saúl Ibarra Corretgé
AG Projects