One document matched: draft-mutz-http-attributes-01.txt
Differences from draft-mutz-http-attributes-00.txt
HTTP Working Group A. Mutz, Hewlett-Packard
INTERNET-DRAFT L. Montulli, Netscape
<draft-mutz-http-attributes-01.txt> L. Masinter, Xerox
Expires February 1, 1997 Aug 1, 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 <http-wg@cuckoo.hpl.hp.com>.
Discussions of the working group are archived at
<URL:http://www.ics.uci.edu/pub/ietf/http/>. General discussions
about HTTP and the applications which use HTTP should take place
on the <www- talk@w3.org> mailing list.
This is a draft intended for soliciting comments and should not be
released in any production software system.
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 the syntax 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 a content negotiation method such as
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] as an extension to the
protocol referred to as HTTP. This enables a client to inform a
server regarding its display capabilities, and enables a server to
present a list of variants of resources to the client. The server
may then provide a variant of the resource more suitable for the
display. This variant would typically have 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. These
display attributes are suitable for use with a negotiation mechanism
of HTTP. The presence of these tags must not cause a request to be
failed for lack of the variant resource.
Operation
The details of feature negotiation are described elsewhere [5].
When a server receives an HTTP request including UA-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. These are
presented formally in the Notation section.
The headers and arguments are case-insensitive.
USER-AGENT ATTRIBUTE FEATURE TAGS:
UA-pix-x= <n>
UA-pix-y= <m>
The display size of the client's device is transmitted in total
horizontal <n> and vertical <m> pixel number, for example: UA-pix-
x=1024, UA-pix-y=768. The intent is to present and allow the
selection of the resource variants best suited to a client's device.
UA-res= <n>
The display device resolution is transmitted in pixels per inch.
For example: UA-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
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
The `default case' (no tag) is UA-media-screen
UA-color=<n>
UA-grey=<n>
The display color capabilities are indicated with feature tag and a
parameter <n> describing the number of color channel bits available.
Values of <n> are typically (but not limited to) 2, 8, or 24. For
example: UA-grey=8 indicates a display capable of representing an
image in 256 levels of a single color, while UA-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 UA-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.
Header fields
UA-attrib defines specific feature tags, UA-pix, UA-
res, UA-media, and UA-color to be added to HTTP/1.1. These
attributes may be used together or independently. The feature tags
are defined as follows:
UA-pix-x = "UA-pix-x" "=" horizontal
UA-pix-y = "UA-pix-y" "=" vertical
UA-res = "UA-res" "=" ppi
UA-media = "UA-media-" media
UA-color = "UA-color" "=" colorbits
UA-grey = "UA-grey" "=" colorbits
horizontal = 1*DIGIT
vertical = 1*DIGIT
ppi = 1*DIGIT
media = token | ("screen" | "stationery" |"transparency" |
"envelope" | "continuous-short")
colorbits = 1*DIGIT
Examples of the above feature tags:
UA-pix-x=1024
UA-pix-y=768
indicates a 1024x768 display
UA-res=72
indicates a 72 dpi display
UA-media-stationery
indicates the display is a cut sheet of opaque material, such as
paper.
UA-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 UA-voiceinput, UA-pointeronly or UA-
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-view tag, as the usage for
combinations of both tags was confusing. The authors are still
discussing this issue.
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 more
consideration.
Acknowledgments
This document has benefited from the comments of Ho John Lee, Brian
Behlendorf, Koen Holtman, 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. "Transparent Content Negotiation in HTTP" IETF
Internet Draft draft-holtman-http-negotiation-02.txt, July 1996.
[6] R. Smith, F. Wright, T. Hastings, S. Zilles, J. Gyllenskog.
"Printer MIB." RFC 1759." IETF, March 1995
Authors' Addresses
Larry Masinter
Xerox Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto CA 94304
Phone: +1 415 812 4365
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
| PAFTECH AB 2003-2026 | 2026-04-23 06:35:44 |