2010/10/21 Daniel-Constantin Mierla miconda@gmail.com:
Hi, I don't agree. SIP end-to-end presence fails when coming to privacy area as the watcher doens't receive the information from a server, but from the watched user itself (so the watcher knows if it's "online" or not). I've tryed end-to-end SIP presence and IMHO is just a toy.
this kind of privacy is affecting the calls as well, for example. I can send you a call or other SIP request to discover you are online/offline. So this is another service that should be applied globally: black-white lists.
Having a mechanism just for presence is another bad design.
Good point. But the fail about this point is in SIMPLE specs.
I'm planning a spec for privacy rules in which a user stores in a server privacy attributes for each contact in his buddylist. These privacy attributes include "presence", "dialog", "voice", "im" along with filtering rules (for example, I want to show my presence status online/offline to a watcher, but I don't want to show him my geolocation data).
So when an INVITE or SUBSCRIBE arrives to the proxy/server, the privacy rules for this contact can be inspected so the presence/dialog SUBSCRIBE or the INVITE (voice, video, MSRP) can be allowed, rejected or "polite" blocked (480 User Not Online).
Also, about XMPP and "ent-to-end" presence:
"distributing states" is done by sending<presence> stanzas. XMPP basic presence (online, offline and text note) works in this way. This is, a XMPP client gets online and sends<presence> stanza to all its non-blocked contacts to inform about its presence status. However, other presence features in XMPP as the avatar, advanced presence (like the music you are listening now), work with publish-subscribe mechanism. This mechanism is much more scalable.
Please read this short thread I open in XMPP-IETF about it: http://www.ietf.org/mail-archive/web/xmpp/current/msg01703.html
This is: publish-subscribe mechanism has also being adopted by XMPP. So IMHO this mechanism is the most suitable also for SIP, but it must be improved (the specs and features).
With a model where client and server must develop in parallel you have always the chicken-egg problem.
But retrieving the contact avatar works in XMPP, doesn't it? :)
While I said that some interaction between endpoint and core network has to be done (e.g., centralized rooster, hosting avatars, etc), it must be pretty much content agnostic. When the core network becomes an active player in the final content delivery of what I send, then innovation is slowed down considerably.
Imagine you have 30 contacts. Having 30 presence subscriptions for each client is not very cool. This is solved with RLS subscription. The concept is good but the final specification is a pain as it requires a painful XCAP document pointintg to a painful list in a painful resource-list document, along with exotic constrains (the client must create a SIP URI unique in the server).
Now also imagine "distribute presence". You have 30 contacts. When you get online you must send 30 presentities for all your allowed contacts. Not very cool IMHO.
And worse: Not all the information a watcher wants to retrieves depends on the watched user itself. The avatar, the user profile (a vCard) is retrieved from the server (this is true in XMPP, MSN, Skype....), so "distribute presence" cannot work here. So, should we implement two mechanims for retrieving buddy's information (one for realtime presence status and other for permanent information stored in the server? I don't think this is a good design.
Regards.