Roy writes:
> entity tag
>
> An opaque string associated with an entity and used to distinguish it
> from other instances of the same resource entity. A "strong entity
> tag" is one that may be shared by two entities of a resource entity
> only if they are equivalent by octet equality. A "weak entity tag" is
> one that may be shared by two entities of a resource entity if they
> are semantically equivalent. A given entity tag value may be used for
> entities identified by two different URIs, or by the same URI and two
> different variant-IDs, without implying anything about the equivalence
> of these entities.
Likewise, the above is incorrect
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.
In other words, the variant-ID was never part of the cache validator
(entity tag), it was just carried in the same header for reasons
of expendiency.
The grammar I wrote for CVal made this implicit
CVal = "CVal" ":" cval-info
cval-info = opaque-validator [ ";" variant-id ]
and then (after a few examples) I immediately added the explicit
statement:
Note that the variant-id is not part of the opaque validator. The
CVal: field is used to transmit a variant-id simply as a matter of
compact representation of responses.
This statement remains in draft-ietf-http-v11-spec-02.txt, by the way.
If it pains or confuses you to have these two distinct values carried
in the same response header, I'm happy to switch back to using a
separate Variant-ID header.
Sorry for the confusion.
-Jeff