HTTP Working Group A. Mutz, Hewlett-Packard INTERNET-DRAFT L. Montulli, Netscape L. Masinter, Xerox K. Holtman, TUE Expires May 26, 1997 Nov 26, 1996 User-Agent Display Attributes STATUS OF THIS MEMO This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or made obsolete by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. Please send comments to the HTTP working group at . Discussions of the working group are archived at . General discussions about HTTP and the applications which use HTTP should take place on the mailing list. THIS DRAFT IS FOR DISCUSSION PURPOSES ONLY AND SHOULD NOT BE RELEASED IN ANY PRODUCTION SOFTWARE. ABSTRACT User-Agent Display Attributes Headers provide a means for an HTTP client [3] and server to negotiate for content dependent on the client display capabilities. This memo describes feature tags for introducing this information into an HTTP transmission. The intent is to present resource variants when available [5] such that a capable server may present documents in a preferred form to a client. If such a preferred form is not available, the server should still provide the requested documents. This specification is intended as an extension to HTTP/1.1 [4], to be implemented using the negotiation mechanism, transparent content negotiation [5]. INTRODUCTION Purpose The Hypertext Transfer Protocol (HTTP) is protocol for distributed, collaborative, hypermedia information systems. At present the server relies on the client's ability to present visual information in a usable fashion without information about the client's display characteristics. The presence of large images, video, and other visual information in HTML documents has strained this model. HTML documents suitable for a certain video monitor size are often less usable on displays of much smaller or larger resolution, such as PDA's and high-resolution printers. This specification defines feature tags [5] in the context of transparent content negotiation, an extension to the protocol referred to as HTTP. These tags enable a client to inform a server regarding its display capabilities. The server may then provide the variant of the resource more suitable for the display. Different variants would typically be higher or lower resolution images (for example) as appropriate. In the case of a printer client, the result would be higher quality output. In the case of a PDA, the result would be faster transmission. The presence of these tags may cause a request to return a reply requiring the client to choose from a list of variants, but must not cause a request to be failed due to lack of the proper variant. Operation The details of feature negotiation are described elsewhere [5]. When a server receives an HTTP request including user-attrib feature tags, it may use this information to return a variant of a resource most appropriate for the client's display (along with a list of the available variants.) The variants are expected to differ primarily in image size and color content, but other variations such as shorter text descriptions are also foreseeable. The number of variants should be limited to provide efficient caching since the number of variants could become very large. Operation of feature negotiation when a resource has a very long list of variants is under discussion. UA-attrib tags can indicate display dimensions (in pixels), display resolution (in pixels/inch), color capability and bit-depth, and display media type. The physical dimensions of the display can be inferred from the display size and display resolution. In the case of paper output, the paper size may be expressed as a token from a list of certain standard paper sizes. These are presented formally in the Notation section. The headers and arguments are case-insensitive. The syntax is presented in terms of the Accept-Features header proposed in [5] for historical reasons. USER-AGENT ATTRIBUTE FEATURE TAGS: pix-x<=n pix-y<=m The maximum display size of the client's device (or window)is transmitted in total horizontal, n, and vertical, m, pixel number, for example: pix- x<=1024, pix-y<=768. The intent is to present and allow the selection of the resource variants best suited to a client's device. This display size may conform to either the device display or the size of the client window depending on application. res<=n The display device maximum resolution is transmitted in pixels per inch. For example: res<=72. Certain resources such as images may have similar total pixel size but differing data size and quality depending on degree of compression. UA-res can be used to resolve a preferred image in this case. The authors recognize English units are not universal, but desire to avoid multiple unit definitions. UA-media=token The display device media is indicated with an ASCII token. Basic token values are: screen, stationary, transparency, envelope, or continuous-long. Other values may be defined. Except for `screen', these tokens are a subset of the Printer MIB MediaType set defined in RFC-1759 [6]. Other tokens could be registered and used as needed. They are defined as: screen: a refreshable display screen-paged: a refreshable display which cannot scroll stationary: separately cut sheets of an opaque material transparency: separately cut sheets of a transparent material envelope: envelopes that can be used for conventional mailing purposes continuous-short: continuously connected sheets of an opaque material connected along the short edge papersize=token For ua-media types such as stationary, it is often useful to have information about the size of display used. While it is more precise and predictable to use absolute resolution and pixel sizes, some applications find it useful to provide paper size in lieu of or in addition to this information. Paper sizes names and definitions are taken from the the Printer MIB RFC [6]. Examples of paper size tokens, with names from [6], are: na-letter: 8.5x11.0 inches iso-A4: 210x297 mm iso-B4: 250x353 mm iso-A3: 297x420 mm na-legal: 8.5x14 inches color<=n grey<=n The display color capabilities are indicated with feature tag and a parameter describing the number of color channel bits available. Values of n are typically (but not limited to) 2, 8, or 24. For example: grey=8 indicates a display capable of representing an image in 256 levels of a single color, while color=8 indicates a display capable of representing an image with a palette of 256 colors. The `default' case, implied by absence of the tag, is color<=24. In this case any palletizing and/or half-toning is done by the client. The authors recognize the issue of color model may be raised, but color model can be implied or specified within image MIME types such as JPEG or TIFF. NEGOTIATION The use of a UA-attrib feature tags should not cause a request to fail. The intent is to request a preferred presentation rather than a basic inability to present a resource (such as inability to handle a MIME type.) Details of feature negotiation are described elsewhere [5]. NOTATION UA-attrib related syntax is specified here relative to the definitions and rules of the HTTP specifications and to the definitions of feature tags described in [5]. Feature tags UA-attrib defines specific feature tags, pix-x, pix-y, res, UA-media paged, grey, and color to be registered as feature tags for transparent feature negotiation. A mechanism to register feature tags has been submitted for discussion [7].These attibutes may be used together or independently. The feature tags are defined as follows: Form of tag Intended use ---------- ----------- pix-x With a numeric range pix-y With a numeric range res With a numeric range UA-media With one or more values of media papersize With one or more values of paper color With a numeric range grey With a numeric range Tokens used: values of tokens: ----------- ----------------- media token | ("screen" | "stationery" |"transparency" | "envelope" | "continuous-short" | "screen-paged") paper token | ("na-letter" | "iso-a4" | "iso-b4" | "iso-a3" | "na-legal") Examples of the above feature tags: pix-x<=1024 pix-y<=768 indicates a 1024x768 display res<=72 indicates a 72 dpi display UA-media=stationery indicates the display is a cut sheet of opaque material, such as paper. papersize=iso-a4 indicates the display size is 210x297mm. color<=24 indicates the display supports 24-bit (8-bit/channel) color. Future work and other issues A discussion of input device availability is ongoing. The use of feature tags such as voiceinput, pointeronly or keyboardonly could be used to serve interactive resources customized for various clients not possessing the `normal' pointer-plus- keyboard interface. The previous draft contained both UA-pixels and UA-windowpixels tags. This draft contains only one UA-pix tag, and it's use (to indicate window size for an application or display size of a device) is dependent on the application. A discussion of rectangular (non-square) pixels was held. The feature may be implemented by introducing an aspect-ratio tag for resolution such as res-aspect, which indicates the resolution ratio of the vertical direction to the horizontal direction. It is unclear whether this is significant at this time. Using numeric feature tags [5] section 7.2, it is possible for a server to construct a variant list which will not provide a `default' variant when the feature tag is not implemented by the client. Proper construction of such variant lists requires care. Acknowledgments This document has benefited from the comments of Ho John Lee, Brian Behlendorf, and Jeff Mogul. References [1] T. Berners-Lee. "Universal Resource Identifiers in WWW." A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web." RFC 1630, CERN, June 1994. [2] T. Berners-Lee, L. Masinter, M. McCahill. "Uniform Resource Locators (URL)." RFC 1738, CERN, Xerox PARC, University of Minnesota, December 1994. [3] T. Berners-Lee, R. Fielding, H. Frystyk. "Hypertext Transfer Protocol -- HTTP/1.0." RFC 1945." MIT/LCS, UC Irvine, May 1996. [4] T. Berners-Lee, R. Fielding,I J. Gettys, J. Mogul, H. Frystyk. "Hypertext Transfer Protocol - HTTP/1.1" MIT/LCS, UC Irvine, May 1996. [5] K. Holtman, A. Mutz, "Transparent Content Negotiation in HTTP" IETF Internet Draft draft-holtman-http-negotiation-04.txt, Nov. 1996. [6] R. Smith, F. Wright, T. Hastings, S. Zilles, J. Gyllenskog. "Printer MIB." RFC 1759." IETF, March 1995 [7] K. Holtman, A. Mutz, "Feature Tag Registration Procedures" IETF Internet Draft draft-ietf-http-feature-reg-00.txt, October 1996. Authors' Addresses Larry Masinter Xerox Palo Alto Research Center 3333 Coyote Hill Road Palo Alto CA 94304 Fax +1 415 812 4333 Email: masinter@parc.xerox.com Lou Montulli Netscape Communications Corp. 501 E. Middlefield Rd. Mountain View, CA 94043, USA Phone +1 415 528 2600 Email: montulli@netscape.com Andrew H. Mutz Hewlett-Packard Company 1501 Page Mill Road 3U-3 Palo Alto CA 94304, USA Fax +1 415 857 4691 Email: mutz@hpl.hp.com Koen Holtman Technische Universiteit Eindhoven Postbus 513 Kamer HG 6.57 5600 MB Eindhoven (The Netherlands) Email: koen@win.tue.nl