21 Oct
2010
21 Oct
'10
1:34 p.m.
2010/10/21 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
Daniel, after re-reading your mails I strongly think we agree more
than we think ;)
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? :)
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
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).