Re: Clarifying Content-Location (Issue 136)

On Oct 5, 2009, at 11:42 PM, Brian Smith wrote:

> Roy T. Fielding wrote:
>> Content-Location is for identifying the resource for which the
>> message payload is a representation. It does not exist for the
>> sake of caching.  It will not go away even if caching no longer
>> mentions it, the spec no longer refers to variants, and the
>> requirements associated with variants are removed.
>
> I said that Content-Location's only interoperable use (if any) is  
> for cache.
> That is true.
>
>> The base-setting effect was for MIME, MHTML, and message archival.
>> The only thing we can change is that it does not apply for HTTP.
>>
>> So, please, if you have specific changes to the document, then
>> be specific about which sentences need to be removed or fixed.
>> Please stop ranting about removing the field altogether,
>> since all that does is interfere with seeing what needs to
>> be changed in the draft.
>
> What I said was:
>
>      "when it is different than the request resource's URI"
>      is unnecessary and wrong.
>
> and:
>
>      At the very least, the specification must not say that
>      Servers "SHOULD" use the Content-Location header.
>
> My full proposal is to change remove all the text in section 5.7 of  
> Part 3,
> and replace it with the following:
>
> -- snip --
> 5.7.  Content-Location
>
>     The "Content-Location" entity-header field is used to supply a URI
>     for the entity in the message.
>
>       Content-Location   = "Content-Location" ":" OWS
>                             Content-Location-v
>       Content-Location-v = absolute-URI / partial-URI
>
>     The meaning of the Content-Location header in requests is
>     undefined; servers are free to ignore it in those cases.
> -- snip --
>
> This would resolve issue #136 and issue #154. It also makes the
> specification easier to read by removing all the explanation of how  
> clients
> and caches are NOT allowed to interpret Content-Location (caches, in
> particular, can only do what they are specifically allowed to do).  
> It also
> removes the redundant statement of how relative URI references are  
> resolved
> (which is stated in Part 1, section 2.1).
>
> Regards,
> Brian

Thanks Brian.  +1 to the proposal.

....Roy

Received on Tuesday, 6 October 2009 19:54:19 UTC