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

Brian Smith wrote:
> ...
>>> 1. The message might not contain an entity (e.g. if the 
>>> request is a HEAD or if the response code is 204 No Content),
>>> so "entity enclosed in the message" is not really correct.
>> That's true (and the same text is in 2616). Care to propose 
>> something else?
> 
> If a response contains an entity with a Content-Location header, then the
> Content-Location identifies a resource, and the response entity is a
> representation of that resource. In responses to GET and HEAD requests the
> Content-Location identifies the selected variant. 
> ...

That doesn't the HEAD issue either, I think. Also it's contrary to our 
goal not to use "variant" anymore. (see below)

>> The current plan for Issue 109 is to get rid of the term 
>> "variant", and to make "representation" and "entity" 
>> equivalent 
>> (<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/109>). There's a
>> *separate* issue for "requested variant", which is issue 69 
>> (<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/69>).
> 
> 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).

> "representation" but it cannot replace "variant." The language that
> describes cache invalidation based on Content-Location makes it clear that
> Content-Location isn't supposed to identify a specific entity. Otherwise,
> Content-Location would be functionally equivalent to ETag. If you think

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

> about it in VCS terms, then a variant is a branch of a resource, and an
> entity is a particular version of a variant. At any particular time, there
> can be many variants of a resource and each variant has one entity that
> describes it at that point of time. Over time, a variant will be described
> by multiple entity as the variant changes.

I think we agree on this.

> I don't really see the motivation for i109. If the specification is going to
> become much clearer by such a change, then I am all for it. But, if "entity"
> is going to lose its precise meaning or be overloaded with multiple meanings
> then how is that an improvement?

The issues we want to solve are:

- we have three terms that mean either the same or very similar thing 
(depending whom you ask), and people *are* confused

- the definition of "representation" is broken ("An entity included with 
a response that is subject to content negotiation, ...) -- it's 
definitively not used that way; and I don't see why we would need a 
special term for that case

- we have no definition of "requested variant", and that affects the 
ETag discussions.

There may be more, but these are my favorites.

>>> 3. The RFC 2616 language says that Content-Location SHOULD 
>>>    be provided in every case. Your change only says
>>>    Content-Location should be required in the special case
>>>    that begins "especially" in RFC 2616. So, it doesn't mean
>>>    the same thing.
>> Yes, that's intentional and reflects what RFC 2068 said. I 
>> think the change in RFC 2616 was incorrect (overzealous 
>> conversion to BCP 14 keywords).
>>
>> So do you think that servers SHOULD return a Content-Location 
>> even when only one entity is associated?
> 
> IF Content-Location is going to live on then I agree that the RFC 2068-like
> definition makes more sense. Basically that if the response contains a Vary
> header then the entity should have a Content-Location header.

Yes (unless the server did not send Vary because of the other issues 
with UA handling of that one).

> ...
>>> 5. What does "might be individually accessed" mean? As far as cache 
>>> validation is concerned (which is the only time Content-Location is 
>>> used in the protocol itself), the Content-Location doesn't 
>> have to be accessible.
>>> That whole condition can be removed since it is meaningless.
>> What's the point in supplying a Content-Location, if nobody 
>> can access it?
> 
> Caches uses Content-Location is to identify the variant (not entity--that is
> what ETag does) so that they can invalidate multiple cache entries at once.
> That is the only use of Content-Location in the protocol itself. Since the
> cache doesn't need to issue a request to invalidate those entries, the
> resource at Content-Location doesn't have to be accessible. The only other
> use of Content-Location in HTTP is to resolve relative URIs in the response
> entity, and the resource doesn't have to be "accessible" for that either.
> ...

There are definitively other uses, such as authoring a specific variant. 
Maybe not clear from RFC 2616, but they exist anyway.

> 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.
> 
> 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).

BR, Julian

Received on Wednesday, 6 August 2008 13:32:49 UTC