On 10/21/10 7:34 PM, Iñaki Baz Castillo wrote:
2010/10/21 Daniel-Constantin Mierla<mico...@gmail.com>:
In both XMPP and MSN the avatar and vcard are retrieved by a watcher
from the server if the watched gives the watcher permissions, so the
server *does* interpret the permissions rules in behalf of the user.
How to achieve this logic in a non-centralized architecture? I cannot
imagine it.
Maybe is a misunderstanding here. Hope you haven't understood that there
will no server involved and is kind of peer-to-peer network like skype.
But everything in the server is just routing to resources. Authorizations
rules exist and we apply them for many years for voice calls. But we don't
authorize typically the content (e.g., not allowed to speak Spanish on a
call).
Daniel, after re-reading your mails I strongly think we agree more
than we think ;)
perhaps was more a misinterpretation of some of the comments send around
from different points :-) .
I also *hate* the mechanism in which the server MUST inspect the
document content in order to filter it and notify the watched with a
filtered version. This is a pain, and that is the base of SIMPLE in
which multiple presentities must be merged in the server, in which the
server must inspect the XML nodes of the resulting presentity and
filter it for each watched based on privady rules and deliver it via
NOTIFY. I hate it.
So what I have in mind is a different approach. Imagine this case:
- Alice has two active resources, both of them publishing basic
presence status ("online"/"busy".... "I'm at home" / "I'm at work
very unhappy"). These PUBLISH have "Event: presence+status".
- There is also a geolocation presence agent which in some way get's
the registration location of both resources of Alice and generates two
PUBLISH "Event: presence+geolocation" (one in behalf of echa
resource).
- The server DOESN'T merge these 4 presentities. Instead it stores in
a database each one with fields "event", "content".
- Alice has a buddylist in the server in which there is a contact Bob
for which Alice allows showing him "presence+status" information, but
not "presence+geolocation".
- Bob susbcribes to Alice's presence by *indicating* in the SUBSCRIBE
body he is interested in "presence+status" and "presence+geolocation"
events (as Bob's device doesn't understand/implement other presence
information and couldn't render it).
- The presence server accepts the subscription (as it checks in
Alice's buddylist that Bob is authorized for "Event: presence").
- The presence server also inspects in Alice's buddylist that Bob is
just allowed for "presence+status".
- So the presence server sends Bob just two NOTIFY's (never merging
documents), the first one containing the presecen+status of Alice's
resource-1 and the second one containing the presecen+status of
Alice's resource-2.
Advantages of this model:
- The server NEVER NEVER NEVER inspects the content of a PUBLISH.
- The subscriber (Bob) can tell the server which events he is
interested in (not to receive information it cannot render).
- The watched (Alice) can decide which events each watcher is allowed to.
Another subject is the permanent information (i.e. "vCard") which is
stored in the server. How the client (Alice) stores its vCard/avatar
into the server is out of the scope of this brief description, but for
sure we don't want XCAP. IMHO a new SIP method is required (in my idea
the new method STORE makes sense).
- Alice set privacy attributes for her buddy Bob, so it allows him to
watch these information:
- presence+status
- vcard
This information is stored within Bob buddy in Alice's buddylist (in
the server).
- Alice uses STORE method to store a vcard in the server.
- Now Bob subscribes to "Event: vcard" of Alice.
- The server inspects Alice's buddylist and finds that Bob is allowed
for retrieving the vcard of Alice.
- The server then sends Bob a NOTIFY containing the vCard of Alice.
- Alice's gets online and upload a new version of her vCard (or
changes it offline via web...).
- The server then sends Bob a new NOTIFY with the new vCard.
Does this fit better your concept of presence? :)
Maybe we are poisoned by the current specs and still are stuck in some
concepts here.
There are two aspects:
1) real time communication routing - voice, im, presence states
2) offline resource routing - vcard, predefined-content documents
1) can always have a correspondent in 2) while some things in 2) might
not be in 1).
Normally every user wants to do 1), but if the peer is offline, then
server can have the capability to re-route to corresponding resource in
2) (like now with redirect to voicemail).
The things that are in 2) without a correspondent in 1) are on-demand
resources. Do I need to get a notification that you changed your vcard
immediately you do it? I would say no, I need to do it when I need to
email, send a snail mail, etc. which may happen when you are offline so
the server storage comes in the picture and sends it to me upon my
request and your authorization rules for that resource. That can be done
very easy in the reply body, without a need to create a dialog state in
the server and send notifies.
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
