[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

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


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/