[OpenSIPS-Users] SIP Presence Aggregation Issue

[Iñaki Baz Castillo]

2010/4/1 Schumann Sebastian <Sebastian.Schumann at t-com.sk>:
> The problem is that for e.g., the case in RFC 3863 (4.3.1) fixed states set (e.g., permanent mail set with XCAP pidf-manipulation) could have a higher priority than automatic states. The example shows mail over IM contact (as IM device is busy). The correct derivation is that the user wants to be contacted by mail preferably and so far correct. However, I would consider it not wanted by the user to show him available in the buddy list (because usually a double click would start IM then and not mail). But this would be wrong acc. priorities...

Yes, this is due to the obsession of SIMPLE authors in order to make
SIMPLE the "world dominator presence system". They try to convince us
that if a user is available via mail (who is not??) then my UA should
display him as "online", WTF??
SIMPLE authors forget that the SIP devices speak SIP, they are not
mail clients, and if I see a contact "online" I expect to be ablo to
chat/call him rather than send a mail.

But finally SIMPLE is designed in this terrible way, making it
unuseful for most of the common cases in which any other presence
protocol just works properly.

I just can say that I've read all the SIMPLE/XCP RFC's and drafts,
also the OMA specifications built on top of SIMPLE/XCAP, and also the
RCS specifications built on top of OMA's ones. Terrible!
Finally RCS provides an "advanced" presence system for IMS world in
which a phone has a buddy list (just uri=phone and display-name, no
more data per user) and can add and delete users, NO MORE. And in
order to achieve such limited presence system (the 25% of what MSN
provided 8 years ago) you must implement something like this:
  http://oversip.net/public/SIP_SIMPLE_OMA.jpeg
(you can reduce the complexity of the architecture, but the features
would remain so limited...)

So IMHO it's time to drop SIMPLE forever. IETF-SIMPLE has failed,
period, there is no need to continue adding more and more
specifications on top of a bad designed framework.

-- 
Iñaki Baz Castillo
<ibc at aliax.net>