| 1 |
wakaba |
1.1 |
|
| 2 |
|
|
HTTP Working Group A. Mutz, Hewlett-Packard |
| 3 |
|
|
INTERNET-DRAFT L. Montulli, Netscape |
| 4 |
|
|
<draft-mutz-http-attributes-02.txt> L. Masinter, Xerox |
| 5 |
|
|
K. Holtman, TUE |
| 6 |
|
|
Expires May 26, 1997 Nov 26, 1996 |
| 7 |
|
|
|
| 8 |
|
|
User-Agent Display Attributes |
| 9 |
|
|
|
| 10 |
|
|
STATUS OF THIS MEMO |
| 11 |
|
|
This document is an Internet-Draft. Internet-Drafts are working |
| 12 |
|
|
documents of the Internet Engineering Task Force (IETF), its |
| 13 |
|
|
areas, and its working groups. Note that other groups may also |
| 14 |
|
|
distribute working documents as Internet-Drafts. Internet-Drafts |
| 15 |
|
|
are draft documents valid for a maximum of six months and may be |
| 16 |
|
|
updated, replaced, or made obsolete by other documents at any |
| 17 |
|
|
time. It is inappropriate to use Internet-Drafts as reference |
| 18 |
|
|
material or to cite them other than as "work in progress". To |
| 19 |
|
|
learn the current status of any Internet-Draft, please check the |
| 20 |
|
|
"1id-abstracts.txt" listing contained in the Internet-Drafts |
| 21 |
|
|
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net |
| 22 |
|
|
(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East |
| 23 |
|
|
Coast), or ftp.isi.edu (US West Coast). |
| 24 |
|
|
|
| 25 |
|
|
Distribution of this document is unlimited. Please send comments |
| 26 |
|
|
to the HTTP working group at <http-wg@cuckoo.hpl.hp.com>. |
| 27 |
|
|
Discussions of the working group are archived at |
| 28 |
|
|
<URL:http://www.ics.uci.edu/pub/ietf/http/>. General discussions |
| 29 |
|
|
about HTTP and the applications which use HTTP should take place |
| 30 |
|
|
on the <www- talk@w3.org> mailing list. |
| 31 |
|
|
|
| 32 |
|
|
THIS DRAFT IS FOR DISCUSSION PURPOSES ONLY AND SHOULD NOT BE RELEASED |
| 33 |
|
|
IN ANY PRODUCTION SOFTWARE. |
| 34 |
|
|
|
| 35 |
|
|
ABSTRACT |
| 36 |
|
|
User-Agent Display Attributes Headers provide a means for an HTTP |
| 37 |
|
|
client [3] and server to negotiate for content dependent on the |
| 38 |
|
|
client display capabilities. This memo describes feature tags for |
| 39 |
|
|
introducing this information into an HTTP transmission. The |
| 40 |
|
|
intent is to present resource variants when available [5] such |
| 41 |
|
|
that a capable server may present documents in a preferred form to |
| 42 |
|
|
a client. If such a preferred form is not available, the server |
| 43 |
|
|
should still provide the requested documents. |
| 44 |
|
|
|
| 45 |
|
|
This specification is intended as an extension to HTTP/1.1 [4], to |
| 46 |
|
|
be implemented using the negotiation mechanism, transparent |
| 47 |
|
|
content negotiation [5]. |
| 48 |
|
|
|
| 49 |
|
|
INTRODUCTION |
| 50 |
|
|
|
| 51 |
|
|
Purpose |
| 52 |
|
|
|
| 53 |
|
|
The Hypertext Transfer Protocol (HTTP) is protocol for distributed, |
| 54 |
|
|
collaborative, hypermedia information systems. At present the |
| 55 |
|
|
server relies on the client's ability to present visual information |
| 56 |
|
|
in a usable fashion without information about the client's display |
| 57 |
|
|
characteristics. The presence of large images, video, and other |
| 58 |
|
|
visual information in HTML documents has strained this model. HTML |
| 59 |
|
|
documents suitable for a certain video monitor size are often less |
| 60 |
|
|
usable on displays of much smaller or larger resolution, such as |
| 61 |
|
|
PDA's and high-resolution printers. |
| 62 |
|
|
|
| 63 |
|
|
This specification defines feature tags [5] in the context of |
| 64 |
|
|
transparent content negotiation, an extension to the |
| 65 |
|
|
protocol referred to as HTTP. These tags enable a client to inform |
| 66 |
|
|
a server regarding its display capabilities. The server may then |
| 67 |
|
|
provide the variant of the resource more suitable for the display. |
| 68 |
|
|
Different variants would typically be higher or lower |
| 69 |
|
|
resolution images (for example) as appropriate. In the case of a |
| 70 |
|
|
printer client, the result would be higher quality output. In the |
| 71 |
|
|
case of a PDA, the result would be faster transmission. |
| 72 |
|
|
The presence of these tags may cause a request to return a reply |
| 73 |
|
|
requiring the client to choose from a list of variants, but must |
| 74 |
|
|
not cause a request to be failed due to lack of the proper variant. |
| 75 |
|
|
|
| 76 |
|
|
Operation |
| 77 |
|
|
|
| 78 |
|
|
The details of feature negotiation are described elsewhere [5]. |
| 79 |
|
|
|
| 80 |
|
|
When a server receives an HTTP request including user-attrib feature |
| 81 |
|
|
tags, it may use this information to return a variant of a resource |
| 82 |
|
|
most appropriate for the client's display (along with a list of the |
| 83 |
|
|
available variants.) The variants are expected to differ primarily |
| 84 |
|
|
in image size and color content, but other variations such as |
| 85 |
|
|
shorter text descriptions are also foreseeable. The number of |
| 86 |
|
|
variants should be limited to provide efficient caching since the |
| 87 |
|
|
number of variants could become very large. Operation of feature |
| 88 |
|
|
negotiation when a resource has a very long list of variants is |
| 89 |
|
|
under discussion. |
| 90 |
|
|
|
| 91 |
|
|
UA-attrib tags can indicate display dimensions (in pixels), display |
| 92 |
|
|
resolution (in pixels/inch), color capability and bit-depth, and |
| 93 |
|
|
display media type. The physical dimensions of the display can be |
| 94 |
|
|
inferred from the display size and display resolution. In the case |
| 95 |
|
|
of paper output, the paper size may be expressed as a token from a |
| 96 |
|
|
list of certain standard paper sizes. These are presented |
| 97 |
|
|
formally in the Notation section. |
| 98 |
|
|
|
| 99 |
|
|
The headers and arguments are case-insensitive. The syntax is presented |
| 100 |
|
|
in terms of the Accept-Features header proposed in [5] for historical |
| 101 |
|
|
reasons. |
| 102 |
|
|
|
| 103 |
|
|
USER-AGENT ATTRIBUTE FEATURE TAGS: |
| 104 |
|
|
|
| 105 |
|
|
pix-x<=n |
| 106 |
|
|
pix-y<=m |
| 107 |
|
|
|
| 108 |
|
|
The maximum display size of the client's device (or window)is transmitted |
| 109 |
|
|
in total horizontal, n, and vertical, m, pixel number, for example: pix- |
| 110 |
|
|
x<=1024, pix-y<=768. The intent is to present and allow the |
| 111 |
|
|
selection of the resource variants best suited to a client's device. |
| 112 |
|
|
This display size may conform to either the device display or the |
| 113 |
|
|
size of the client window depending on application. |
| 114 |
|
|
|
| 115 |
|
|
res<=n |
| 116 |
|
|
|
| 117 |
|
|
The display device maximum resolution is transmitted in pixels per inch. |
| 118 |
|
|
For example: res<=72. Certain resources such as images may have |
| 119 |
|
|
similar total pixel size but differing data size and quality |
| 120 |
|
|
depending on degree of compression. UA-res can be used to resolve a |
| 121 |
|
|
preferred image in this case. |
| 122 |
|
|
|
| 123 |
|
|
The authors recognize English units are not universal, but desire to |
| 124 |
|
|
avoid multiple unit definitions. |
| 125 |
|
|
|
| 126 |
|
|
UA-media=token |
| 127 |
|
|
|
| 128 |
|
|
The display device media is indicated with an ASCII token. Basic |
| 129 |
|
|
token values are: screen, stationary, transparency, envelope, or |
| 130 |
|
|
continuous-long. Other values may be defined. Except for `screen', |
| 131 |
|
|
these tokens are a subset of the Printer MIB MediaType set defined |
| 132 |
|
|
in RFC-1759 [6]. Other tokens could be registered and used as |
| 133 |
|
|
needed. |
| 134 |
|
|
|
| 135 |
|
|
They are defined as: |
| 136 |
|
|
screen: a refreshable display |
| 137 |
|
|
screen-paged: a refreshable display which cannot scroll |
| 138 |
|
|
stationary: separately cut sheets of an opaque material |
| 139 |
|
|
transparency: separately cut sheets of a transparent material |
| 140 |
|
|
envelope: envelopes that can be used for conventional |
| 141 |
|
|
mailing purposes |
| 142 |
|
|
continuous-short: continuously connected sheets of an opaque |
| 143 |
|
|
material connected along the short edge |
| 144 |
|
|
|
| 145 |
|
|
papersize=token |
| 146 |
|
|
|
| 147 |
|
|
For ua-media types such as stationary, it is often useful to |
| 148 |
|
|
have information about the size of display used. While it is more |
| 149 |
|
|
precise and predictable to use absolute resolution and pixel sizes, |
| 150 |
|
|
some applications find it useful to provide paper size in lieu of |
| 151 |
|
|
or in addition to this information. Paper sizes names and definitions |
| 152 |
|
|
are taken from the the Printer MIB RFC [6]. |
| 153 |
|
|
|
| 154 |
|
|
Examples of paper size tokens, with names from [6], are: |
| 155 |
|
|
na-letter: 8.5x11.0 inches |
| 156 |
|
|
iso-A4: 210x297 mm |
| 157 |
|
|
iso-B4: 250x353 mm |
| 158 |
|
|
iso-A3: 297x420 mm |
| 159 |
|
|
na-legal: 8.5x14 inches |
| 160 |
|
|
|
| 161 |
|
|
color<=n |
| 162 |
|
|
grey<=n |
| 163 |
|
|
|
| 164 |
|
|
The display color capabilities are indicated with feature tag and a |
| 165 |
|
|
parameter describing the number of color channel bits available. |
| 166 |
|
|
Values of n are typically (but not limited to) 2, 8, or 24. For |
| 167 |
|
|
example: grey=8 indicates a display capable of representing an |
| 168 |
|
|
image in 256 levels of a single color, while color=8 indicates a |
| 169 |
|
|
display capable of representing an image with a palette of 256 |
| 170 |
|
|
colors. |
| 171 |
|
|
|
| 172 |
|
|
The `default' case, implied by absence of the tag, is color<=24. |
| 173 |
|
|
In this case any palletizing and/or half-toning is done by the |
| 174 |
|
|
client. |
| 175 |
|
|
|
| 176 |
|
|
The authors recognize the issue of color model may be raised, but |
| 177 |
|
|
color model can be implied or specified within image MIME types such |
| 178 |
|
|
as JPEG or TIFF. |
| 179 |
|
|
|
| 180 |
|
|
NEGOTIATION |
| 181 |
|
|
|
| 182 |
|
|
The use of a UA-attrib feature tags should not cause a request to |
| 183 |
|
|
fail. The intent is to request a preferred presentation rather than |
| 184 |
|
|
a basic inability to present a resource (such as inability to handle |
| 185 |
|
|
a MIME type.) Details of feature negotiation are described |
| 186 |
|
|
elsewhere [5]. |
| 187 |
|
|
|
| 188 |
|
|
|
| 189 |
|
|
NOTATION |
| 190 |
|
|
|
| 191 |
|
|
UA-attrib related syntax is specified here relative to the |
| 192 |
|
|
definitions and rules of the HTTP specifications and to the definitions |
| 193 |
|
|
of feature tags described in [5]. |
| 194 |
|
|
|
| 195 |
|
|
Feature tags |
| 196 |
|
|
|
| 197 |
|
|
UA-attrib defines specific feature tags, pix-x, pix-y, res, UA-media |
| 198 |
|
|
paged, grey, and color to be registered as feature tags for |
| 199 |
|
|
transparent feature negotiation. A mechanism to register feature tags |
| 200 |
|
|
has been submitted for discussion [7].These attibutes may be used |
| 201 |
|
|
together or independently. The feature tags are defined as follows: |
| 202 |
|
|
|
| 203 |
|
|
|
| 204 |
|
|
Form of tag Intended use |
| 205 |
|
|
---------- ----------- |
| 206 |
|
|
pix-x With a numeric range |
| 207 |
|
|
pix-y With a numeric range |
| 208 |
|
|
res With a numeric range |
| 209 |
|
|
UA-media With one or more values of media |
| 210 |
|
|
papersize With one or more values of paper |
| 211 |
|
|
color With a numeric range |
| 212 |
|
|
grey With a numeric range |
| 213 |
|
|
|
| 214 |
|
|
|
| 215 |
|
|
Tokens used: values of tokens: |
| 216 |
|
|
----------- ----------------- |
| 217 |
|
|
media token | ("screen" | "stationery" |"transparency" | |
| 218 |
|
|
"envelope" | "continuous-short" | "screen-paged") |
| 219 |
|
|
paper token | ("na-letter" | "iso-a4" | "iso-b4" | "iso-a3" |
| 220 |
|
|
| "na-legal") |
| 221 |
|
|
|
| 222 |
|
|
Examples of the above feature tags: |
| 223 |
|
|
|
| 224 |
|
|
pix-x<=1024 |
| 225 |
|
|
pix-y<=768 |
| 226 |
|
|
indicates a 1024x768 display |
| 227 |
|
|
|
| 228 |
|
|
res<=72 |
| 229 |
|
|
indicates a 72 dpi display |
| 230 |
|
|
|
| 231 |
|
|
UA-media=stationery |
| 232 |
|
|
indicates the display is a cut sheet of opaque material, such as |
| 233 |
|
|
paper. |
| 234 |
|
|
|
| 235 |
|
|
papersize=iso-a4 |
| 236 |
|
|
indicates the display size is 210x297mm. |
| 237 |
|
|
|
| 238 |
|
|
color<=24 |
| 239 |
|
|
indicates the display supports 24-bit (8-bit/channel) color. |
| 240 |
|
|
|
| 241 |
|
|
Future work and other issues |
| 242 |
|
|
|
| 243 |
|
|
A discussion of input device availability is ongoing. The use of |
| 244 |
|
|
feature tags such as voiceinput, pointeronly or keyboardonly |
| 245 |
|
|
could be used to serve interactive resources customized |
| 246 |
|
|
for various clients not possessing the `normal' pointer-plus- |
| 247 |
|
|
keyboard interface. |
| 248 |
|
|
|
| 249 |
|
|
The previous draft contained both UA-pixels and UA-windowpixels |
| 250 |
|
|
tags. This draft contains only one UA-pix tag, and it's use |
| 251 |
|
|
(to indicate window size for an application or display size of |
| 252 |
|
|
a device) is dependent on the application. |
| 253 |
|
|
|
| 254 |
|
|
A discussion of rectangular (non-square) pixels was held. The |
| 255 |
|
|
feature may be implemented by introducing an aspect-ratio tag |
| 256 |
|
|
for resolution such as res-aspect, which indicates the resolution |
| 257 |
|
|
ratio of the vertical direction to the horizontal direction. It |
| 258 |
|
|
is unclear whether this is significant at this time. |
| 259 |
|
|
|
| 260 |
|
|
Using numeric feature tags [5] section 7.2, it is possible for a |
| 261 |
|
|
server to construct a variant list which will not provide a |
| 262 |
|
|
`default' variant when the feature tag is not implemented by the |
| 263 |
|
|
client. Proper construction of such variant lists requires care. |
| 264 |
|
|
|
| 265 |
|
|
Acknowledgments |
| 266 |
|
|
|
| 267 |
|
|
This document has benefited from the comments of Ho John Lee, Brian |
| 268 |
|
|
Behlendorf, and Jeff Mogul. |
| 269 |
|
|
|
| 270 |
|
|
References |
| 271 |
|
|
|
| 272 |
|
|
[1] T. Berners-Lee. "Universal Resource Identifiers in WWW." A |
| 273 |
|
|
Unifying Syntax for the Expression of Names and Addresses of Objects |
| 274 |
|
|
on the Network as used in the World-Wide Web." RFC 1630, CERN, June |
| 275 |
|
|
1994. |
| 276 |
|
|
|
| 277 |
|
|
[2] T. Berners-Lee, L. Masinter, M. McCahill. |
| 278 |
|
|
"Uniform Resource Locators (URL)." RFC 1738, CERN, Xerox PARC, |
| 279 |
|
|
University of Minnesota, December 1994. |
| 280 |
|
|
|
| 281 |
|
|
[3] T. Berners-Lee, R. Fielding, H. Frystyk. |
| 282 |
|
|
"Hypertext Transfer Protocol -- HTTP/1.0." RFC 1945." MIT/LCS, UC |
| 283 |
|
|
Irvine, May 1996. |
| 284 |
|
|
|
| 285 |
|
|
[4] T. Berners-Lee, R. Fielding,I J. Gettys, J. Mogul, H. |
| 286 |
|
|
Frystyk. "Hypertext Transfer Protocol - HTTP/1.1" MIT/LCS, |
| 287 |
|
|
UC Irvine, May 1996. |
| 288 |
|
|
|
| 289 |
|
|
[5] K. Holtman, A. Mutz, "Transparent Content Negotiation in HTTP" |
| 290 |
|
|
IETF Internet Draft draft-holtman-http-negotiation-04.txt, Nov. 1996. |
| 291 |
|
|
|
| 292 |
|
|
[6] R. Smith, F. Wright, T. Hastings, S. Zilles, J. Gyllenskog. |
| 293 |
|
|
"Printer MIB." RFC 1759." IETF, March 1995 |
| 294 |
|
|
|
| 295 |
|
|
[7] K. Holtman, A. Mutz, "Feature Tag Registration Procedures" IETF |
| 296 |
|
|
Internet Draft draft-ietf-http-feature-reg-00.txt, October 1996. |
| 297 |
|
|
|
| 298 |
|
|
Authors' Addresses |
| 299 |
|
|
|
| 300 |
|
|
Larry Masinter |
| 301 |
|
|
Xerox Palo Alto Research Center |
| 302 |
|
|
3333 Coyote Hill Road |
| 303 |
|
|
Palo Alto CA 94304 |
| 304 |
|
|
Fax +1 415 812 4333 |
| 305 |
|
|
Email: masinter@parc.xerox.com |
| 306 |
|
|
|
| 307 |
|
|
Lou Montulli |
| 308 |
|
|
Netscape Communications Corp. |
| 309 |
|
|
501 E. Middlefield Rd. |
| 310 |
|
|
Mountain View, CA 94043, USA |
| 311 |
|
|
Phone +1 415 528 2600 |
| 312 |
|
|
Email: montulli@netscape.com |
| 313 |
|
|
|
| 314 |
|
|
Andrew H. Mutz |
| 315 |
|
|
Hewlett-Packard Company |
| 316 |
|
|
1501 Page Mill Road 3U-3 |
| 317 |
|
|
Palo Alto CA 94304, USA |
| 318 |
|
|
Fax +1 415 857 4691 |
| 319 |
|
|
Email: mutz@hpl.hp.com |
| 320 |
|
|
|
| 321 |
|
|
|
| 322 |
|
|
Koen Holtman |
| 323 |
|
|
Technische Universiteit Eindhoven |
| 324 |
|
|
Postbus 513 |
| 325 |
|
|
Kamer HG 6.57 |
| 326 |
|
|
5600 MB Eindhoven (The Netherlands) |
| 327 |
|
|
Email: koen@win.tue.nl |
| 328 |
|
|
|
Parent Directory
| 
Revision Log