[SR-Users] [OT] Fwd: [dispatch] proposed SIXPAC charter

[Iñaki Baz Castillo]

2010/10/21 Daniel-Constantin Mierla <miconda at 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.


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