W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 1997

RE: New Requirements Draft

From: Yaron Goland <yarong@microsoft.com>
Date: Wed, 27 Aug 1997 13:38:57 -0700
Message-ID: <11352BDEEB92CF119F3F00805F14F485037BC1FF@RED-44-MSG.dns.microsoft.com>
To: (wrong string) ürst'" <mduerst@ifi.unizh.ch>
Cc: "'Andre van der Hoek'" <andre@bigtime.cs.colorado.edu>, "'Judith Slein'" <slein@wrc.xerox.com>, w3c-dist-auth@w3.org
I know, I made the same mistake that everyone else did. In the first
paragraph you site I was using the term variant in the way that I think
you and Andre mean it. Of course that road leads to madness. That is why
I later defined the word variant as I understand its meaning in HTTP.
However matters only get worse because the definition given in the HTTP
spec does not necessarily match the common usage of the term in the HTTP
working group.

So might I suggest we all put our definitions down on the table so we at
least have some clue as to what we are talking about?

When I speak of "variant support" I am specifically speaking of putting
in place commands which instruct a server how it should handle accept*
headers. Thus if a client puts up a document and marks it as "the French
variant" it is expected that if the server receives accept-language:
(whatever the hell the French code is), it will return the French
version. It is this behavior which I do not wish to have specified by
DAV because I believe this is more server configuration than document
authoring. Document authoring is creating a document and putting
properties on it. One of those properties could even be "Language". But
it says nothing about how a server will server up that document. Only
that if you get the URL you PUT the document to, you will get the
document back.


> -----Original Message-----
> From:	Martin J. Dürst [SMTP:mduerst@ifi.unizh.ch]
> Sent:	Wednesday, August 27, 1997 1:24 PM
> To:	Yaron Goland
> Cc:	'Andre van der Hoek'; 'Judith Slein'; w3c-dist-auth@w3.org
> Subject:	RE: New Requirements Draft
> 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, 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, 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:39:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:11 UTC