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

2012/10/18 Ben Campbell <[email protected]>:
>> Hi Ben, some others as me propose a third vision:
>>
>> Trying to revive SIMPLE for open environments (i.e. Internet) is a
>> no-go given the complexity of the existing specs. IMHO technical
>> details about this realitity have been already given during the last
>> mail threads, including the number of lines of high level programming
>> code for building all the SIMPLE specs (more than 15000, and the
>> result is something non interoperable with any other client or server
>> implementation).
>
> How is that different from my second item (above)?

Well, that depends on the ammount of existing specs that would be kept
when designing a new SIP presence proposal. See below please.




>> A new effort 100% from scratch makes more sense for me (just my
>> opinion). Regards.
>
> 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.

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

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

- 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).


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.


Best regards.


-- 
Iñaki Baz Castillo
<[email protected]>
_______________________________________________
Simple mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/simple