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

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

Received on Wednesday, 1 May 1996 10:07:55 UTC