Re: Variant-IDs and Entity Tags (was Re: HTTP 1.1 document terminology.)

>       entity tag
> 	 A string associated with an entity and used to distinguish it
> 	 from other entities of the requested resource.  A "strong entity tag"
> 	 is one that may be shared by two entities of a resource only if they
> 	 are equivalent by octet equality.  A "weak entity tag" is
> 	 one that may be shared by two or more entities of a resource if they
> 	 are semantically equivalent.  A given entity tag value may be used for
> 	 entities obtained by requests on different URIs without implying
> 	 anything about the equivalence of these entities.
>     
>     [assuming the variant-id is still part of the entity tag, which it must
>     be if we are going to allow variant-ids at all].
> 
> Your assumption is wrong, but it's perhaps understandable why you
> made it.
> 
> Originally, the variant-ID proposal was for a distinct response
> header, e.g.:
> 	Variant-ID: "foo"
> I believe that Koen actually made the first such proposal, and then
> I elaborated it with the variant-set mechanism later on.  Since some
> people objected to this as "unnecessary", and some people were acting
> aghast at each and every proposed new field-name, at some point I
> realized that the variant-ID could be piggybacked in the (old) CVal:
> header, along with the entity-tag (aka opaque validator), since
> variant-IDs were only useful in conjunction with a cache validator.
> This was done purely to avoid defining another response header.

No, it was done because I proposed the VID (later changed to EID)
header field which accomplished the exact same functionality with two
fewer header fields and a much simpler explanation, and was applicable
to both caching and collaborative authoring.  I never accepted the
CVal header field as desirable, and it should never have been added to
the specification.  I expected to see the EID header field, as I defined
it, or nothing at all in draft 02 related to validators, and certainly
not something which was clearly unacceptable from the very beginning.

I am not at all surprised to see that this has just perpetuated the
confusion.  An entity tag must include the variant-id if it is indeed
an entity tag, since the variant-id is part of what discriminates
between different entities of the same requested resource, which is
the purpose of the entity tag.  When it is used as a validator, the
entity tag includes both the opaque change-indicator and the variant-id
(if one is present), since both are necessary for the server to test
for valididty (or sameness) of the entity that would be sent in the
response.


 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/

Received on Thursday, 2 May 1996 02:24:55 UTC