As per Relevance of the word transparent, we have this rfc below:
Network Working Group K.
Request for Comments: 2295
Category: Experimental A.
Hewlett-
March 1998
Transparent Content Negotiation in
Status of this
This memo defines an Experimental Protocol for the
community. It does not specify an Internet standard of any kind
Discussion and suggestions for improvement are requested
Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
HTTP allows web site authors to put multiple versions of the
information under a single URL. Transparent content negotiation
an extensible negotiation mechanism, layered on top of HTTP,
automatically selecting the best version when the URL is accessed
This enables the smooth deployment of new web data formats and
tags
TABLE OF
1 Introduction................................................4
1.1 Background................................................4
2 Terminology.................................................5
2.1 Terms from HTTP/1.1.......................................5
2.2 New terms.................................................6
3 Notation....................................................8
4 Overview....................................................9
4.1 Content negotiation.......................................9
4.2 HTTP/1.0 style negotiation scheme.........................9
4.3 Transparent content negotiation scheme...................10
4.4 Optimizing the negotiation process.......................12
4.5 Downwards compatibility with non-negotiating user agents.14
4.6 Retrieving a variant by hand.............................15
4.7 Dimensions of negotiation................................15
Holtman & Mutz Experimental [Page 1]
RFC 2295 Transparent Content Negotiation March 1998
4.8 Feature negotiation......................................15
4.9 Length of variant lists..................................16
4.10 Relation with other negotiation schemes.................16
5 Variant descriptions.......................................17
5.1 Syntax...................................................17
5.2 URI......................................................17
5.3 Source-quality...........................................18
5.4 Type, charset, language, and length......................19
5.5 Features.................................................19
5.6 Description..............................................19
5.7 Extension-attribute......................................20
6 Feature negotiation........................................20
6.1 Feature tags.............................................20
6.1.1 Feature tag values.....................................21
6.2 Feature sets.............................................21
6.3 Feature predicates.......................................22
6.4 Features attribute.......................................24
7 Remote variant selection algorithms........................25
7.1 Version numbers..........................................25
8 Content negotiation status codes and headers...............25
8.1 506 Variant Also Negotiates..............................25
8.2 Accept-Features..........................................26
8.3 Alternates...............................................27
8.4 Negotiate................................................28
8.5 TCN......................................................30
8.6 Variant-Vary.............................................30
9 Cache validators...........................................31
9.1 Variant list validators..................................31
9.2 Structured entity tags...................................31
9.3 Assigning entity tags to variants........................32
10 Content negotiation responses..............................32
10.1 List response...........................................33
10.2 Choice response.........................................34
10.3 Adhoc response..........................................37
10.4 Reusing the Alternates header...........................38
10.5 Extracting a normal response from a choice response.....39
10.6 Elaborate Vary headers..................................39
10.6.1 Construction of an elaborate Vary header..............40
10.6.2 Caching of an elaborate Vary header...................41
10.7 Adding an Expires header for HTTP/1.0 compatibility.....41
10.8 Negotiation on content encoding.........................41
Holtman & Mutz Experimental [Page 2]
RFC 2295 Transparent Content Negotiation March 1998
11 User agent support for transparent negotiation.............42
11.1 Handling of responses...................................42
11.2 Presentation of a transparently negotiated resource.....42
12 Origin server support for transparent negotiation..........43
12.1 Requirements............................................43
12.2 Negotiation on transactions other than GET and HEAD.....45
13 Proxy support for transparent negotiation..................45
14 Security and privacy considerations........................46
14.1 Accept- headers revealing personal information..........46
14.2 Spoofing of responses from variant resources............47
14.3 Security holes revealed by negotiation..................47
15 Internationalization considerations........................47
16 Acknowledgments............................................47
17 References.................................................48
18 Authors' Addresses.........................................48
19 Appendix: Example of a local variant selection algorithm...49
19.1 Computing overall quality values........................49
19.2 Determining the result..................................51
19.3 Ranking dimensions......................................51
20 Appendix: feature negotiation examples.....................52
20.1 Use of feature tags.....................................52
20.2 Use of numeric feature tags.............................53
20.3 Feature tag design......................................53
21 Appendix: origin server implementation considerations......54
21.1 Implementation with a CGI script........................54
21.2 Direct support by HTTP servers..........................55
21.3 Web publishing tools....................................55
22 Appendix: Example of choice response construction..........55
23 Full Copyright Statement...................................58
Holtman & Mutz Experimental [Page 3]
RFC 2295 Transparent Content Negotiation March 1998
1
HTTP allows web site authors to put multiple versions of the
information under a single URI. Each of these versions is called
`variant'. Transparent content negotiation is an
negotiation mechanism for automatically and efficiently
the best variant when a GET or HEAD request is made. This
the smooth deployment of new web data formats and markup tags
This specification defines transparent content negotiation as
extension on top of the HTTP/1.1 protocol [1]. However, use of
extension does not require use of HTTP/1.1: transparent
negotiation can also be done if some or all of the parties
HTTP/1.0 [2] systems
Transparent content negotiation is called `transparent' because
makes all variants which exist inside the origin server visible
outside parties
Note: Some members of the IETF are currently undertaking a
of activities which are loosely related to this
protocol. First, there is an effort to define a protocol
independent registry for feature tags. The intention is that
experimental protocol will be one of the clients of the registry
Second, some research is being done on content negotiation
for other transport protocols (like internet mail and internet fax
and on generalized negotiation systems for multiple
protocols. At the time of writing, it is unclear if or when
research will lead to results in the form of complete
system specifications. It is also unclear to which extent
future specifications can or will re-use elements of
experimental protocol
1.1
The addition of content negotiation to the web infrastructure
been considered important since the early days of the web. Among
expected benefits of a sufficiently powerful system for
negotiation
* smooth deployment of new data formats and markup tags
allow graceful evolution of the
* eliminating the need to choose between a `state of the
multimedia homepage' and one which can be viewed by all web
* enabling good service to a wider range of
platforms (from low-end PDA's to high-end VR setups
Holtman & Mutz Experimental [Page 4]
RFC 2295 Transparent Content Negotiation March 1998
* eliminating error-prone and cache-
User-Agent based
* enabling construction of sites without `click here for the
version'
* internationalization, and the ability to offer multi-
content without a bias towards one language
2
The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
this document are to be interpreted as described in RFC 2119 [4].
This specification uses the term `header' as an abbreviation for
`header field in a request or response message'.
2.1 Terms from HTTP/1.1
This specification mostly uses the terminology of the HTTP/1.1
specification [1]. For the convenience of the reader, this
reproduces some key terminology definition from [1].
An HTTP request message
An HTTP response message
A network data object or service that can be identified by a URI
Resources may be available in multiple representations (e.g
multiple languages, data formats, size, resolutions) or vary
other ways
content
The mechanism for selecting the appropriate representation
servicing a request
A program that establishes connections for the purpose of
requests
user
The client which initiates a request. These are often browsers
editors, spiders (web-traversing robots), or other end user tools
Holtman & Mutz Experimental [Page 5]
RFC 2295 Transparent Content Negotiation March 1998
An application program that accepts connections in order to
requests by sending back responses. Any given program may
capable of being both a client and a server; our use of these
refers only to the role being performed by the program for
particular connection, rather than to the program's capabilities
general. Likewise, any server may act as an origin server, proxy
gateway, or tunnel, switching behavior based on the nature of
request
origin
The server on which a given resource resides or is to be created
An intermediary program which acts as both a server and a
for the purpose of making requests on behalf of other clients
Requests are serviced internally or by passing them on,
possible translation, to other servers. A proxy must
both the client and server requirements of this specification
The age of a response is the time since it was sent by,
successfully validated with, the origin server
A response is fresh if its age has not yet exceeded its
lifetime
2.2 New
transparently negotiable
A resource, identified by a single URI, which has
representations (variants) associated with it. When servicing
request on its URI, it allows selection of the best
using the transparent content negotiation mechanism.
transparently negotiable resource always has a variant list
to it, which can be represented as an Alternates header (defined
section 8.3).
variant
A list containing variant descriptions, which can be bound to
transparently negotiable resource
Holtman & Mutz Experimental [Page 6]
RFC 2295 Transparent Content Negotiation March 1998
variant
A machine-readable description of a variant resource, usually
in a variant list. A variant description contains the
resource URI and various attributes which describe properties
the variant. Variant descriptions are defined in section 5.
variant
A resource from which a variant of a negotiable resource can
retrieved with a normal HTTP/1.x GET request, i.e. a GET
which does not use transparent content negotiation
neighboring
A variant resource is called a neighboring variant resource of
transparently negotiable HTTP resource if the variant resource
a HTTP URL, and if the absolute URL of the variant resource up
its last slash equals the absolute URL of the negotiable
up to its last slash, where equality is determined with the
comparison rules in section 3.2.3 of [1]. The property of being
neighboring variant is important because of security
(section 14.2). Not all variants of a negotiable resource need
be neighboring variants. However, access to neighboring
can be more highly optimized by the use of remote variant
algorithms (section 7) and choice responses (section 10.2).
remote variant selection
A standardized algorithm by which a server can sometimes choose
best variant on behalf of a negotiating user agent. The
typically computes whether the Accept- headers in the
contain sufficient information to allow a choice, and if so,
variant is the best variant. The use of a remote algorithm
speed up the negotiation process
list
A list response returns the variant list of the
resource, but no variant data. It can be generated when the
does not want to, or is not allowed to, return a particular
variant for the request. List responses are defined in
10.1.
choice
A choice response returns a representation of the best variant
the request, and may also return the variant list of the
resource. It can be generated when the server has
information to be able to choose the best variant on behalf
user agent, but may only be generated if this best variant is
neighboring variant. Choice responses are defined in section 10.2.
Holtman & Mutz Experimental [Page 7]
RFC 2295 Transparent Content Negotiation March 1998
adhoc
An adhoc response can be sent by an origin server as an
measure, to achieve compatibility with a non-negotiating or
client if this compatibility cannot be achieved by sending a
or choice response. There are very little requirements on
contents of an adhoc response. Adhoc responses are defined
section 10.3.
Accept-
The request headers: Accept, Accept-Charset, Accept-Language,
Accept-Features
supports transparent content
From the viewpoint of an origin server or proxy, a user
supports transparent content negotiation if and only if it sends
Negotiate header (section 8.4) which indicates such support
server-side
If a request on a transparently negotiated resource is made by
client which supports transparent content negotiation, an
server is said to perform a server-side override if the
ignores the directives in the Negotiate request header, and
uses a custom algorithm to choose an appropriate response.
server-side override can sometimes be used to work around
client bugs. It could also be used by protocol extensions on
of transparent content negotiation
3
The version of BNF used in this document is taken from [1], and
of the nonterminals used are defined in [1]. Note that
underlying charset is US-ASCII
One new BNF construct is added
1%
stands for one or more instances of "rule", separated by whitespace
1%rule = rule *( 1*LWS rule )
This specification also
number = 1*
short-float = 1*3DIGIT [ "." 0*3DIGIT ]
Holtman & Mutz Experimental [Page 8]
RFC 2295 Transparent Content Negotiation March 1998
This specification uses the same conventions as in [1] (see
1.2 of [1]) for defining the significance of each
requirement
4
This section gives an overview of transparent content negotiation
It starts with a more general discussion of negotiation as
by HTTP
4.1 Content
HTTP/1.1 allows web site authors to put multiple versions of the
information under a single resource URI. Each of these versions
called a `variant'. For example, a resource http://x.org/paper
bind to three different variants of a paper
1. HTML,
2. HTML,
3. Postscript,
Content negotiation is the process by which the best variant
selected if the resource is accessed. The selection is done
matching the properties of the available variants to the
of the user agent and the preferences of the user
It has always been possible under HTTP to have
representations available for one resource, and to return the
appropriate representation for each subsequent request. However
HTTP/1.1 is the first version of HTTP which has provisions for
this in a cache-friendly way. These provisions include the
response header, entity tags, and the If-None-Match request header
4.2 HTTP/1.0 style negotiation
The HTTP/1.0 protocol elements allow for a negotiation scheme
follows
Server _____ proxy _____ proxy _____
x.org cache cache
< ----------------------------------
| GET http://x.org/
| Accept-
|
---------------------------------- >
Best
Holtman & Mutz Experimental [Page 9]
RFC 2295 Transparent Content Negotiation March 1998
When the resource is accessed, the user agent sends (along with
request) various Accept- headers which express the user
capabilities and the user preferences. Then the origin server
these Accept- headers to choose the best variant, which is
in the response
The biggest problem with this scheme is that it does not scale well
For all but the most minimal user agents, Accept- headers
all capabilities and preferences would be very large, and
them in every request would be hugely inefficient, in
because only a small fraction of the resources on the web
multiple variants
4.3 Transparent content negotiation
The transparent content negotiation scheme eliminates the need
send huge Accept- headers, and nevertheless allows for a
process that always yields either the best variant, or an
message indicating that user agent is not capable of displaying
of the available variants
Under the transparent content negotiation scheme, the server sends
list with the available variants and their properties to the
agent. An example of a list with three variants
{"paper.1" 0.9 {type text/html} {language en}},
{"paper.2" 0.7 {type text/html} {language fr}},
{"paper.3" 1.0 {type application/postscript} {language en}}
The syntax and semantics of the variant descriptions in this list
covered in section 5. When the list is received, the user agent
choose the best variant and retrieve it. Graphically,
communication can be represented as follows
Holtman & Mutz Experimental [Page 10]
RFC 2295 Transparent Content Negotiation March 1998
Server _____ proxy _____ proxy _____
x.org cache cache
< ----------------------------------
| GET http://x.org/
|
----------------------------------- > [list response
return of list |
|
< ----------------------------------
| GET http://x.org/paper.1
|
---------------------------------- > [normal response
return of paper.1
The first response returning the list of variants is called a `
response'. The second response is a normal HTTP response: it
not contain special content negotiation related information.
the user agent needs to know that the second request
retrieves a variant. For the other parties in the communication,
second transaction is indistinguishable from a normal
transaction
With this scheme, information about capabilities and preferences
only used by the user agent itself. Therefore, sending
information in large Accept- headers is unnecessary. Accept-
do have a limited use in transparent content negotiation however;
sending of small Accept- headers can often speed up the
process. This is covered in section 4.4.
List responses are covered in section 10.1. As an example, the
response in the above picture could be
HTTP/1.1 300 Multiple
Date: Tue, 11 Jun 1996 20:02:21
TCN:
Alternates: {"paper.1" 0.9 {type text/html} {language en}},
{"paper.2" 0.7 {type text/html} {language fr}},
{"paper.3" 1.0 {type application/postscript
{language en}}
Vary: negotiate, accept, accept-
ETag: "blah;1234"
Cache-control: max-age=86400
Content-Type: text/
Content-Length: 227
Holtman & Mutz Experimental [Page 11]
RFC 2295 Transparent Content Negotiation March 1998
HTML, English version
HTML, French version
Postscript, English version
The Alternates header in the response contains the variant list.
Vary header is included to ensure correct caching by plain HTTP/1.1
caches (see section 10.6). The ETag header allows the response to
revalidated by caches, the Cache-Control header controls
revalidation. The HTML entity included in the response allows
user to select the best variant by hand if desired
4.4 Optimizing the negotiation
The basic transparent negotiation scheme involves two
transactions: one to retrieve the list, and a second one to
the chosen variant. There are however several ways to `cut corners
in the data flow path of the basic scheme
First, caching proxies can cache both variant lists and variants
Such caching can reduce the communication overhead, as shown in
following example
Server _____ proxy _____ proxy __________
x.org cache cache
< --------------
| GET ../
|
has the
in
|
------------- > [list response
list |
|
|
< --------------------------
| GET ../paper.1
|
has the
in
|
-------------------------- > [normal response
return of paper.1
Holtman & Mutz Experimental [Page 12]
RFC 2295 Transparent Content Negotiation March 1998
Second, the user agent can send small Accept- headers, which
contain enough information to allow the server to choose the
variant and return it directly
Server _____ proxy _____ proxy _____
x.org cache cache
< ----------------------------------
| GET http://x.org/
| small Accept-
|
able to choose
behalf of user
|
---------------------------------- > [choice response
return of paper.1 and
This choosing based on small Accept- headers is done with a `
variant selection algorithm'. Such an algorithm takes the
list and the Accept- headers as input. It then computes whether
Accept- headers contain sufficient information to choose on behalf
the user agent, and if so, which variant is the best variant. If
best variant is a neighboring variant, it may be returned,
with the variant list, in a choice response
A server may only choose on behalf of a user agent
transparent content negotiation if the user agent explicitly
the use of a particular remote variant selection algorithm in
Negotiate request header. User agents with sophisticated
variant selection algorithms may want to disallow a remote choice,
may want to allow it only when retrieving inline images. If
local algorithm of the user agent is superior in only some
areas of negotiation, it is possible to enable the remote
for the easy areas only. More information about the use of a
variant selection algorithm can be found in [3].
Choice responses are covered in section 10.2. For example,
choice response in the above picture could be
HTTP/1.1 200
Date: Tue, 11 Jun 1996 20:05:31
TCN:
Content-Type: text/
Last-Modified: Mon, 10 Jun 1996 10:01:14
Content-Length: 5327
Cache-control: max-age=604800
Content-Location: paper.1
Alternates: {"paper.1" 0.9 {type text/html} {language en}},
Holtman & Mutz Experimental [Page 13]
RFC 2295 Transparent Content Negotiation March 1998
{"paper.2" 0.7 {type text/html} {language fr}},
{"paper.3" 1.0 {type application/postscript
{language en}}
Etag: "gonkyyyy;1234"
Vary: negotiate, accept, accept-
Expires: Thu, 01 Jan 1980 00:00:00
A paper about ....<br>
<br>
Finally, the above two kinds of optimization can be combined; <br>
caching proxy which has the list will <A HREF="/relevance/projects/rfc/sometimes.html">sometimes</A> be able to choose <br>
behalf of the user agent. This could lead to the <br>
<A HREF="/relevance/projects/rfc/communication.html">communication</A> pattern<br>
<br>
Server _____ proxy _____ proxy __________ <br>
x.org cache cache <br>
<br>
< ---------------<br>
| GET ../<br>
| small <br>
|<br>
able to <br>
on <br>
|<br>
< ----------<br>
| GET ../paper.1<br>
|<br>
---------- > [normal <A HREF="/relevance/projects/rfc/response.html">response</A><br>
paper.1 |<br>
---------------- > [choice <A HREF="/relevance/projects/rfc/response.html">response</A><br>
paper.1 and <br>
<br>
Note that this cutting of corners not only saves <A HREF="/relevance/projects/rfc/bandwidth.html">bandwidth</A>, it <br>
eliminates delays due to packet round trip times, and reduces <br>
load on the origin server<br>
<br>
4.5 Downwards compatibility with non-negotiating user <br>
<br>
To handle <A HREF="/relevance/projects/rfc/requests.html">requests</A> from user agents which do not support <br>
content <A HREF="/relevance/projects/rfc/negotiation.html">negotiation</A>, this <A HREF="/relevance/projects/rfc/specification.html">specification</A> allows the origin server <br>
revert to a HTTP/1.0 style <A HREF="/relevance/projects/rfc/negotiation.html">negotiation</A> scheme. The <A HREF="/relevance/projects/rfc/specification.html">specification</A> <br>
heuristics for such schemes is beyond the scope of this <A HREF="/relevance/projects/rfc/document.html">document</A><br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
Holtman & Mutz <A HREF="/relevance/projects/rfc/experimental.html">Experimental</A> [Page 14]<br>
<br>
RFC 2295 <A HREF="/relevance/projects/rfc/transparent.html">Transparent</A> Content <A HREF="/relevance/projects/rfc/negotiation.html">Negotiation</A> March 1998<br>
<br>
<br>
4.6 Retrieving a variant by <br>
<br>
It is always <A HREF="/relevance/projects/rfc/possible.html">possible</A> for a user agent to <A HREF="/relevance/projects/rfc/retrieve.html">retrieve</A> the variant <br>
which is bound to a negotiable <A HREF="/relevance/projects/rfc/resource.html">resource</A>. The user agent can use <br>
list to make <A HREF="/relevance/projects/rfc/available.html">available</A> a menu of all <A HREF="/relevance/projects/rfc/variants.html">variants</A> and <br>
characteristics to the user. Such a menu allows the user to <br>
browse other <A HREF="/relevance/projects/rfc/variants.html">variants</A>, and makes it <A HREF="/relevance/projects/rfc/possible.html">possible</A> to manually correct <br>
sub-optimal choice made by the <A HREF="/relevance/projects/rfc/automatic.html">automatic</A> <A HREF="/relevance/projects/rfc/negotiation.html">negotiation</A> process<br>
<br>
4.7 Dimensions of <br>
<br>
<A HREF="/relevance/projects/rfc/transparent.html">Transparent</A> content <A HREF="/relevance/projects/rfc/negotiation.html">negotiation</A> defines four dimensions <br>
<A HREF="/relevance/projects/rfc/negotiation.html">negotiation</A><br>
<br>
1. Media type (MIME type<br>
2. <br>
3. <br>
4. <br>
<br>
The first three dimensions have traditionally been present in HTTP<br>
The fourth dimension is added by this <A HREF="/relevance/projects/rfc/specification.html">specification</A>. <br>
dimensions, beyond the four mentioned above, could be added by <br>
<A HREF="/relevance/projects/rfc/specifications.html">specifications</A><br>
<br>
<A HREF="/relevance/projects/rfc/negotiation.html">Negotiation</A> on the content <A HREF="/relevance/projects/rfc/encoding.html">encoding</A> of a <A HREF="/relevance/projects/rfc/response.html">response</A> (gzipped<br>
<A HREF="/relevance/projects/rfc/compressed.html">compressed</A>, etc.) is left outside of the realm of <br>
<A HREF="/relevance/projects/rfc/negotiation.html">negotiation</A>. See section 10.8 for more <A HREF="/relevance/projects/rfc/information.html">information</A><br>
<br>
4.8 Feature <br>
<br>
Feature <A HREF="/relevance/projects/rfc/negotiation.html">negotiation</A> intends to provide for all areas of <br>
not covered by the type, charset, and <A HREF="/relevance/projects/rfc/language.html">language</A> dimensions. <br>
are <A HREF="/relevance/projects/rfc/negotiation.html">negotiation</A> <br>
<br>
* HTML <br>
* <A HREF="/relevance/projects/rfc/extensions.html">Extensions</A> of other media <br>
* Color <A HREF="/relevance/projects/rfc/capabilities.html">capabilities</A> of the user <br>
* Screen <br>
* Output medium (screen, paper, ...)<br>
* <A HREF="/relevance/projects/rfc/preference.html">Preference</A> for speed vs. <A HREF="/relevance/projects/rfc/preference.html">preference</A> for graphical <br>
<br>
The feature <A HREF="/relevance/projects/rfc/negotiation.html">negotiation</A> <A HREF="/relevance/projects/rfc/framework.html">framework</A> (section 6) is the <A HREF="/relevance/projects/rfc/principal.html">principal</A> <br>
by which <A HREF="/relevance/projects/rfc/transparent.html">transparent</A> <A HREF="/relevance/projects/rfc/negotiation.html">negotiation</A> offers extensibility; a <br>
dimension of <A HREF="/relevance/projects/rfc/negotiation.html">negotiation</A> (really a sub-dimension of the <br>
dimension) can be added without the need for a new <A HREF="/relevance/projects/rfc/standards.html">standards</A> <br>
by the simple <A HREF="/relevance/projects/rfc/registration.html">registration</A> of a `feature tag'.<br>
<br>
<br>
<br>
<br>
<br>
Holtman & Mutz <A HREF="/relevance/projects/rfc/experimental.html">Experimental</A> [Page 15]<br>
<br>
RFC 2295 <A HREF="/relevance/projects/rfc/transparent.html">Transparent</A> Content <A HREF="/relevance/projects/rfc/negotiation.html">Negotiation</A> March 1998<br>
<br>
<br>
4.9 Length of variant <br>
<br>
As a general rule, variant lists should be short: it is <A HREF="/relevance/projects/rfc/expected.html">expected</A> <br>
a typical transparently negotiable <A HREF="/relevance/projects/rfc/resource.html">resource</A> will have 2 to 10<br>
<A HREF="/relevance/projects/rfc/variants.html">variants</A>, depending on its purpose. Variant lists should be <br>
for a number of reasons<br>
<br>
1. The user must be able to pick a variant by hand to correct <br>
bad <A HREF="/relevance/projects/rfc/automatic.html">automatic</A> choice, and this is more difficult with a <br>
variant list<br>
<br>
2. A large number of <A HREF="/relevance/projects/rfc/variants.html">variants</A> will decrease the <A HREF="/relevance/projects/rfc/efficiency.html">efficiency</A> <br>
<A HREF="/relevance/projects/rfc/internet.html">internet</A> proxy caches<br>
<br>
3. Long variant lists will make some transparently <br>
responses longer<br>
<br>
In general, it is not <A HREF="/relevance/projects/rfc/desirable.html">desirable</A> to create a transparently <br>
<A HREF="/relevance/projects/rfc/resource.html">resource</A> with hundreds of <A HREF="/relevance/projects/rfc/variants.html">variants</A> in order to fine-tune <br>
graphical <A HREF="/relevance/projects/rfc/presentation.html">presentation</A> of a <A HREF="/relevance/projects/rfc/resource.html">resource</A>. Any graphical fine-<br>
should be done, as much as <A HREF="/relevance/projects/rfc/possible.html">possible</A>, by using constructs which act <br>
the user agent side, for <br>
<br>
<center><img src=titlebanner.gif width=100%<br>
alt="MegaBozo Corp"></center<br>
<br>
In order to promote user agent side fine tuning, which is <br>
<A HREF="/relevance/projects/rfc/scalable.html">scalable</A> than fine tuning over the network, user agents <br>
<A HREF="/relevance/projects/rfc/implement.html">implement</A> a scripting <A HREF="/relevance/projects/rfc/language.html">language</A> for content rendering are <br>
to make the availability of this <A HREF="/relevance/projects/rfc/language.html">language</A> visible for <br>
content <A HREF="/relevance/projects/rfc/negotiation.html">negotiation</A>, and to allow rendering scripts to access <br>
<A HREF="/relevance/projects/rfc/capabilities.html">capabilities</A> and preferences data used for content <A HREF="/relevance/projects/rfc/negotiation.html">negotiation</A>, <br>
far as privacy <A HREF="/relevance/projects/rfc/considerations.html">considerations</A> permit this<br>
<br>
4.10 <A HREF="/relevance/projects/rfc/relation.html">Relation</A> with other <A HREF="/relevance/projects/rfc/negotiation.html">negotiation</A> <br>
<br>
The HTTP/1.x <A HREF="/relevance/projects/rfc/protocol.html">protocol</A> suite allows for many <A HREF="/relevance/projects/rfc/different.html">different</A> <br>
mechanisms. <A HREF="/relevance/projects/rfc/transparent.html">Transparent</A> content <A HREF="/relevance/projects/rfc/negotiation.html">negotiation</A> specializes in <A HREF="/relevance/projects/rfc/scalable.html">scalable</A><br>
interoperable <A HREF="/relevance/projects/rfc/negotiation.html">negotiation</A> of content representations at the <br>
level. It is intended that <A HREF="/relevance/projects/rfc/transparent.html">transparent</A> <A HREF="/relevance/projects/rfc/negotiation.html">negotiation</A> can co-exist <br>
other <A HREF="/relevance/projects/rfc/negotiation.html">negotiation</A> schemes, both open and proprietary, which <br>
<A HREF="/relevance/projects/rfc/different.html">different</A> <A HREF="/relevance/projects/rfc/application.html">application</A> domains or work at <A HREF="/relevance/projects/rfc/different.html">different</A> points in <br>
author-to-user chain. Ultimately, it will be up to the <br>
author to decide which <A HREF="/relevance/projects/rfc/negotiation.html">negotiation</A> <A HREF="/relevance/projects/rfc/mechanism.html">mechanism</A>, or <A HREF="/relevance/projects/rfc/combination.html">combination</A> <br>
<A HREF="/relevance/projects/rfc/negotiation.html">negotiation</A> mechanisms, is most <A HREF="/relevance/projects/rfc/appropriate.html">appropriate</A> for the task at hand<br>
<br>
<br>
<br>
<br>
<br>
<br>
Holtman & Mutz <A HREF="/relevance/projects/rfc/experimental.html">Experimental</A> [Page 16]<br>
<br>
RFC 2295 <A HREF="/relevance/projects/rfc/transparent.html">Transparent</A> Content <A HREF="/relevance/projects/rfc/negotiation.html">Negotiation</A> March 1998<br>
<br>
<br>
5 Variant <br>
<br>
5.1 <br>
<br>
A variant can be <A HREF="/relevance/projects/rfc/described.html">described</A> in a machine-<A HREF="/relevance/projects/rfc/readable.html">readable</A> way with a <br>
<A HREF="/relevance/projects/rfc/description.html">description</A><br>
<br>
variant-<A HREF="/relevance/projects/rfc/description.html">description</A> =<br>
"{" <"> URI <"> source-quality *variant-<A HREF="/relevance/projects/rfc/attribute.html">attribute</A>"}"<br>
<br>
source-quality = <br>
<br>
variant-<A HREF="/relevance/projects/rfc/attribute.html">attribute</A> = "{" "type" media-type "}"<br>
| "{" "charset" charset "}"<br>
| "{" "<A HREF="/relevance/projects/rfc/language.html">language</A>" 1#<A HREF="/relevance/projects/rfc/language.html">language</A>-tag "}"<br>
| "{" "length" 1*DIGIT "}"<br>
| "{" "<A HREF="/relevance/projects/rfc/features.html">features</A>" feature-list "}"<br>
| "{" "<A HREF="/relevance/projects/rfc/description.html">description</A><br>
quoted-string [ <A HREF="/relevance/projects/rfc/language.html">language</A>-tag ] "}"<br>
| <A HREF="/relevance/projects/rfc/extension.html">extension</A>-<br>
<br>
<A HREF="/relevance/projects/rfc/extension.html">extension</A>-<A HREF="/relevance/projects/rfc/attribute.html">attribute</A> = "{" <A HREF="/relevance/projects/rfc/extension.html">extension</A>-name <A HREF="/relevance/projects/rfc/extension.html">extension</A>-value "}"<br>
<A HREF="/relevance/projects/rfc/extension.html">extension</A>-name = <br>
<A HREF="/relevance/projects/rfc/extension.html">extension</A>-value = *( token | quoted-string | <br>
| <A HREF="/relevance/projects/rfc/extension.html">extension</A>-specials )<br>
<br>
<A HREF="/relevance/projects/rfc/extension.html">extension</A>-specials =<br>
<any element of tspecials except <"> and "}"><br>
<br>
The feature-list syntax is defined in section 6.4.<br>
<br>
<A HREF="/relevance/projects/rfc/examples.html">Examples</A> <br>
<br>
{"paper.2" 0.7 {type text/html} {<A HREF="/relevance/projects/rfc/language.html">language</A> fr}}<br>
<br>
{"paper.5" 0.9 {type text/html} {<A HREF="/relevance/projects/rfc/features.html">features</A> tables}}<br>
<br>
{"paper.1" 0.001}<br>
<br>
The various attributes which can be present in a variant <br>
are covered in the subsections below. Each <A HREF="/relevance/projects/rfc/attribute.html">attribute</A> may appear <br>
once in a variant <A HREF="/relevance/projects/rfc/description.html">description</A><br>
<br>
5.2 <br>
<br>
The URI <A HREF="/relevance/projects/rfc/attribute.html">attribute</A> gives the URI of the <A HREF="/relevance/projects/rfc/resource.html">resource</A> from which <br>
variant can be retrieved with a GET request. It can be <A HREF="/relevance/projects/rfc/absolute.html">absolute</A> <br>
<A HREF="/relevance/projects/rfc/relative.html">relative</A> to the Request-URI. The variant <A HREF="/relevance/projects/rfc/resource.html">resource</A> may vary (on <br>
<br>
<br>
<br>
Holtman & Mutz <A HREF="/relevance/projects/rfc/experimental.html">Experimental</A> [Page 17]<br>
<br>
RFC 2295 <A HREF="/relevance/projects/rfc/transparent.html">Transparent</A> Content <A HREF="/relevance/projects/rfc/negotiation.html">Negotiation</A> March 1998<br>
<br>
<br>
Cookie request header, for example), but MUST NOT engage <br>
<A HREF="/relevance/projects/rfc/transparent.html">transparent</A> content <A HREF="/relevance/projects/rfc/negotiation.html">negotiation</A> itself<br>
<br>
5.3 Source-<br>
<br>
The source-quality <A HREF="/relevance/projects/rfc/attribute.html">attribute</A> gives the quality of the variant, as <br>
<A HREF="/relevance/projects/rfc/representation.html">representation</A> of the negotiable <A HREF="/relevance/projects/rfc/resource.html">resource</A>, when this variant <br>
rendered with a perfect rendering engine on the best <A HREF="/relevance/projects/rfc/possible.html">possible</A> <br>
medium<br>
<br>
If the source-quality is less than 1, it often expresses a <br>
degradation caused by a lossy <A HREF="/relevance/projects/rfc/conversion.html">conversion</A> to a <A HREF="/relevance/projects/rfc/particular.html">particular</A> data format<br>
For example, a picture <A HREF="/relevance/projects/rfc/originally.html">originally</A> in JPEG form would have a <br>
source quality when translated to the XBM format, and a much <br>
source quality when translated to an ASCII-art variant. <br>
however, that degradation is a <A HREF="/relevance/projects/rfc/function.html">function</A> of the source; an <br>
piece of ASCII-art may degrade in quality if it is captured in <br>
form<br>
<br>
The source-quality could also <A HREF="/relevance/projects/rfc/represent.html">represent</A> a level of quality caused <br>
skill of <A HREF="/relevance/projects/rfc/language.html">language</A> <A HREF="/relevance/projects/rfc/translation.html">translation</A>, or ability of the used media type <br>
capture the intended artistic <A HREF="/relevance/projects/rfc/expression.html">expression</A><br>
<br>
Servers should use the <A HREF="/relevance/projects/rfc/following.html">following</A> table a guide when assigning <br>
quality values<br>
<br>
1.000 perfect <br>
0.900 <A HREF="/relevance/projects/rfc/threshold.html">threshold</A> of noticeable loss of <br>
0.800 noticeable, but acceptable quality <br>
0.500 barely acceptable <br>
0.300 severely degraded <br>
0.000 completely degraded <br>
<br>
The same table can be used by local variant <A HREF="/relevance/projects/rfc/selection.html">selection</A> algorithms (<br>
<A HREF="/relevance/projects/rfc/appendix.html">appendix</A> 19) when assigning degradation factors for <A HREF="/relevance/projects/rfc/different.html">different</A> <br>
rendering mechanisms. Note that most meaningful values in this <br>
are close to 1. This is due to the fact that quality factors <br>
generally combined by multiplying them, not by adding them<br>
<br>
When assigning source-quality values, servers should not account <br>
the size of the variant and its impact on <A HREF="/relevance/projects/rfc/transmission.html">transmission</A> and <br>
delays; the size of the variant should be stated in the <br>
<A HREF="/relevance/projects/rfc/attribute.html">attribute</A> and any size-dependent calculations should be done by <br>
variant <A HREF="/relevance/projects/rfc/selection.html">selection</A> <A HREF="/relevance/projects/rfc/algorithm.html">algorithm</A>. Any <A HREF="/relevance/projects/rfc/constant.html">constant</A> rendering delay for <br>
<A HREF="/relevance/projects/rfc/particular.html">particular</A> media type (for example due to the startup time of <br>
helper <A HREF="/relevance/projects/rfc/application.html">application</A>) should be accounted for by the user agent, <br>
assigning a quality factor to that media type<br>
<br>
<br>
<br>
<br>
Holtman & Mutz <A HREF="/relevance/projects/rfc/experimental.html">Experimental</A> [Page 18]<br>
<br>
RFC 2295 <A HREF="/relevance/projects/rfc/transparent.html">Transparent</A> Content <A HREF="/relevance/projects/rfc/negotiation.html">Negotiation</A> March 1998<br>
<br>
<br>
5.4 Type, charset, <A HREF="/relevance/projects/rfc/language.html">language</A>, and <br>
<br>
The type <A HREF="/relevance/projects/rfc/attribute.html">attribute</A> of a variant <A HREF="/relevance/projects/rfc/description.html">description</A> carries the <br>
<A HREF="/relevance/projects/rfc/information.html">information</A> as its Content-Type <A HREF="/relevance/projects/rfc/response.html">response</A> header counterpart <br>
in [1], except for any charset <A HREF="/relevance/projects/rfc/information.html">information</A>, which MUST be carried <br>
the charset <A HREF="/relevance/projects/rfc/attribute.html">attribute</A>. For, example, the <br>
<br>
Content-Type: text/html; charset=ISO-8859-4<br>
<br>
has the counterpart <br>
<br>
{type text/html} {charset ISO-8859-4}<br>
<br>
The <A HREF="/relevance/projects/rfc/language.html">language</A> and length attributes carry the same <A HREF="/relevance/projects/rfc/information.html">information</A> <br>
their Content-* <A HREF="/relevance/projects/rfc/response.html">response</A> header counterparts in [1]. The <br>
<A HREF="/relevance/projects/rfc/attribute.html">attribute</A>, if present, MUST thus reflect the length of the <br>
alone, and not the total size of the variant and any objects <br>
or <A HREF="/relevance/projects/rfc/embedded.html">embedded</A> by the variant<br>
<br>
Though all of these attributes are <A HREF="/relevance/projects/rfc/optional.html">optional</A>, it is often <A HREF="/relevance/projects/rfc/desirable.html">desirable</A> <br>
include as many attributes as <A HREF="/relevance/projects/rfc/possible.html">possible</A>, as this will <A HREF="/relevance/projects/rfc/increase.html">increase</A> <br>
quality of the <A HREF="/relevance/projects/rfc/negotiation.html">negotiation</A> process<br>
<br>
Note: A server is not <A HREF="/relevance/projects/rfc/required.html">required</A> to <A HREF="/relevance/projects/rfc/maintain.html">maintain</A> a one-to-<br>
<A HREF="/relevance/projects/rfc/correspondence.html">correspondence</A> between the attributes in the variant <br>
and the Content-* headers in the variant <A HREF="/relevance/projects/rfc/response.html">response</A>. For example<br>
if the variant <A HREF="/relevance/projects/rfc/description.html">description</A> <A HREF="/relevance/projects/rfc/contains.html">contains</A> a <A HREF="/relevance/projects/rfc/language.html">language</A> <A HREF="/relevance/projects/rfc/attribute.html">attribute</A>, <br>
<A HREF="/relevance/projects/rfc/response.html">response</A> does not necessarily have to contain a Content-<br>
header. If a Content-<A HREF="/relevance/projects/rfc/language.html">Language</A> header is present, it does not <br>
to contain an exact copy of the <A HREF="/relevance/projects/rfc/information.html">information</A> in the <br>
<A HREF="/relevance/projects/rfc/attribute.html">attribute</A><br>
<br>
5.5 <br>
<br>
The <A HREF="/relevance/projects/rfc/features.html">features</A> <A HREF="/relevance/projects/rfc/attribute.html">attribute</A> <A HREF="/relevance/projects/rfc/specifies.html">specifies</A> how the <A HREF="/relevance/projects/rfc/presence.html">presence</A> or absence <br>
<A HREF="/relevance/projects/rfc/particular.html">particular</A> feature tags in the user agent affects the overall <br>
of the variant. This <A HREF="/relevance/projects/rfc/attribute.html">attribute</A> is covered in section 6.4.<br>
<br>
5.6 <br>
<br>
The <A HREF="/relevance/projects/rfc/description.html">description</A> <A HREF="/relevance/projects/rfc/attribute.html">attribute</A> gives a textual <A HREF="/relevance/projects/rfc/description.html">description</A> of the variant<br>
It can be <A HREF="/relevance/projects/rfc/included.html">included</A> if the URI and normal attributes of a variant <br>
<A HREF="/relevance/projects/rfc/considered.html">considered</A> too opaque to allow <A HREF="/relevance/projects/rfc/interpretation.html">interpretation</A> by the user. If a <br>
agent is showing a menu of <A HREF="/relevance/projects/rfc/available.html">available</A> <A HREF="/relevance/projects/rfc/variants.html">variants</A> compiled from a <br>
list, and if a variant has a <A HREF="/relevance/projects/rfc/description.html">description</A> <A HREF="/relevance/projects/rfc/attribute.html">attribute</A>, the user <br>
SHOULD show the <A HREF="/relevance/projects/rfc/description.html">description</A> <A HREF="/relevance/projects/rfc/attribute.html">attribute</A> of the variant instead <br>
showing the normal attributes of the variant. The <A HREF="/relevance/projects/rfc/description.html">description</A> <br>
uses the UTF-8 <A HREF="/relevance/projects/rfc/character.html">character</A> <A HREF="/relevance/projects/rfc/encoding.html">encoding</A> scheme [5], which is a superset <br>
<br>
<br>
<br>
Holtman & Mutz <A HREF="/relevance/projects/rfc/experimental.html">Experimental</A> [Page 19]<br>
<br>
RFC 2295 <A HREF="/relevance/projects/rfc/transparent.html">Transparent</A> Content <A HREF="/relevance/projects/rfc/negotiation.html">Negotiation</A> March 1998<br>
<br>
<br>
US-ASCII, with ""%" HEX HEX" <A HREF="/relevance/projects/rfc/encoding.html">encoding</A>. The <A HREF="/relevance/projects/rfc/optional.html">optional</A> <A HREF="/relevance/projects/rfc/language.html">language</A> tag <br>
be used to specify the <A HREF="/relevance/projects/rfc/language.html">language</A> used in the <A HREF="/relevance/projects/rfc/description.html">description</A> text<br>
<br>
5.7 <A HREF="/relevance/projects/rfc/extension.html">Extension</A>-<br>
<br>
The <A HREF="/relevance/projects/rfc/extension.html">extension</A>-<A HREF="/relevance/projects/rfc/attribute.html">attribute</A> allows future <A HREF="/relevance/projects/rfc/specifications.html">specifications</A> to <br>
define dimensions of <A HREF="/relevance/projects/rfc/negotiation.html">negotiation</A> which cannot be created by using <br>
feature <A HREF="/relevance/projects/rfc/negotiation.html">negotiation</A> <A HREF="/relevance/projects/rfc/framework.html">framework</A>, and eases content <br>
experiments. In <A HREF="/relevance/projects/rfc/experimental.html">experimental</A> situations, servers MUST ONLY <br>
<A HREF="/relevance/projects/rfc/extension.html">extension</A>-attributes whose names start with "x-". User agents <br>
ignore all <A HREF="/relevance/projects/rfc/extension.html">extension</A> attributes they do not recognize. Proxies <br>
NOT run a remote variant <A HREF="/relevance/projects/rfc/selection.html">selection</A> <A HREF="/relevance/projects/rfc/algorithm.html">algorithm</A> if an unknown <br>
<A HREF="/relevance/projects/rfc/attribute.html">attribute</A> is present in the variant list<br>
<br>
6 Feature <br>
<br>
This section defines the feature <A HREF="/relevance/projects/rfc/negotiation.html">negotiation</A> <A HREF="/relevance/projects/rfc/mechanism.html">mechanism</A>. <br>
<A HREF="/relevance/projects/rfc/negotiation.html">negotiation</A> has been introduced in section 4.8. <A HREF="/relevance/projects/rfc/appendix.html">Appendix</A> 19 <br>
<A HREF="/relevance/projects/rfc/examples.html">examples</A> of feature <A HREF="/relevance/projects/rfc/negotiation.html">negotiation</A><br>
<br>
6.1 Feature <br>
<br>
A feature tag (ftag) identifies <A HREF="/relevance/projects/rfc/something.html">something</A> which can be negotiated on<br>
for example a <A HREF="/relevance/projects/rfc/property.html">property</A> (feature) of a <A HREF="/relevance/projects/rfc/representation.html">representation</A>, a <br>
(feature) of a user agent, or the <A HREF="/relevance/projects/rfc/preference.html">preference</A> of a user for <br>
<A HREF="/relevance/projects/rfc/particular.html">particular</A> type of <A HREF="/relevance/projects/rfc/representation.html">representation</A>. The use of feature tags need <br>
be limited to <A HREF="/relevance/projects/rfc/transparent.html">transparent</A> content <A HREF="/relevance/projects/rfc/negotiation.html">negotiation</A>, and not every <br>
tag needs to be usable in the HTTP <A HREF="/relevance/projects/rfc/transparent.html">transparent</A> content <br>
<A HREF="/relevance/projects/rfc/framework.html">framework</A><br>
<br>
ftag = token | quoted-<br>
<br>
Note: A <A HREF="/relevance/projects/rfc/protocol.html">protocol</A>-<A HREF="/relevance/projects/rfc/independent.html">independent</A> system for feature tag <br>
is <A HREF="/relevance/projects/rfc/currently.html">currently</A> being developed in the IETF. This <A HREF="/relevance/projects/rfc/specification.html">specification</A> <br>
not define any feature tags. In <A HREF="/relevance/projects/rfc/experimental.html">experimental</A> situations, the <br>
of tags which start with "x." is encouraged<br>
<br>
Feature tags are used in feature sets (section 6.2) and in <br>
predicates (section 6.3). Feature predicates are in turn used <br>
<A HREF="/relevance/projects/rfc/features.html">features</A> attributes (section 6.4), which are used in <br>
descriptions (section 5). Variant descriptions can be <A HREF="/relevance/projects/rfc/transmitted.html">transmitted</A> <br>
Alternates headers (section 8.3).<br>
<br>
The US-ASCII charset is used for feature tags. Feature <br>
<A HREF="/relevance/projects/rfc/comparison.html">comparison</A> is case-insensitive. A token tag XYZ is equal to <br>
quoted-string tag "XYZ". <A HREF="/relevance/projects/rfc/examples.html">Examples</A> <br>
<br>
tables, fonts, blebber, wolx, screenwidth, <br>
<br>
<br>
<br>
Holtman & Mutz <A HREF="/relevance/projects/rfc/experimental.html">Experimental</A> [Page 20]<br>
<br>
RFC 2295 <A HREF="/relevance/projects/rfc/transparent.html">Transparent</A> Content <A HREF="/relevance/projects/rfc/negotiation.html">Negotiation</A> March 1998<br>
<br>
<br>
An example of the use of feature tags in a variant <A HREF="/relevance/projects/rfc/description.html">description</A> is<br>
<br>
{"index.html" 1.0 {type text/html} {<A HREF="/relevance/projects/rfc/features.html">features</A> tables frames}}<br>
<br>
This <A HREF="/relevance/projects/rfc/specification.html">specification</A> follows general <A HREF="/relevance/projects/rfc/computing.html">computing</A> <A HREF="/relevance/projects/rfc/practice.html">practice</A> in that <br>
places no restrictions on what may be called a feature. At <br>
<A HREF="/relevance/projects/rfc/protocol.html">protocol</A> level, this <A HREF="/relevance/projects/rfc/specification.html">specification</A> does not <A HREF="/relevance/projects/rfc/distinguish.html">distinguish</A> <br>
<A HREF="/relevance/projects/rfc/different.html">different</A> uses of feature tags: a tag will be processed in the <br>
way, no matter whether it identifies a <A HREF="/relevance/projects/rfc/property.html">property</A>, <A HREF="/relevance/projects/rfc/capability.html">capability</A>, <br>
<A HREF="/relevance/projects/rfc/preference.html">preference</A>. For some tags, it may be fluid whether the <br>
<A HREF="/relevance/projects/rfc/represents.html">represents</A> a <A HREF="/relevance/projects/rfc/property.html">property</A>, <A HREF="/relevance/projects/rfc/preference.html">preference</A>, or <A HREF="/relevance/projects/rfc/capability.html">capability</A>. For example, <br>
content <A HREF="/relevance/projects/rfc/negotiation.html">negotiation</A> on web pages, a "textonly" tag would identify <br>
<A HREF="/relevance/projects/rfc/capability.html">capability</A> of a text-only user agent, but the user of a <br>
user agent may use this tag to specify that text-only content <br>
preferred over graphical content<br>
<br>
6.1.1 Feature tag <br>
<br>
The <A HREF="/relevance/projects/rfc/definition.html">definition</A> of a feature tag may state that a feature tag can <br>
zero, one, or more values <A HREF="/relevance/projects/rfc/associated.html">associated</A> with it. These <br>
specialize the meaning of the tag. For example, a feature <br>
`paper' could be <A HREF="/relevance/projects/rfc/associated.html">associated</A> with the values `A4' and `A5'.<br>
<br>
tag-value = token | quoted-<br>
<br>
The US-ASCII charset is used for feature tag values. <br>
<A HREF="/relevance/projects/rfc/comparison.html">comparison</A> for tag values MUST be done with a case-sensitive, octet<br>
by-octet <A HREF="/relevance/projects/rfc/comparison.html">comparison</A>, where any ""%" HEX HEX" encodings MUST <br>
processed as in [1]. A token value XYZ is equal to a quoted-<br>
value "XYZ".<br>
<br>
6.2 Feature <br>
<br>
The feature set of a user agent is a data <A HREF="/relevance/projects/rfc/structure.html">structure</A> which records <br>
<A HREF="/relevance/projects/rfc/capabilities.html">capabilities</A> of the user agent and the preferences of the user<br>
<br>
Feature sets are used by local variant <A HREF="/relevance/projects/rfc/selection.html">selection</A> algorithms (<br>
<A HREF="/relevance/projects/rfc/appendix.html">appendix</A> 19 for an example). A user agent can use the Accept<br>
<A HREF="/relevance/projects/rfc/features.html">Features</A> header (section 8.2) to make some of the <A HREF="/relevance/projects/rfc/contents.html">contents</A> of <br>
feature set known to remote variant <A HREF="/relevance/projects/rfc/selection.html">selection</A> algorithms<br>
<br>
Structurally, a feature set is a possibly empty set, <br>
records of the <br>
<br>
( feature tag , set of feature tag values )<br>
<br>
<br>
<br>
<br>
<br>
<br>
Holtman & Mutz <A HREF="/relevance/projects/rfc/experimental.html">Experimental</A> [Page 21]<br>
<br>
RFC 2295 <A HREF="/relevance/projects/rfc/transparent.html">Transparent</A> Content <A HREF="/relevance/projects/rfc/negotiation.html">Negotiation</A> March 1998<br>
<br>
<br>
If a record with a feature tag is present in the set, this means <br>
the user agent implements the <A HREF="/relevance/projects/rfc/corresponding.html">corresponding</A> <A HREF="/relevance/projects/rfc/capability.html">capability</A>, or that <br>
user has expressed the <A HREF="/relevance/projects/rfc/corresponding.html">corresponding</A> <A HREF="/relevance/projects/rfc/preference.html">preference</A><br>
<br>
Each record in a feature set has a, possibly empty, set of <br>
values. For feature tags which cannot have values <A HREF="/relevance/projects/rfc/associated.html">associated</A> <br>
it, this set is always empty. For feature tags which can have zero<br>
one, or more values <A HREF="/relevance/projects/rfc/associated.html">associated</A> with it, this set <A HREF="/relevance/projects/rfc/contains.html">contains</A> <br>
values <A HREF="/relevance/projects/rfc/currently.html">currently</A> <A HREF="/relevance/projects/rfc/associated.html">associated</A> with the tag. If the set of a <br>
tag T has the value V in it, it is said that `the tag T is <br>
with the value V'.<br>
<br>
This <A HREF="/relevance/projects/rfc/specification.html">specification</A> does not define a <A HREF="/relevance/projects/rfc/standard.html">standard</A> <A HREF="/relevance/projects/rfc/notation.html">notation</A> for <br>
sets. An example of a very small feature set, in a <br>
<A HREF="/relevance/projects/rfc/notation.html">notation</A>, <br>
<br>
{ ( "frames" , { } ) ,<br>
( "paper" , { "A4" , "A5" } )<br>
}<br>
<br>
As feature <A HREF="/relevance/projects/rfc/registration.html">registration</A> is <A HREF="/relevance/projects/rfc/expected.html">expected</A> to be an ongoing process, it <br>
generally not <A HREF="/relevance/projects/rfc/possible.html">possible</A> for a user agent to know the meaning of <br>
feature tags it can possibly encounter in a variant <A HREF="/relevance/projects/rfc/description.html">description</A>. <br>
user agent SHOULD treat all <A HREF="/relevance/projects/rfc/features.html">features</A> tags unknown to it as <br>
from its feature set<br>
<br>
A user agent may change the <A HREF="/relevance/projects/rfc/contents.html">contents</A> of its feature set depending <br>
the type of request, and may also update it to reflect <br>
conditions, for example a change in the window size. <A HREF="/relevance/projects/rfc/therefore.html">Therefore</A>, <br>
considering feature <A HREF="/relevance/projects/rfc/negotiation.html">negotiation</A>, one usually talks about `the <br>
set of the current request'.<br>
<br>
6.3 Feature <br>
<br>
Feature predicates are predicates on the <A HREF="/relevance/projects/rfc/contents.html">contents</A> of feature sets<br>
They appear in the <A HREF="/relevance/projects/rfc/features.html">features</A> <A HREF="/relevance/projects/rfc/attribute.html">attribute</A> of a variant <A HREF="/relevance/projects/rfc/description.html">description</A><br>
<br>
fpred = [ "!" ] <br>
| ftag ( "=" | "!=" ) tag-<br>
| ftag "=" "[" numeric-range "]"<br>
<br>
numeric-range = [ number ] "-" [ number ]<br>
<br>
Feature predicates are used in <A HREF="/relevance/projects/rfc/features.html">features</A> attributes (section 6.4),<br>
which are used in variant descriptions (section 5). <br>
descriptions can be <A HREF="/relevance/projects/rfc/transmitted.html">transmitted</A> in Alternates headers (section 8.3).<br>
<br>
<br>
<br>
<br>
<br>
Holtman & Mutz <A HREF="/relevance/projects/rfc/experimental.html">Experimental</A> [Page 22]<br>
<br>
RFC 2295 <A HREF="/relevance/projects/rfc/transparent.html">Transparent</A> Content <A HREF="/relevance/projects/rfc/negotiation.html">Negotiation</A> March 1998<br>
<br>
<br>
<A HREF="/relevance/projects/rfc/examples.html">Examples</A> of feature predicates <br>
<br>
blebber, !blebber, paper=a4, colordepth=5, blex!=54,<br>
dpi=[300-599], colordepth=[24-]<br>
<br>
Using the feature set of the current request, a user agent <br>
compute the truth value of the <A HREF="/relevance/projects/rfc/different.html">different</A> feature predicates <br>
follows<br>
<br>
ftag true if the feature is present, false <br>
<br>
!ftag true if the feature is absent, false <br>
<br>
ftag=V true if the feature is present with the value V<br>
false otherwise<br>
<br>
ftag!=V true if the feature is not present with the value V<br>
false otherwise<br>
<br>
ftag=[N-M] true if the feature is present with at least <br>
numeric value, while the highest value with which <br>
is present in the range N-M, false otherwise. If <br>
is missing, the lower bound is 0. If M is missing<br>
the upper bound is <A HREF="/relevance/projects/rfc/infinity.html">infinity</A><br>
<br>
As an example, with the feature <br>
<br>
{ ( "blex" , { } ),<br>
( "colordepth" , { "5" } ),<br>
( "UA-media" , { "stationary" } ),<br>
( "paper" , { "A4", "A3" } ) ,<br>
( "x-version" , { "104", "200" } )<br>
}<br>
<br>
the <A HREF="/relevance/projects/rfc/following.html">following</A> predicates are true<br>
<br>
blex, colordepth=[4-], colordepth!=6, colordepth, !screenwidth, UA<br>
media=stationary, UA-media!=screen, paper=A4, paper =!A0,<br>
colordepth=[ 4 - 6 ], x-version=[100-300], x-version=[200-300]<br>
<br>
and the <A HREF="/relevance/projects/rfc/following.html">following</A> predicates are false<br>
<br>
!blex, blebber, colordepth=6, colordepth=foo, !colordepth<br>
screenwidth, screenwidth=640, screenwidth!=640, x-version=99, UA<br>
media=screen, paper=A0, paper=a4, x-version=[100-199], <br>
<br>
<br>
<br>
<br>
<br>
<br>
Holtman & Mutz <A HREF="/relevance/projects/rfc/experimental.html">Experimental</A> [Page 23]<br>
<br>
RFC 2295 <A HREF="/relevance/projects/rfc/transparent.html">Transparent</A> Content <A HREF="/relevance/projects/rfc/negotiation.html">Negotiation</A> March 1998<br>
<br>
<br>
6.4 <A HREF="/relevance/projects/rfc/features.html">Features</A> <br>
<br>
The <A HREF="/relevance/projects/rfc/features.html">features</A> <A HREF="/relevance/projects/rfc/attribute.html">attribute</A>, for which section 5.1 defines the <br>
<br>
"{" "<A HREF="/relevance/projects/rfc/features.html">features</A>" feature-list "}"<br>
<br>
is used in a variant <A HREF="/relevance/projects/rfc/description.html">description</A> to specify how the <A HREF="/relevance/projects/rfc/presence.html">presence</A> <br>
absence of <A HREF="/relevance/projects/rfc/particular.html">particular</A> feature tags in the user agent affects <br>
overall quality of the variant<br>
<br>
feature-list = 1%feature-list-<br>
<br>
feature-list-element = ( fpred | fpred-bag )<br>
[ ";" [ "+" true-improvement ]<br>
[ "-" false-degradation ]<br>
]<br>
<br>
fpred-bag = "[" 1%fpred "]"<br>
<br>
true-improvement = short-<br>
false-degradation = short-<br>
<br>
<A HREF="/relevance/projects/rfc/features.html">Features</A> attributes are used in variant descriptions (section 5).<br>
Variant descriptions can be <A HREF="/relevance/projects/rfc/transmitted.html">transmitted</A> in Alternates <br>
(section 8.3).<br>
<br>
<A HREF="/relevance/projects/rfc/examples.html">Examples</A> are<br>
<br>
{<A HREF="/relevance/projects/rfc/features.html">features</A> !textonly [blebber !wolx] colordepth=3;+0.7}<br>
<br>
{<A HREF="/relevance/projects/rfc/features.html">features</A> !blink;-0.5 background;+1.5 [blebber !wolx];+1.4-0.8}<br>
<br>
The default value for the true-improvement is 1. The default <br>
for the false-degradation is 0, or 1 if a true-improvement value <br>
given<br>
<br>
A user agent SHOULD, and a remote variant <A HREF="/relevance/projects/rfc/selection.html">selection</A> <A HREF="/relevance/projects/rfc/algorithm.html">algorithm</A> <br>
compute the quality degradation factor <A HREF="/relevance/projects/rfc/associated.html">associated</A> with the <br>
<A HREF="/relevance/projects/rfc/attribute.html">attribute</A> by multiplying all quality degradation factors of <br>
<A HREF="/relevance/projects/rfc/elements.html">elements</A> of the feature-list. Note that the result can be a <br>
greater than 1.<br>
<br>
A feature list element yields its true-improvement factor if <br>
<A HREF="/relevance/projects/rfc/corresponding.html">corresponding</A> feature <A HREF="/relevance/projects/rfc/predicate.html">predicate</A> is true, or if at least one <br>
of the <A HREF="/relevance/projects/rfc/corresponding.html">corresponding</A> fpred-bag is true. The element yields <br>
false-degradation factor otherwise<br>
<br>
<br>
<br>
<br>
<br>
Holtman & Mutz <A HREF="/relevance/projects/rfc/experimental.html">Experimental</A> [Page 24]<br>
<br>
RFC 2295 <A HREF="/relevance/projects/rfc/transparent.html">Transparent</A> Content <A HREF="/relevance/projects/rfc/negotiation.html">Negotiation</A> March 1998<br>
<br>
<br>
7 Remote variant <A HREF="/relevance/projects/rfc/selection.html">selection</A> <br>
<br>
A remote variant <A HREF="/relevance/projects/rfc/selection.html">selection</A> <A HREF="/relevance/projects/rfc/algorithm.html">algorithm</A> is a standardized <A HREF="/relevance/projects/rfc/algorithm.html">algorithm</A> <br>
which a server can choose a best variant on behalf of a <br>
user agent. The use of a remote <A HREF="/relevance/projects/rfc/algorithm.html">algorithm</A> can speed up <br>
<A HREF="/relevance/projects/rfc/negotiation.html">negotiation</A> process by eliminating a request-<A HREF="/relevance/projects/rfc/response.html">response</A> round trip<br>
<br>
A remote <A HREF="/relevance/projects/rfc/algorithm.html">algorithm</A> <A HREF="/relevance/projects/rfc/typically.html">typically</A> computes whether the Accept- headers <br>
the request contain sufficient <A HREF="/relevance/projects/rfc/information.html">information</A> to allow a choice, and <br>
so, which variant is the best variant. This <A HREF="/relevance/projects/rfc/specification.html">specification</A> does <br>
define any remote algorithms, but does define a <A HREF="/relevance/projects/rfc/mechanism.html">mechanism</A> <br>
<A HREF="/relevance/projects/rfc/negotiate.html">negotiate</A> on the use of such algorithms<br>
<br>
7.1 Version <br>
<br>
A version <A HREF="/relevance/projects/rfc/numbering.html">numbering</A> scheme is used to <A HREF="/relevance/projects/rfc/distinguish.html">distinguish</A> between <br>
remote variant <A HREF="/relevance/projects/rfc/selection.html">selection</A> algorithms<br>
<br>
rvsa-version = major "." <br>
<br>
major = 1*4<br>
minor = 1*4<br>
<br>
An <A HREF="/relevance/projects/rfc/algorithm.html">algorithm</A> with the version number X.Y, with Y>0, MUST be <br>
compatible with all algorithms from X.0 up to X.Y. <br>
compatibility means that, if supplied with the same <A HREF="/relevance/projects/rfc/information.html">information</A>, <br>
newer <A HREF="/relevance/projects/rfc/algorithm.html">algorithm</A> MUST make the same choice, or a better choice, as <br>
old <A HREF="/relevance/projects/rfc/algorithm.html">algorithm</A>. There are no compatibility <A HREF="/relevance/projects/rfc/requirements.html">requirements</A> <br>
algorithms with <A HREF="/relevance/projects/rfc/different.html">different</A> major version numbers<br>
<br>
8 Content <A HREF="/relevance/projects/rfc/negotiation.html">negotiation</A> status codes and <br>
<br>
This <A HREF="/relevance/projects/rfc/specification.html">specification</A> adds one new HTTP status code, and introduces <br>
new HTTP headers. It also extends the <A HREF="/relevance/projects/rfc/semantics.html">semantics</A> of an <br>
HTTP/1.1 header<br>
<br>
8.1 506 Variant Also <br>
<br>
The 506 status code <A HREF="/relevance/projects/rfc/indicates.html">indicates</A> that the server has an <br>
<A HREF="/relevance/projects/rfc/configuration.html">configuration</A> error: the chosen variant <A HREF="/relevance/projects/rfc/resource.html">resource</A> is <A HREF="/relevance/projects/rfc/configured.html">configured</A> <br>
engage in <A HREF="/relevance/projects/rfc/transparent.html">transparent</A> content <A HREF="/relevance/projects/rfc/negotiation.html">negotiation</A> itself, and is <br>
not a proper end point in the <A HREF="/relevance/projects/rfc/negotiation.html">negotiation</A> process<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
Holtman & Mutz <A HREF="/relevance/projects/rfc/experimental.html">Experimental</A> [Page 25]<br>
<br>
RFC 2295 <A HREF="/relevance/projects/rfc/transparent.html">Transparent</A> Content <A HREF="/relevance/projects/rfc/negotiation.html">Negotiation</A> March 1998<br>
<br>
<br>
8.2 Accept-<br>
<br>
The Accept-<A HREF="/relevance/projects/rfc/features.html">Features</A> request header can be used by a user agent <br>
give <A HREF="/relevance/projects/rfc/information.html">information</A> about the <A HREF="/relevance/projects/rfc/presence.html">presence</A> or absence of certain <A HREF="/relevance/projects/rfc/features.html">features</A> <br>
the feature set of the current request. Servers can use <br>
<A HREF="/relevance/projects/rfc/information.html">information</A> when running a remote variant <A HREF="/relevance/projects/rfc/selection.html">selection</A> <A HREF="/relevance/projects/rfc/algorithm.html">algorithm</A><br>
<br>
Note: the name `Accept-<A HREF="/relevance/projects/rfc/features.html">Features</A>' for this header was <br>
because of symmetry <A HREF="/relevance/projects/rfc/considerations.html">considerations</A> with other Accept- headers<br>
even though the Accept-<A HREF="/relevance/projects/rfc/features.html">Features</A> header will generally not <br>
an exhaustive list of <A HREF="/relevance/projects/rfc/features.html">features</A> which are somehow `<A HREF="/relevance/projects/rfc/accepted.html">accepted</A>'. <br>
more accurate name of this header would have been `Feature-Set<br>
Info'.<br>
<br>
Accept-<A HREF="/relevance/projects/rfc/features.html">Features</A> = "Accept-<A HREF="/relevance/projects/rfc/features.html">Features</A>" ":"<br>
#( feature-expr *( ";" feature-<A HREF="/relevance/projects/rfc/extension.html">extension</A> ) )<br>
<br>
feature-expr = [ "!" ] <br>
| ftag ( "=" | "!=" ) tag-<br>
| ftag "=" "{" tag-value "}"<br>
| "*"<br>
<br>
feature-<A HREF="/relevance/projects/rfc/extension.html">extension</A> = token [ "=" ( token | quoted-string ) ]<br>
<br>
No feature <A HREF="/relevance/projects/rfc/extensions.html">extensions</A> are defined in this <A HREF="/relevance/projects/rfc/specification.html">specification</A>. An <br>
is<br>
<br>
Accept-<A HREF="/relevance/projects/rfc/features.html">Features</A>: blex, !blebber, colordepth={5}, !screenwidth<br>
paper = A4, paper!="A2", x-version=104, *<br>
<br>
The <A HREF="/relevance/projects/rfc/different.html">different</A> feature expressions have the <A HREF="/relevance/projects/rfc/following.html">following</A> meaning<br>
<br>
ftag ftag is <br>
<br>
!ftag ftag is <br>
<br>
ftag=V ftag is present with the value <br>
<br>
ftag!=V ftag is present, but not with the value <br>
<br>
ftag={V} ftag is present with the value V, and not with <br>
other <br>
<br>
* the expressions in this header do not fully <br>
the feature set: feature tags not mentioned in <br>
header may also be present, and, except for the <br>
ftag={V}, tags may be present with more values <br>
mentioned<br>
<br>
<br>
<br>
Holtman & Mutz <A HREF="/relevance/projects/rfc/experimental.html">Experimental</A> [Page 26]<br>
<br>
RFC 2295 <A HREF="/relevance/projects/rfc/transparent.html">Transparent</A> Content <A HREF="/relevance/projects/rfc/negotiation.html">Negotiation</A> March 1998<br>
<br>
<br>
Absence of the Accept-<A HREF="/relevance/projects/rfc/features.html">Features</A> header in a request is <A HREF="/relevance/projects/rfc/equivalent.html">equivalent</A> <br>
the inclusion <br>
<br>
Accept-<A HREF="/relevance/projects/rfc/features.html">Features</A>: *<br>
<br>
By using the Accept-<A HREF="/relevance/projects/rfc/features.html">Features</A> header, a remote variant <br>
<A HREF="/relevance/projects/rfc/algorithm.html">algorithm</A> can <A HREF="/relevance/projects/rfc/sometimes.html">sometimes</A> <A HREF="/relevance/projects/rfc/determine.html">determine</A> the truth value of a <br>
<A HREF="/relevance/projects/rfc/predicate.html">predicate</A> on behalf of the user agent. For example, with the <br>
<br>
Accept-<A HREF="/relevance/projects/rfc/features.html">Features</A>: blex, !blebber, colordepth={5}, !screenwidth<br>
paper = A4, paper!="A2", x-version=104, *<br>
<br>
the <A HREF="/relevance/projects/rfc/algorithm.html">algorithm</A> can <A HREF="/relevance/projects/rfc/determine.html">determine</A> that the <A HREF="/relevance/projects/rfc/following.html">following</A> predicates are true<br>
<br>
blex, colordepth=[4-], colordepth!=6, colordepth, !screenwidth<br>
paper=A4, colordepth=[4-6]<br>
<br>
and that the <A HREF="/relevance/projects/rfc/following.html">following</A> predicates are false<br>
<br>
!blex, blebber, colordepth=6, colordepth=foo, !colordepth<br>
screenwidth, screenwidth=640, screenwidth!=640,<br>
<br>
but the truth value of the <A HREF="/relevance/projects/rfc/following.html">following</A> predicates cannot <br>
<A HREF="/relevance/projects/rfc/determined.html">determined</A><br>
<br>
UA-media=stationary, UA-media!=screen, paper!=a0,<br>
x-version=[100-300], x-version=[200-300], x-version=99,<br>
UA-media=screen, paper=A0, paper=a4, x-version=[100-199], <br>
<br>
8.3 <br>
<br>
The Alternates <A HREF="/relevance/projects/rfc/response.html">response</A> header is used to convey the list of <br>
bound to a negotiable <A HREF="/relevance/projects/rfc/resource.html">resource</A>. This list can also <br>
directives for any content <A HREF="/relevance/projects/rfc/negotiation.html">negotiation</A> process. If a <A HREF="/relevance/projects/rfc/response.html">response</A> from <br>
transparently negotiable <A HREF="/relevance/projects/rfc/resource.html">resource</A> includes an Alternates header, <br>
header MUST contain the <A HREF="/relevance/projects/rfc/complete.html">complete</A> variant list bound to the <br>
<A HREF="/relevance/projects/rfc/resource.html">resource</A>. Responses from resources which do not support <br>
content <A HREF="/relevance/projects/rfc/negotiation.html">negotiation</A> MAY also use Alternates headers<br>
<br>
Alternates = "Alternates" ":" variant-<br>
<br>
variant-list = 1#( variant-<br>
| fallback-<br>
| list-<A HREF="/relevance/projects/rfc/directive.html">directive</A> )<br>
<br>
fallback-variant = "{" <"> URI <"> "}"<br>
<br>
list-<A HREF="/relevance/projects/rfc/directive.html">directive</A> = ( "proxy-rvsa" "=" <"> 0#rvsa-version <"> )<br>
<br>
<br>
<br>
Holtman & Mutz <A HREF="/relevance/projects/rfc/experimental.html">Experimental</A> [Page 27]<br>
<br>
RFC 2295 <A HREF="/relevance/projects/rfc/transparent.html">Transparent</A> Content <A HREF="/relevance/projects/rfc/negotiation.html">Negotiation</A> March 1998<br>
<br>
<br>
| <A HREF="/relevance/projects/rfc/extension.html">extension</A>-list-<br>
<br>
<A HREF="/relevance/projects/rfc/extension.html">extension</A>-list-<A HREF="/relevance/projects/rfc/directive.html">directive</A> =<br>
token [ "=" ( token | quoted-string ) ]<br>
<br>
An example <br>
<br>
Alternates: {"paper.1" 0.9 {type text/html} {<A HREF="/relevance/projects/rfc/language.html">language</A> en}},<br>
{"paper.2" 0.7 {type text/html} {<A HREF="/relevance/projects/rfc/language.html">language</A> fr}},<br>
{"paper.3" 1.0 {type <A HREF="/relevance/projects/rfc/application.html">application</A>/<A HREF="/relevance/projects/rfc/postscript.html">postscript</A><br>
{<A HREF="/relevance/projects/rfc/language.html">language</A> en}},<br>
proxy-rvsa="1.0, 2.5"<br>
<br>
Any <A HREF="/relevance/projects/rfc/relative.html">relative</A> URI <A HREF="/relevance/projects/rfc/specified.html">specified</A> in a variant-<A HREF="/relevance/projects/rfc/description.html">description</A> or fallback<br>
variant field is <A HREF="/relevance/projects/rfc/relative.html">relative</A> to the request-URI. Only one fallback<br>
variant field may be present. If the variant <A HREF="/relevance/projects/rfc/selection.html">selection</A> <A HREF="/relevance/projects/rfc/algorithm.html">algorithm</A> <br>
the user agent finds that all <A HREF="/relevance/projects/rfc/described.html">described</A> <A HREF="/relevance/projects/rfc/variants.html">variants</A> are unacceptable<br>
then it SHOULD choose the fallback variant, if present, as the <br>
variant. If the user agent computes the overall quality values <br>
the <A HREF="/relevance/projects/rfc/described.html">described</A> <A HREF="/relevance/projects/rfc/variants.html">variants</A>, and finds that several <A HREF="/relevance/projects/rfc/variants.html">variants</A> share <br>
highest value, then the first variant with this value in the <br>
SHOULD be chosen as the best variant<br>
<br>
The proxy-rvsa <A HREF="/relevance/projects/rfc/directive.html">directive</A> restricts the use of remote <br>
<A HREF="/relevance/projects/rfc/selection.html">selection</A> algorithms by proxies. If present, a proxy MUST ONLY <br>
algorithms which have one of the version numbers listed, or have <br>
same major version number and a higher minor version number as one <br>
the <A HREF="/relevance/projects/rfc/versions.html">versions</A> listed. Any restrictions set by proxy-rvsa come on <br>
of the restrictions set by the user agent in the <A HREF="/relevance/projects/rfc/negotiate.html">Negotiate</A> <br>
header. The <A HREF="/relevance/projects/rfc/directive.html">directive</A> proxy-rvsa="" will disable variant <br>
by proxies entirely. Clients SHOULD ignore all <A HREF="/relevance/projects/rfc/extension.html">extension</A>-list<br>
directives they do not <A HREF="/relevance/projects/rfc/understand.html">understand</A><br>
<br>
A variant list may contain <A HREF="/relevance/projects/rfc/multiple.html">multiple</A> differing descriptions of <br>
same variant. This can be convenient if the variant uses <br>
rendering constructs, or if the variant <A HREF="/relevance/projects/rfc/resource.html">resource</A> returns <br>
representations using a <A HREF="/relevance/projects/rfc/multipart.html">multipart</A> media type<br>
<br>
8.4 <br>
<br>
The <A HREF="/relevance/projects/rfc/negotiate.html">Negotiate</A> request header can contain directives for any <br>
<A HREF="/relevance/projects/rfc/negotiation.html">negotiation</A> process initiated by the request<br>
<br>
<A HREF="/relevance/projects/rfc/negotiate.html">Negotiate</A> = "<A HREF="/relevance/projects/rfc/negotiate.html">Negotiate</A>" ":" 1#<A HREF="/relevance/projects/rfc/negotiate.html">negotiate</A>-<br>
<br>
<A HREF="/relevance/projects/rfc/negotiate.html">negotiate</A>-<A HREF="/relevance/projects/rfc/directive.html">directive</A> = "trans<br>
| "vlist<br>
| "guess-small<br>
<br>
<br>
<br>
Holtman & Mutz <A HREF="/relevance/projects/rfc/experimental.html">Experimental</A> [Page 28]<br>
<br>
RFC 2295 <A HREF="/relevance/projects/rfc/transparent.html">Transparent</A> Content <A HREF="/relevance/projects/rfc/negotiation.html">Negotiation</A> March 1998<br>
<br>
<br>
| rvsa-<br>
| "*"<br>
| <A HREF="/relevance/projects/rfc/negotiate.html">negotiate</A>-<br>
<br>
<A HREF="/relevance/projects/rfc/negotiate.html">negotiate</A>-<A HREF="/relevance/projects/rfc/extension.html">extension</A> = token [ "=" token ]<br>
<br>
<A HREF="/relevance/projects/rfc/examples.html">Examples</A> <br>
<br>
<A HREF="/relevance/projects/rfc/negotiate.html">Negotiate</A>: 1.0, 2.5<br>
<A HREF="/relevance/projects/rfc/negotiate.html">Negotiate</A>: *<br>
<br>
The <A HREF="/relevance/projects/rfc/negotiate.html">negotiate</A> directives have the <A HREF="/relevance/projects/rfc/following.html">following</A> <br>
<br>
"trans<br>
The user agent <A HREF="/relevance/projects/rfc/supports.html">supports</A> <A HREF="/relevance/projects/rfc/transparent.html">transparent</A> content <A HREF="/relevance/projects/rfc/negotiation.html">negotiation</A> <br>
the current request<br>
<br>
"vlist<br>
The user agent <A HREF="/relevance/projects/rfc/requests.html">requests</A> that any transparently <br>
<A HREF="/relevance/projects/rfc/response.html">response</A> for the current request includes an <br>
header with the variant list bound to the negotiable <A HREF="/relevance/projects/rfc/resource.html">resource</A><br>
Implies "trans".<br>
<br>
"guess-small<br>
The user agent allows origin servers to run a custom <br>
which guesses the best variant for the request, and to <br>
this variant in a choice <A HREF="/relevance/projects/rfc/response.html">response</A>, if the resulting <br>
<A HREF="/relevance/projects/rfc/response.html">response</A> is smaller than or not much larger than a <br>
<A HREF="/relevance/projects/rfc/response.html">response</A>. The <A HREF="/relevance/projects/rfc/definition.html">definition</A> of `not much larger' is left <br>
origin server heuristics. Implies "vlist" and "trans".<br>
<br>
rvsa-<br>
The user agent allows origin servers and proxies to run <br>
remote variant <A HREF="/relevance/projects/rfc/selection.html">selection</A> <A HREF="/relevance/projects/rfc/algorithm.html">algorithm</A> with the <A HREF="/relevance/projects/rfc/indicated.html">indicated</A> <br>
number, or with the same major version number and a <br>
minor version number. If the <A HREF="/relevance/projects/rfc/algorithm.html">algorithm</A> has <br>
<A HREF="/relevance/projects/rfc/information.html">information</A> to choose a best, neighboring variant, the <br>
server or proxy MAY return a choice <A HREF="/relevance/projects/rfc/response.html">response</A> with <br>
variant. Implies "trans".<br>
<br>
"*"<br>
The user agent allows origin servers and proxies to run <br>
remote variant <A HREF="/relevance/projects/rfc/selection.html">selection</A> <A HREF="/relevance/projects/rfc/algorithm.html">algorithm</A>. The origin server <br>
even run algorithms which have not been standardized. If <br>
<A HREF="/relevance/projects/rfc/algorithm.html">algorithm</A> has sufficient <A HREF="/relevance/projects/rfc/information.html">information</A> to choose a best<br>
neighboring variant, the origin server or proxy MAY return <br>
choice <A HREF="/relevance/projects/rfc/response.html">response</A> with this variant. Implies "trans".<br>
<br>
<br>
<br>
<br>
Holtman & Mutz <A HREF="/relevance/projects/rfc/experimental.html">Experimental</A> [Page 29]<br>
<br>
RFC 2295 <A HREF="/relevance/projects/rfc/transparent.html">Transparent</A> Content <A HREF="/relevance/projects/rfc/negotiation.html">Negotiation</A> March 1998<br>
<br>
<br>
Servers SHOULD ignore all <A HREF="/relevance/projects/rfc/negotiate.html">negotiate</A>-directives they do <br>
<A HREF="/relevance/projects/rfc/understand.html">understand</A>. If the <A HREF="/relevance/projects/rfc/negotiate.html">Negotiate</A> header allows a choice between <br>
remote variant <A HREF="/relevance/projects/rfc/selection.html">selection</A> algorithms which are all <A HREF="/relevance/projects/rfc/supported.html">supported</A> by <br>
server, the server SHOULD use some <A HREF="/relevance/projects/rfc/internal.html">internal</A> <A HREF="/relevance/projects/rfc/precedence.html">precedence</A> heuristics <br>
select the best <A HREF="/relevance/projects/rfc/algorithm.html">algorithm</A><br>
<br>
8.5 <br>
<br>
The TCN <A HREF="/relevance/projects/rfc/response.html">response</A> header is used by a server to signal that <br>
<A HREF="/relevance/projects/rfc/resource.html">resource</A> is transparently negotiated<br>
<br>
TCN = "TCN" ":" #( <A HREF="/relevance/projects/rfc/response.html">response</A>-<br>
| server-side-override-<br>
| tcn-<A HREF="/relevance/projects/rfc/extension.html">extension</A> )<br>
<br>
<A HREF="/relevance/projects/rfc/response.html">response</A>-type = "list" | "choice" | "adhoc<br>
<br>
server-side-override-<A HREF="/relevance/projects/rfc/directive.html">directive</A> = "re-choose" | "keep<br>
<br>
tcn-<A HREF="/relevance/projects/rfc/extension.html">extension</A> = token [ "=" ( token | quoted-string ) ]<br>
<br>
If the <A HREF="/relevance/projects/rfc/resource.html">resource</A> is not transparently negotiated, a TCN header <br>
NOT be <A HREF="/relevance/projects/rfc/included.html">included</A> in any <A HREF="/relevance/projects/rfc/response.html">response</A>. If the <A HREF="/relevance/projects/rfc/resource.html">resource</A> is <br>
negotiated, a TCN header, which includes the <A HREF="/relevance/projects/rfc/response.html">response</A>-type value <br>
the <A HREF="/relevance/projects/rfc/response.html">response</A>, MUST be <A HREF="/relevance/projects/rfc/included.html">included</A> in every <A HREF="/relevance/projects/rfc/response.html">response</A> with a 2xx <br>
code or any 3xx status code, except 304, in which it MAY be <A HREF="/relevance/projects/rfc/included.html">included</A><br>
A TCN header MAY also be <A HREF="/relevance/projects/rfc/included.html">included</A>, without a <A HREF="/relevance/projects/rfc/response.html">response</A>-type value, <br>
other responses from transparently negotiated resources<br>
<br>
A server-side override <A HREF="/relevance/projects/rfc/directive.html">directive</A> MUST be <A HREF="/relevance/projects/rfc/included.html">included</A> if the <br>
server performed a server-side override when <A HREF="/relevance/projects/rfc/choosing.html">choosing</A> the <A HREF="/relevance/projects/rfc/response.html">response</A><br>
If the <A HREF="/relevance/projects/rfc/directive.html">directive</A> is "re-choose", the server MUST include <br>
Alternates header with the variant bound to the negotiable <br>
in the <A HREF="/relevance/projects/rfc/response.html">response</A>, and user agent SHOULD use its <A HREF="/relevance/projects/rfc/internal.html">internal</A> <br>
<A HREF="/relevance/projects/rfc/selection.html">selection</A> <A HREF="/relevance/projects/rfc/algorithm.html">algorithm</A> to choose, <A HREF="/relevance/projects/rfc/retrieve.html">retrieve</A>, and display the best <br>
from this list. If the <A HREF="/relevance/projects/rfc/directive.html">directive</A> is "keep" the user agent SHOULD <br>
renegotiate on the <A HREF="/relevance/projects/rfc/response.html">response</A>, but display it directly, or act on <br>
directly if it is a <A HREF="/relevance/projects/rfc/redirection.html">redirection</A> <A HREF="/relevance/projects/rfc/response.html">response</A><br>
<br>
Clients SHOULD ignore all tcn-<A HREF="/relevance/projects/rfc/extensions.html">extensions</A> they do not <A HREF="/relevance/projects/rfc/understand.html">understand</A><br>
<br>
8.6 Variant-<br>
<br>
The Variant-Vary <A HREF="/relevance/projects/rfc/response.html">response</A> header can be used in a choice <A HREF="/relevance/projects/rfc/response.html">response</A> <br>
record any vary <A HREF="/relevance/projects/rfc/information.html">information</A> which applies to the variant data (<br>
entity body combined with some of the entity headers) contained <br>
the <A HREF="/relevance/projects/rfc/response.html">response</A>, rather than to the <A HREF="/relevance/projects/rfc/response.html">response</A> as a whole<br>
<br>
<br>
<br>
<br>
Holtman & Mutz <A HREF="/relevance/projects/rfc/experimental.html">Experimental</A> [Page 30]<br>
<br>
RFC 2295 <A HREF="/relevance/projects/rfc/transparent.html">Transparent</A> Content <A HREF="/relevance/projects/rfc/negotiation.html">Negotiation</A> March 1998<br>
<br>
<br>
Variant-Vary = "Variant-Vary" ":" ( "*" | 1#field-name )<br>
<br>
Use of the Variant-Vary header is discussed in section 10.2.<br>
<br>
9 Cache <br>
<br>
To allow for correct and efficient caching and revalidation <br>
negotiated responses, this <A HREF="/relevance/projects/rfc/specification.html">specification</A> extends the caching model <br>
HTTP/1.1 [1] in various ways<br>
<br>
This <A HREF="/relevance/projects/rfc/specification.html">specification</A> does not <A HREF="/relevance/projects/rfc/introduce.html">introduce</A> a `variant-list-max-age<br>
<A HREF="/relevance/projects/rfc/directive.html">directive</A> which explicitly bounds the freshness lifetime of a <br>
variant list, like the `max-age' Cache-Control <A HREF="/relevance/projects/rfc/directive.html">directive</A> bounds <br>
freshness lifetime of a cached <A HREF="/relevance/projects/rfc/response.html">response</A>. However, this <br>
does ensure that a variant list which is sent at a time T by <br>
origin server will never be re-used without revalidation <br>
semantically <A HREF="/relevance/projects/rfc/transparent.html">transparent</A> caches after the time T+M. This M is <br>
maximum of all freshness lifetimes <A HREF="/relevance/projects/rfc/assigned.html">assigned</A> (using max-age <br>
or Expires headers) by the origin server <br>
<br>
a. the responses from the negotiable <A HREF="/relevance/projects/rfc/resource.html">resource</A> itself, <br>
<br>
b. the responses from its neighboring variant <br>
<br>
If no freshness lifetimes are <A HREF="/relevance/projects/rfc/assigned.html">assigned</A> by the origin server, M is <br>
maximum of the freshness lifetimes which were heuristically <br>
by all caches which can re-use the variant list<br>
<br>
9.1 Variant list <br>
<br>
A variant list validator is an opaque value which acts as the <br>
validator of a variant list bound to a negotiable <A HREF="/relevance/projects/rfc/resource.html">resource</A><br>
<br>
variant-list-validator = <quoted-string not <A HREF="/relevance/projects/rfc/containing.html">containing</A> any ";"><br>
<br>
If two responses contain the same variant list validator, a cache <br>
treat the Alternates headers in these responses as <A HREF="/relevance/projects/rfc/equivalent.html">equivalent</A> (<br>
the headers themselves need not be identical).<br>
<br>
9.2 <A HREF="/relevance/projects/rfc/structured.html">Structured</A> entity <br>
<br>
A <A HREF="/relevance/projects/rfc/structured.html">structured</A> entity tag <A HREF="/relevance/projects/rfc/consists.html">consists</A> of a normal entity tag of which <br>
opaque string is <A HREF="/relevance/projects/rfc/extended.html">extended</A> with a semicolon <A HREF="/relevance/projects/rfc/followed.html">followed</A> by the <br>
(without the surrounding quotes) of a variant list validator<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
Holtman & Mutz <A HREF="/relevance/projects/rfc/experimental.html">Experimental</A> [Page 31]<br>
<br>
RFC 2295 <A HREF="/relevance/projects/rfc/transparent.html">Transparent</A> Content <A HREF="/relevance/projects/rfc/negotiation.html">Negotiation</A> March 1998<br>
<br>
<br>
normal | variant list | <br>
entity tag | validator | entity <br>
-------------+----------------+-----------------<br>
"etag" | "vlv" | "etag;vlv<br>
W/"etag" | "vlv" | W/"etag;vlv<br>
<br>
Note that a <A HREF="/relevance/projects/rfc/structured.html">structured</A> entity tag is itself also an entity tag. <br>
<A HREF="/relevance/projects/rfc/structured.html">structured</A> nature of the tag allows caching proxies capable <br>
<A HREF="/relevance/projects/rfc/transparent.html">transparent</A> content <A HREF="/relevance/projects/rfc/negotiation.html">negotiation</A> to perform some optimizations <br>
in section 10. When not performing such optimizations, a <br>
tag SHOULD be treated as a single opaque value, <A HREF="/relevance/projects/rfc/according.html">according</A> to <br>
general rules in HTTP/1.1. <A HREF="/relevance/projects/rfc/examples.html">Examples</A> of <A HREF="/relevance/projects/rfc/structured.html">structured</A> entity tags are<br>
<br>
"xyzzy;1234" W/"xyzzy;1234" "gonkxxxx;1234" "a;b;c;;1234"<br>
<br>
In the last example, the normal entity tag is "a;b;c;" and <br>
variant list validator is "1234".<br>
<br>
If a transparently negotiated <A HREF="/relevance/projects/rfc/response.html">response</A> includes an entity tag, <br>
MUST be a <A HREF="/relevance/projects/rfc/structured.html">structured</A> entity tag. The variant list validator in <br>
<A HREF="/relevance/projects/rfc/structured.html">structured</A> tag MUST act as a validator for the variant list <br>
in the Alternates header. The normal entity tag in the <br>
tag MUST act as a validator of the entity body in the <A HREF="/relevance/projects/rfc/response.html">response</A> and <br>
all entity headers except Alternates<br>
<br>
9.3 Assigning entity tags to <br>
<br>
To allow for correct revalidation of transparently <br>
responses by clients, origin servers SHOULD <A HREF="/relevance/projects/rfc/generate.html">generate</A> all <br>
entity tags for the neighboring variant resources of the <br>
<A HREF="/relevance/projects/rfc/resource.html">resource</A> in such a way <br>
<br>
1. the same tag is never used by two <A HREF="/relevance/projects/rfc/different.html">different</A> <A HREF="/relevance/projects/rfc/variants.html">variants</A><br>
unless this tag labels exactly the same entity on all occasions<br>
<br>
2. if one normal tag "X" is a prefix of another normal tag "XY",<br>
then "Y" must never be a semicolon <A HREF="/relevance/projects/rfc/followed.html">followed</A> by a variant <br>
validator<br>
<br>
10 Content <A HREF="/relevance/projects/rfc/negotiation.html">negotiation</A> <br>
<br>
If a request on a transparently negotiated <A HREF="/relevance/projects/rfc/resource.html">resource</A> yields a <br>
with a 2xx status code or any 3xx status code except 304, <br>
<A HREF="/relevance/projects/rfc/response.html">response</A> MUST always be either a list <A HREF="/relevance/projects/rfc/response.html">response</A>, a choice <A HREF="/relevance/projects/rfc/response.html">response</A>, <br>
an adhoc <A HREF="/relevance/projects/rfc/response.html">response</A>. These responses MUST always include a TCN <br>
which <A HREF="/relevance/projects/rfc/specifies.html">specifies</A> their type. Transparently negotiated responses <br>
other status codes MAY also include a TCN header<br>
<br>
<br>
<br>
<br>
Holtman & Mutz <A HREF="/relevance/projects/rfc/experimental.html">Experimental</A> [Page 32]<br>
<br>
RFC 2295 <A HREF="/relevance/projects/rfc/transparent.html">Transparent</A> Content <A HREF="/relevance/projects/rfc/negotiation.html">Negotiation</A> March 1998<br>
<br>
<br>
The conditions under which the <A HREF="/relevance/projects/rfc/different.html">different</A> content <br>
responses may be sent are defined in section 12.1 for origin <br>
and in section 13 for proxies<br>
<br>
After having constructed a list, choice, or adhoc <A HREF="/relevance/projects/rfc/response.html">response</A>, a <br>
MAY process any If-No-Match or If-Range headers in the <br>
message and shorten the <A HREF="/relevance/projects/rfc/response.html">response</A> to a 304 (Not Modified) or 206<br>
(Partial Content) <A HREF="/relevance/projects/rfc/response.html">response</A>, <A HREF="/relevance/projects/rfc/following.html">following</A> the rules in the HTTP/1.1<br>
<A HREF="/relevance/projects/rfc/specification.html">specification</A> [1]. In this case, the entity tag of the <br>
<A HREF="/relevance/projects/rfc/response.html">response</A> will identify it indirectly as a list, choice, or <br>
<A HREF="/relevance/projects