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

Daniel-Constantin Mierla miconda at gmail.com
Thu Oct 21 22:21:26 CEST 2010



On 10/21/10 7:34 PM, Iñaki Baz Castillo wrote:
> 2010/10/21 Daniel-Constantin Mierla<miconda at 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




More information about the sr-users mailing list