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

2012/10/14 Olle E. Johansson <[email protected]>:
> I've tested Zoiper, Bria, Jitsi and Blink (for Mac).
>
> On the server side you have Kamailio (which I used), OpenSIPS as well as a separate server for Xcap called OpenXCAP.

We should assume that 99% of SIMPLE implementations in the "open
internet" are buggy, but IMHO it makes sense taking into account the
complexity of the so many RFC's required for implementing a not
complete presence/permissions/buddylist platform. The only good
implementation (AFAIK) is Blink and its related server stuff (after
YEARS of work) and, finally, it can only interoperate *well* with
other Blink instances.

So we have really complex specs that use partial SIP subscription to
partial XML documents distributed in HTTP/XCAP servers, with XML
resource-list documents that can just store "display name" and "uri",
and include *absolute* references (including HTTP schema, domain,
path...) to other XML nodes within the *same* document (but they
usually point to other XML documents in the same or *any* other
HTTP/XCAP server). This is just annoying, nobody in the Internet world
can deploy something like this and make it to properly work, but in
the other side we have tons of XMPP clients and servers which
interoperate very well when sharing buddy-list and permissions.

What was the purpose of IETF in SIMPLE presence stuff? The specs are
so ambiguous and complex that nobody knows what exactly to implement.
We need a "Presence Profile" for the OPEN Internet ("implement exactly
this and this and this in this exact way"), and not just for telcos
private networks (OMA/RCS...). Let's be honest: the only environments
in which SIMPLE presence stuff can "work" is within private networks
or walled wardens, with their own clients and servers managing XML
documents that will never be readable/writable by end users or open
SIP clients.


Then we have OMA that adds a layer on top of IETF SIMPLE specs (so we
have stuf like "my-oma-PoC-users"...), and we also have RCS which is
an extra layer on top of OMA specs... (¿?¿?¿?¿?). XMPP presence is
defined in a single RFC and implementors make it to work without
problems (at least basic presence and buddylist/authorization rules
management).



Why is SIMPLE-presence so difficult? Some keys:

- A "presence" NOTIFY can contain multiple tuples for the same AoR,
but there is no way to correlate them between different instances of
the same AoR (GRUU??).

- A PIDF body can contain exotic information (state basic: "close",
contact: "mailto:[email protected]"). It is just imposssible to
render it in client side.

- The pres-rules document (according to OMA specs) contains HTTP
absolute links to the resource-list document, but the resource-list
document also contains HTTP links to XML nodes within the same
document. This is really annoying, what would happen if the service
provider has to change its domain or upgrades from HTTP to HTTPS? all
the XCAP documents would get invalidated! Why a document must point to
other document and that document to others? why does a URI list
contain a link to other lists with links to others? it's really HARD
to inspect both the pres-rules and resource-list documents and decide
how to draw my buddylist and who is blocked and who is not. That
should be a single task.


The buddylist should be a SINGLE "document" in which each contact has
attributes (i.e. presence watching allowed or not, visible in the
buddy list or not, groups, tags, vcard info, and so on). A single
"document" hopefully managed via SIP (we have TCP so why to add HTTP
to the SIP ecosystem?). I don't want to subscribe to a XCAP server,
receive notifications with *partial* XML diffs and/or retrieve the XML
document new fragment via HTTP/XCAP. Too many points of failure and
inconsistency.

IMHO the keywords that define all the SIMPLE presence stuff are
"weak", "fragile" and "complex", so complex. The most basic operation
(so easy in any other IM/presence protocol) becomes the hardest task
in SIP (see the lines of code in Blink for the presence stuff and the
years it took to make it to work). Why so hard? take a look to RCS
specs, they provide NOTHING that XMPP does not provide since years,
why to build a so complex spec and infrastructure that provides less
than MSN 10 years ago but in a much more complex and expensive way?


So, is this a failure of the IETF? No idea, what I really don't know
is *what* the purpose of the IETF was when it designed all those
specifications that don't explain how to build a single addressbook to
be shared by different SIP devices. It seems like SIMPLE presence
RFC's are just a skeleton in which telcos or vendors can add their
custom extra layers for their private networks, and it seems that
nobody cared about the open Internet when writting SIMPLE presence
specs. What should I implement in a generic open source SIP client for
interoperating with others and sharing a full-featured addressbook?
There is no response for this question yet.


NOTE: I spent more than a year implementing all the RFCs/OMA specs in
my own XCAP/XDMS server and SIMPLE/XCAP clients. After having a
working and strict implementation of a XCAP/XDMS server and a client
capable of rendering the info from both the pres-rules and
resource-lists all together, I decided to drop all my effort. Too many
lines of code and wasted weeks for implementing nothing cool or new.
IMHO life should be easier.


Regards.



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