Subject: RE: [Simple] Authorization Rules Discussion A: Sphere Interpretation

From: [email-masked]
Date: Thu, 28 Oct 2004 14:58:29 +0300

I also assumed that composition is watcher specific, but something in this discussion has confused me.

If I publish 2 views of my presence, one for co-workers and another for friends.

In sphere "work-mode" : I am "in-a-meeting"

In sphere "play-mode": I am "busy"

I want my co-workers to see my person presence with sphere "work-mode" and my friends to see my person presence with sphere "play-mode".

Now, if the composition takes place before the authorisation policy, then I am no longer able to do that. The composition policy might merge these 2 to be sphere "play-mode".

If I have a rule for a co-worker, Aki, that says only show him presence info with sphere "work-mode", then Aki will not get any presence info of mine as a person. Is the right?

/Hisham

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of ext Jonathan Rosenberg
> Sent: 11.October.2004 23:20
> To: Paul Kyzivat
> Cc: Simple WG
> Subject: Re: [Simple] Authorization Rules Discussion A: Sphere
> Interpretation
> 
> 
> inline.
> 
> Paul Kyzivat wrote:
> 
> > 
> > 
> > Jonathan Rosenberg wrote:
> > 
> >> It may be that, prior to composition, there are multiple 
> sources of 
> >> documents that define my <sphere>. Thats OK. The 
> composition process 
> >> will resolve these conflicts somehow and produce a single <person> 
> >> element with a <sphere>. The conditioning in the presence 
> >> authorization model is based on that <sphere>.
> >>
> >> Now, this does raise another interesting question: the composition 
> >> policy itself may be watcher dependent. As a result, my value of 
> >> <sphere> may well be different for some watchers compared to other 
> >> watchers. Thats ok; the composition policy is applied before the 
> >> authorization policy. When a new subscription arrives for 
> a watcher, 
> >> the composition policy will execute, and then the <sphere> will be 
> >> set, allowing the authorization policies to execute.
> > 
> > 
> > Do we need this much generality? It seems much simpler if 
> we say that 
> > composition is itself independent of subscriber. (I have 
> always assumed 
> > that.)
> 
> I don't think we've ever had this discussion explicitly, so it's good 
> that this has brought it to the surface.
> 
> > 
> > Doing composition independently for each watcher seems to 
> present some 
> > implementation issues. In particular, suppose there are a number of 
> > transient sources of presence data with long expiration 
> intervals. Each 
> > source document needs to be retained until it expires, even 
> if all the 
> > data in it has subsequently be overridden by other sources.
> 
> One could make the same argument about the raw presence 
> document prior 
> to application of privacy filtering; you may need to retain lots of 
> information, even though none of the recipients will ever get 
> any of it.
> 
> I had assumed that composition was watcher specific because 
> every other 
> aspect of policy can be, and it didnt seem like this would be an 
> exception. Seems logical that I would want one set of users 
> to see one 
> view for my presence, and another set to see something entirely 
> different. The canonical example is whether or not I'm in a meeting. 
> Isn't it reasonable to report to my co-workers that I am in a 
> meeting, 
> while I would report to my friends that I am just busy? If 
> composition 
> is the process by which (amongst other things), conflicting 
> status can 
> be removed, doesn't it need to be watcher specific?
> 
> Even if you remove conflicting data, it seems like the act of 
> merging of 
> services might be watcher specific. Might not I want my co-workers to 
> see my cell phone and work phone as separate devices, but my 
> friends to 
> see just one?
> 
> -Jonathan R.
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> Chief Technology Officer                    Parsippany, NJ 07054-2711
> dynamicsoft
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 28 Oct 2004 13:59:22 -0400

Injecting a terminology clarification here:

There may be a subtle difference of understanding here: The 'sphere' 
property in RPID describes the current state of the presentity, not 
groups of watchers. Your labeling sounds much more like what the 'class' 
parameter is supposed to address, namely the ability to group presence 
elements and then assign rules to that class as a whole.

Thus, I can either be in work or in play mode ("sphere"), but not in 
both at the same. It allows me to say something like "If my current 
sphere is work, my personal friends do not get to see my (work-related) 
presence information."

(Two sensors of mine may well disagree on my current sphere, but that's 
a separate issue, having to do with the imperfection of sensors.)

Henning