2010/10/21 Daniel-Constantin Mierla miconda@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 ;)
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.