Subject: Re: [Geopriv] draft-ietf-geopriv-policy-uri-00 WGLC

From: Ted Hardie <[email-masked]>
Date: Mon, 2 May 2011 13:48:05 -0700

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.

Did I miss a section where this was described?

regards,

Ted Hardie

> If another editor manages to overcome #1, then I'm OK with having the hint.
>
> --Martin
>
>
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv
>

---

From: Adam Roach <[email-masked]>
Date: Mon, 02 May 2011 17:13:40 -0500

On 5/2/11 3:48 PM, Ted Hardie wrote:
>     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
> 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

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 4 May 2011 18:35:43 +0200

These seem like excellent issues to address in a future update to this document that specifies a second possible URI scheme.  I don't think we need to address extensibility or multi-scheme issues in this document.  

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:

>> 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
>> 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.
> 
> 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