- From: Koen Holtman <koen@win.tue.nl>
- Date: Tue, 30 Apr 1996 00:48:26 +0200 (MET DST)
- To: jg@w3.org
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
jg@w3.org:
>
[....]
> 2) I like Tim's term of "generic resource" for a resource that
>you can do content negotiation against (and I incorporated some words
>of his into the terminology section below), rather than Roy's
>suggestion of group resource.
While the terms `generic/specific resource' would work, the words that
explain them are totally inappropriate for the 1.1 spec. I guess you
took them from a research-like paper, where Tim explored a continuum
between totally specific and totally generic resources. Such a
continuum does _not_ exist for 1.1 resources. Generic or specific is
a binary property for 1.1 resources, and a property that is orthogonal
to variance through time. In summary, Tim's words would totally
confuse the reader. The edits suggested by John Franks improve the
text somewhat, but even with these edits it stays confusing.
Also, sentences like `(a little like a Platonic ideal)' and `When we
discuss electronic resources, an interesting fact is that a small
number of dimensions of genericity emerge.' do not belong in a
protocol specification.
[...]
> I'll go with "specific resource" unless
>someone argues me out of it or suggests a better term. Similarly, if
>someone has a bit of blinding insight for a better term, please speak
>up now.
I am using "plain resource" to denote "non-generic resource" in my
draft of the next content negotiation internet draft.
Using "plain resource" has two advantages:
- "plain" is short
- "plain" implies things like `the simple case', `the normal case',
`the thing we started out with (the kind provided by 1.0 servers)',
`the case without the special rules', which are all implications
we want to make.
Is this blinding enough?
>variant
>-------
>An specific resource that is a member of at least one generic
>resource. Sometimes called a resource variant. Note that the set of
>variants of a generic resource may change over time as well.
This `variant' is not the kind of variant referred to in the 1.1
caching section. There, a variant is an entity bound to a varying
resource as I defined it in the Vary header section. This kind of
variant that is identified by a tuple (URI,variant-ID), it does not
(necessarily) have its own URI: this variant is _not_ a resource
(unless a resource is something which is not always identified by a
URI). The truth about the relation between variants and resources is
complicated, and is revealed with gory graphical detail in the text
included below.
I have been working on the next version of the content negotiation
internet draft. I hope I will get it finished before the web
conference, but cannot guarantee that I will, as contributing fixes to
the 1.1 draft is higher on my priority list.
I include some parts of my draft of the content negotiation
terminology/overview section below. Read it for the terminology
explanations, not for the terms themselves, I plan to adjust them to
the 1.1 terminology once this terminology is known. Feel free to
steal text you can use. You do not need to steal from 3.4 below: 1.1
does not need to distinguish between opaque and transparent resources,
and 1.1 can ignore the extra level of indirection between a
transparent resource and its variants.
A table:
1.1-02 text New 1.1 terminology Terminology in my text below
resource resource resource
varying resource generic resource varying resource
non-varying res. specific resource plain resource
variant resource entity variant
<not mentioned> variant alternate
entity entity entity
transparent c. n. content negotiation transparent c.n.
opaque c.n. <not taken into opaque c.n.
account?>
Koen.
-------snip--------
[Note: this text has not been proof-read by me yet!]
3.2 Variants and entities
variant
A particular representation, rendition, encoding, or
presentation of a piece of information. Varying resources have
multiple variants associated with them. Plain resources have
only one variant. A variant is a container of data. The
contents of the variant may be updated over time.
entity
A piece of data, usually representing the contents of a variant
at a given point in time, transferred in a HTTP transaction. An
entity is transferred as metainformation in the form of entity
headers and content in the form of an entity body.
3.3 Resources and negotiation
resource
A network information repository or service, residing on an
origin server, that can be identified by a URI. In this
specification, resources are active parties in the
communication. Our sentence `the resource X returns Y' would be
`if a request is made on the resource X, the server returns Y'
in the terminology of [1].
This specification divides all resources into classes as follows:
-- plain resources
/
/
resources
\ -- opaque resources
\ /
-- varying resources
\
-- transparent resources
Opaque and transparent resources are collectively called varying
resources. At any given moment in time, a resource is either a plain
resource, an opaque resource, or a transparent resource. Resources
can change their class, but it is not expected that this will occur
often.
HTTP/1.1 [1] defines the distinction between plain and varying
resources. This specification defines the additional distinction
between opaque and transparent resources. HTTP/1.1 defines minimal
caching behavior for all varying resources. This specification
defines additional, optional, caching behavior for transparent
resources.
plain resource
A resource which is not a varying resource. A plain resource
only has one variant associated with it, and will return either
this variant, or an error message for every request. Resources
which have no associated variants, but instead return
redirection (301, 302, 303) type responses, are also called
plain resources. Plain resources are called non-varying
resources in [1]. Traditional HTTP/1.0 servers only provide
plain resources.
varying resource
A varying resource has multiple variants associated with it, all
of which are representations of the content of the resource. If
a GET or HEAD request on a varying resource is received, the
server will try to select one variant as the one best matching
the request. This selection process is called content
negotiation. If a resource is varying, this has an important
effect on cache management, particularly for caching proxies
which service a diverse set of user agents.
negotiated resource
synonym for varying resource
content negotiation
The process by which the best variant is selected when a GET or
HEAD request is made on a varying resource. Selection is based
on a matching of the properties of the variants to the
capabilities of the requesting user agent. Content negotiation
may not always succeed in finding the best variant, for example
because none of the variants are acceptable to the user agent.
In this case, a 3xx (redirection) or 4xx (client error) type
response can be generated.
There are two types of content negotiation: opaque negotiation and
transparent negotiation.
opaque negotiation
With opaque negotiation, the selection of the best
variant is done by an algorithm located at the origin
server, and unknown to the proxies and user agents involved.
Selection is based on the contents of particular header fields
in the request message, or on other information pertaining to
the request, like the network address of the sending client.
A typical example of opaque negotiation would be the selection of a
text/html response in a particular language based on the contents of
the Accept-Language request header field. A disadvantage of opaque
negotiation is that the request headers may not always contain enough
information to allow for selection. If the Accept header
Accept: text/*: q=0.3, text/html, */*: q=0.5
is sent in a request on a varying resource which has a video/mpeg and
a video/quicktime variant, the selection algorithm in the origin
server will either have to make a default choice, or return an error
response which allows the user to decide on further actions.
opaque resource
A resource which is opaquely negotiated. Opaque resources always
include a Vary header every 2xx class response.
3.4 Transparent resources and transparent negotiation
A transparent resource does not directly `contain' variants. Instead,
a transparent resource binds to multiple alternate resources, which
in turn `contain' variants.
An example is a resource http://x.org/intro, which uses negotiation
to provide a paper about x.org:
resource alternates variants
-------- ---------- --------
----- plain resource ---------- variant 1
/ http://x.org/paper.html.notables
/
transparent resource ------- plain resource ---------- variant 2
http://x.org/paper \ http://x.org/paper.html.tables
\
----- plain resource ---------- variant 3
http://x.org/paper.ps
In this example, the transparent resource http://x.org/paper has
three different alternates and three different variants. Note that
there is a one-to-one mapping between alternate URIs and variants.
An alternate resource can be a plain resource or an opaque resource,
but can never be a transparent resource itself.
alternate resource
A resource bound to by a transparent resource. An alternate
resource is either a plain resource or an opaque resource, but
can never be a transparent resource itself.
best alternate resource
The alternate resource best matching to the user agent
preferences for the request. If none of the alternates can be
handled by the user agent, the request does not have a best
alternate resource.
transparent negotiation
With transparent negotiation, the selection of the best
alternate resource is done by a distributed algorithm which can
perform computation steps in the origin server, in proxies, or
in the user agent. Transparent negotiation guarantees that, if
the user agent supports the transparent negotiation algorithm
and is correctly configured, the request will always correctly
yield either the best alternate resource, or an error message
indicating that none of the alternates bound to the resource can
be handled by the user agent.
transparent resource
A resource which is transparently negotiated. A transparent
resource binds to multiple alternate resources, which together
contain all variants available for the transparent resource.
Transparent resources always include an Alternates header in
every 2xx and 3xx class response. This Alternates header
describes the alternate resources bound to the transparent
resource.
A more complicated example is a resource http://x.org/intro, which
uses negotiation to provide introductory information about x.org:
resource alternates variants
-------- ---------- --------
----- plain resource ---------- variant 1
/ http://x.org/intro.mpeg
/
transparent resource ------- plain resource ---------- variant 2
http://x.org/intro \ http://x.org/intro.quicktime
\
\ ------ variant 3
\ /
--- opaque resource ------- variant 4
http://x.org/intro.html
\
------ variant 5
In this example, the transparent resource http://x.org/intro has
three different alternates and five different variants. It is not
expected that opaque alternate resources like the
http://x.org/intro.html above will be used often.
An opaque alternate resource could be useful, for example, to
opaquely negotiate around bugs in the HTML rendering code of certain
user agents. The resource http://x.org/intro.html above would use an
opaque algorithm located at the origin server, which looks at the
User-Agent request header to select a html variant which will render
without triggering bugs. If variant 4 is returned when
http://x.org/intro is accessed, this will be the result of
transparent negotiation, which selected http://x.org/intro.html as
the best alternate, followed by opaque negotiation, which selected
variant 4 as the best variant.
Note that use of opaque resources is not necessary to negotiate on
features, rather than bugs, of HTML rendering engines. The feature
negotiation facilities of transparent negotiation allow for
negotiation on HTML rendering features with greater flexibility and
efficiency.
[End of text]
Received on Monday, 29 April 1996 15:57:08 UTC