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

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. 

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)
* Buddy lists are too complex and unmanageable
* 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

* 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"

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

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.

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.

/O