< draft-ietf-http-rvsa-v10-01.txt   draft-ietf-http-rvsa-v10-02.txt >
HTTP Working Group Koen Holtman, TUE HTTP Working Group Koen Holtman, TUE
Internet-Draft Andrew Mutz, Hewlett-Packard Internet-Draft Andrew Mutz, Hewlett-Packard
Expires: September 23, 1997 March 23, 1997 Expires: January 28, 1998 July 28, 1997
HTTP Remote Variant Selection Algorithm -- RVSA/1.0 HTTP Remote Variant Selection Algorithm -- RVSA/1.0
draft-ietf-http-rvsa-v10-01.txt draft-ietf-http-rvsa-v10-02.txt
STATUS OF THIS MEMO STATUS OF THIS MEMO
This document is an Internet-Draft. Internet-Drafts are This document is an Internet-Draft. Internet-Drafts are
working documents of the Internet Engineering Task Force working documents of the Internet Engineering Task Force
(IETF), its areas, and its working groups. Note that other (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of Internet-Drafts are draft documents valid for a maximum of
skipping to change at line 59 skipping to change at line 59
negotiation process. This document defines the remote variant negotiation process. This document defines the remote variant
selection algorithm with the version number 1.0. selection algorithm with the version number 1.0.
OVERVIEW OF THE TRANSPARENT CONTENT NEGOTIATION DOCUMENT SET OVERVIEW OF THE TRANSPARENT CONTENT NEGOTIATION DOCUMENT SET
An up-to-date overview of documents related to transparent content An up-to-date overview of documents related to transparent content
negotiation is maintained on the web page negotiation is maintained on the web page
<URL:http://gewis.win.tue.nl/~koen/conneg/>. <URL:http://gewis.win.tue.nl/~koen/conneg/>.
The transparent content negotiation document set currently consists The transparent content negotiation document set currently consists
of three series of internet drafts. of two series of internet drafts.
1. draft-ietf-http-negotiation-XX.txt 1. draft-ietf-http-negotiation-XX.txt
`Transparent Content Negotiation in HTTP' `Transparent Content Negotiation in HTTP'
Defines the core mechanism. Standards track. Defines the core mechanism. Experimental track.
2. draft-ietf-http-rvsa-v10-XX.txt (this document) 2. draft-ietf-http-rvsa-v10-XX.txt (this document)
`HTTP Remote Variant Selection Algorithm -- RVSA/1.0' `HTTP Remote Variant Selection Algorithm -- RVSA/1.0'
Defines the remote variant selection algorithm version 1.0. Defines the remote variant selection algorithm version 1.0.
Standards track. Experimental track.
Two related series of drafts are
3. draft-ietf-http-feature-reg-XX.txt 3. draft-ietf-http-feature-reg-XX.txt
`Feature Tag Registration Procedures' `Feature Tag Registration Procedures'
Defines feature tag registration. Best Current Practice track. Defines feature tag registration. Best Current Practice
track.
4. draft-ietf-http-feature-scenarios-XX.txt
`Feature Tag Scenarios'
Discusses feature tag scenarios. Informational track.
An additional document about `the core feature set', which may An additional document about `the core feature set', which may
later become an informational RFC, may also appear. Currently, later become an informational RFC, may also appear. Currently,
there are two internet drafts which discuss parts of what could be there are two internet drafts which discuss parts of what could be
a core feature set: draft-mutz-http-attributes-XX.txt and a core feature set: draft-mutz-http-attributes-XX.txt and
draft-goland-http-headers-XX.txt draft-goland-http-headers-XX.txt
Older versions of the text in documents 1 and 2 may be found in the Older versions of the text in documents 1 and 2 may be found in the
draft-holtman-http-negotiation-XX.txt series of internet drafts. draft-holtman-http-negotiation-XX.txt series of internet drafts.
skipping to change at line 140 skipping to change at line 149
request-response round trip. request-response round trip.
This document defines the remote variant selection algorithm with This document defines the remote variant selection algorithm with
the version number 1.0. The algorithm computes whether the Accept- the version number 1.0. The algorithm computes whether the Accept-
headers in the request contain sufficient information to allow a headers in the request contain sufficient information to allow a
choice, and if so, which variant must be chosen. choice, and if so, which variant must be chosen.
1.1 Revision history 1.1 Revision history
This revision was made to resynchronise this document with the main This revision was made to resynchronise this document with the main
transparent content negotiation specification [5]. This revision transparent content negotiation specification [5].
makes no semantical changes to the remote variant selection
algorithm.
2 Terminology and notation 2 Terminology and notation
This specification uses the terminology and notation of the HTTP This specification uses the terminology and notation of the HTTP
transparent content negotiation specification [5]. transparent content negotiation specification [5].
3 The remote variant selection algorithm 3 The remote variant selection algorithm
This section defines the remote variant selection algorithm with This section defines the remote variant selection algorithm with
the version number 1.0. To implement this definition, a server MAY the version number 1.0. To implement this definition, a server MAY
run any algorithm which gives equal results. run any algorithm which gives equal results.
Note: According to [5], servers are always free to return a list Note: According to [5], servers are always free to return a list
response instead of running a remote algorithm. Therefore, response instead of running a remote algorithm. Therefore,
whenever a server may run a remote algorithm, it may also run a whenever a server may run a remote algorithm, it may also run a
partial implementation of the algorithm, provided that the partial implementation of the algorithm, provided that the
partial implementation always returns List_Response when it partial implementation always returns List_response when it
cannot compute the real result. cannot compute the real result.
3.1 Input 3.1 Input
The algorithm is always run for a particular request on a The algorithm is always run for a particular request on a
particular transparently negotiable resource. It takes the particular transparently negotiable resource. It takes the
following information as input. following information as input.
1. The variant list of the resource, as present in the Alternates 1. The variant list of the resource, as present in the Alternates
header of the resource. header of the resource.
skipping to change at line 182 skipping to change at line 189
user agent for this particular request, as given in the Accept- user agent for this particular request, as given in the Accept-
headers of the request. headers of the request.
If a fallback variant description If a fallback variant description
{"fallback.html"} {"fallback.html"}
is present in the Alternates header, the algorithm MUST interpret is present in the Alternates header, the algorithm MUST interpret
it as the variant description it as the variant description
{"fallback.html" 0.00000000000000000001} {"fallback.html" 0.000001}
The extremely low source quality value ensures that the fallback The extremely low source quality value ensures that the fallback
variant only gets chosen if all other options are exhausted. variant only gets chosen if all other options are exhausted.
3.2 Output 3.2 Output
As its output, the remote variant selection algorithm and will As its output, the remote variant selection algorithm and will
yield the appropriate action to be performed. There are two yield the appropriate action to be performed. There are two
possibilities: possibilities:
skipping to change at line 214 skipping to change at line 221
choice itself. choice itself.
3.3 Computing overall quality values 3.3 Computing overall quality values
As a first step in the remote variant selection algorithm, the As a first step in the remote variant selection algorithm, the
overall qualities of the individual variants in the list are overall qualities of the individual variants in the list are
computed. computed.
The overall quality Q of a variant is the value The overall quality Q of a variant is the value
Q = qs * qt * qc * ql * qf Q = round5( qs * qt * qc * ql * qf )
where the factors qs, qt, qc, ql, and qf are determined as follows. where round5 is a function which rounds a floating point value to
5 decimal places after the point, and where the factors qs, qt, qc,
ql, and qf are determined as follows.
qs Is the source quality factor in the variant description. qs Is the source quality factor in the variant description.
qt The media type quality factor is 1 if there is no type qt The media type quality factor is 1 if there is no type
attribute in the variant description, or if there is no attribute in the variant description, or if there is no
Accept header in the request. Otherwise, it is the quality Accept header in the request. Otherwise, it is the quality
assigned by the Accept header to the media type in the type assigned by the Accept header to the media type in the type
attribute. attribute.
Note: If a type is matched by none of the elements of an Note: If a type is matched by none of the elements of an
Accept header, the Accept header assigns the quality factor Accept header, the Accept header assigns the quality factor
0 to that type. 0 to that type.
qc The charset quality factor is 1 if there is no charset qc The charset quality factor is 1 if there is no charset
attribute in the variant description, or if there is no attribute in the variant description, or if there is no
Accept-Charset header in the request. Otherwise, the charset Accept-Charset header in the request. Otherwise, the charset
quality factor is the quality assigned by the Accept-Charset quality factor is the quality assigned by the Accept-Charset
header to the charset in the charset attribute, see section header to the charset in the charset attribute.
8.2 of [5].
ql The language quality factor is 1 if there is no language ql The language quality factor is 1 if there is no language
attribute in the variant description, or if there is no attribute in the variant description, or if there is no
Accept-Language header in the request. Otherwise, the Accept-Language header in the request. Otherwise, the
language quality factor is the highest quality factor language quality factor is the highest quality factor
assigned by the Accept-Language header to any one of the assigned by the Accept-Language header to any one of the
languages listed in the language attribute. languages listed in the language attribute.
qf The features quality factor is 1 if there is no features qf The features quality factor is 1 if there is no features
attribute in the variant description, or if there is no attribute in the variant description, or if there is no
skipping to change at line 266 skipping to change at line 274
Accept: text/html:q=1.0, */*:q=0.8 Accept: text/html:q=1.0, */*:q=0.8
Accept-Language: en;q=1.0, fr;q=0.5 Accept-Language: en;q=1.0, fr;q=0.5
the remote variant selection algorithm will compute an overall the remote variant selection algorithm will compute an overall
quality for the variant as follows: quality for the variant as follows:
{"paper.html.fr" 0.7 {type text/html} {language fr}} {"paper.html.fr" 0.7 {type text/html} {language fr}}
| | | | | |
| | | | | |
V V V V V V
0.7 * 1.0 * 0.5 = 0.35 round5 ( 0.7 * 1.0 * 0.5 ) = 0.35000
With the above Accept- headers, the complete variant list With the above Accept- headers, the complete variant list
{"paper.html.en" 0.9 {type text/html} {language en}}, {"paper.html.en" 0.9 {type text/html} {language en}},
{"paper.html.fr" 0.7 {type text/html} {language fr}}, {"paper.html.fr" 0.7 {type text/html} {language fr}},
{"paper.ps.en" 1.0 {type application/postscript} {language en}} {"paper.ps.en" 1.0 {type application/postscript} {language en}}
would yield the following computations: would yield the following computations:
qs * qt * qc * ql * qf = Q round5 ( qs * qt * qc * ql * qf ) = Q
--- --- --- --- --- ---- --- --- --- --- --- -------
paper.html.en: 0.9 * 1.0 * 1.0 * 1.0 * 1.0 = 0.9 paper.html.en: 0.9 * 1.0 * 1.0 * 1.0 * 1.0 = 0.90000
paper.html.fr: 0.7 * 1.0 * 1.0 * 0.5 * 1.0 = 0.35 paper.html.fr: 0.7 * 1.0 * 1.0 * 0.5 * 1.0 = 0.35000
paper.ps.en: 1.0 * 0.8 * 1.0 * 1.0 * 1.0 = 0.8 paper.ps.en: 1.0 * 0.8 * 1.0 * 1.0 * 1.0 = 0.80000
3.4 Definite and speculative quality values 3.4 Definite and speculative quality values
A computed overall quality value can be either definite or A computed overall quality value can be either definite or
speculative. An overall quality value is definite if it was speculative. An overall quality value is definite if it was
computed without using any wildcard characters '*' in the Accept- computed without using any wildcard characters '*' in the Accept-
headers, and without the need to use the absence of a particular headers, and without the need to use the absence of a particular
Accept- header. An overall quality value is speculative otherwise. Accept- header. An overall quality value is speculative otherwise.
As an example, in the previous section, the quality values of As an example, in the previous section, the quality values of
skipping to change at line 479 skipping to change at line 487
en-us;q=0.9, en-gb;q=0.7, en;q=0.8, da --> *;q=0.9, da en-us;q=0.9, en-gb;q=0.7, en;q=0.8, da --> *;q=0.9, da
It is also safe to collapse a language range into a wildcard, or to It is also safe to collapse a language range into a wildcard, or to
replace it by a wildcard, if its primary tag appears only once: replace it by a wildcard, if its primary tag appears only once:
*;q=0.9, da --> * *;q=0.9, da --> *
Finally, in the Accept-Features header, every feature expression Finally, in the Accept-Features header, every feature expression
can be collapsed into a wildcard, or replaced by a wildcard: can be collapsed into a wildcard, or replaced by a wildcard:
colordepth<=5, * --> * colordepth!=5, * --> *
4.2.2 Omitting Accept- headers 4.2.2 Omitting Accept- headers
According to the HTTP/1.1 specification [1], the complete absence According to the HTTP/1.1 specification [1], the complete absence
of an Accept header from the request is equivalent to the presence of an Accept header from the request is equivalent to the presence
of `Accept: */*'. Thus, if the Accept header is collapsed to of `Accept: */*'. Thus, if the Accept header is collapsed to
`Accept: */*', a user agent may omit it entirely. An `Accept: */*', a user agent may omit it entirely. An
Accept-Charset, Accept-Language, or Accept-Features header which Accept-Charset, Accept-Language, or Accept-Features header which
only contains `*' may also be omitted. only contains `*' may also be omitted.
skipping to change at line 569 skipping to change at line 577
example also use multiplication to combine quality factors. If the example also use multiplication to combine quality factors. If the
user agent combines quality factors by addition, it would be more user agent combines quality factors by addition, it would be more
advantageous to define a new remote variant selection algorithm, advantageous to define a new remote variant selection algorithm,
with a new major version number, for use by this agent. with a new major version number, for use by this agent.
4.3.2 Working around minor differences 4.3.2 Working around minor differences
Even if a local algorithm uses multiplication to combine quality Even if a local algorithm uses multiplication to combine quality
factors, it could use an extended quality formulae like factors, it could use an extended quality formulae like
Q = ( qs * qt * qc * ql * qf ) * q_adjust Q = round5( qs * qt * qc * ql * qf ) * q_adjust
in order to account for special interdependencies between in order to account for special interdependencies between
dimensions, which are due to limitations of the user agent. For dimensions, which are due to limitations of the user agent. For
example, if the user agent, for some reason, cannot handle the example, if the user agent, for some reason, cannot handle the
iso-8859-7 charset when rendering text/plain documents, the iso-8859-7 charset when rendering text/plain documents, the
q_adjust factor would be 0 when the text/plain - iso-8859-7 q_adjust factor would be 0 when the text/plain - iso-8859-7
combination is present in the variant description, and 1 otherwise. combination is present in the variant description, and 1 otherwise.
By selectively withholding information from the remote variant By selectively withholding information from the remote variant
selection algorithm, the user agent can ensure that the remote selection algorithm, the user agent can ensure that the remote
skipping to change at line 632 skipping to change at line 640
[2] Roy T. Fielding, Henrik Frystyk Nielsen, and Tim Berners-Lee. [2] Roy T. Fielding, Henrik Frystyk Nielsen, and Tim Berners-Lee.
Hypertext Transfer Protocol -- HTTP/1.1. Internet-Draft Hypertext Transfer Protocol -- HTTP/1.1. Internet-Draft
draft-ietf-http-v11-spec-01.txt, HTTP Working Group, January, draft-ietf-http-v11-spec-01.txt, HTTP Working Group, January,
1996. 1996.
[3] T. Berners-Lee, R. Fielding, and H. Frystyk. Hypertext [3] T. Berners-Lee, R. Fielding, and H. Frystyk. Hypertext
Transfer Protocol -- HTTP/1.0. RFC 1945. MIT/LCS, UC Irvine, Transfer Protocol -- HTTP/1.0. RFC 1945. MIT/LCS, UC Irvine,
May 1996. May 1996.
[4] K. Holtman, A. Mutz. Feature Tag Registration Procedures. [4] K. Holtman, A. Mutz. Feature Tag Registration Procedures.
Internet-Draft draft-ietf-http-feature-reg-00.txt, HTTP Working Internet-Draft draft-ietf-http-feature-reg-02.txt, HTTP Working
Group, October 30, 1996. Group. July 1997.
[5] K. Holtman, A. Mutz. Transparent Content Negotiation in HTTP. [5] K. Holtman, A. Mutz. Transparent Content Negotiation in HTTP.
Internet-Draft draft-ietf-http-negotiation-01.txt, HTTP Working Internet-Draft draft-ietf-http-negotiation-03.txt, HTTP Working
Group. Group. July 1997.
8 Authors' addresses 8 Authors' addresses
Koen Holtman Koen Holtman
Technische Universiteit Eindhoven Technische Universiteit Eindhoven
Postbus 513 Postbus 513
Kamer HG 6.57 Kamer HG 6.57
5600 MB Eindhoven (The Netherlands) 5600 MB Eindhoven (The Netherlands)
Email: koen@win.tue.nl Email: koen@win.tue.nl
Andrew H. Mutz Andrew H. Mutz
Hewlett-Packard Company Hewlett-Packard Company
1501 Page Mill Road 3U-3 1501 Page Mill Road 3U-3
Palo Alto CA 94304, USA Palo Alto CA 94304, USA
Fax +1 415 857 4691 Fax +1 415 857 4691
Email: mutz@hpl.hp.com Email: mutz@hpl.hp.com
Expires: September 23, 1997 Expires: January 28, 1998
 End of changes. 20 change blocks. 
28 lines changed or deleted 36 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/