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

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

> -----Original Message-----
> From: ext Henning Schulzrinne [mailto:[email-masked]]
> Sent: Sunday, September 07, 2003 5:03 PM
> To: Jonathan Rosenberg
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes 
> for IETF #57]
> 
> 
> Jonathan Rosenberg wrote:
> 
> 
> > Fair enough, thought I don't think I would call this "syntactic".
> 
> Document-oriented? Presumably it would use
> 
> > 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.
> 
> I don't think this is necessarily binary. For example, I might be ok 
> with letting others know what timezone I'm in, although this may hint 
> that I'm traveling or on vacation.
> 
> > 
> > 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.
> 
> Particularly if this is meant to be more than a binary yes/no 
> decision. 
> Different elements reveal different amounts of information 
> depending on 
> context, depending on what the watcher knows about me, etc. (For 
> example, if the watcher knows that my employer has a branch office in 
> Tokyo, even something as vague as timezone=Japan will provide a good 
> hint as to what I'm doing right now.)
> 
> > 
> > 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".
> 
> Agreed. As a side-effect, this essentially makes the namespace flat, 
> i.e., we can't have two PIDF-and-related namespaces use the same term 
> for something different. I don't think this is a significant 
> restriction 
> in practice. One possibility to formalize this is to indeed have a 
> single IANA registry for presence attributes. Each entry 
> would point to 
> one or more namespace/element-name combinations.

Well, with XPath, you don't even need that. Let me expand the example I gave in an earlier email:

//*[placetype]

> 
> 
> 
> > I agree this is a great idea. In fact, I had exactly this 
> kind of thing 
> > in mind for the compound permissions.
> 
> The proof of feasibility will be whether we can arrive at 
> such a list, 
> across PIDF, RPID + related, and the emerging GEOPRIV items. I would 
> suggest that these levels should be motivated by the likely use and 
> audience. For example, for two mid-levels:
> 
> (1) "Can I visit this person": this would be useful for intra-company 
> coordination
> 
> Would need information about my campus-level whereabouts.
> 
> (2) "Is this person amenable to business (or private) communication?"
> 
> This would include timezone, possibly country and 
> open/closed. Possibly 
> a 'private/business' coarse-grain activity (rather than a placetype).
> 
> Are there others?
> 
> > 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.
> 
> There was a long discussion on this topic at the GEOPRIV 
> interim meeting 
> that took place Friday and Saturday. Two approaches were identified:
> 
> (1) a tool presents a high-level interface to the user, but the 
> on-the-wire ruleset (XCAP-AUTH, etc.) identifies lower-level elements 
> (either at the document-oriented level or, probably better, 
> by content 
> type).
> 
> (2) the authorization policy itself contains a high-level description 
> that then is translated by the policy enforcement entity into 
> filtering 
> actions.
> 
> (2) has fewer things to test and thus may reach 
> interoperability sooner, 
> but requires that the policy enforcement point be upgraded 
> each time a 
> new element is added.
> 
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

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