Subject: RE: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57]

From: [email-masked]
Date: Tue, 9 Sep 2003 10:37:16 +0300

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Sunday, September 07, 2003 7:53 AM
> To: Henning Schulzrinne
> Cc: Khartabil Hisham (NMP/Helsinki); [email-masked]; 
> [email-masked]
> Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes 
> for IETF #57]
> 
> 
> 
> 
> Henning Schulzrinne wrote:
> 
> > I agree that we seem to need to ways of identifying information:
> > 
> > (1) syntactically, for fine-grained control; after all, 
> someone may well 
> > be prepared to reveal the type of place they are in, but 
> not the actual 
> > location.
> 
> Fair enough, thought I don't think I would call this "syntactic".
> 
> > 
> > (2) semantically, where we label each piece of information 
> as being part 
> > of one or more broader classes, such as "where am I" and "what am I 
> > doing" or "what device capabilities do I have" or, as another axis, 
> > "present" and "future".
> > 
> > Beyond the obvious location identification, it might be 
> useful to go 
> > through the set of PIDF and RPID (and related document) 
> items to see if 
> > they are amenable to such a grouping. If each group has one 
> element, 
> > this approach isn't too helpful.
> 
> I thought about this a bunch.
> 
> The conclusion I came to is that, in many cases, the types of 
> authorization policies that users will want are those which block the 
> ability of a watcher to deduce a specific fact. For example, 
> if I take 
> a day off, and don't want my boss or colleauges to know it, I will 
> want my presence to be structured so that no one can figure 
> out that I 
> am not working. This would mean, for example, that if I am sleeping, 
> this activity value should not be shown to watchers.
> 
> My geolocation concerns were similar. I think what users may want is 
> the ability to say "I don't want people to know where I am". Many 
> possible presence elements can reveal this - including ones like 
> activity and privacy, which reveal indirect clues about location.
> 
> Unfortunately, I don't think its practical to have authorization 
> mechanisms which require the server to figure out what rpid elements 
> are needed to deduce a specific fact.
> 
> As such, the best we can do is avoid dependencies on encoding details 
> (such as whether placetype is put in a status or future-status 
> element). I would suggest that the best way to do this is to allow 
> filters and authorization policies to point at rpids and pidf 
> elements 
> by element name, no matter where that element appears in an XML 
> document. So, if I don't want people to know my geoloc, I would 
> specify an auth policy that blocks "placetype".

Welcomme on board :) And I think XPath is the exact tool you need for this, especially wen you say "no matter where that element appears in an XML document".

The following XPath expression selects the <placetype> element no matter where it appears in the XML document:

//*[placetype]

> 
> 
> > 
> > Another approach (3) is to have a scale of privacy concern 
> or 'presence 
> > resolution', i.e., establish some default ordering, from 
> "OPEN/CLOSED" 
> > at the low end to "every new item that I publish" at the 
> high end, with 
> > no more than half a dozen levels. Each new element would 
> then be labeled 
> > as falling into one of these groupings.
> 
> I agree this is a great idea. In fact, I had exactly this kind of 
> thing in mind for the compound permissions.
> 
> > 
> > I think both (2) and (3) have the distinct advantage that 
> they are far 
> > easier to explain to users than dozens of checkboxes for each 
> > RPID/geoloc/PIDF element. (3) is roughly similar to the 
> privacy slider 
> > in the Internet Options menu for IE, for example. There is no 
> > requirement that everybody agrees with an ordering, just that it is 
> > plausible for the majority of use cases. Advanced users can click 
> > through to the per-element include/exclude list.
> 
> I agree that we don't want users to click on checkboxes for each rpid 
> type. I think you might have a checkbox for "don't reveal my 
> location", and when its selected, the client generates an xcap-auth 
> document which blocks a whole bunch of elements, each listed by name. 
> This may require us to produce a use case document that helps folks 
> figure out what types of facts users might want to control, and what 
> elements are involved in computing such facts.

I agree. This sound like a plan.

Regards,
Hisham

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