Re: Should SIMPLE be rechartered, replaced, closed, or what?

On Oct 18, 2012, at 8:23 PM, Olle E. Johansson wrote:

> As I haven't even tried to implement a full SIMPLE client I can't argue with developers, just learn from what you write. The more the better. 
> 
> I don't think we should throw away everything going down to the core SIP protocol and trying to replace SUBSCRIBE/NOTIFY and PUBLISH. There are ways to filter notifications and significant work. 
> 

I also lean towards not replacing those, but I may not be seeing the trees because of the forest (I'm right now working on fixing a RLS implementation).

> So far, I've seen a few issues brought up:
> 
> * PIDF status *may* bee too complex, especially in combination with XCAP and the operations of XCAP (non-atomic, external references with full urls etc)

Those are 2 different issues:

1- Ambiguous data in a PIDF: both per-person and per-device presence can be expressed, which ends un in a weird mixture where only heuristics can be used to try to draw a conclusion.
2- Use of different documents: this is what kills atomicity.

> * Buddy lists are too complex and unmanageable

They don't currently exist in SIMPLE. OMA added the oma_buddylist on top of resource-lists, but IMHO the foundation is not right, we need something new.

> * The IETF documents leave gaps in Buddy List management
> 
> Apart from that, there are many mails about the total complexity with 18 subscriptions, multiple XCAP formats intermingled with multiple sources of application usages from both organizations and developers. Seems like most of us that have mailed so far agree that this is too complex.
> 
> To take a naive approach to this, can we
> 
> * Dramatically reduce the number of subscriptions by implementing
>  - one for synchronization of informaiton between one user's clients - presence-ua-config
>  - one for presence updates from my buddy list - presence-updates
> 
> * Reduce the number of documents, possibly
>  - one simple-buddy-list 
>  - one auth-rules document
> 

Hum, yes and no :-) The actual buddylist could contain the policy for each buddy. There would be the need for a different entity, which is not a buddy, but holds policy information, for example when you would block someone but don't want to see him in your buddylist.

> * FInd a way to separate device states from user states and rules on how to aggregate this
>   - "This phone is busy" vs "OEJ's calendar says he is on a wine-tasting in France, so he's obviously busy"
> 

Yes, we need this.

> The icon could be part of my own entry in my own buddy list, visible for all buddies
> 

This doesn't scale very well. I'd rather use a different means of storage for the icon and then have a mechanism to fetch it. Mobile devices may not want to download all icons at all times, for example. Also, documents can get really big if you start embedding icons, been there :-)

> The notifications from presence-ua-config would include changes in buddy lists, auth requests and much more. An aggregation - and simplification - of a lot of the stuff that the years of work done in SIMPLE, XMPP and OMA. If you shut your eyes for the pile of XML schemas and XCAP auids, there is a lot of ideas and good functionality for applications hidden in there. I see no point in throwing it away, just trying to create something simple that is a concentrated, stream-lined and focused application. And we should not forget that it has to be extensible in some way too, so we don't end up with a new subscription, new XML schema, new URN and new AUID for every extension. Then we're going to end up quickly in the very same situation we are in now.

+1. This ua-config could be a base package and extensions could be implemented as sub packages (like presence and presence.winfo). They would surely need to provide a schema for the extension format, but that's ok. I need to think about new AUIDs more, but we should at least provide a working model based on 1 or 2 AUIDs.

> 
> Let's try to focus on attacking the solution from this end and see if we can agree. I think we're done complaining over the existing solution for a while. Note that I'm not saying that we have to use XML or XCAP. Let's just talk "documents" and "subscriptions" and see where we end up.

+1.


Regards,

--
Saúl Ibarra Corretgé
AG Projects