a road we rejected once before. If I am reading this correctly, the
Policy URI has all the rules which apply to the location info. What
that creates is a sort of split LO, with the location at one spot and
policy at another.
In the long-ago-time, we agreed that doing that basically didn't work
because anything that blocked access to the URI blocked access to the
policy. One response to that was to make sure that the defaults in an
LO granted no rights and so this block could not result in leakage
(the "only grants"theory). This seems to substitute that theory with
the *whole* policy being separated from the location. Is that right,
or did I miss some basic thing here?
I also, frankly, think specifying how the resource gets provisioned is
pretty much a secondary issue. Sure, PUT and DELETE would work, but
so would a lot of WEBDAV style commands and so would XCAP style POST
etc. The real problem is actually in determining who has the rights
to change them, and HTTP's mechaisms for that are, as you know, not
all that useful in cases like these.
You can get around this mentally by saying all LI is really LO with a
default set of permissions (read: none), but that is deeply
impractical for getting the actual work of the group done, because
there is no way of ensuring that others know that is what you meant.
And blocking access to an all-encompassing policy URI seems to get us
back to that square one.
Am I missing something basic here, in my fogged state?
regards,
Ted
On Wed, Oct 7, 2009 at 10:08 AM, Richard Barnes <rbarnes@bbn.com> wrote:
> Hey GEOPRIV,
>
> I put together a short draft proposing a simple mechanism for allowing end
> users to control policy for location URIs. Basically, wherever an LCP has a
> slot for a location URI, we add a link for a "policy URI", and define a very
> basic usage of HTTP for handling policy.
>
> The one major thing that's missing from this draft is an extension of this
> mechanism to non-LbyR policy -- to allow the Target to provision policy
> related to third-party dereferences. At least in HELD, I think this can be
> done by adding a similar policy URI link to the <locationResponse> element
> (i.e., a reference to the *overall* policy for theclinet). But I didn't
> feel like mhy XSD mojo was quite up to defining this.
>
> Comments welcome!
>
> --Richard
>
>
>
>
>
> -------- Original Message --------
> Subject: New Version Notification for draft-barnes-geopriv-policy-uri-00
> Date: Wed, 7 Oct 2009 10:00:55 -0700 (PDT)
> From: IETF I-D Submission Tool <idsubmission@ietf.org>
> To: rbarnes@bbn.com
>
>
> A new version of I-D, draft-barnes-geopriv-policy-uri-00.txt has been
> successfuly submitted by Richard Barnes and posted to the IETF repository.
>
> Filename: draft-barnes-geopriv-policy-uri
> Revision: 00
> Title: Location Configuration Extensions for Policy Management
> Creation_date: 2009-10-07
> WG ID: Independent Submission
> Number_of_pages: 13
>
> Abstract:
> Current location configuration protocols are capable of provisioning
> an Internet host with a location URI that refers to the host's
> location. However, these protocols lack a mechnism for the htarget
> host to inspect or set the privacy rules that are applied to the URIs
> they distribute. This document extends the current location
> configuration protocols to provide hosts with a reference to the
> rules that are applied to a URI, so that the host can view or set
> these rules.
>
>
>
>
> The IETF Secretariat.
>
>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
