Subject: RE: [Simple] Presence Authorization Discussion E: Subscriptionpolicyvs. document processing

From: [email-masked]
Date: Mon, 1 Nov 2004 10:08:23 +0200

> -----Original Message-----
> From: ext Boyer, David G (Dave) [mailto:[email-masked]]
> Sent: 29.October.2004 21:47
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); [email-masked];
> [email-masked]
> Cc: [email-masked]; Boyer, David G (Dave)
> Subject: RE: [Simple] Presence Authorization Discussion E:
> Subscriptionpolicyvs. document processing
> 
> 
> Hisham -
> 
> Comments inline.
> 
> Dave
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]]On Behalf
> > Of [email-masked]
> > Sent: Thursday, October 28, 2004 8:41 AM
> > To: [email-masked]; [email-masked]
> > Cc: [email-masked]
> > Subject: RE: [Simple] Presence Authorization Discussion E:
> > Subscriptionpolicyvs. document processing
> > 
> > 
> > I have some concerns about having a watcher dependent policy 
> > as you describe it. Your model suggests that a presentity 
> > needs to assign composition policies to watchers. I do not 
> > like that at all.
> 
> Many users of a presence system insist on being able to control
> who is allowed to view their presence data.   Watcher specific
> filtering is necessary because a given user may want (or may
> be required to) their boss to always see their presence state
> and may only want certain business associates or colleagues
> to only be aware of their office phone 9 - 5 during the work
> week.

I wasn't talking about privacy filtering. I was talking about composition policy.

> > 
> > The other concern that I have with this is that if the first 
> > composition policy is watcher dependent, then it means that a 
> > presence server cannot process presence documents to compose 
> > a raw presence document until a subscription has arrived. It 
> > also requires the presence server to keep a raw presence 
> > document for every subscriber. I prefer one raw presence 
> > document for the privacy rules to work with, but I can be 
> > convinced otherwise if I am presented with compelling reasons :)
> 
> The latest draft of the datamodel says -
> This document is "raw" because it
>    contains more information than any watcher might actually see.
>    Privacy and watcher filtering may eliminate some of the 
> data from the
>    document.
> 
> From this I take it that the first composition policy is watcher
> independent - 

No its not currently.

> the raw presence document contains unfiltered data
> from all presence sources.  The "Create View" computation box
> confuses me a bit though - The raw presence document that is 
> the outcome
> of this step is not filtered on a per watcher basis.  Isn't
> a "view" of a raw presence document specific to a watcher(s)?

That's the issue that we're trying to address. Is it or is it not.

/Hisham

> 
> 
> > 
> > /Hisham
> > 
> > > -----Original Message-----
> > > From: [email-masked] 
> > > [mailto:[email-masked]]On Behalf
> > > Of ext Jonathan Rosenberg
> > > Sent: 11.October.2004 23:24
> > > To: Paul Kyzivat
> > > Cc: Simple WG
> > > Subject: Re: [Simple] Presence Authorization Discussion E: 
> > > Subscription
> > > policyvs. document processing
> > > 
> > > 
> > > inline.
> > > 
> > > Paul Kyzivat wrote:
> > > 
> > > > I mostly agree with this partitioning. However I do have 
> > > one concern. 
> > > > See below.
> > > > 
> > > >     Paul
> > > > 
> > > > Jonathan Rosenberg wrote:
> > > > 
> > > >> This is really the only major open issue that is not 
> > > resolved by the 
> > > >> data model, and its one of the most important ones to 
> > resolve. So, 
> > > >> please comment on this one.
> > > >>
> > > >> Currently, our presence authorization policy documents 
> > > specify how to 
> > > >> filter presence documents for presentation to a watcher, 
> > > and they also 
> > > >> specify whether or not a subscription should be accepted 
> > > or rejected 
> > > >> (via the <action>). They also specify polite-blocking as 
> > > an action. As 
> > > >> a result of all of these being actions, there is an 
> > > explicit privacy 
> > > >> ordering - block -> confirm -> polite block -> allow.
> > > >>
> > > >> Henning had suggested on the list that perhaps we should 
> > split the 
> > > >> process of acceptance/rejection of the subscription from the 
> > > >> processing of the document itself.
> > > >>
> > > >> If anything, the data model would currently argue in 
> > favor of that 
> > > >> position. The processing of figure 4 defines the privacy 
> > filtering 
> > > >> step as serving the fucntion of removing sensitive 
> > > information from 
> > > >> the presence document. This sequence of operations gets 
> > > applied when a 
> > > >> document needs to be generated for a watcher. It doesnt 
> > > address the 
> > > >> actual acceptance/rejection of the subscription itself.
> > > >>
> > > >> In fact, its more complicated than that. In light of the 
> > > data model, 
> > > >> "polite blocking" is really a combination of accepting of the 
> > > >> subscription, along with a composition policy which produces a 
> > > >> document for the watcher that lies about my presence status.
> > > >>
> > > >> So, the question is, do we keep these concepts combined 
> > > into a single 
> > > >> action, or do we split them apart? In either case, how 
> > > does this play 
> > > >> in the model?
> > > >>
> > > >>  From a *modeling* perspective, I think that processing of the 
> > > >> subscription is most definitely a separate thing. That 
> > > processing puts 
> > > >> the subscription in only one of three allowed states 
> (accepted, 
> > > >> pending, denied). It is only once accepted that the 
> > actual privacy 
> > > >> filtering operation makes sense. I'd further argue that 
> > > the process of 
> > > >> polite blocking is really only meaningful when the 
> > > subscription itself 
> > > >> has been accepted (in the sense that the subscription got 
> > > a 200 ok and 
> > > >> a NOTIFY gets sent). It's clearly privacy-related, but its not 
> > > >> "privacy filtering" in the sense that it is not a process 
> > > of removing 
> > > >> information at all, its really creation of a fake input 
> > > document into 
> > > >> the processing of figure 4.
> > > > 
> > > > 
> > > > Yup.
> > > > 
> > > >> So, here is my proposal:
> > > >>
> > > >> 1. the data model identify an additional processing 
> step, which 
> > > >> happens when a subscription arrives. It defines how that 
> > > subscription 
> > > >> is procssed (accept, reject, confirm), and it determines the 
> > > >> composition policy of figure 4. Note that, because 
> > > composition hasn't 
> > > >> happened yet, conditions that are based on the presence 
> > > state itself 
> > > >> are meaningless and would be ignored. I think this is a 
> > > feature; it 
> > > >> means that the state of the subscription itself doesnt 
> > > really change 
> > > >> with my presence state, it will be based only on more static 
> > > >> information, such as the identity of the watcher, time 
> > of day, etc.
> > > >>
> > > >> 2. The processing in step 1 above is defined by the 
> > <sub-handling> 
> > > >> element, as it is today in the authorization document
> > > >>
> > > >> 3. we separate the processing of subscription handling 
> > > from privacy 
> > > >> filtering in the model, but both use the same input 
> > document - the 
> > > >> authorization policy. Thus, the <sub-handling> element 
> > is used to 
> > > >> guide the subscription processing, and the rest is 
> used to guide 
> > > >> privacy filtering. This has the benefit of allowing us 
> a single 
> > > >> document for a user to manage via xcap, but allowing it 
> > to really 
> > > >> represent two separate poliices.
> > > >>
> > > >> 4. The value of "polite-block" basically selects a 
> > > composition policy 
> > > >> which creates a fake document for a user, and "accept" 
> uses the 
> > > >> default policy. More generally, we might imagine that 
> > composition 
> > > >> policies themselves have privacy implications - some will 
> > > reveal more, 
> > > >> and some less. To resolve that, we can give each policy a 
> > > number based 
> > > >> on the amount of information it provides, and select which 
> > > policy as 
> > > >> part of the <sub-handling> element. Beacuse the 
> > > <sub-handling> element 
> > > >> is combined using the combination rules of common-policy, 
> > > it has the 
> > > >> right privacy properties.
> > > > 
> > > > 
> > > > This relates back to my comment in another thread about 
> > whether we 
> > > > really need the composition policy to differ by subscriber. 
> > > This seems 
> > > > to suggest that the answer is yes, but the issues of 
> that remain.
> > > 
> > > Right. Lets debate that in the other thread.
> > > 
> > > > 
> > > > The data model (figure 4) has the same composition policy 
> > > being used 
> > > > *twice* - once to combine all the inputs, and later to 
> > > patch up any mess 
> > > > made by the filtering. This always seemed a bit odd to me.
> > > > 
> > > > Maybe the answer is that these should be different 
> > > policies. The policy 
> > > > used to combine all the inputs could be common to all 
> > > subscribers, while 
> > > > the post-filter policy might differ by subscriber. One of 
> > > the functions 
> > > > of this post-filter composition policy could be to do 
> > > polite blocking.
> > > 
> > > I'm not sure I see how they really differ. Indeed, if we had 
> > > determined 
> > > that the scope of functions for composition policy were 
> > > commutative with 
> > > filtering, and idempotent, one might conclude that there is 
> > > no need at 
> > > all to do it prior to filtering.
> > > 
> > > In any case, I see the scope of composiiton policy being 
> > guiding the 
> > > decisions on how services and devices are merged, split, and 
> > > conflicts 
> > > are resolved. I don't see how the policies on how this is 
> > done would 
> > > really differ based on whether they happen to be executed 
> > > prior or after 
> > > privacy and watcher filtering. What logic would one specify 
> > > differently 
> > > in one place as opposed to another?
> > > 
> > > -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
> > 
> 

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 01 Nov 2004 10:36:53 -0500

(Changed to subject to be more specific)

I had a discussion with Jonathan about this, and I am coming to agree 
that letting composition policy be subscriber dependent is probably the 
right course for us.

I had two objections to this:
- efficiency
- complexity of defining composition policy

I have now concluded that the efficiency differences between the two 
approaches are probably negligible in the overall scheme of things - at 
least so that it shouldn't be a criterion in the decision.

Re complexity of composition policy - I think composition policy is 
going to be a challenging area in either case. I don't immediately see 
how to define a policy that does the kinds of things we all hint at, and 
is at the same time comprehensible to the average user. As a result, I 
think we will see a lot of experimentation, and lots of policy 
representations that aren't fully featured.

Allowing subscriber dependent policy adds another degree of freedom to 
this mix. Those who can't cope with it can simply not use that 
capability. And if they don't, they are free to create implementations 
that have a single composed document.

This will not become an issue until and unless we get to the point of 
attempting to standardize composition policy. Until then I see no 
problem in leaving it as a possibility.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 03 Nov 2004 03:13:45 -0500

> least so that it shouldn't be a criterion in the decision.

Let me try to address one of Hisham's points specifically. His concern 
was that if you had composition policy be watcher dependent, then you 
couldn't store the raw presence document in advance of a subscription; 
you'd have to re-do composiiton for each watcher.

The short answer is, yes, but I don't see the alternative. In the model, 
  composition is where I am able to do things like have totally 
different versions of my status for different watchers. Polite blocking 
is in this category. Thus, if we want this capability (and I think we 
do), then we can't just say "composition should be independent of 
watcher" - you need to provide an alternative formulation of the model 
where this functionality resides.

The other response I would give is that, in the event where the number 
of composition policies is limited, you can pre-compute the outputs of 
all of the possible composition poliices, and thus get the same savings 
you are looking for.

Paul had pointed out to me a problem in the data model. It current 
envisions composition policy as taking place before filtering and then 
again afterwards to recombine tuples that may no longer make sense to 
exist separately after removal of information. However, if the scope of 
composition policy is the ability to inject static tuples (for example, 
to support polite blocking), then you can't do this. Any composition 
policy that occurs after privacy filtering can not ever introduce 
additional inforamtion into the document, and currently composition can. 
Thus, this post-privacy composition policy may actually be something 
else entirely or in part.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com