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

Iñaki Baz Castillo ibc at aliax.net
Thu Oct 21 16:15:22 CEST 2010


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

Then blocking a user not to view your avatar is not possible. Sending
the image into a SIP message (as XMPP mainly does) is better IMHO.


> 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 have a non very powerful phone, why should you send me advanced
presence information if my device cannot render it? will you send a
photo to my Linksys ATA? why should I receive information I'm not
capable of rendering? why should I receive information I haven't
asked?
As I said before, XMPP solves this problem with publish-subscribe
mechanism when coming to advanded presence (not just "online - I'm at
home").

Subscriptions (including filters in the subscription) can help with
this. Sending direct presence doesn't allow it. XMPP confirms this.



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

This is not impossible with centralized logic IMHO.



> But end-to-end freedom of communication must exist. Presence update is a
> communication to the other peer.

Only if such peer has asked you for such information, am I wrong?


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

Yes, but as I said before, how can a watcher get information from you
when you are offline (this is, you cannot send such information from
your device to the watcher)?
Couldn't the watcher get your vcard or your avatar neither your
offline status information? if this feature makes sense (and IMHO it
does as exists in all the IM/presence protocols) how to implement it
without subscription?


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

So then I cannot filter some information to some specific watchers
(i.e: I want a specific watcher not to see my geolocation).


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

There is a lot to discuss about it, even more than the sum of RFC's
about SIMPLE XD


Regards.


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



More information about the sr-users mailing list