1 |
|
2 |
HTTP Working Group Koen Holtman, TUE |
3 |
Internet-Draft Andrew Mutz, Hewlett-Packard |
4 |
Expires: January 28, 1998 July 28, 1997 |
5 |
|
6 |
HTTP Remote Variant Selection Algorithm -- RVSA/1.0 |
7 |
|
8 |
draft-ietf-http-rvsa-v10-02.txt |
9 |
|
10 |
|
11 |
STATUS OF THIS MEMO |
12 |
|
13 |
This document is an Internet-Draft. Internet-Drafts are |
14 |
working documents of the Internet Engineering Task Force |
15 |
(IETF), its areas, and its working groups. Note that other |
16 |
groups may also distribute working documents as |
17 |
Internet-Drafts. |
18 |
|
19 |
Internet-Drafts are draft documents valid for a maximum of |
20 |
six months and may be updated, replaced, or obsoleted by |
21 |
other documents at any time. It is inappropriate to use |
22 |
Internet-Drafts as reference material or to cite them other |
23 |
than as "work in progress". |
24 |
|
25 |
To learn the current status of any Internet-Draft, please |
26 |
check the "1id-abstracts.txt" listing contained in the |
27 |
Internet-Drafts Shadow Directories on ftp.is.co.za |
28 |
(Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific |
29 |
Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US |
30 |
West Coast). |
31 |
|
32 |
Distribution of this document is unlimited. Please send |
33 |
comments to the HTTP working group at |
34 |
<http-wg@cuckoo.hpl.hp.com>. Discussions of the working |
35 |
group are archived at |
36 |
<URL:http://www.ics.uci.edu/pub/ietf/http/>. General |
37 |
discussions about HTTP and the applications which use HTTP |
38 |
should take place on the <www-talk@w3.org> mailing list. |
39 |
|
40 |
HTML and change bar versions of this document are available |
41 |
at <URL:http://gewis.win.tue.nl/~koen/conneg/>. |
42 |
|
43 |
|
44 |
ABSTRACT |
45 |
|
46 |
HTTP allows web site authors to put multiple versions of the |
47 |
same information under a single URL. Transparent content |
48 |
negotiation is a mechanism for automatically selecting the |
49 |
best version when the URL is accessed. A remote variant |
50 |
selection algorithm can be used to speed up the transparent |
51 |
negotiation process. This document defines the remote variant |
52 |
selection algorithm with the version number 1.0. |
53 |
|
54 |
|
55 |
OVERVIEW OF THE TRANSPARENT CONTENT NEGOTIATION DOCUMENT SET |
56 |
|
57 |
An up-to-date overview of documents related to transparent content |
58 |
negotiation is maintained on the web page |
59 |
<URL:http://gewis.win.tue.nl/~koen/conneg/>. |
60 |
|
61 |
The transparent content negotiation document set currently consists |
62 |
of two series of internet drafts. |
63 |
|
64 |
1. draft-ietf-http-negotiation-XX.txt |
65 |
|
66 |
`Transparent Content Negotiation in HTTP' |
67 |
|
68 |
Defines the core mechanism. Experimental track. |
69 |
|
70 |
2. draft-ietf-http-rvsa-v10-XX.txt (this document) |
71 |
|
72 |
`HTTP Remote Variant Selection Algorithm -- RVSA/1.0' |
73 |
|
74 |
Defines the remote variant selection algorithm version 1.0. |
75 |
Experimental track. |
76 |
|
77 |
Two related series of drafts are |
78 |
|
79 |
3. draft-ietf-http-feature-reg-XX.txt |
80 |
|
81 |
`Feature Tag Registration Procedures' |
82 |
|
83 |
Defines feature tag registration. Best Current Practice |
84 |
track. |
85 |
|
86 |
4. draft-ietf-http-feature-scenarios-XX.txt |
87 |
|
88 |
`Feature Tag Scenarios' |
89 |
|
90 |
Discusses feature tag scenarios. Informational track. |
91 |
|
92 |
An additional document about `the core feature set', which may |
93 |
later become an informational RFC, may also appear. Currently, |
94 |
there are two internet drafts which discuss parts of what could be |
95 |
a core feature set: draft-mutz-http-attributes-XX.txt and |
96 |
draft-goland-http-headers-XX.txt |
97 |
|
98 |
Older versions of the text in documents 1 and 2 may be found in the |
99 |
draft-holtman-http-negotiation-XX.txt series of internet drafts. |
100 |
|
101 |
|
102 |
TABLE OF CONTENTS |
103 |
|
104 |
1 Introduction |
105 |
1.1 Revision history |
106 |
|
107 |
2 Terminology and notation |
108 |
|
109 |
3 The remote variant selection algorithm |
110 |
3.1 Input |
111 |
3.2 Output |
112 |
3.3 Computing overall quality values |
113 |
3.4 Definite and speculative quality values |
114 |
3.5 Determining the result |
115 |
|
116 |
4 Use of the algorithm |
117 |
4.1 Using quality factors to rank preferences |
118 |
4.2 Construction of short requests |
119 |
4.2.1 Collapsing Accept- header elements |
120 |
4.2.2 Omitting Accept- headers |
121 |
4.2.3 Dynamically lengthening requests |
122 |
4.3 Differences between the local and the remote algorithm |
123 |
4.3.1 Avoiding major differences |
124 |
4.3.2 Working around minor differences |
125 |
|
126 |
5 Security and privacy considerations |
127 |
|
128 |
6 Acknowledgments |
129 |
|
130 |
7 References |
131 |
|
132 |
8 Authors' addresses |
133 |
|
134 |
|
135 |
1 Introduction |
136 |
|
137 |
HTTP allows web site authors to put multiple versions (variants) of |
138 |
the same information under a single URL. Transparent content |
139 |
negotiation [5] is a mechanism for automatically selecting the best |
140 |
variant when the URL is accessed. A remote variant selection |
141 |
algorithm can be used by a server to choose a best variant on |
142 |
behalf of a negotiating user agent. The use of a remote algorithm |
143 |
can speed up the transparent negotiation process by eliminating a |
144 |
request-response round trip. |
145 |
|
146 |
This document defines the remote variant selection algorithm with |
147 |
the version number 1.0. The algorithm computes whether the Accept- |
148 |
headers in the request contain sufficient information to allow a |
149 |
choice, and if so, which variant must be chosen. |
150 |
|
151 |
|
152 |
1.1 Revision history |
153 |
|
154 |
This revision was made to resynchronise this document with the main |
155 |
transparent content negotiation specification [5]. |
156 |
|
157 |
|
158 |
2 Terminology and notation |
159 |
|
160 |
This specification uses the terminology and notation of the HTTP |
161 |
transparent content negotiation specification [5]. |
162 |
|
163 |
|
164 |
3 The remote variant selection algorithm |
165 |
|
166 |
This section defines the remote variant selection algorithm with |
167 |
the version number 1.0. To implement this definition, a server MAY |
168 |
run any algorithm which gives equal results. |
169 |
|
170 |
Note: According to [5], servers are always free to return a list |
171 |
response instead of running a remote algorithm. Therefore, |
172 |
whenever a server may run a remote algorithm, it may also run a |
173 |
partial implementation of the algorithm, provided that the |
174 |
partial implementation always returns List_response when it |
175 |
cannot compute the real result. |
176 |
|
177 |
|
178 |
3.1 Input |
179 |
|
180 |
The algorithm is always run for a particular request on a |
181 |
particular transparently negotiable resource. It takes the |
182 |
following information as input. |
183 |
|
184 |
1. The variant list of the resource, as present in the Alternates |
185 |
header of the resource. |
186 |
|
187 |
2. (Partial) Information about capabilities and preferences of the |
188 |
user agent for this particular request, as given in the Accept- |
189 |
headers of the request. |
190 |
|
191 |
If a fallback variant description |
192 |
|
193 |
{"fallback.html"} |
194 |
|
195 |
is present in the Alternates header, the algorithm MUST interpret |
196 |
it as the variant description |
197 |
|
198 |
{"fallback.html" 0.000001} |
199 |
|
200 |
The extremely low source quality value ensures that the fallback |
201 |
variant only gets chosen if all other options are exhausted. |
202 |
|
203 |
|
204 |
3.2 Output |
205 |
|
206 |
As its output, the remote variant selection algorithm and will |
207 |
yield the appropriate action to be performed. There are two |
208 |
possibilities: |
209 |
|
210 |
Choice_response |
211 |
|
212 |
The Accept- headers contain sufficient information to make a |
213 |
choice on behalf of the user agent possible, and the best |
214 |
variant MAY be returned in a choice response. |
215 |
|
216 |
List_response |
217 |
|
218 |
The Accept- headers do not contain sufficient information to |
219 |
make a choice on behalf of the user agent possible. A list |
220 |
response MUST be returned, allowing the user agent to make the |
221 |
choice itself. |
222 |
|
223 |
|
224 |
3.3 Computing overall quality values |
225 |
|
226 |
As a first step in the remote variant selection algorithm, the |
227 |
overall qualities of the individual variants in the list are |
228 |
computed. |
229 |
|
230 |
The overall quality Q of a variant is the value |
231 |
|
232 |
Q = round5( qs * qt * qc * ql * qf ) |
233 |
|
234 |
where round5 is a function which rounds a floating point value to |
235 |
5 decimal places after the point, and where the factors qs, qt, qc, |
236 |
ql, and qf are determined as follows. |
237 |
|
238 |
qs Is the source quality factor in the variant description. |
239 |
|
240 |
qt The media type quality factor is 1 if there is no type |
241 |
attribute in the variant description, or if there is no |
242 |
Accept header in the request. Otherwise, it is the quality |
243 |
assigned by the Accept header to the media type in the type |
244 |
attribute. |
245 |
|
246 |
Note: If a type is matched by none of the elements of an |
247 |
Accept header, the Accept header assigns the quality factor |
248 |
0 to that type. |
249 |
|
250 |
qc The charset quality factor is 1 if there is no charset |
251 |
attribute in the variant description, or if there is no |
252 |
Accept-Charset header in the request. Otherwise, the charset |
253 |
quality factor is the quality assigned by the Accept-Charset |
254 |
header to the charset in the charset attribute. |
255 |
|
256 |
ql The language quality factor is 1 if there is no language |
257 |
attribute in the variant description, or if there is no |
258 |
Accept-Language header in the request. Otherwise, the |
259 |
language quality factor is the highest quality factor |
260 |
assigned by the Accept-Language header to any one of the |
261 |
languages listed in the language attribute. |
262 |
|
263 |
qf The features quality factor is 1 if there is no features |
264 |
attribute in the variant description, or if there is no |
265 |
Accept-Features header in the request. Otherwise, it is the |
266 |
quality degradation factor for the features attribute, see |
267 |
section 6.4 of [5]. |
268 |
|
269 |
As an example, if a variant list contains the variant description |
270 |
|
271 |
{"paper.html.en" 0.7 {type text/html} {language fr}} |
272 |
|
273 |
and if the request contains the Accept- headers |
274 |
|
275 |
Accept: text/html:q=1.0, */*:q=0.8 |
276 |
Accept-Language: en;q=1.0, fr;q=0.5 |
277 |
|
278 |
the remote variant selection algorithm will compute an overall |
279 |
quality for the variant as follows: |
280 |
|
281 |
{"paper.html.fr" 0.7 {type text/html} {language fr}} |
282 |
| | | |
283 |
| | | |
284 |
V V V |
285 |
round5 ( 0.7 * 1.0 * 0.5 ) = 0.35000 |
286 |
|
287 |
With the above Accept- headers, the complete variant list |
288 |
|
289 |
{"paper.html.en" 0.9 {type text/html} {language en}}, |
290 |
{"paper.html.fr" 0.7 {type text/html} {language fr}}, |
291 |
{"paper.ps.en" 1.0 {type application/postscript} {language en}} |
292 |
|
293 |
would yield the following computations: |
294 |
|
295 |
round5 ( qs * qt * qc * ql * qf ) = Q |
296 |
--- --- --- --- --- ------- |
297 |
paper.html.en: 0.9 * 1.0 * 1.0 * 1.0 * 1.0 = 0.90000 |
298 |
paper.html.fr: 0.7 * 1.0 * 1.0 * 0.5 * 1.0 = 0.35000 |
299 |
paper.ps.en: 1.0 * 0.8 * 1.0 * 1.0 * 1.0 = 0.80000 |
300 |
|
301 |
|
302 |
3.4 Definite and speculative quality values |
303 |
|
304 |
A computed overall quality value can be either definite or |
305 |
speculative. An overall quality value is definite if it was |
306 |
computed without using any wildcard characters '*' in the Accept- |
307 |
headers, and without the need to use the absence of a particular |
308 |
Accept- header. An overall quality value is speculative otherwise. |
309 |
|
310 |
As an example, in the previous section, the quality values of |
311 |
paper.html.en and paper.html.fr are definite, and the quality value |
312 |
of paper.ps.en is speculative because the type |
313 |
application/postscript was matched to the range */*. |
314 |
|
315 |
Definiteness can be defined more formally as follows. An overall |
316 |
quality value Q is definite if the same quality value Q can be |
317 |
computed after the request message is changed in the following way: |
318 |
|
319 |
1. If an Accept, Accept-Charset, Accept-Language, or |
320 |
Accept-Features header is missing from the request, add |
321 |
this header with an empty field. |
322 |
|
323 |
2. Delete any media ranges containing a wildcard character '*' |
324 |
from the Accept header. Delete any wildcard '*' from the |
325 |
Accept-Charset, Accept-Language, and Accept-Features |
326 |
headers. |
327 |
|
328 |
As another example, the overall quality factor for the variant |
329 |
|
330 |
{"blah.html" 1 {language en-gb} {features blebber [x y]}} |
331 |
|
332 |
is 1 and definite with the Accept- headers |
333 |
|
334 |
Accept-Language: en-gb, fr |
335 |
Accept-Features: blebber, x, !y, * |
336 |
|
337 |
and |
338 |
|
339 |
Accept-Language: en, fr |
340 |
Accept-Features: blebber, x, * |
341 |
|
342 |
The overall quality factor is still 1, but speculative, with the |
343 |
Accept- headers |
344 |
|
345 |
Accept-language: en-gb, fr |
346 |
Accept-Features: blebber, !y, * |
347 |
|
348 |
and |
349 |
|
350 |
Accept-Language: fr, * |
351 |
Accept-Features: blebber, x, !y, * |
352 |
|
353 |
|
354 |
3.5 Determining the result |
355 |
|
356 |
The best variant, as determined by the remote variant selection |
357 |
algorithm, is the one variant with the highest overall quality |
358 |
value, or, if there are multiple variants which share the highest |
359 |
overall quality, the first variant in the list with this value. |
360 |
|
361 |
The end result of the remote variant selection algorithm is |
362 |
Choice_response if all of the following conditions are met |
363 |
|
364 |
a. the overall quality value of the best variant is greater |
365 |
than 0 |
366 |
|
367 |
b. the overall quality value of the best variant is a definite |
368 |
quality value |
369 |
|
370 |
c. the variant resource is a neighbor of the negotiable |
371 |
resource. This last condition exists to ensure that a |
372 |
security-related restriction on the generation of choice |
373 |
responses is met, see sections 10.2 and 14.2 of [5]. |
374 |
|
375 |
In all other cases, the end result is List_response. |
376 |
|
377 |
The requirement for definiteness above affects the interpretation |
378 |
of Accept- headers in a dramatic way. For example, it causes the |
379 |
remote algorithm to interpret the header |
380 |
|
381 |
Accept: image/gif;q=0.9, */*;q=1.0 |
382 |
|
383 |
as |
384 |
|
385 |
`I accept image/gif with a quality of 0.9, and assign quality |
386 |
factors up to 1.0 to other media types. If this information is |
387 |
insufficient to make a choice on my behalf, do not make a choice |
388 |
but send the list of variants'. |
389 |
|
390 |
Without the requirement, the interpretation would have been |
391 |
|
392 |
`I accept image/gif with a quality of 0.9, and all other media |
393 |
types with a quality of 1.0'. |
394 |
|
395 |
|
396 |
4 Use of the algorithm |
397 |
|
398 |
This section discusses how user agents can use the remote algorithm |
399 |
in an optimal way. This section is not normative, it is included |
400 |
for informational purposes only. |
401 |
|
402 |
|
403 |
4.1 Using quality factors to rank preferences |
404 |
|
405 |
Using quality factors, a user agent can not only rank the elements |
406 |
within a particular Accept- header, it can also express precedence |
407 |
relations between the different Accept- headers. Consider for |
408 |
example the following variant list: |
409 |
|
410 |
{"paper.english" 1.0 {language en} {charset ISO-8859-1}}, |
411 |
{"paper.greek" 1.0 {language el} {charset ISO-8859-7}} |
412 |
|
413 |
and suppose that the user prefers "el" over "en", while the user |
414 |
agent can render "ISO-8859-1" with a higher quality than |
415 |
"ISO-8859-7". If the Accept- headers are |
416 |
|
417 |
Accept-Language: gr, en;q=0.8 |
418 |
Accept-Charset: ISO-8859-1, ISO-8859-7;q=0.6, * |
419 |
|
420 |
then the remote variant selection algorithm would choose the |
421 |
English variant, because this variant has the least overall quality |
422 |
degradation. But if the Accept- headers are |
423 |
|
424 |
Accept-Language: gr, en;q=0.8 |
425 |
Accept-Charset: ISO-8859-1, ISO-8859-7;q=0.95, * |
426 |
|
427 |
then the algorithm would choose the Greek variant. In general, the |
428 |
Accept- header with the biggest spread between its quality factors |
429 |
gets the highest precedence. If a user agent allows the user to |
430 |
set the quality factors for some headers, while other factors are |
431 |
hard-coded, it should use a low spread on the hard-coded factors |
432 |
and a high spread on the user-supplied factors, so that the user |
433 |
settings take precedence over the built-in settings. |
434 |
|
435 |
|
436 |
4.2 Construction of short requests |
437 |
|
438 |
In a request on a transparently negotiated resource, a user agent |
439 |
need not send a very long Accept- header, which lists all of its |
440 |
capabilities, to get optimal results. For example, instead of |
441 |
sending |
442 |
|
443 |
Accept: image/gif;q=0.9, image/jpeg;q=0.8, image/png;q=1.0, |
444 |
image/tiff;q=0.5, image/ief;q=0.5, image/x-xbitmap;q=0.8, |
445 |
application/plugin1;q=1.0, application/plugin2;q=0.9 |
446 |
|
447 |
the user agent can send |
448 |
|
449 |
Accept: image/gif;q=0.9, */*;q=1.0 |
450 |
|
451 |
It can send this short header without running the risk of getting a |
452 |
choice response with, say, an inferior image/tiff variant. For |
453 |
example, with the variant list |
454 |
|
455 |
{"x.gif" 1.0 {type image/gif}}, {"x.tiff" 1.0 {type image/tiff}}, |
456 |
|
457 |
the remote algorithm will compute a definite overall quality of 0.9 |
458 |
for x.gif and a speculative overall quality value of 1.0 for |
459 |
x.tiff. As the best variant has a speculative quality value, the |
460 |
algorithm will not choose x.tiff, but return a list response, after |
461 |
which the selection algorithm of the user agent will correctly |
462 |
choose x.gif. The end result is the same as if the long Accept- |
463 |
header above had been sent. |
464 |
|
465 |
Thus, user agents can vary the length of the Accept- headers to get |
466 |
an optimal tradeoff between the speed with which the first request |
467 |
is transmitted, and the chance that the remote algorithm has enough |
468 |
information to eliminate a second request. |
469 |
|
470 |
4.2.1 Collapsing Accept- header elements |
471 |
|
472 |
This section discusses how a long Accept- header which lists all |
473 |
capabilities and preferences can be safely made shorter. The |
474 |
remote variant selection algorithm is designed in such a way that |
475 |
it is always safe to shorten an Accept or Accept-Charset header by |
476 |
two taking two header elements `A;q=f' and `B;q=g' and replacing |
477 |
them by a single element `P;q=m' where P is a wildcard pattern that |
478 |
matches both A and B, and m is the maximum of f and g. Some |
479 |
examples are |
480 |
|
481 |
text/html;q=1.0, text/plain;q=0.8 --> text/*;q=1.0 |
482 |
image/*;q=0.8, application/*;q=0.7 --> */*;q=0.8 |
483 |
|
484 |
iso-8859-5;q=1.0, unicode-1-1;q=0.8 --> *;q=1.0 |
485 |
|
486 |
Note that every `;q=1.0' above is optional, and can be omitted: |
487 |
|
488 |
iso-8859-7;q=0.6, * --> * |
489 |
|
490 |
For Accept-Language, it is safe to collapse all language ranges |
491 |
with the same primary tag into a wildcard: |
492 |
|
493 |
en-us;q=0.9, en-gb;q=0.7, en;q=0.8, da --> *;q=0.9, da |
494 |
|
495 |
It is also safe to collapse a language range into a wildcard, or to |
496 |
replace it by a wildcard, if its primary tag appears only once: |
497 |
|
498 |
*;q=0.9, da --> * |
499 |
|
500 |
Finally, in the Accept-Features header, every feature expression |
501 |
can be collapsed into a wildcard, or replaced by a wildcard: |
502 |
|
503 |
colordepth!=5, * --> * |
504 |
|
505 |
4.2.2 Omitting Accept- headers |
506 |
|
507 |
According to the HTTP/1.1 specification [1], the complete absence |
508 |
of an Accept header from the request is equivalent to the presence |
509 |
of `Accept: */*'. Thus, if the Accept header is collapsed to |
510 |
`Accept: */*', a user agent may omit it entirely. An |
511 |
Accept-Charset, Accept-Language, or Accept-Features header which |
512 |
only contains `*' may also be omitted. |
513 |
|
514 |
4.2.3 Dynamically lengthening requests |
515 |
|
516 |
In general, a user agent capable of transparent content negotiation |
517 |
can send short requests by default. Some short Accept- headers |
518 |
could be included for the benefit of existing servers which use |
519 |
HTTP/1.0 style negotiation (see section 4.2 of [5]). An example is |
520 |
|
521 |
GET /paper HTTP/1.1 |
522 |
Host: x.org |
523 |
User-Agent: WuxtaWeb/2.4 |
524 |
Negotiate: 1.0 |
525 |
Accept-Language: en, *;q=0.9 |
526 |
|
527 |
If the Accept- headers included in such a default request are not |
528 |
suitable as input to the remote variant selection algorithm, the |
529 |
user agent can disable the algorithm by sending `Negotiate: trans' |
530 |
instead of `Negotiate: 1.0'. |
531 |
|
532 |
If the user agent discovers, though the receipt of a list or choice |
533 |
response, that a particular origin server contains transparently |
534 |
negotiated resources, it could dynamically lengthen future requests |
535 |
to this server, for example to |
536 |
|
537 |
GET /paper/chapter1 HTTP/1.1 |
538 |
Host: x.org |
539 |
User-Agent: WuxtaWeb/2.4 |
540 |
Negotiate: 1.0 |
541 |
Accept: text/html, application/postscript;q=0.8, */* |
542 |
Accept-Language: en, fr;q=0.5, *;q=0.9 |
543 |
Accept-Features: tables, * |
544 |
|
545 |
This will increase the chance that the remote variant selection |
546 |
algorithm will have sufficient information to choose on behalf of |
547 |
the user agent, thereby optimizing the negotiation process. A good |
548 |
strategy for dynamic extension would be to extend the headers with |
549 |
those media types, languages, charsets, and feature tags mentioned |
550 |
in the variant lists of past responses from the server. |
551 |
|
552 |
|
553 |
4.3 Differences between the local and the remote algorithm |
554 |
|
555 |
A user agent can only optimize content negotiation though the use |
556 |
of a remote algorithm if its local algorithm will generally make |
557 |
the same choice. If a user agent receives a choice response |
558 |
containing a variant X selected by the remote algorithm, while the |
559 |
local algorithm would have selected Y, the user agent has two |
560 |
options: |
561 |
|
562 |
1. Retrieve Y in a subsequent request. This is sub-optimal |
563 |
because it takes time. |
564 |
|
565 |
2. Display X anyway. This is sub-optimal because it makes the |
566 |
end result of the negotiation process dependent on factors |
567 |
that can randomly change. For the next request on the same |
568 |
resource, and intermediate proxy cache could return a list |
569 |
response, which would cause the local algorithm to choose and |
570 |
retrieve Y instead of X. Compared to a stable |
571 |
representation, a representation which randomly switches |
572 |
between X and Y (say, the version with and without frames) has |
573 |
a very low subjective quality for most users. |
574 |
|
575 |
As both alternatives above are unattractive, a user agent should |
576 |
try to avoid the above situation altogether. The sections below |
577 |
discuss how this can be done. |
578 |
|
579 |
4.3.1 Avoiding major differences |
580 |
|
581 |
If the user agent enables the remote algorithm in this |
582 |
specification, it should generally use a local algorithm which |
583 |
closely resembles the remote algorithm. The algorithm should for |
584 |
example also use multiplication to combine quality factors. If the |
585 |
user agent combines quality factors by addition, it would be more |
586 |
advantageous to define a new remote variant selection algorithm, |
587 |
with a new major version number, for use by this agent. |
588 |
|
589 |
4.3.2 Working around minor differences |
590 |
|
591 |
Even if a local algorithm uses multiplication to combine quality |
592 |
factors, it could use an extended quality formulae like |
593 |
|
594 |
Q = round5( qs * qt * qc * ql * qf ) * q_adjust |
595 |
|
596 |
in order to account for special interdependencies between |
597 |
dimensions, which are due to limitations of the user agent. For |
598 |
example, if the user agent, for some reason, cannot handle the |
599 |
iso-8859-7 charset when rendering text/plain documents, the |
600 |
q_adjust factor would be 0 when the text/plain - iso-8859-7 |
601 |
combination is present in the variant description, and 1 otherwise. |
602 |
|
603 |
By selectively withholding information from the remote variant |
604 |
selection algorithm, the user agent can ensure that the remote |
605 |
algorithm will never make a choice if the local q_adjust is less |
606 |
than 1. For example, to prevent the remote algorithm from ever |
607 |
returning a text/plain - iso-8859-7 choice response, the user agent |
608 |
should take care to never produce a request which exactly specifies |
609 |
the quality factors of both text/plain and iso-8859-7. The |
610 |
omission of either factor from a request will cause the overall |
611 |
quality value of any text/plain - iso-8859-7 variant to be |
612 |
speculative, and variants with speculative quality values can never |
613 |
be returned in a choice response. |
614 |
|
615 |
In general, if the local q_adjust does not equal 1 for a particular |
616 |
combination X - Y - Z, then a remote choice can be prevented by |
617 |
always omitting at least one of the elements of the combination |
618 |
from the Accept- headers, and adding a suitable wildcard pattern to |
619 |
match the omitted element, if such a pattern is not already |
620 |
present. |
621 |
|
622 |
|
623 |
5 Security and privacy considerations |
624 |
|
625 |
This specification introduces no security and privacy |
626 |
considerations not already covered in [5]. See [5] for a |
627 |
discussion of privacy risks connected to the sending of Accept- |
628 |
headers. |
629 |
|
630 |
|
631 |
6 Acknowledgments |
632 |
|
633 |
Work on HTTP content negotiation has been done since at least 1993. |
634 |
The authors are unable to trace the origin of many of the ideas |
635 |
incorporated in this document. This specification builds on an |
636 |
earlier incomplete specification of content negotiation recorded in |
637 |
[2]. Many members of the HTTP working group have contributed to |
638 |
the negotiation model in this specification. The authors wish to |
639 |
thank the individuals who have commented on earlier versions of |
640 |
this document, including Brian Behlendorf, Daniel DuBois, Ted |
641 |
Hardie, Larry Masinter, and Roy T. Fielding. |
642 |
|
643 |
|
644 |
7 References |
645 |
|
646 |
[1] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and |
647 |
T. Berners-Lee. Hypertext Transfer Protocol -- HTTP/1.1. RFC |
648 |
2068, HTTP Working Group, January, 1997. |
649 |
|
650 |
[2] Roy T. Fielding, Henrik Frystyk Nielsen, and Tim Berners-Lee. |
651 |
Hypertext Transfer Protocol -- HTTP/1.1. Internet-Draft |
652 |
draft-ietf-http-v11-spec-01.txt, HTTP Working Group, January, |
653 |
1996. |
654 |
|
655 |
[3] T. Berners-Lee, R. Fielding, and H. Frystyk. Hypertext |
656 |
Transfer Protocol -- HTTP/1.0. RFC 1945. MIT/LCS, UC Irvine, |
657 |
May 1996. |
658 |
|
659 |
[4] K. Holtman, A. Mutz. Feature Tag Registration Procedures. |
660 |
Internet-Draft draft-ietf-http-feature-reg-02.txt, HTTP Working |
661 |
Group. July 1997. |
662 |
|
663 |
[5] K. Holtman, A. Mutz. Transparent Content Negotiation in HTTP. |
664 |
Internet-Draft draft-ietf-http-negotiation-03.txt, HTTP Working |
665 |
Group. July 1997. |
666 |
|
667 |
|
668 |
8 Authors' addresses |
669 |
|
670 |
Koen Holtman |
671 |
Technische Universiteit Eindhoven |
672 |
Postbus 513 |
673 |
Kamer HG 6.57 |
674 |
5600 MB Eindhoven (The Netherlands) |
675 |
Email: koen@win.tue.nl |
676 |
|
677 |
Andrew H. Mutz |
678 |
Hewlett-Packard Company |
679 |
1501 Page Mill Road 3U-3 |
680 |
Palo Alto CA 94304, USA |
681 |
Fax +1 415 857 4691 |
682 |
Email: mutz@hpl.hp.com |
683 |
|
684 |
|
685 |
Expires: January 28, 1998 |
686 |
|