RE: Deprecate Content-Location? (was RE: "Variant" language in Content-Location (Issue 109))

Julian Reschke wrote:
> Brian Smith wrote:
> > I know. What I am trying to say is that plan doesn't work 
> > because "entity" and "variant" mean two different things.
> > I think "entity" could replace
> 
> Do they?
> 
> RFC 2616 says about "variant":
> 
> "A resource may have one, or more than one, representation(s) 
> associated with it at any given instant. Each of these 
> representations is termed a `varriant'. Use of the term 
> `variant' does not necessarily imply that the resource is 
> subject to content negotiation."

> So a variant *is* a representation. (And I think we have 
> decided earlier that there's really no distinction between 
> "representation" and "entity" either).

I agree, "representation" and "entity" are the same. 

> Although Content-Location identifies an entity, that doesn't 
> mean that that entity can't change over time.

That is the part that I disagreed with because I've always thought of
"entity" as describing an immutable value. However, I guess entities are
immutable in RFC 2616 just because "entity" is used to describe parts of
messages only, and messages are immutable. I guess as long as writers are
careful to differentiate between "entity" and "version of an entity" when
the distinction matters, things can work. But, "version of an entity" isn't
really clearly defined in RFC 2616 either.

That is why I think it is clearer to say "variant" instead of "entity" when
describing things that potentially change over time, and say "entity"
instead of "verssion/instance/value of an entity" to describe particular
values of such things. That would allow the removal of the terms
"representation," and "entity value", "versions of an entity", and
"instances of that entity". (Incidentally, "document" is another term that
should be removed.) 

> > If the "might be individually accessed" condition is 
> > important then it needs to be clarified so that
> > implementations know what they are supposed to do to
> > meet the condition. But, I don't think the condition 
> > adds any value which is why I suggest that it is simply
> > removed.

If the "might be individually access" condition is going to stay in, then
please add an explanation of how to conform to that requirement. If it
doesn't affect conformance then it doesn't make sense to keep it.

> > But, again, I think we should first decide if the use of 
> > Content-Location should ever be encouraged at all given how 
> > problematic it is.
> > ...
> 
> I must admit that I'm not aware of any problems with 
> Content-Location in practice (besides the issues raised 
> months ago wrt the base URI).

The base URI issue makes Content-Location dangerous to use. The only time it
is safe to use Content-Location is when the Content-Location is exactly the
same as the Request-URI (because of relative URI references like
"#fragment"), or when the response entity doesn't contain any relative URIs.
However, if you limit Content-Location to be the same as the Request-URI
then it can no longer identify individual variants of the resource, which is
its main purpose. As a rule of thumb, it is safer to omit the
Content-Location than it is to include it. That is why I think some language
like "Servers SHOULD NOT include a Content-Location header in responses
[unless...]" is important.

Another problem with Content-Location is that some implementations
apparently use it to edit individual variants of a resource, but that use of
Content-Location isn't well-defined in RFC 2616, there are security
considerations that make it very difficult to define in a useful way,
describing how that works would be a lot of work, and there is no evidence
of interoperability for this use of the header anyway.

- Brian

Received on Wednesday, 6 August 2008 14:27:36 UTC