I agree on the generalization.
On 2011-04-29 at 07:58:31, Adam Roach wrote:
> 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.
Updating the examples is good, maybe even pointing out that conditional requests are the safest way to update resources. In practice there is probably only one client updating the resource, so I expect that anything more than this would be overkill.
> 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"/>
This is the right idea, but I don't think that a request parameter is going to help. It would be unlikely that a server is able to support a new policy URI scheme because a client asks for that scheme. Instead, we can simply suggest that the server provide a policy URI for every scheme that it supports. The client can then pick the one that suits it best.
Note that for DHCP, this implies the need for some changes to draft-ietf-geopriv-lbyr-uri-option. I'll have to follow up on that separately.
--Martin
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
