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

From: [email-masked]
Date: Thu, 28 Oct 2004 15:41:24 +0300

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.

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 :)

/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