>
> I am assuming that a location may be fairly long lived-e.g. created by my cable company for my "home" location and re-used with its policy URI for long periods. If the validity intervals are short and the LS does not re-use the policy URI when a new location URI for that same location is created, this is less of a problem (this latter problem may require some thought in the inputs to a hash-based mechanism for the creation of a policy URI, especially if an LS re-used the random entropy in a new run. It can neither use the location URI nor the location description, I'd guess).
We should keep in mind that there are at least three different validity intervals here:
1. The validity interval of the location value
2. The validity interval of the location URI
3. The validity interval of the policy URI
Would it address your concern to require (2) and (3) to be equal? This seems sensible and implementable to me. Proposed text:
"
A policy URI is only valid while the corresponding location URI set is valid. A location server MUST NOT respond to any requests to a policy URIs once the corresponding location URI set has expired. This expiry time is specified by the 'expires' attribute in the HELD locationResponse or the 'Valid-For' LuriType in DHCP.
"
> > It's also not clear whether a location server that allows clients to inspect policy but not update actually meets the goals of this document, since it either then requires some other side-loading mechanism or is incomplete.
>
> Being pragmatic about this, we can't really legislate what policies LS provider will apply. We could have a requirement that servers allow changes to policy, but that just risks that portion of the spec being unused. IMO, even being able to inspect policy is an improvement over the current state of the art.
>
>
> No, but we can say that it is recommended for cases where there is no other way to set policy.
Proposed text:
FROM
"
A Location Server SHOULD allow all requests, but it MAY deny certain requests based on local policy. For instance, a Location Server might allow clients to inspect policy (GET), but not to update it (PUT).
"
TO
"
A Location Server MUST allow GET requests to allow clients to inspect policy. A Location Server SHOULD support PUT and DELETE requests to allow clients to control policy, especially if clients cannot set policy through other means.
"
> Overloading removing the policy URI with "delete access to the resource" seems like an un-needed optimization to me. As a client writer, I'd update the policy with a validity interval that is gone, set provide-location to false or something similar. That's just my personal take on this obviously, and if other folks feel that this is the optimization to make, I can live with it.
Ok, I think I understand you better now. I can agree that overloading DELETE makes sense, especially in light of the fact that we have two other ways of invalidating location URIs (policy-based validity intervals and the global expiration of the URI). It still seems like an LS shouldn't respond to requests for the location URI while there's no policy document (after a DELETE).
Proposed text:
FROM
"
A DELETE request to a policy URI is a request to delete the referenced policy document and terminate access to the protected resource. If the request is authorized, then the Location Server MUST delete the policy referenced by the URI and disallow any further access to the location resources it governs.
A location URI can thus become invalid in three ways: By the expiration of a validity interval in policy, by the removal of a policy document with a DELETE request, or by the expiry of the HELD-specified validity interval. The former is temporary, since the policy URI can be used to update the validity interval in the policy; the latter two are permanent.
"
TO
"
A DELETE request to a policy URI is a request to delete the referenced policy document. If the request is authorized, then the Location Server MUST delete the policy referenced by the URI and disallow access to the location URIs it governs until a new policy document has been put in place via a PUT request.
A location URI can thus become invalid in three ways: By the expiration of a validity interval in policy, by the removal of a policy document with a DELETE request, or by the expiry of the LCP-specified validity interval. The former two are temporary, since the policy URI can be used to update the policy. The latter one is permanent, since the expiry causes the policy URI to be invalidated as well.
"
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
