> We have WGLCs open for draft-ietf-geopriv-deref-protocol-02 and
> draft-ietf-geopriv-policy-uri-00 until next Tuesday, April 12. Please
> send your comments to the appropriate threads (even if you're just
> giving a thumbs-up). Thus far there have been no responses.
Although I'm not following GEOPRIV (and so don't know if there are
relevant threads to comment on), Richard asked me to perform a review of
this document. I'm doing this in kind of a hurry, so please excuse the
fact that my comments are mostly in the order I encountered them when
reading through the document.
The first thing that I notice is that the document rather tightly scopes
policy URIs to being HTTP-only. I'm not suggesting that this document
should go about defining other mechanisms; but it probably should leave
the door open for future documents to do so without redefining key
terms. (For example, if there were a good reason to use SIP to deliver
policy information in the future, we should be able to do so without
having to change the definition of "Policy URI.")
Specifically, I would suggest re-crafting section 3 to read more like:
A policy URI is a URI that identifies a policy resource that
contains the authorization policy for a linked location resource.
Access to the location resource is governed by the contents of
the authorization policy. This document defines the behavior of
clients and servers using HTTP [RFC2616] policy URIs.
A policy URI identifies a resource that a Rule Maker can use to
inspect and install policy documents that tell a Location Server
how it should protect the associated location resource.
This would also have minor impacts elsewhere in the document so that
statements specific to the HTTP usage were qualified to indicate that
the statements are specific to the HTTP usage (e.g. changing the title
of section 3.1 to "HTTP Policy URI Usage").
On a separate topic, I note that the document implies that multiple
clients are capable of updating the document via PUT and DELETE
operations, but without mentioning the use of etags. This can cause
races in the multi-client case (client A GETs the policy, appends a
rule; client B PUTs a set of rules; and then client A PUTs his modified
policy in place, overwriting B's policy). I believe the document needs
to address this case by mentioning etags as a means for avoiding races.
I would suggest that we even go so far as to require servers to return
Etag header fields for all HTTP Policy URIs, so as to ensure that
clients can use this mechanism. (This has impacts on the examples in
section 5.3: add an "ETag" to the 200, and an "If-Match" to the PUT).
[Minor editorial nit in the first paragraph of section 3.2: I believe
"different to" is a uniquely British usage, while "different from" is
used in all English dialects]
Section 3.2 states: "A HELD-specific extension also allows a requester
to specifically ask for a policy URI." I think this needs a citation
(e.g., "See section 4.1").
Section 4.1 claims 'A policy URI MUST use the "http:" or "http:"
scheme...' I suspect that one of those should be "https," but the more
relevant comment here is that this seems an unnecessary restriction. As
I mentioned above, I think it would be short-sighted to close the door
to using other protocols in the future. I suggest that we instead define
clear behavior if the client does not understand the URI scheme (e.g.,
it is treated the same as if there were no URI present). What would be
really nice would be adding an attribute to the "requestPolicyUri"
element that indicated the preferred URI scheme. For example:
<requestPolicyUri scheme="https"/>
(The same comments apply to section 4.2, minus the bit about
requestPolicyUri).
/a
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
