If at least one overall quality value is greater than 0, then the
best variant is the variant which has the description with the
highest overall quality value, or, if there are multiple variant
descriptions which share the highest overall quality value, the
variant of the first variant description in the list which has this
highest overall quality value.
19.3 Ranking dimensions
Consider the following variant list:
{"paper.greek" 1.0 {language el} {charset ISO-8859-7}},
{"paper.english" 1.0 {language en} {charset ISO-8859-1}}
It could be the case that the user prefers the language "el" over
"en", while the user agent can render "ISO-8859-1" better than "ISO-
8859-7". The result is that in the language dimension, the first
variant is best, while the second variant is best in the charset
dimension. In this situation, it would be preferable to choose the
first variant as the best variant: the user settings in the language
dimension should take precedence over the hard-coded values in the
charset dimension.
To express this ranking between dimensions, the user agent
configuration database should have a higher spread in the quality
values for the language dimension than for the charset dimension.
For example, with
languages: el;q=1.0, en-gb;q=0.7, en;q=0.6, da;q=0, ...
charsets: ISO-8859-1;q=1.0, ISO-8859-7;q=0.95,
ISO-8859-5;q=0.97, unicode-1-1;q=0, ...
the first variant will have an overall quality of 0.95000, while the
second variant will have an overall quality 0.70000. This makes the
first variant the best variant.
20 Appendix: feature negotiation examples
This appendix contains examples of the use of feature tags in variant
descriptions. The tag names used here are examples only, they do not
in general reflect the tag naming scheme proposed in [4].
20.1 Use of feature tags
Feature tags can be used in variant lists to express the quality
degradation associated with the presence or absence of certain
features. One example is
{"index.html.plain" 0.7 },
{"index.html" 1.0 {features tables frames}}
Here, the "{features tables frames}" part expresses that index.html
uses the features tagged as tables and frames. If these features are
absent, the overall quality of index.html degrades to 0. Another
example is
{"home.graphics" 1.0 {features !textonly}},
{"home.textonly" 0.7 }
where the "{features !textonly}" part expresses that home.graphics
requires the absence of the textonly feature. If the feature is
present, the overall quality of home.graphics degrades to 0.
The absence of a feature need not always degrade the overall quality
to 0. In the example
{"x.html.1" 1.0 {features fonts;-0.7}}
the absence of the fonts feature degrades the quality with a factor
of 0.7. Finally, in the example
{"y.html" 1.0 {features [blebber wolx] }}
The "[blebber wolx]" expresses that y.html requires the presence of
the blebber feature or the wolx feature. This construct can be used
in a number of cases:
1. blebber and wolx actually tag the same feature, but they were
registered by different people, and some user agents say they
support blebber while others say they support wolx.
2. blebber and wolx are HTML tags of different vendors which
implement the same functionality, and which are used together in
y.html without interference.
3. blebber and wolx are HTML tags of different vendors which
implement the same functionality, and y.html uses the tags in a
conditional HTML construct.
4. blebber is a complicated HTML tag with only a sketchy
definition, implemented by one user agent vendor, and wolx
indicates implementation of a well-defined subset of the blebber
tag by some other vendor(s). y.html uses only this well-defined
subset.
20.2 Use of numeric feature tags
As an example of negotiation in a numeric area, the following variant
list describes four variants with title graphics designed for
increasing screen widths:
{"home.pda" 1.0 {features screenwidth=[-199] }},
{"home.narrow" 1.0 {features screenwidth=[200-599] }},
{"home.normal" 1.0 {features screenwidth=[600-999] }},
{"home.wide" 1.0 {features screenwidth=[1000-] }},
{"home.normal"}
The last element of the list specifies a safe default for user agents
which do not implement screen width negotiation. Such user agents
will reject the first four variants as unusable, as they seem to rely
on a feature which they do not understand.
20.3 Feature tag design
When designing a new feature tag, it is important to take into
account that existing user agents, which do not recognize the new tag
will treat the feature as absent. In general, a new feature tag
needs to be designed in such a way that absence of the tag is the
default case which reflects current practice. If this design
principle is ignored, the resulting feature tag will generally be
unusable.
As an example, one could try to support negotiation between
monochrome and color content by introducing a `color' feature tag,
the presence of which would indicate the capability to display color
graphics. However, if this new tag is used in a variant list, for
example
{"rainbow.gif" 1.0 {features color} }
{"rainbow.mono.gif" 0.6 {features !color}}
then existing user agents, which would not recognize the color tag,
would all display the monochrome rainbow. The color tag is therefore
unusable in situations where optimal results for existing user agents
are desired. To provide for negotiation in this area, one must
introduce a `monochrome' feature tag; its presence indicates that the
user agent can only render (or the user prefers to view) monochrome
graphics.
21 Appendix: origin server implementation considerations
21.1 Implementation with a CGI script
Transparent content negotiation has been designed to allow a broad
range of implementation options at the origin server side. A very
minimal implementation can be done using the CGI interface. The CGI
script below is an example.
#!/bin/sh
cat - <<'blex'
TCN: list
Alternates: {"stats.tables.html" 1.0 {type text/html} {features
tables}}, {"stats.html" 0.8 {type text/html}}, {"stats.ps" 0.95
{type application/postscript}}
Vary: *
Content-Type: text/html
<title>Multiple Choices for Web Statistics</title>
<h2>Multiple Choices for Web Statistics:</h2>
<ul>
<li><a href=stats.tables.html>Version with HTML tables</a>
<p>
<li><a href=stats.html>Version without HTML tables</a>
<p>
<li><a href=stats.ps>Postscript version</a>
</ul>
blex
The Alternates header in the above script must be read as a single
line. The script always generates a list response with the 200 (OK)
code, which ensures compatibility with non-negotiating HTTP/1.0
agents.
21.2 Direct support by HTTP servers
Sophisticated HTTP servers could make a transparent negotiation
module available to content authors. Such a module could incorporate
a remote variant selection algorithm and an implementation of the
algorithm for generating choice responses (section 10.2). The
definition of interfaces to such modules is beyond the scope of this
specification.
21.3 Web publishing tools
Web publishing tools could automatically generate several variants of
a document (for example the original TeX version, a HTML version with
tables, a HTML version without tables, and a Postscript version),
together with an appropriate variant list in the interface format of
a HTTP server transparent negotiation module. This would allow
documents to be published as transparently negotiable resources.
22 Appendix: Example of choice response construction
The following is an example of the construction of a choice response
by a proxy cache which supports HTTP/1.1 and transparent content
negotiation. The use of the HTTP/1.1 conditional request mechanisms
is also shown.
Assume that a user agent has cached a variant list with the validator
"1234" for the negotiable resource http://x.org/paper. Also assume
that it has cached responses from two neighboring variants, with the
entity tags "gonkyyyy" and W/"a;b". Assume that all three user agent
cache entries are stale: they would need to be revalidated before the
user agent can use them. If http://x.org/paper accessed in this
situation, the user agent could send the following request to its
proxy cache:
GET /paper HTTP/1.1
Host: x.org
User-Agent: WuxtaWeb/2.4
Negotiate: 1.0
Accept: text/html, application/postscript;q=0.4, */*
Accept-Language: en
If-None-Match: "gonkyyyy;1234", W/"a;b;1234"
Assume that the proxy cache has cached the same three items as the
user agent, but that it has revalidated the variant list 8000 seconds
ago, so that the list is still fresh for the proxy. This means that
the proxy can run a remote variant selection algorithm on the list
and the incoming request.
Assume that the remote algorithm is able to choose paper.html.en as
the best variant. The proxy can now construct a choice response,
using the algorithm in section 10.2. In steps 1 and 2 of the
algorithm, the proxy can construct the following conditional request
on the best variant, and send it to the origin server:
GET /paper.html.en HTTP/1.1
Host: x.org
User-Agent: WuxtaWeb/2.4
Negotiate: 1.0
Accept: text/html, application/postscript;q=0.4, */*
Accept-Language: en
If-None-Match: "gonkyyyy", W/"a;b"
Via: 1.1 fred
On receipt of the response
HTTP/1.1 304 Not Modified
Date: Tue, 11 Jun 1996 20:05:31 GMT
Etag: "gonkyyyy"
from the origin server, the proxy can use its freshly revalidated
paper.html.en cache entry to expand the response to a non-304
response:
HTTP/1.1 200 OK
Date: Tue, 11 Jun 1996 20:05:31 GMT
Content-Type: text/html
Last-Modified: Mon, 10 Jun 1996 10:01:14 GMT
Content-Length: 5327
Cache-control: max-age=604800
Etag: "gonkyyyy"
Via: 1.1 fred
Age: 0
<title>A paper about ....
Using this 200 response, the proxy can construct a choice response
in step 4 of the algorithm:
HTTP/1.1 200 OK
Date: Tue, 11 Jun 1996 20:05:31 GMT
TCN: choice
Content-Type: text/html
Last-Modified: Mon, 10 Jun 1996 10:01:14 GMT
Content-Length: 5327
Cache-control: max-age=604800
Content-Location: paper.html.en
Alternates: {"paper.html.en" 0.9 {type text/html} {language en}},
{"paper.html.fr" 0.7 {type text/html} {language fr}},
{"paper.ps.en" 1.0 {type application/postscript}
{language en}}
Etag: "gonkyyyy;1234"
Vary: negotiate, accept, accept-language
Expires: Thu, 01 Jan 1980 00:00:00 GMT
Via: 1.1 fred
Age: 8000
<title>A paper about ....
The choice response can subsequently be shortened to a 304 response,
because of the If-None-Match header in the original request from the
user agent. Thus, the proxy can finally return
HTTP/1.1 304 Not Modified
Date: Tue, 11 Jun 1996 20:05:31 GMT
Etag: "gonkyyyy;1234"
Content-Location: paper.html.en
Vary: negotiate, accept, accept-language
Expires: Thu, 01 Jan 1980 00:00:00 GMT
Via: 1.1 fred
Age: 8000
to the user agent.
23 Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.