HTTP Working Group                             A.  Mutz, Hewlett-Packard 
INTERNET-DRAFT                                    L.  Montulli, Netscape 
<draft-mutz-http-attributes-02.txt>                  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 <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 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