| 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