- From: Martin J. Dürst <mduerst@ifi.unizh.ch>
- Date: Wed, 27 Aug 1997 22:23:59 +0200 (MET DST)
- To: Yaron Goland <yarong@microsoft.com>
- cc: "'Andre van der Hoek'" <andre@bigtime.cs.colorado.edu>, "'Judith Slein'" <slein@wrc.xerox.com>, w3c-dist-auth@w3.org
On Wed, 27 Aug 1997, Yaron Goland wrote:
> We can't have a conversation where everyone is using the same word to
> mean different things. I have defined what the term variant means in
> HTTP.
You mentionned earlier what the term variant means for you:
> > > In so far as I am concerned a variant is simply "yet another
> > > version" and requires no special handling outside of the normal
> > > versioning mechanisms.
and in this mail, you indicate that believe it is the definition
from HTTP.
> If you use the word variant, in a HTTP working group, it is
> expected that you will use it to mean what it means in HTTP. If you are
> referring to a concept other than the one meant by HTTP, please use
> another term.
So let's go back to the sources (RFC 2068). For "variant", we find
in 1.3, Terminology, on page 9:
>>>>
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 `variant.' Use of the term `variant'
does not necessarily imply that the resource is subject to content
negotiation.
<<<<
For "version", it's more difficult. The word version mostly turns
up in RFC 2068 in the sense of "protocol version" for HTTP.
But upon careful sceening, one finds, in 19.6.2.2, Content-Version,
the following paragraph:
>>>>
The Content-Version entity-header field defines the version tag
associated with a rendition of an evolving entity. Together with the
Derived-From field described in section 19.6.2.3, it allows a group
of people to work simultaneously on the creation of a work as an
iterative process. The field should be used to allow evolution of a
particular work along a single path rather than derived works or
renditions in different representations.
<<<<
True, this appears in an appendix entitled "additional features".
But it is the only place where in RFC 2068, versions have anything
like a definition. Either you accept this as part of RFC 2068,
in which case your statement "variant is simply 'yet another version'"
is definitely not in agreement with HTTP terminology, or you exclude
it from HTTP as such, in which case your statement "variant is simply
'yet another version'" has nothing to do with HTTP terminology
because HTTP terminology neither defines "version" nor anywhere
says that a variant is simply a version.
Regards, Martin.
Received on Wednesday, 27 August 1997 16:25:40 UTC