It seems like the URI scheme of the policy URI should provide enough information for clients to tell whether they've gotten a URI they support, so an extension would need just to (1) define the alternative policy URI system, and (2) change the requirement that the policy URI MUST be an HTTP URI.
With those considerations, I think the only thing we need to do here is make sure that clients for this document fail safely if they get a non-HTTP URI. Proposed text:
FROM
"
4.3. Client Processing
It is possible that this document will be updated to allow the use of
policy URIs that use protocols other than the HTTP-based protocol
described above. To ensure that they fail safely when presented with
such a URI, clients implementing this specification MUST verify that
a policy URI received from either HELD or DHCP uses either the
"http:" or "https:" scheme. If the URI does not match those schemes,
then the client MUST discard the URI and behave as if no policy URI
was provided.
"
On May 3, 2011, at 12:13 AM, Adam Roach wrote:
> On 5/2/11 3:48 PM, Ted Hardie wrote:
>> On Thu, Apr 28, 2011 at 10:07 PM, Thomson, Martin <
>> I'm inclined to classify this as an optimization. So three reasons not to add the parameter:
>> 1. laziness
>> 2. it's probably not too much extra load to create a resource for most types of resources, especially if you optimize for the case where the resource isn't accessed
>> 3. DHCP won't have any hinting
>>
>>
>> It strikes me that the PUT/DELETE nature of client management of these resources creates a bit of a problem with this multiple-URI approach. If the user has two different clients from which policy updates may come, updates PUT from one must be synchronized to the other URI by some back-end process, or your risk silly states where the user has updated policy using one URI, but the policy accessed from a different client using a different scheme gets old data because the URIs are distinct and no PUT occurred to that URI.
>
> That's a very good point. We would need to add text around this issue.
>
>> Did I miss a section where this was described?
>
> No, because the current version of the document makes certain strong assumptions around "HTTP now, HTTP forever." This whole conversation stems from my feedback that we should make the approach more extensible, even if we don't describe other protocols right now. So you won't find any related text in the document at this time.
>
> /a
> _______________________________________________
> 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
