W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2009

Re: Clarifying Content-Location (Issue 136)

From: Roy T. Fielding <fielding@gbiv.com>
Date: Tue, 6 Oct 2009 12:54:00 -0700
Message-Id: <EE03A855-1A54-4166-A54D-BD7AEA4217F7@gbiv.com>
Cc: "'Mark Nottingham'" <mnot@mnot.net>, "'Julian Reschke'" <julian.reschke@gmx.de>, "'Robert Brewer'" <fumanchu@aminus.org>, "'HTTP Working Group'" <ietf-http-wg@w3.org>
To: "Brian Smith" <brian@briansmith.org>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:12 GMT