Subject: RE: [Simple] Update to xcap authorization rules - rpid type

From: [email-masked]
Date: Thu, 13 May 2004 00:08:36 +0300

Jonathan,

I think what you suggest below makes sense, but I would still like to see a bit more flexibility. It is definitely necessary to be able to select which tuples _and_ which attributes to give based on the following conditions:
- class
- URI scheme

Actually I don't see the problem with the way proposed in the current draft, even though I don't have clear use cases for all that level of flexibility.

Markus 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Jonathan Rosenberg
> Sent: 06 May, 2004 06:34
> To: Henning Schulzrinne
> Cc: Simple WG
> Subject: Re: [Simple] Update to xcap authorization rules - rpid type
> 
> 
> inline.
> 
> Henning Schulzrinne wrote:
> 
> > Rather than trying more in-line response, let me try to summarize.
> > 
> > I'm starting to think that subscription permissions and 
> view permissions 
> > are somewhat different and it may well be easier if we don't try to 
> > shoehorn them into one set of rules.
> 
> I'm also with you on divide-and-conquer, though I don't think 
> I'd divide 
> it like you do. See below.
> 
> > 
> > The model I'm trying to work out details for:
> > 
> > (1) have a rule set that only takes into account watcher 
> identity (with 
> > the usual exception and wildcard models) and time-of-day 
> for allowing 
> > subscriptions
> > 
> > (2) another rule set that applies conceptually to each 
> tuple and takes 
> > into account, as conditions ('if' part), the current state of the 
> > presentity, including identity, time, location and sphere (but not 
> > class). The 'then' part simply selects tuples by class 
> (only tuples that 
> > have 'class X') and adds RPID, contact and other elements, for each 
> > tuple, according to the rules.
> > 
> > After the filtering, the resulting set of (modified) tuples is 
> > delivered, if non-empty.
> > 
> > There's no ambiguity as to the current state for (1), so 
> this is easy.
> 
> Yes, in fact, too easy I think. The problem with this 
> approach is that 
> we would have something really, really simple right now, with less 
> functionality than existing systems (wireless village, for 
> example, does 
> allow you to specify which attributes get delivered to whom). If you 
> want more than the minimum, you'd need to add this second 
> thing, and I 
> think we're far from being done with that, since the 
> what-is-a-tuple and 
> mysteries of composition have yet to be fully fleshed out, 
> and they need 
> to be fleshed out if we want to define policies that control them.
> 
> So, I'd rather break it this way. For now, we focus on 
> defining privacy 
> policies that apply after the server has performed 
> composition, since we 
> don't know enough to control composition yet. Those policies 
> allow you 
> to accept/deny subscriptions as you suggest, but also grant 
> permissions 
> for uers to see various presence attributes. We can go back to the 
> simple boolean appraoch we had before (send it or not). We 
> also remove 
> sphere as a condition because of the issues about determining 
> what tuple 
> sphere is defined in.
> 
> We also allow the user to specify which tuples get sent, 
> selecting based 
> only on URI scheme and class.
> 
> If you remove information so that the result are tuples that seem 
> similar, we include some text on optional combining 
> operations that the 
> server can do, but clarify that these are not normative in 
> any way. In 
> essence, the work we're doing now is truly a privacy filter - 
> it simply 
> states who can and can't see what information, rather than saying 
> anything about how to structure the information for which we have 
> granted permission. I like that model.
> 
> Then, at a later point in time, we could define policies that control 
> composition, and those would allow for more selective inclusion of 
> information in specific tuples.
> 
> The benefit here is that the scope of the current work 
> provides what I 
> believe to be minimal functionality now, and the framework (viewing 
> downstream work as controlling composiiton as opposed to an 
> extension to 
> the current work) would allow us to do a lot more later.
> 
> Are people comfortable with this scope?
> 
> Thanks,
> 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: [email-masked]
Date: Thu, 13 May 2004 00:08:36 +0300

Jonathan,

Markus