1 |
Internet-Draft Koen Holtman/TUE |
2 |
Expires: 13 December 1996 13 June 1996 |
3 |
|
4 |
|
5 |
Transparent Content Negotiation |
6 |
|
7 |
draft-holtman-http-negotiation-01.txt |
8 |
|
9 |
|
10 |
STATUS OF THIS MEMO |
11 |
|
12 |
This document is an Internet-Draft. Internet-Drafts are |
13 |
working documents of the Internet Engineering Task Force |
14 |
(IETF), its areas, and its working groups. Note that other |
15 |
groups may also distribute working documents as |
16 |
Internet-Drafts. |
17 |
|
18 |
Internet-Drafts are draft documents valid for a maximum of |
19 |
six months and may be updated, replaced, or obsoleted by |
20 |
other documents at any time. It is inappropriate to use |
21 |
Internet-Drafts as reference material or to cite them other |
22 |
than as "work in progress". |
23 |
|
24 |
To learn the current status of any Internet-Draft, please |
25 |
check the "1id-abstracts.txt" listing contained in the |
26 |
Internet-Drafts Shadow Directories on ftp.is.co.za |
27 |
(Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific |
28 |
Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US |
29 |
West Coast). |
30 |
|
31 |
Distribution of this document is unlimited. Please send |
32 |
comments to the HTTP working group at |
33 |
<http-wg@cuckoo.hpl.hp.com>. Discussions of the working |
34 |
group are archived at |
35 |
<URL:http://www.ics.uci.edu/pub/ietf/http/>. General |
36 |
discussions about HTTP and the applications which use HTTP |
37 |
should take place on the <www-talk@w3.org> mailing list. |
38 |
|
39 |
|
40 |
ABSTRACT |
41 |
|
42 |
HTTP/1.1 will allow one to put multiple versions of the same |
43 |
information under a single URL. Transparent content negotiation |
44 |
is a mechanism, layered on top of HTTP/1.1, for selecting the |
45 |
best version when a retrieval request is made. This document |
46 |
outlines the planned transparent negotiation mechanism, and |
47 |
identifies some issues and tradeoffs that have yet to be |
48 |
addressed. |
49 |
|
50 |
|
51 |
|
52 |
|
53 |
|
54 |
|
55 |
|
56 |
|
57 |
[Page 1] |
58 |
|
59 |
Internet-Draft Content Negotiation 13 June 1996 |
60 |
|
61 |
1 Introduction |
62 |
|
63 |
Transparent content negotiation is a mechanism layered on top of the |
64 |
HTTP/1.1 protocol [1]. HTTP/1.1 will allow one to put multiple |
65 |
versions of the same information under a single URL. Each of these |
66 |
versions is called a `variant'. Transparent content negotiation is a |
67 |
mechanism for selecting the best variant when a retrieval request is |
68 |
made. This document outlines the planned transparent content |
69 |
negotiation mechanism, and identifies some issues and tradeoffs that |
70 |
have yet to be addressed. |
71 |
|
72 |
|
73 |
2 Overview of HTTP transparent content negotiation |
74 |
|
75 |
This section contains an extended version of the HTTP content |
76 |
negotiation presentation given by the author at the Fifth |
77 |
International WWW Conference in Paris. This section tries to avoid |
78 |
the use of terminology local to the IETF http-wg. For example, the |
79 |
term `URL' is used instead of `URI'. |
80 |
|
81 |
|
82 |
2.1 Content negotiation |
83 |
|
84 |
HTTP/1.1 will allow one to put multiple versions of the same |
85 |
information under a single URL. Each of these versions is called a |
86 |
`variant'. For example, a URL http://x.org/paper could bind to three |
87 |
different variants of a paper: |
88 |
|
89 |
1. HTML, English |
90 |
2. HTML, French |
91 |
3. Postscript, English |
92 |
|
93 |
Content negotiation is the process by which the best variant is |
94 |
selected if the URL is accessed. |
95 |
|
96 |
It has always been possible under HTTP to have multiple |
97 |
representations available for one URL, and to return the most |
98 |
appropriate representation for each subsequent request. However, |
99 |
HTTP/1.1 is the first version of HTTP which has provisions for doing |
100 |
this in a cache-friendly way. These provisions include the Vary |
101 |
response header, entity tags, and the If-None-Match request header. |
102 |
|
103 |
In content negotiation, the selection of the best variant for a |
104 |
particular request is based on a matching of the properties of the |
105 |
available variants to the capabilities of the user agent and the |
106 |
preferences of the user. |
107 |
|
108 |
|
109 |
2.2 HTTP/1.0 variant selection scheme |
110 |
|
111 |
Under the HTTP/1.0 scheme, the variant selection happens as follows: |
112 |
|
113 |
|
114 |
|
115 |
|
116 |
|
117 |
[Page 2] |
118 |
|
119 |
Internet-Draft Content Negotiation 13 June 1996 |
120 |
|
121 |
Server _____ proxy _____ proxy _____ user |
122 |
x.org cache cache agent |
123 |
|
124 |
< ---------------------------------- |
125 |
| GET http://x.org/paper |
126 |
| Accept headers |
127 |
choose |
128 |
| |
129 |
---------------------------------- > |
130 |
Best variant |
131 |
|
132 |
When the URL is accessed, the user agent sends, along with its |
133 |
request, various Accept headers which express the user agent |
134 |
capabilities and the user preferences. Then, the origin server uses |
135 |
these Accept headers to choose the best variant, which is returned |
136 |
in the response. |
137 |
|
138 |
The biggest problem with this scheme is that it does not scale well. |
139 |
For all but the most minimal user agents, Accept headers expressing |
140 |
all capabilities and preferences would be very large, and sending |
141 |
them in every request would be hugely inefficient, in particular |
142 |
because only a small fraction of the URLs on the web will have |
143 |
multiple variants. |
144 |
|
145 |
In current practice, user agents send short Accept headers which |
146 |
inadequately describe capabilities and preferences, except maybe for |
147 |
inline image requests. Servers providing multiple representations of |
148 |
the same information usually do so under different URLs, and allow |
149 |
users to manually select a representation by clicking a particular |
150 |
link. |
151 |
|
152 |
Also in current practice, servers often use the contents of the |
153 |
User-Agent request header for selection purposes. These contents |
154 |
sometimes allow the server to infer information about capabilities |
155 |
which cannot be expressed with existing Accept headers. |
156 |
|
157 |
|
158 |
2.3 Transparent content negotiation scheme |
159 |
|
160 |
The transparent negotiation scheme eliminates the need to send huge |
161 |
Accept headers, and nevertheless allows for a selection process that |
162 |
always yields either the best variant, or an error message indicating |
163 |
that user agent is not capable of displaying any of the available |
164 |
variants. |
165 |
|
166 |
Under the transparent content negotiation scheme, the server sends a |
167 |
list with the available variants and their properties to the user |
168 |
agent. An example of a list with three variants is |
169 |
|
170 |
{"paper.html.en" 0.9 {type text/html} {language en}}, |
171 |
{"paper.html.fr" 0.7 {type text/html} {language fr}}, |
172 |
{"paper.ps.en" 1.0 {type application/postscript} {language en}} |
173 |
|
174 |
The syntax and semantics of the variant descriptions in this list are |
175 |
covered in depth in Section 3. When the list is received, the user |
176 |
|
177 |
[Page 3] |
178 |
|
179 |
Internet-Draft Content Negotiation 13 June 1996 |
180 |
|
181 |
agent can choose the best variant and retrieve it. Graphically, the |
182 |
communication can be represented as follows: |
183 |
|
184 |
Server _____ proxy _____ proxy _____ user |
185 |
x.org cache cache agent |
186 |
|
187 |
< ---------------------------------- |
188 |
| GET http://x.org/paper |
189 |
| |
190 |
----------------------------------- > |
191 |
return of list | |
192 |
choose |
193 |
| |
194 |
< ---------------------------------- |
195 |
| GET http://x.org/paper.html.en |
196 |
| |
197 |
---------------------------------- > |
198 |
return of html.en |
199 |
|
200 |
With this scheme, the information about capabilities and preferences |
201 |
is only used by the user agent itself. Therefore, the sending of |
202 |
such information in large Accept headers is unnecessary. Accept |
203 |
headers do have a limited use in transparent content negotiation |
204 |
however: the sending of small Accept headers can often speed up the |
205 |
negotiation process, this is covered in Section 2.4. |
206 |
|
207 |
According to current plans, the response that returns the list in the |
208 |
above picture will look as follows, with the list of variants in the |
209 |
Alternates header: |
210 |
|
211 |
HTTP/1.1 300 Multiple Choices |
212 |
Date: Tue, 11 Jun 1996 19:39:48 GMT |
213 |
Alternates: {"paper.html.en" 0.9 {type text/html} {language en}}, |
214 |
{"paper.html.fr" 0.7 {type text/html} {language fr}}, |
215 |
{"paper.ps.en" 1.0 {type application/postscript} |
216 |
{language en}} |
217 |
Vary: accept, accept-language |
218 |
Content-Type: text/html |
219 |
Content-Length: 227 |
220 |
|
221 |
<h2>Multiple Choices:</h2> |
222 |
<ul> |
223 |
<li><a href=paper.html.en>HTML, English version</a> |
224 |
<li><a href=paper.html.fr>HTML, French version</a> |
225 |
<li><a href=paper.ps.en>Postscript, English version</a> |
226 |
</ul> |
227 |
|
228 |
The HTML page included in the response is intended for compatibility |
229 |
with (existing) user agents which do not support transparent content |
230 |
negotiation. Such user agents will ignore the computer-readable list |
231 |
in the Alternates header and just display the HTML page, allowing the |
232 |
user to select the best variant by hand. |
233 |
|
234 |
[##Issue to be resolved: Some existing HTTP/1.0 user agents crash |
235 |
when getting a 300 response without a Location header. This problem |
236 |
|
237 |
[Page 4] |
238 |
|
239 |
Internet-Draft Content Negotiation 13 June 1996 |
240 |
|
241 |
may be big enough to warrant use of a response code outside of the |
242 |
3xx class, at least for responses to HTTP/1.0 clients.##] |
243 |
|
244 |
|
245 |
2.4 Cutting corners |
246 |
|
247 |
The basic transparent negotiation scheme involves two HTTP |
248 |
transactions: one to retrieve the list, and a second one to retrieve |
249 |
the chosen variant. There are however several ways to `cut corners' |
250 |
in the data flow path of the basic scheme. |
251 |
|
252 |
First, caching proxies can cache both lists and responses from |
253 |
variant URLs. Such caching can reduce the communication overhead, as |
254 |
shown in the following example: |
255 |
|
256 |
Server _____ proxy _____ proxy __________ user |
257 |
x.org cache cache agent |
258 |
|
259 |
< -------------- |
260 |
| GET ../paper |
261 |
| |
262 |
has the list |
263 |
in cache |
264 |
| |
265 |
------------- > |
266 |
list | |
267 |
| |
268 |
choose |
269 |
| |
270 |
< -------------------------- |
271 |
| GET ../paper.html.en |
272 |
| |
273 |
has the variant |
274 |
in cache |
275 |
| |
276 |
-------------------------- > |
277 |
return of html.en |
278 |
|
279 |
Second, the user agent can send small Accept headers which could |
280 |
allow a server to determine the choice the user agent would make on |
281 |
receiving the list. If the Accept headers contain enough |
282 |
information, the origin server can send back the variant directly: |
283 |
|
284 |
Server _____ proxy _____ proxy _____ user |
285 |
x.org cache cache agent |
286 |
|
287 |
< ---------------------------------- |
288 |
| GET http://x.org/paper |
289 |
| small Accept headers |
290 |
| |
291 |
able to choose on |
292 |
behalf of user agent |
293 |
| |
294 |
---------------------------------- > |
295 |
return of html.en and list |
296 |
|
297 |
[Page 5] |
298 |
|
299 |
Internet-Draft Content Negotiation 13 June 1996 |
300 |
|
301 |
|
302 |
|
303 |
According to current plans, the response that returns the html.en |
304 |
variant and the list in the above picture will look as follows: |
305 |
|
306 |
HTTP/1.1 200 OK |
307 |
Date: Tue, 11 Jun 1996 19:51:02 GMT |
308 |
Alternates: {"paper.html.en" 0.9 {type text/html} {language en}}, |
309 |
{"paper.html.fr" 0.7 {type text/html} {language fr}}, |
310 |
{"paper.ps.en" 1.0 {type application/postscript} |
311 |
{language en}} |
312 |
Vary: accept, accept-language |
313 |
Content-Location: paper.html.en |
314 |
Content-Type: text/html |
315 |
Last-Modified: Mon, 10 Jun 1996 10:01:14 GMT |
316 |
Etag: "gonkyyyy" |
317 |
Content-Length: ... |
318 |
|
319 |
... |
320 |
|
321 |
Finally, the above two kinds of optimization can be combined: a |
322 |
caching proxy which has the list will sometimes be able to choose on |
323 |
behalf of the user agent. This could lead to the following |
324 |
communication pattern: |
325 |
|
326 |
Server _____ proxy _____ proxy __________ user |
327 |
x.org cache cache agent |
328 |
|
329 |
< --------------- |
330 |
| GET ../paper |
331 |
| small Accept |
332 |
| |
333 |
able to choose |
334 |
on behalf |
335 |
| |
336 |
< ---------- |
337 |
| GET ../paper.html.en |
338 |
| |
339 |
----------- |
340 |
html.en | |
341 |
---------------- > |
342 |
html.en and list |
343 |
|
344 |
|
345 |
2.5 The network negotiation algorithm |
346 |
|
347 |
To allow for the second optimization above, choosing on behalf of the |
348 |
user agent, transparent content negotiation will standardize the |
349 |
so-called network negotiation algorithm. |
350 |
|
351 |
The algorithm will take as input |
352 |
|
353 |
- the list of variants of a transparently negotiable URL |
354 |
|
355 |
- the (small) Accept headers of an incoming request on that URL |
356 |
|
357 |
[Page 6] |
358 |
|
359 |
Internet-Draft Content Negotiation 13 June 1996 |
360 |
|
361 |
|
362 |
and will yield as output the appropriate action to be performed by |
363 |
the proxy cache or origin server. Proxy caches are required to |
364 |
either perform this appropriate action or to perform any other action |
365 |
allowed by the HTTP/1.1 standard. Origin servers are not required to |
366 |
follow the network negotiation algorithm. |
367 |
|
368 |
If the request was made by a user agent capable of transparent |
369 |
negotiation, the algorithm can yield two possible actions: |
370 |
|
371 |
A) Choice on behalf of the user agent: |
372 |
A particular variant X may be retrieved and returned on behalf |
373 |
of the user agent. |
374 |
|
375 |
B) No choice possible, return the list: |
376 |
The Accept headers do not contain sufficient information to |
377 |
make a choice on behalf of the user agent possible: the list of |
378 |
variants should be returned so that the user agent can make the |
379 |
choice itself. |
380 |
|
381 |
If the request was made by an (old) user agent not capable of |
382 |
transparent negotiation, the algorithm can yield three possible |
383 |
actions: |
384 |
|
385 |
C) Choice on behalf of the origin server: |
386 |
A particular variant X may be retrieved and returned on behalf |
387 |
of the origin server |
388 |
|
389 |
D) No choice possible, return a cached 300 response: |
390 |
The Accept headers do not contain sufficient information to |
391 |
make a choice on behalf of the origin server possible, and a |
392 |
cached or freshly retrieved 300 response should be returned, |
393 |
allowing the user to manually select the best variant |
394 |
|
395 |
E) No choice possible, forward request towards the origin server: |
396 |
The Accept headers do not contain sufficient information to |
397 |
make a choice on behalf of the origin server possible, and the |
398 |
request should be forwarded towards the origin server so that |
399 |
it can choose the best variant with a custom negotiation |
400 |
algorithm. |
401 |
|
402 |
[##Issue to be resolved: though several definitions of subsets of the |
403 |
network negotiation algorithm exist, the algorithm has not been fully |
404 |
defined yet. A mechanism for deciding between D) and E) has not yet |
405 |
been discussed.##] |
406 |
|
407 |
As the network negotiation algorithm is only an optimization device, |
408 |
complete or partial implementation of the algorithm by proxies is |
409 |
optional. To support transparent content negotiation, a HTTP/1.1 |
410 |
proxy need only follow the caching rules defined in the HTTP/1.1 |
411 |
specification. |
412 |
|
413 |
The core computations performed by the network negotiation algorithm |
414 |
are based on quality factors, which are short real numbers in the |
415 |
|
416 |
|
417 |
[Page 7] |
418 |
|
419 |
Internet-Draft Content Negotiation 13 June 1996 |
420 |
|
421 |
range 0.000 -- 1.000. These factors appear in variant lists and in |
422 |
Accept headers. |
423 |
|
424 |
2.5.1 Network negotiation algorithm example 1 |
425 |
|
426 |
As an example, if a variant list contains the variant description |
427 |
|
428 |
{"paper.html.en" 0.7 {type text/html} {language fr}} |
429 |
|
430 |
and if the request contains the following Accept headers: |
431 |
|
432 |
Accept: text/html:q=1.0, */*:q=0.8, transparent |
433 |
Accept-Language: en;q=1.0, fr;q=0.5 |
434 |
|
435 |
the network negotiation algorithm will compute an `overall quality' |
436 |
for the variant by multiplying quality factors as follows: |
437 |
|
438 |
{"paper.html.en" 0.7 {type text/html} {language fr}} |
439 |
| | | |
440 |
| | | |
441 |
V V V |
442 |
0.7 * 1.0 * 0.5 = 0.35 |
443 |
|
444 |
The 1.0 above is the quality factor assigned to "text/html" by the |
445 |
Accept header, the 0.5 is the quality factor assigned to "fr" by the |
446 |
Accept-Language header. The overall quality of this variant is 0.35. |
447 |
|
448 |
With the above Accept headers, the complete variant list |
449 |
|
450 |
{"paper.html.en" 0.9 {type text/html} {language en}}, |
451 |
{"paper.html.fr" 0.7 {type text/html} {language fr}}, |
452 |
{"paper.ps.en" 1.0 {type application/postscript} |
453 |
{language en}} |
454 |
|
455 |
would yield the following computations: |
456 |
|
457 |
paper.html.en: 0.9 * 1.0 * 1.0 = 0.9 |
458 |
paper.html.fr: 0.7 * 1.0 * 0.5 = 0.35 |
459 |
paper.ps.en: 1.0 * 0.8 * 1.0 = 0.8 |
460 |
|
461 |
The variant with the highest overall quality, "paper.html.en" in this |
462 |
case, is the variant that seems most acceptable to the user agent. |
463 |
|
464 |
[##Aside for mathematicians: note that this calculation scheme has |
465 |
similarities with fuzzy set theory. As far as I know, fuzzy set |
466 |
theory was not involved when the scheme was thought up.##] |
467 |
|
468 |
The inclusion of the word `transparent' in the received Accept header |
469 |
|
470 |
Accept: text/html:q=1.0, */*:q=0.8, transparent |
471 |
|
472 |
indicates that the user agent is capable of transparent negotiation. |
473 |
The second stage of the network negotiation algorithm will therefore |
474 |
have to choose between two possible end results: |
475 |
|
476 |
|
477 |
[Page 8] |
478 |
|
479 |
Internet-Draft Content Negotiation 13 June 1996 |
480 |
|
481 |
A) Choice on behalf of the user agent: |
482 |
The variant paper.html.en may be retrieved and returned on |
483 |
behalf of the user agent. |
484 |
|
485 |
B) No choice possible, return the list: |
486 |
The Accept headers do not contain sufficient information to |
487 |
make a choice on behalf of the user agent possible. |
488 |
|
489 |
The choice is made by examining the Accept header components used to |
490 |
derive the best overall quality value of 0.9 for paper.html.en: |
491 |
|
492 |
text/html:q=1.0 |
493 |
en;q=1.0 |
494 |
|
495 |
If none of these components contain a wildcard character *, as is the |
496 |
case here, the appropriate action is A). If a wildcard character is |
497 |
present, the appropriate action is B). |
498 |
|
499 |
2.5.2 Network negotiation algorithm example 2 |
500 |
|
501 |
If the same variant list is matched to the following shorter Accept |
502 |
headers: |
503 |
|
504 |
Accept: */*:q=1.0, transparent |
505 |
Accept-Language: en;q=1.0, fr;q=0.5 |
506 |
|
507 |
the calculations would as follows: |
508 |
|
509 |
paper.html.en: 0.9 * 1.0 * 1.0 = 0.9 |
510 |
paper.html.fr: 0.7 * 1.0 * 0.5 = 0.35 |
511 |
paper.ps.en: 1.0 * 1.0 * 1.0 = 1.0 |
512 |
|
513 |
Now, paper.ps.en is the best candidate. However, if the Accept |
514 |
header components used to derive the best overall quality value of |
515 |
1.0 are examined: |
516 |
|
517 |
*/*:q=1.0 |
518 |
en;q=1.0 |
519 |
|
520 |
it is found that a wildcard character * is present. Therefore, the |
521 |
algorithm yields the result |
522 |
|
523 |
B) No choice possible, return the list: |
524 |
The Accept headers do not contain sufficient information to |
525 |
make a choice on behalf of the user agent possible. |
526 |
|
527 |
Note that the interpretation of */*:q=1.0, if sent by a user agent |
528 |
supporting transparent negotiation, is therefore not |
529 |
|
530 |
`I accept all media types with a quality of 1.0' |
531 |
|
532 |
but |
533 |
|
534 |
|
535 |
|
536 |
|
537 |
[Page 9] |
538 |
|
539 |
Internet-Draft Content Negotiation 13 June 1996 |
540 |
|
541 |
`I accept several media types, and assign quality factors from 0.0 |
542 |
up to 1.0 to them. If this information is insufficient to make a |
543 |
choice on my behalf, do not make a choice but send the list of |
544 |
variants'. |
545 |
|
546 |
This means that a user agent can always send the short |
547 |
|
548 |
Accept: */*, transparent |
549 |
|
550 |
by default, without this affecting the quality of the negotiation |
551 |
process. If it is found that requests to the server often return 300 |
552 |
responses, the user agent can try to dynamically extend the Accept |
553 |
header sent in requests to that server, for example to |
554 |
|
555 |
Accept: text/html, application/postscript:q=0.8, |
556 |
*/*, transparent |
557 |
|
558 |
to increase the chance that the network negotiation algorithm will be |
559 |
able to optimize the retrieval process. A good strategy for dynamic |
560 |
extension would be to extend the Accept header with those media types |
561 |
mentioned in the variant lists of past (300) responses from the |
562 |
server. |
563 |
|
564 |
|
565 |
2.6 Retrieving a variant by hand |
566 |
|
567 |
If a transparently negotiated resource is accessed, the user agent |
568 |
will always at some point receive the list of available variants. |
569 |
The user agent can use this list to make available a menu (in HTML or |
570 |
not) which lists all variants and their characteristics to the user. |
571 |
Such a menu will allow the user to randomly browse other variants, |
572 |
and will also make it possible to manually correct any sub-optimal |
573 |
choice made by the automatic negotiation process. |
574 |
|
575 |
|
576 |
2.7 Dimensions of negotiation |
577 |
|
578 |
Transparent content negotiation defines four dimensions of |
579 |
negotiation: |
580 |
|
581 |
1. Media type (MIME type) |
582 |
2. Charset |
583 |
3. Language |
584 |
4. Features |
585 |
|
586 |
The first three dimensions have traditionally been present in HTTP, |
587 |
the fourth dimension is added by the transparent content negotiation |
588 |
specification. |
589 |
|
590 |
Additional dimensions, beyond the four mentioned above, could be |
591 |
added by future specifications. |
592 |
|
593 |
Negotiation on the content encoding of a response (gzipped, |
594 |
compressed, etc.) is left outside of the realm of transparent |
595 |
negotiation. Transparent negotiation does not prohibit proxies to |
596 |
|
597 |
[Page 10] |
598 |
|
599 |
Internet-Draft Content Negotiation 13 June 1996 |
600 |
|
601 |
encode or decode a relayed or cached response on the fly: the |
602 |
response still contains the same variant as far as transparent |
603 |
negotiation is concerned. |
604 |
|
605 |
|
606 |
2.8 Feature negotiation |
607 |
|
608 |
Feature negotiation intends to provide for all areas of negotiation |
609 |
not covered by the first three dimensions. Examples are negotiation |
610 |
on |
611 |
|
612 |
* HTML extensions |
613 |
* Extensions of non-HTML media types |
614 |
* Color capabilities of the user agent |
615 |
* Output medium (screen, paper, ...) |
616 |
* Preference for speed vs. preference for graphical detail |
617 |
|
618 |
The feature negotiation framework is the main means by which |
619 |
transparent negotiation offers extensibility: a new dimension of |
620 |
negotiation (really a sub-dimension of the feature dimension) can be |
621 |
added without the need for a new standards effort, by the simple |
622 |
registration of a `feature tag'. |
623 |
|
624 |
2.8.1 Feature tags |
625 |
|
626 |
A feature tag identifies a capability of a user agent or a preference |
627 |
of a user. A feature is said to be `present' in a user agent if the |
628 |
corresponding capability is implemented, or if the user has expressed |
629 |
corresponding preference. |
630 |
|
631 |
Examples of feature tags are |
632 |
|
633 |
ns_tables, fonts, monochrome, textonly |
634 |
|
635 |
Note that it sometimes depends on context whether a feature tag |
636 |
expresses a capability or a preference. For a text-only browser, the |
637 |
`textonly' tag is naturally present, but the user of a graphical |
638 |
browser could set the tag to be present if text-only content is |
639 |
preferred to graphical content. |
640 |
|
641 |
The `feature set' of a user agent contains all tags of the features |
642 |
present in the user agent for the current request. In general, the |
643 |
part of the feature set which reflects capabilities will be |
644 |
hard-coded in the user agent binary or in a user agent library file, |
645 |
and the part which reflects preferences will have been configured by |
646 |
the user. |
647 |
|
648 |
As feature registration will be an ongoing process, it is generally |
649 |
not possible for a user agent to know the meaning of all feature tags |
650 |
it can possibly encounter in a variant description. A user agent |
651 |
should assume that all feature tags unknown to it are not in its |
652 |
feature set. |
653 |
|
654 |
|
655 |
|
656 |
|
657 |
[Page 11] |
658 |
|
659 |
Internet-Draft Content Negotiation 13 June 1996 |
660 |
|
661 |
2.8.2 Feature tag registration |
662 |
|
663 |
According to current plans, everybody will be allowed to register |
664 |
feature tags: registration only requires that the tag follows the |
665 |
syntax rules, and that a definition of the meaning of the tag is |
666 |
supplied. In particular, registration will not require actual |
667 |
implementation of a feature, and there will be no test on whether the |
668 |
feature definition overlaps with another feature definition. |
669 |
|
670 |
The feature negotiation mechanism is designed not to break if 1000+ |
671 |
features, partially overlapping, are registered. It is expected that |
672 |
after the introduction of feature negotiation, an explosion in |
673 |
feature tag registration will occur, and that only some of these tags |
674 |
will end up being actively used to label variants. Web indexing |
675 |
robots could, while traversing the web, gather statistics about |
676 |
actual use of feature tags. These statistics could be used by |
677 |
individuals to compile lists, intended for content authors, of useful |
678 |
feature tags for particular areas of negotiation. Note that this |
679 |
indexing activity is orthogonal to the feature registration process. |
680 |
It is expected that, once an area of negotiation is well-understood, |
681 |
this process will converge on a commonly-used and commonly-recognized |
682 |
set of feature tags for that area. |
683 |
|
684 |
[##Issue to be resolved: it is unclear yet whether it is desirable |
685 |
for feature tags to have some hierarchical structure, which would |
686 |
make it easier, for example, to trace who registered the feature. |
687 |
All that is known now is that it is desirable to have short feature |
688 |
tags. A naming scheme like that for SGML-DTDs or PEP protocol names |
689 |
would probably yield feature tags which are too long. The main |
690 |
advantage of having a registration process at all is that it allows |
691 |
for short tags without running the risk of `tag collision'.##] |
692 |
|
693 |
2.8.3 Use of feature tags |
694 |
|
695 |
Feature tags can be used in variant lists to express the quality |
696 |
degradation associated with the presence or absence of certain |
697 |
features. This is covered in depth in Section 4.4. One example is |
698 |
|
699 |
{"index.html.plain" 0.7 {type text/html} }, |
700 |
{"index.html" 1.0 {type text/html} |
701 |
{features ns_tables ns_frames} } |
702 |
|
703 |
Here, the "{features ns_tables ns_frames}" part expresses that |
704 |
index.html uses the features tagged as ns_tables and ns_frames. If |
705 |
these features are absent, the overall quality of index.html degrades |
706 |
to 0. Another example is |
707 |
|
708 |
{"home.graphics" 1.0 {type text/html} {features !textonly} }, |
709 |
{"home.textonly" 0.7 {type text/html} } |
710 |
|
711 |
where the "{features !textonly}" part expresses that home.graphics |
712 |
requires the absence of the textonly feature. If the feature is |
713 |
present, the overall quality of home.graphics degrades to 0. |
714 |
|
715 |
|
716 |
|
717 |
[Page 12] |
718 |
|
719 |
Internet-Draft Content Negotiation 13 June 1996 |
720 |
|
721 |
The absence of a feature need not always degrade the overall quality |
722 |
to 0. In the example |
723 |
|
724 |
{"x.html.1" 1.0 {type text/html} {features fonts/0.7}} |
725 |
|
726 |
the absence of the fonts feature degrades the quality with a factor |
727 |
of 0.7. "fonts/0.7" can be pronounced as "fonts, or a degradation of |
728 |
0.7". In the example |
729 |
|
730 |
{"x.html.2" 0.5 {type text/html} {features fonts:1.5}} |
731 |
|
732 |
the presence of the fonts feature improves the overall quality with a |
733 |
factor of 1.5. If the fonts feature is absent, the overall quality is |
734 |
not affected. "fonts:1.5" can be pronounced as "fonts improves with |
735 |
1.5". Finally, in the example |
736 |
|
737 |
{"y.html" 1.0 {type text/html} {features [blebber wolx] } } |
738 |
|
739 |
The "[blebber wolx]" expresses that y.html.1 requires the presence of |
740 |
the blebber feature or the wolx feature. This construct can be used |
741 |
in a number of cases: |
742 |
|
743 |
1. blebber and wolx actually tag the same feature, but they |
744 |
were registered by different people, and some browsers say |
745 |
they support blebber while others say they support wolx. |
746 |
|
747 |
2. blebber and wolx are HTML tags of different vendors which |
748 |
implement the same functionality, and which were used |
749 |
together in y.html without interference. |
750 |
|
751 |
3. blebber and wolx are HTML tags of different vendors which |
752 |
implement the same functionality, and y.html uses conditional |
753 |
HTML to provide versions using both tags [##Note: conditional |
754 |
HTML does not yet exist, but it is something people are thinking |
755 |
about.##] |
756 |
|
757 |
4. blebber is a complicated HTML tag with only a sketchy |
758 |
definition, implemented by one browser vendor, and wolx |
759 |
indicates implementation of a well-defined subset of the blebber |
760 |
tag by some other vendor(s). y.html uses only this well-defined |
761 |
subset. |
762 |
|
763 |
|
764 |
2.9 Current status of transparent content negotiation |
765 |
|
766 |
There is no complete specification of transparent content negotiation |
767 |
yet. Documents completely specifying some subset of transparent |
768 |
content negotiation have been written, and have had some review by |
769 |
the http-wg, but none of these define feature negotiation, and none |
770 |
of them take the specific caching mechanisms defined by the latest |
771 |
version of the HTTP/1.1 specification [1] into account. |
772 |
|
773 |
The author of this document plans to finish a complete specification |
774 |
of transparent content negotiation, including feature negotiation, |
775 |
within the time frame of a few months. Many aspects of the design of |
776 |
|
777 |
[Page 13] |
778 |
|
779 |
Internet-Draft Content Negotiation 13 June 1996 |
780 |
|
781 |
feature negotiation are still in flux. Some tradeoffs between |
782 |
complexity and expressive power have yet to be discussed. |
783 |
|
784 |
No serious efforts have yet been made to invent and define feature |
785 |
tags for particular complicated areas of negotiation. The final |
786 |
shape of the feature negotiation mechanism will in part depend on the |
787 |
result of such efforts. It is expected that feature negotiation will |
788 |
solve many of the current negotiation problems. However, it is also |
789 |
expected that there will remain negotiation problems not solved by |
790 |
feature negotiation. |
791 |
|
792 |
2.9.1 Feature negotiation in numeric areas |
793 |
|
794 |
Feature tags as covered in Section 2.8 have a boolean nature, because |
795 |
they serve as indicators of the simple presence or absence of some |
796 |
feature. Many areas of negotiation however, like negotiation on |
797 |
screen size, color depth, or bandwidth, have a numeric nature. A |
798 |
numeric area like negotiation on color depth can however be trivially |
799 |
mapped onto the feature negotiation framework. One can define a |
800 |
collection of four feature tags |
801 |
|
802 |
colordepth_1 |
803 |
colordepth_4 |
804 |
colordepth_8 |
805 |
colordepth_24 |
806 |
|
807 |
to span the numeric range of color depth negotiation. Each of these |
808 |
tags would indicate the capability to render pictures up to the given |
809 |
color depth. Under this scheme, a user agent rendering on a screen |
810 |
with 8 bit color depth would have all three features |
811 |
|
812 |
colordepth_1, colordepth_4, colordepth_8 |
813 |
|
814 |
present in its feature set, so that a variant using 10 distinct |
815 |
colors can be safely described as |
816 |
|
817 |
{"button.gif" 0.5 {type image/gif} {features colordepth_4}} |
818 |
|
819 |
While this technique seems adequate for to many numeric areas of |
820 |
negotiation, it is unknown at this point whether it provides |
821 |
sufficient expressive power to cover all areas feature negotiation |
822 |
intends to cover. Section 4 will introduce additional feature |
823 |
negotiation protocol elements which provide more direct support for |
824 |
negotiation on numbers. |
825 |
|
826 |
|
827 |
2.9.2 Bandwidth negotiation |
828 |
|
829 |
With a bandwidth negotiation mechanism, the time needed to retrieve |
830 |
a particular variant over the network can be taken into account |
831 |
during the negotiation process. Work on mechanisms for bandwidth |
832 |
negotiation has been done since at least 1993, but this work has |
833 |
not yet yielded a successful standard mechanism for bandwidth |
834 |
negotiation. Cascaded proxy caches introduce additional complexity |
835 |
in this area. |
836 |
|
837 |
[Page 14] |
838 |
|
839 |
Internet-Draft Content Negotiation 13 June 1996 |
840 |
|
841 |
|
842 |
The planned transparent content negotiation specification will not |
843 |
attempt to solve the problem of bandwidth negotiation. There is some |
844 |
hope that the feature negotiation framework will allow the |
845 |
introduction of an adequate solution for bandwidth negotiation. |
846 |
|
847 |
2.9.3 Content transformation by proxies |
848 |
|
849 |
Recently, there has been some attention to content transformation by |
850 |
proxies. An example is the transformation of an image/gif response |
851 |
to a shorter image/jpeg response, with potential degraded quality, to |
852 |
save bandwidth. Another example is the transformation of an |
853 |
application/postscript response to a text/html response, with |
854 |
definite degraded quality, to allow viewing by a user agent which |
855 |
cannot handle postscript. |
856 |
|
857 |
The impact of such transformations on the quality of content on the |
858 |
web, and the impact on the current model for the allocation of trust |
859 |
to various parties in a HTTP transaction, has not yet been fully |
860 |
explored. |
861 |
|
862 |
Content transformation could be a useful optimization for transparent |
863 |
content negotiation. A response with a variant list |
864 |
|
865 |
{"map.gif" 1.0 {type image/gif} {features !monochrome}}, |
866 |
{"map.mono.gif" 0.8 {type image/gif} {features monochrome}} |
867 |
|
868 |
could include an additional response header |
869 |
|
870 |
Allow-Transform: "map.gif" -> "map.mono.gif" with "dither-2" |
871 |
|
872 |
to allow a proxy which has cached "map.gif" to create "map.mono.gif" |
873 |
on demand, by applying a particular standardized transformation to |
874 |
the "map.gif" data. Another interesting possibility would be |
875 |
|
876 |
Allow-Transform: "map.gif" -> "map.mono.gif" |
877 |
with "http://x.org/java/filters/my_dither" |
878 |
|
879 |
|
880 |
3 Variant descriptions |
881 |
|
882 |
Variant descriptions have been informally introduced in Section 2.3. |
883 |
This section defines variant descriptions more formally. |
884 |
|
885 |
The version of BNF used in the rest of this document is taken from |
886 |
[1], and many of the nonterminals used here are also defined in [1]. |
887 |
One new notation is added: |
888 |
|
889 |
1%rule |
890 |
|
891 |
stands for one or more instances of "rule", separated by |
892 |
whitespace: |
893 |
|
894 |
1%rule = rule *( 1*LWS rule ) . |
895 |
|
896 |
|
897 |
[Page 15] |
898 |
|
899 |
Internet-Draft Content Negotiation 13 June 1996 |
900 |
|
901 |
|
902 |
3.1 Syntax |
903 |
|
904 |
A variant can be described in a machine-readable way with a variant |
905 |
description. |
906 |
|
907 |
variant-descr = |
908 |
"{" <"> URI <"> |
909 |
source-quality |
910 |
[ "{" "type" media-type "}" ] |
911 |
[ "{" "language" 1#language-tag "}" ] |
912 |
[ "{" "length" 1*DIGIT "}" ] |
913 |
[ "{" "features" feature-list "}" ] |
914 |
[ "{" "description" quoted-string "}" ] |
915 |
[ extension-attribute ] |
916 |
"}" |
917 |
|
918 |
source-quality = qvalue |
919 |
|
920 |
extension-attribute = "{" extension-name extension-value "}" |
921 |
extension-name = token |
922 |
extension-value = *( token | quoted-string | LWS |
923 |
| <any element of tspecials except "}"> ) |
924 |
|
925 |
Examples are |
926 |
|
927 |
{"paper.html.fr" 0.7 {type text/html} {language fr}} |
928 |
|
929 |
{"paper.html.tables" 0.9 {type text/html} {features tables}} |
930 |
|
931 |
The various attributes which can be present in a variant |
932 |
description are covered in the subsections below. |
933 |
|
934 |
[##Issue to be resolved: earlier versions had quotes (<">) around |
935 |
the media-type and 1#language-tag. Are these necessary for some |
936 |
reason unknown to me?##] |
937 |
|
938 |
|
939 |
3.2 URI |
940 |
|
941 |
The URI attribute gives the URI of the un-negotiated resource from |
942 |
which the variant can be retrieved with a GET request. It can be |
943 |
absolute or relative to the Request-URI. |
944 |
|
945 |
|
946 |
3.3 Source-quality |
947 |
|
948 |
The source-quality attribute gives the quality of the variant as a |
949 |
representation of the content of the negotiable URI when the |
950 |
variant is rendered with a perfect rendering engine on the best |
951 |
possible output medium. |
952 |
|
953 |
If it is less than 1, this attribute often expresses degradation |
954 |
caused by lossy conversion to a particular data format. For example, |
955 |
a picture originally in JPEG form would have a lower source quality |
956 |
|
957 |
[Page 16] |
958 |
|
959 |
Internet-Draft Content Negotiation 13 June 1996 |
960 |
|
961 |
when translated to the XBM format, and a much lower source quality |
962 |
when translated to an ASCII-art variant. Note, however, that |
963 |
degradation is a function of the source -- an original piece of |
964 |
ASCII-art may degrade in quality if it is captured in JPEG form. |
965 |
|
966 |
Content providers should use the following table as a guide when |
967 |
assigning source quality values: |
968 |
|
969 |
1.000 no degradation |
970 |
0.999-0.900 no noticeable degradation |
971 |
0.899-0.700 noticeable, but acceptable degradation |
972 |
0.699-0.500 barely acceptable degradation |
973 |
0.499-0.000 unacceptable degradation |
974 |
|
975 |
[##Issue to be resolved: can we come up with a word other than |
976 |
`degradation' that covers better the case of variants not converted |
977 |
from one source?##] |
978 |
|
979 |
It is important that content providers do not assign very low source |
980 |
quality values without good reason, as this would limit the ability |
981 |
of users to influence the negotiation process with their own |
982 |
preference settings. |
983 |
|
984 |
When assigning source-quality values, content providers must not |
985 |
account for the size of the variant and its impact on transmission |
986 |
and rendering delays. Source-quality values are assigned assuming |
987 |
instantaneous transmission and rendering. This rule ensures that a |
988 |
future mechanism for bandwidth negotiation (Section 2.9.2) can be |
989 |
cleanly added. |
990 |
|
991 |
|
992 |
3.4 Type and charset, language, length |
993 |
|
994 |
The type, language, and length attributes of a variant description |
995 |
refer to their Content-* header counterparts as defined in [1]. Note |
996 |
that the type attribute also holds the charset of the variant, if |
997 |
appropriate. An example is |
998 |
|
999 |
{type text/html;charset=ISO-8859-4} |
1000 |
|
1001 |
Though all of these attributes are optional, it is often desirable to |
1002 |
include as many attributes as possible as this will increase the |
1003 |
quality of the negotiation process. |
1004 |
|
1005 |
The length attribute, if present, must reflect the length of the |
1006 |
variant only, not the length of the variant plus the length of any |
1007 |
objects inlined or included by the variant. |
1008 |
|
1009 |
|
1010 |
3.5 Features |
1011 |
|
1012 |
The features attribute specifies how the presence or absence of |
1013 |
particular features in the user agent affects the overall quality of |
1014 |
the variant. This attribute is covered in Section 4.4. |
1015 |
|
1016 |
|
1017 |
[Page 17] |
1018 |
|
1019 |
Internet-Draft Content Negotiation 13 June 1996 |
1020 |
|
1021 |
|
1022 |
3.6 Description |
1023 |
|
1024 |
The description attribute is meant to provide a textual description |
1025 |
of some properties of the variant, to be displayed by a user agent |
1026 |
when showing a menu of available variants (Section 2.6). This |
1027 |
attribute can be included if the URI and normal attributes of a |
1028 |
variant are considered too opaque to allow interpretation by the |
1029 |
user. |
1030 |
|
1031 |
|
1032 |
3.7 Extension-attribute |
1033 |
|
1034 |
The extension-attribute allows future specifications to incrementally |
1035 |
define new dimensions of negotiation (Section 2.7), and eases content |
1036 |
negotiation experiments under HTTP/1.1. In experimental situations, |
1037 |
servers must only generate extension-attributes whose names start |
1038 |
with "x-". User agents should ignore all extension attributes they |
1039 |
do not recognize. Proxies must not run the network negotiation |
1040 |
algorithm if an unknown attribute is present in the variant list. |
1041 |
|
1042 |
|
1043 |
4 Feature negotiation |
1044 |
|
1045 |
Feature negotiation has been informally introduced in Section 2.8. |
1046 |
This section defines feature negotiation more formally. Note that |
1047 |
much of the material in this section is still in flux. Some |
1048 |
tradeoffs between complexity and expressive power have yet to be |
1049 |
discussed. |
1050 |
|
1051 |
|
1052 |
4.1 Feature tags |
1053 |
|
1054 |
A feature tag (ftag) identifies a capability of a user agent or a |
1055 |
preference of a user. |
1056 |
|
1057 |
ftag = 1*<any CHAR except CTLs or tspecials or "!"> |
1058 |
|
1059 |
tspecials = "(" | ")" | "<" | ">" | "@" |
1060 |
| "," | ";" | ":" | "\" | <"> |
1061 |
| "/" | "[" | "]" | "?" | "=" |
1062 |
| "{" | "}" | SP | HT |
1063 |
|
1064 |
Examples are |
1065 |
|
1066 |
ns_tables, fonts, blebber, wolx, screenwidth, colordepth |
1067 |
|
1068 |
Feature-tags are case-insensitive. (Case-sensitivity would add a |
1069 |
huge factor of potential confusion to a process already designed to |
1070 |
be chaotic). |
1071 |
|
1072 |
The definition of a feature tag may state that a feature tag, if |
1073 |
present, must be have associated with it a numeric value which |
1074 |
reflects a particular capability or preference. For example, a |
1075 |
feature tag `screenwidth' could be present with a value of 640. |
1076 |
|
1077 |
[Page 18] |
1078 |
|
1079 |
Internet-Draft Content Negotiation 13 June 1996 |
1080 |
|
1081 |
|
1082 |
4.2 Accept-Features header |
1083 |
|
1084 |
The Accept-Features request header can be used by a client to give |
1085 |
information about the presence or absence of certain features. |
1086 |
|
1087 |
Accept-Features = "Accept-Features" : |
1088 |
1#( ftag |
1089 |
| "!" ftag |
1090 |
| ftag "=" number |
1091 |
| "*" |
1092 |
) |
1093 |
|
1094 |
number = 1*DIGIT |
1095 |
|
1096 |
An example is: |
1097 |
|
1098 |
Accept-Features: blex, !blebber, colordepth=5, * |
1099 |
|
1100 |
A feature tag must never occur twice in an Accept-Features header. |
1101 |
In the Accept-Features header, an ftag without a "!" indicates that |
1102 |
the corresponding feature is present, but that is has no numeric |
1103 |
value associated with it. An ftag with a "!" indicates that the |
1104 |
corresponding feature is absent. An ftag with a number indicates |
1105 |
that the corresponding feature is present with the given numeric |
1106 |
value. |
1107 |
|
1108 |
The special construct "*" is best interpreted in terms of its effect |
1109 |
on the network negotiation algorithm calculations. As an |
1110 |
approximation, the "*" indicates that all features not named |
1111 |
explicitly in the Accept-Features header are present, present with |
1112 |
any numeric value, and absent, all at the same time. |
1113 |
|
1114 |
Absence of the Accept-Features header in a request is equivalent to |
1115 |
the inclusion of |
1116 |
|
1117 |
Accept-Features: * |
1118 |
|
1119 |
|
1120 |
4.3 Feature predicates |
1121 |
|
1122 |
Feature predicates are used in the features attribute of a variant |
1123 |
description. |
1124 |
|
1125 |
fpred = [ "!" ] ftag [ "=" number ] |
1126 |
|
1127 |
Examples feature predicates are |
1128 |
|
1129 |
blebber, !blebber, colordepth=5, !blex=54 |
1130 |
|
1131 |
The network negotiation algorithm can compute the truth value of a |
1132 |
feature predicate by using the contents of the Accept-Features |
1133 |
header of the current request. |
1134 |
|
1135 |
|
1136 |
|
1137 |
[Page 19] |
1138 |
|
1139 |
Internet-Draft Content Negotiation 13 June 1996 |
1140 |
|
1141 |
If the ftag in a feature predicate appears in the Accept-Features |
1142 |
header, the truth value of the predicate is defined as follows, |
1143 |
depending on its form: |
1144 |
|
1145 |
ftag true if the feature is present according to the |
1146 |
Accept-Features header, false otherwise. |
1147 |
|
1148 |
!ftag true if the feature is absent according to the |
1149 |
Accept-Features header, false otherwise. |
1150 |
|
1151 |
ftag=N true if the feature is present with a value greater than |
1152 |
or equal to N according to the Accept-Features header, |
1153 |
false otherwise. |
1154 |
|
1155 |
!ftag=N true if the feature is present with a value less than N |
1156 |
according to the Accept-Features header, false otherwise. |
1157 |
|
1158 |
If the ftag in a feature predicate does not appear in the |
1159 |
Accept-Features header, the value of the predicate is true if there |
1160 |
is a "*" in the Accept-Features header, false otherwise. |
1161 |
|
1162 |
As an example, the header |
1163 |
|
1164 |
Accept-Features: blex, !blebber, colordepth=5, !screenwidth, * |
1165 |
|
1166 |
makes the following predicates true: |
1167 |
|
1168 |
blex, colordepth=4, !colordepth=6, colordepth, !screenwidth, |
1169 |
frtnbf, !frtnbf, frtnbf=4, !frtnbf=4 |
1170 |
|
1171 |
and makes the following predicates false: |
1172 |
|
1173 |
!blex, blex=0, blebber, colordepth=6, !colordepth, |
1174 |
screenwidth, screenwidth=640, !screenwidth=640 |
1175 |
|
1176 |
|
1177 |
4.4 Features attribute |
1178 |
|
1179 |
The features attribute |
1180 |
|
1181 |
"{" "features" feature-list "}" |
1182 |
|
1183 |
is used in a variant description to specify how the presence or |
1184 |
absence of particular features in the user agent affects the overall |
1185 |
quality of the variant. |
1186 |
|
1187 |
|
1188 |
|
1189 |
|
1190 |
|
1191 |
|
1192 |
|
1193 |
|
1194 |
|
1195 |
|
1196 |
|
1197 |
[Page 20] |
1198 |
|
1199 |
Internet-Draft Content Negotiation 13 June 1996 |
1200 |
|
1201 |
feature-list = 1%feature-list-element |
1202 |
|
1203 |
feature-list-element = ( fpred | fpred-bag ) |
1204 |
[ ":" present-improvement ] |
1205 |
[ "/" absent-degradation ] |
1206 |
|
1207 |
fpred-bag = "[" 1%fpred "]" |
1208 |
|
1209 |
absent-degradation = 1*3DIGIT [ "." 0*3DIGIT ] |
1210 |
present-improvement = 1*3DIGIT [ "." 0*3DIGIT ] |
1211 |
|
1212 |
Examples are: |
1213 |
|
1214 |
{features !textonly [blebber !wolx] colordepth=3:0.7 } |
1215 |
|
1216 |
{features !blink/0.5 background:1.5 [blebber !wolx]:1.4/0.8 } |
1217 |
|
1218 |
The default value for the present-improvement is 1. The default |
1219 |
value for the absent-degradation is 0, or 1 if a present-improvement |
1220 |
value is given. |
1221 |
|
1222 |
The network negotiation algorithm can compute the quality degradation |
1223 |
factor associated with the features attribute by multiplying all |
1224 |
quality degradation factors of the elements of the feature-list. |
1225 |
Note that the result can be a factor greater than 1. |
1226 |
|
1227 |
A feature list element yields its present-improvement value if the |
1228 |
corresponding feature predicate is true, or if at least one element |
1229 |
of the corresponding fpred-bag is true. The element yields its |
1230 |
absent-degradation value otherwise. |
1231 |
|
1232 |
[##Issue to be resolved: It is unknown yet whether this features |
1233 |
attribute definition makes the right tradeoff between complexity and |
1234 |
(ease of) expressive power. The attribute grammar above is designed |
1235 |
to be parsable with simple non-recursive parsers. The |
1236 |
present-improvement construct does not add expressive power in a |
1237 |
theoretical sense, but does make the (automatic) construction of |
1238 |
variant lists more straightforward in many cases.##] |
1239 |
|
1240 |
[##Aside for mathematicians: note the similarity between the |
1241 |
feature-list |
1242 |
|
1243 |
[f1 !f2] [!f1 f3] |
1244 |
|
1245 |
and the conjunctive normal form of a boolean expression. This |
1246 |
similarity implies good things about the expressive power of the |
1247 |
features attribute. I have not yet explored how far this power |
1248 |
extends into the non-boolean domain.##] |
1249 |
|
1250 |
|
1251 |
4.5 Example of negotiation in a numeric area |
1252 |
|
1253 |
As an example of negotiation in a numeric area, the following variant |
1254 |
list describes four variants with title graphics designed for |
1255 |
increasing screen widths: |
1256 |
|
1257 |
[Page 21] |
1258 |
|
1259 |
Internet-Draft Content Negotiation 13 June 1996 |
1260 |
|
1261 |
|
1262 |
{"home.pda" 1.0 {type text/html} {features !screenwidth=200} }, |
1263 |
{"home.narrow" 1.0 {type text/html} |
1264 |
{features screenwidth=200 !screenwidth=600} }, |
1265 |
{"home.normal" 1.0 {type text/html} |
1266 |
{features screenwidth=600 !screenwidth=1000} }, |
1267 |
{"home.wide" 1.0 {type text/html} {features screenwidth=1000} } |
1268 |
|
1269 |
The above variant list has the disadvantage that a user agent not |
1270 |
supporting screenwidth negotiation is given no guidance on which |
1271 |
variant to select: all would have an overall quality value of 0 if |
1272 |
the screenwidth feature is not present. A feature list which solves |
1273 |
this problem is |
1274 |
|
1275 |
{"home.pda" 1.0 {type text/html} {features !screenwidth=200} }, |
1276 |
{"home.narrow" 1.0 {type text/html} |
1277 |
{features screenwidth=200 !screenwidth=600} }, |
1278 |
{"home.normal" 0.95 {type text/html} }, |
1279 |
{"home.wide" 0.1 {type text/html} {features screenwidth=1000} } |
1280 |
|
1281 |
with this list, a user agent which does not support the screenwidth |
1282 |
feature will always select the third variant. A user agent which |
1283 |
does support the screenwidth feature will only select the third |
1284 |
variant if the overall qualities of all other variants are 0. |
1285 |
|
1286 |
|
1287 |
4.6 Content-Features header |
1288 |
|
1289 |
The Content-Features response header can be used by a server to |
1290 |
indicate how the presence or absence of particular features in the |
1291 |
user agent affects the overall quality of the response. |
1292 |
|
1293 |
Content-Features = "Content-Features" : feature-list |
1294 |
|
1295 |
|
1296 |
5 Security and privacy considerations |
1297 |
|
1298 |
5.1 Accept headers revealing information of a private nature |
1299 |
|
1300 |
Accept headers, in particular Accept-Language headers, may reveal |
1301 |
information that the user rather keeps private unless it will |
1302 |
directly improve the quality of service. For example, a user may not |
1303 |
want to send language preferences to sites which do not offer |
1304 |
multilingual content. The transparent content negotiation mechanism |
1305 |
allows user agents to omit sending of the Accept-Language header by |
1306 |
default, without this affecting the outcome of the negotiation |
1307 |
process if transparently negotiated multilingual content is accessed. |
1308 |
|
1309 |
However, even if the Accept headers never send any information other |
1310 |
than that the user agent is capable of transparent negotiation, |
1311 |
automatic selection and retrieval of a variant by a user agent will |
1312 |
reveal a preference for this variant to the server. A malicious |
1313 |
service author could provide a page with `fake' negotiability on |
1314 |
(ethnicity-correlated) languages, with all variants actually being |
1315 |
the same English document, as a means of extracting privacy-sensitive |
1316 |
|
1317 |
[Page 22] |
1318 |
|
1319 |
Internet-Draft Content Negotiation 13 June 1996 |
1320 |
|
1321 |
information. Such a plot would however be visible to an alert victim |
1322 |
if the menu of available variants and their properties made available |
1323 |
by the user agent is reviewed. |
1324 |
|
1325 |
Some additional privacy considerations connected to Accept headers |
1326 |
are discussed in [1]. |
1327 |
|
1328 |
|
1329 |
5.2 Spoofing of responses from variant URLs |
1330 |
|
1331 |
In the second optimization of the transparent negotiation process |
1332 |
outlined in Section 2.4, a request on a transparently negotiable URL |
1333 |
http://x.org/paper can lead to a response which must be interpreted |
1334 |
as belonging to a variant URL http://x.org/paper.html.en. According |
1335 |
to current plans, a proxy cache will be allowed to return this |
1336 |
response, after removal of the list of variants and the |
1337 |
Content-Location header, if a direct request on the variant URL |
1338 |
http://x.org/paper.html.en is received. This caching shortcut could, |
1339 |
for some negotiable resources, save up to a factor 2 in bandwidth |
1340 |
usage for requests made by the cache. |
1341 |
|
1342 |
However, this shortcut also allows the author of the URL |
1343 |
http://x.org/paper to control the data cached for the URL |
1344 |
http://x.org/paper.html.en. If the variant URL belongs to another |
1345 |
author, this is a security problem. Therefore, it is planned to |
1346 |
restrict the use of the second optimization by origin servers to |
1347 |
cases where the negotiable URL and the variant URL are equal up to |
1348 |
the last slash. If an origin server generates a response which does |
1349 |
not satisfy this restriction on use, the recipient must reject it and |
1350 |
signal a server error. |
1351 |
|
1352 |
|
1353 |
6 Acknowledgments |
1354 |
|
1355 |
This document builds on an earlier specification of content |
1356 |
negotiation as recorded in [2], and directly incorporates text from |
1357 |
[2] in some places. Many members of the HTTP working group have |
1358 |
contributed to the work reflected in this document. The author |
1359 |
wishes to thank the individuals who have commented on earlier |
1360 |
versions of the transparent content negotiation specification, |
1361 |
including Brian Behlendorf, Daniel DuBois, Larry Masinter, and Roy |
1362 |
T. Fielding. |
1363 |
|
1364 |
|
1365 |
7 References |
1366 |
|
1367 |
[1] Fielding et al, Hypertext Transfer Protocol -- HTTP/1.1. |
1368 |
Internet-Draft draft-ietf-http-v11-spec-05.txt, HTTP Working |
1369 |
Group, June, 1996. |
1370 |
|
1371 |
[2] Roy T. Fielding, Henrik Frystyk Nielsen, and Tim Berners-Lee. |
1372 |
Hypertext Transfer Protocol -- HTTP/1.1. Internet-Draft |
1373 |
draft-ietf-http-v11-spec-01.txt, HTTP Working Group, January, |
1374 |
1996. |
1375 |
|
1376 |
|
1377 |
[Page 23] |
1378 |
|
1379 |
Internet-Draft Content Negotiation 13 June 1996 |
1380 |
|
1381 |
|
1382 |
8 Author's address |
1383 |
|
1384 |
Koen Holtman |
1385 |
Technische Universiteit Eindhoven |
1386 |
Postbus 513 |
1387 |
Kamer HG 6.57 |
1388 |
5600 MB Eindhoven (Holland) |
1389 |
|
1390 |
e-mail: koen@win.tue.nl |
1391 |
|
1392 |
|
1393 |
|
1394 |
|
1395 |
|
1396 |
|
1397 |
|
1398 |
|
1399 |
|
1400 |
|
1401 |
|
1402 |
|
1403 |
|
1404 |
|
1405 |
|
1406 |
|
1407 |
|
1408 |
|
1409 |
|
1410 |
|
1411 |
|
1412 |
|
1413 |
|
1414 |
|
1415 |
|
1416 |
|
1417 |
|
1418 |
|
1419 |
|
1420 |
|
1421 |
|
1422 |
|
1423 |
|
1424 |
|
1425 |
|
1426 |
|
1427 |
|
1428 |
|
1429 |
|
1430 |
|
1431 |
|
1432 |
Expires: 13 December 1996 |
1433 |
|
1434 |
|
1435 |
|
1436 |
|
1437 |
[Page 24] |
1438 |
|
1439 |
|