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
