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

Re: Clarifying Content-Location (Issue 136)

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 07 Oct 2009 15:21:51 +0200
Message-ID: <4ACC95EF.5050906@gmx.de>
To: "Roy T. Fielding" <fielding@gbiv.com>
CC: Brian Smith <brian@briansmith.org>, 'Mark Nottingham' <mnot@mnot.net>, 'Robert Brewer' <fumanchu@aminus.org>, 'HTTP Working Group' <ietf-http-wg@w3.org>
Roy T. Fielding wrote:
> 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


not convinced. First of all, because this changes too many things at 
once for my taste.


1) Completely dropping an explanation *why* you would want to supply a 
URI seems to be a bit drastic.

2) I agree that it's clear how relative references are resolved, but I 
think mentioning what the base URI is still useful. Otherwise, we could 
have a generic statement somewhere in Part 1 that, unless stated 
otherwise, relative references are always resolved against the 
Request-URI (noting that we still need a definition for that).

3) I *think* the text should reference the new section in Part 2 

4) Wrt dropping the base setting semantics I'll reply in a separate mail.

BR, Julian
Received on Wednesday, 7 October 2009 13:22:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:51 UTC