2010/4/12 Bogdan-Andrei Iancu <[email protected]>: > Hi Iñaki, > Hi Bogdan, replies inline:
> well, right now there is a kind of pressure coming from the providers > level - providers do want to offer presence with SIP ; also presence > comes in a natural way of doing dome enhanced services (more complex > than simple BLA, BLF, etc). -- please note I said presence, not SIMPLE. > > So, a natural demand for it there, and we, as developers, are looking > for solutions to make it happened. and for implementations you need some > specs. > > Now, if you see the SIMPLE specs are wrong - it might be - I'm not > directly involved in the depth of SIMPLE to be able to say yes or no. > This "aggregation" problem is the first we encountered during some > projects - not only once, but several times, different contexts ; and > I'm trying with Anca to see how to get over it. > > So, overall, there are 2 options (according to your perception): > - use SIMPLE and get a poor result (a crippled presence) SIMPLE is not just poor, but also inneficient at server level (a single change in a XCAP document requires the presence server to reload all the permissions for that user). Even in case of solving it, the result owuld be poor, sure. > - come up with a new spec Yes. I'm doing a presence spec for SIP from scratch, by learning about XMPP and so. I've already defined the concept of "resources", "different status priority", "global status". And best of all, there is no HTTP/XCAP, but just SIP. Well, I have to spent lot of hours yet :) > - do feedback to IETF to make SIMPLE simpler and working IMHO this is not possible at this point, as IETF already chose XCAP for buddies and permissions management (along with others). IMHO there is no way to improve/fix current SIMPLE specs. > For SIMPLE, looking at the basics (exchanging the info), the aggregation > is the biggest issue I see. Whatever is on top (RLS, XCAP, buddy lists, > etc) is another story and it might need a second look and thought. OMA tries to define an aggregation mechanism (like rules). I've read it, and it's a pain, a dirty hack over IETF *incomplete* specifications. Sorry for sounding so rude :) -- Iñaki Baz Castillo <[email protected]> _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
