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

On Oct 18, 2012, at 11:04 AM, Iñaki Baz Castillo <[email protected]> wrote:

>> Can you clarify what you mean by "from scratch"? Do you suggest we should start SIMPLE over from a blank slate?
> 
> Basically yes. I know SIMPLE specs very well and honestly I don't like
> them at all. Just for mentioning some points:
> 
> - The Presence Data Model is too complex. In the world we have users
> and the user has devices. I don't understand what a "service" is.
> Theorically two devices managed by same AoR should not publish a
> different <person> since <person> must be unique, how to do that? And
> in case of various devices, how can the watcher match each <tuple> to
> each device? it would make sense to use GRUU here (XMPP uses
> "resources"), but we have nothing about that.

The data model could be simplified, or perhaps we could do a BCP clarifying things and recommending particular usages.

> 
> - If I subscribe using RLS I will get a very big first NOTIFY
> containing all the presence bodies of all my watched contacts, so SIP
> TCP is required. If so, why must I implement HTTP/XCAP for storing my
> "buddy list"? Which other IM/presence protocol implements both the
> protocol itself and HTTP for related stuff? This involves two servers,
> two TLS certificates, two authentication points, double lines of
> code... We can transfer a ISO image using MSRP but we need HTTP for
> storing a simple buddy list and permissions policy?

I'm not convinced by the "just implement one protocol" argument. I'm hard pressed to imagine a useful client that only implements SIP, and I'd be surprised if a mature client with high market penetration doesn't eventually need to implement HTTP _somewhere_ for _something_. 

> 
> - As Adrian pointed out, a SIMPLE client needs to mantain ~18 SIP/HTTP
> "dialogs" (subscriptions to XCAP-diff, winfo, presence...).
> Subscriptions means "dialogs" and dialogs are really a bad idea in the
> new Internet ecosystem: the mobile devices (those that dynamically
> change their IP or gets unreachable for a while). Mobiles apps want to
> use the PUSH mechanism, something unfeasible with SIMPLE
> subscriptions. IMHO a stateless mechanism based on PULL and PUSH would
> be the key. Nothing to reuse from SIMPLE here.

Are these issues specific to SIMPLE, or an artifact of SIMPLE using SIP in the first place? Are 18 dialogs that much worse than 1, if it forces the client to nail up a TCP connection and/or outbound proxy binding? (i.e. is this a protocol problem, or a network architecture problem?)

What mechanism do you have in mind for "the PUSH mechanism"?

> 
> - Managing a buddy list or presence authorizations should be simple
> and easy. Instead we have a generic protocol (XCAP) for performing
> partial modifications in remote XML documents, and when a modification
> takes place the presence server and all the watchers (same AoR) must
> re-evaluate all the XML documents along their relationship with all
> the other XML documents, otherwise it's near imposible to detect what
> such an incremental XML change involves, and this means high CPU usage
> in both servers and clients.
> 
> - Blocking/allowing presence authorization for a buddy should be an
> atomic/boolean operation (like in XMPP). But in SIMPLE/XCAP we have
> two options:
> 
>  1) Upload the new full XML documents with all the buddies (so let
> the server and others to full re-evaluate it again).
>  2) Two operations: delete a buddy from some "list", and then include
> it in some other "list" (partial DELETE/PUT), so double notification.
> 
> - In XMPP blocking/allowing/subscribing/desubscribing to a buddy is an
> atomic operation: the user sends the full XML definition of the buddy
> to the server, with all the buddy attributes. The server notifies the
> buddy new properties to other resources of the same account. In SIMPLE
> anyone can do whatever XCAP allows (which is really too much). Does
> XMPP need so powerful control over the "XML files"? Sure not.
> 
> - XCAP is like Xpath 1.0 but is not compatible with it since it adds a
> "cool" feature to save 10-20 bytes in a HTTP request (the "default
> document namespace") so developers cannot use the widely extended
> libxml library (which includes Xpath 1.0). Not good.
> 
> - XML diff is too complex for expecting that anyone can properly use
> it. If I want to code a JavaScript web application for watching SIP
> presence, how will I implement XML diff in JavaScript? It's a no
> sense, and taking a look to other protocols (i.e. XMPP) they do NOT
> need it (and still they are really scalable in the whole Internet).
> 

'm open to the argument that XCAP is too complex. But that's only one piece of the bigger puzzle.

> 
> So IMHO, after years of playing with SIMPLE, it's clear for me that
> there is no way for SIMPLE to become developer-friendly and thus, a
> new SIP presence proposal from scratch makes lot of sense IMHO.

I'm extremely doubtful we could get traction with a completely new SIP based PIM. I also strongly doubt the IESG would approve work on such a thing. If SIMPLE is completely unfit for purpose, then we'd be better focusing on using XMPP with SIP.