RE: Clarifying Content-Location (Issue 136)

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

Received on Tuesday, 6 October 2009 06:43:14 UTC