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

[Daniel-Constantin Mierla]

On 10/21/10 12:20 PM, Iñaki Baz Castillo wrote:
> 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.

The fail is the SIP steering group, which divided to many subgroups 
which don't actually interact one with another. SIMPLE group looks as 
SIP as being the protocol only for im & p.

With xmpp, at least so far, there is the same group taking care of 
everything.

> 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? :)

Never tried to look deep at it :-) , probably the xmpp client does it ok.

On the other hand, this is just exchange of content, like voice call is. 
I can send to my peer a link to a web resource from where to download, 
or, the clients can start a machine-to-machine session for a file 
transfer. This actions are done upon my agreement on what to allow for 
the other peer, whether I decided to store the rules locally or used a 
remote storage engine like xcap or http server.

I don't like my provider to control everything related to my person. I 
may have different avatars for different persons or locations.

>> 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.

Indeed you reduce some traffic from client to server, but add complexity 
and limitations to the core of the network.

I see a business case for such services, where you get value-added 
features from the core. They exist for voice as well (e.g., transforming 
your voice). If the provider offers it and I want it, I can opt in.

But end-to-end freedom of communication must exist. Presence update is a 
communication to the other peer. Like we do with calls, e.g., permanent 
redirect, there can be static rules for im and presence. But 
requiring/imposing support of some functionality and control from core 
network would not be successful in long term.

> 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.

The server sends 30 notifies, so you save half of the communication. 
There is a feature called parallel forking, we can branch a request in 
as many destinations as we want. That doesn't imply states on server, 
just a list stored in db.

> 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.
I will comment separately later, this is getting big.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
http://www.asipto.com