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

Hi,

On Oct 16, 2012, at 4:49 PM, Olle E. Johansson wrote:

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

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