Re: Clarifying Content-Location (Issue 136)

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

Hm,

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

Furthermore,

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 
(<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-latest.html#identifying.response.associated.with.representation>)

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