On 10/21/10 4:15 PM, Iñaki Baz Castillo wrote:
2010/10/21 Daniel-Constantin Mierla<mico...@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.
If you mean that by current specs, could be. I was referring to what
seems better for me. Any kind of end-to-end content exchange should be
processed by end device rules.
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?
I send to you because you asked. If you don't subscribe to that
resource, I don't send it.
Where did you get the I idea that everything is sent to everybody?
On the other hand, if your phone subscribes to my shoes-size-changes, my
phone can notify you using 2d barcode payload, but the server does not
know how to mix it, would you feel better paying NNNN bucks for the
device and the provider tells you it is not supported?
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?
I have also many questions why you have such questions now. Nobody is
sending anything if not 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").
Again, this is not presence specific, imo. If I call you and you are not
registered, I get to your voicemail, or to your mobile, or ... If I am
not online and you ask for my presence, the request can be replied with
some default/predefined states.
When I become online, I have my list of buddies and take care to tell them.
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.
Centralize logic should be the routing, not the content of
communication. That can come extra, as additional service, if I want to
opt in for it.
For me, a man-in-the-middle like presence server trying to understand
everything would be like an English voice analyzer on server for each
call dropping everything that couldn't be understood as good English. So
if you want to talk with your parents and the provider does not support
Spanish, you have two options:
- screw the provider
- tell your parents by snail mail they have to use english when in a
call with you
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?
There was not at all a discard of subscriptions. That must exist, the
discussion was who and how should handle subscriptions.
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)?
Do you get my ring-back tone from my phone when you call and I am
offline? You get the voicebox service which I set for such cases. For
presence you may get as well a pre-defined state or document.
Like with voicemail, I can record a message and say "Hi, you called XYZ,
leave the message..." or simple "Leave the message after...". Same I can
publish my vcard for such cases or not, combined with black-white lists,
the privacy can be controlled in the same way for all SIP based services.
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).
If your client is able to send such details, then it has the list with
who is allowed and disallowed.
As I said, this list can be stored on server, so you can retrieved. But
I do not see the reason why the server must know what my client can
publish and to mix/process it.
Rooting the debate:
- subscription mechanism is good, the bad part now is who interprets it
- storing various resources, being it your voicemail message, redirect
number, white-black lists, is an useful service
- all signaling optimization attempts were big failures (see sip
compression)
- today, more than ever, trends are for smart end devices
- to be successful, a new technology has to be _simple_ : easy to
implement and use, without complex dependency constraints to deploy
Failing again to see that by time an "optimization" spec is implemented,
the bandwidth and processing power are far ahead, may be a safe bet for
disaster.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
