One document matched: draft-mutz-http-attributes-00.txt


HTTP Working Group                              A. Mutz, Hewlett-Packard  
INTERNET-DRAFT                                     L. Montulli, Netscape  
<draft-mutz-http-attributes-00.txt> 		    L. Masinter, Xerox  
                                                   
  
Expires December 12, 1996                                  June 12, 1996  

User-Agent Display Attributes Headers  

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 an initial 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] to inform a server about its display capabilities.  This memo   
describes the syntax for introducing this information into an HTTP   
transmission. The intent is to express a client's capabilities such that   
a capable server may present documents in a preferred form.  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].  
  
Introduction   

Purpose   

The Hypertext Transfer Protocol (HTTP) is protocol for distributed,   
collaborative, hypermedia information systems.   
At present it 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 message headers as an extension to the   
protocol referred to as HTTP. This extension enables a client to inform   
a server regarding its display capabilities.  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 attribute headers should be   
suitable for use with the negotiation mechanisms of HTTP.  The presence   
of these headers must not cause a request to be failed for lack of the   
variant resouce.  

Operation   

When a server receives an HTTP request including  UA-attrib message   
headers, it may use this information to indicate a variant of a resource   
most appropriate for the client's display.  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.    
  
UA-attrib headers can indicate display size (in pixels), window size (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.  
  
Five UA-attrib headers are defined.  

User-Agent Attributes:  

UA-pixels: <n>x<m>  

The available display size of the client's device is transmitted in   
total (horizontal) <n>  x (vertical) <m> pixel number, for example:  UA-  
pixels: 1024x768.    The intent is to expose a maximum capability rather   
than a preferred size such as current browser window, with the   
presumption that a user would prefer to resize a window than request a   
new set of resources.  In the case of paper media, the size should   
represent the printable area rather than the physical sheet size (to   
avoid clipping of contents).  
  
For the case of an embedded object, this should be the size of the   
embedding frame.  

UA-windowpixels: <n>x<m>  

The window size of the client's application is transmitted in total   
(horizontal) <n>  x (vertical) <m> pixel number, for example:  UA-  
pixels: 640x300.    The intent is to relay the client's preferred window   
size, with the presumption that a user would like to view the available   
resources in this window.   
  
The authors are debating the utility of this field, and it is included   
here for discussion.  

UA-resolution: <n>  

The display device resolution is transmitted in pixels per inch.  For   
example:  UA-resolution: 72.  
  
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].     
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  

UA-color: <token><n>  

The display color capabilities are indicated with a combination of an   
ASCII token and a parameter <n> describing the number of color channel   
bits available.  Token values must be:  grey or color.  Values of <n>   
are typically (but not limited to)  2, 8, or 24.   For example:  grey8   
indicates a display capable of representing an image in 256 levels of  a   
single color, while color8 indicates a display capable of representing   
an image with a palette of 256 colors.  
  
The authors recognize the issue of color model may be raised, but have   
concluded for this draft multiple color models such as CMYK and display   
gamma are not included.  The RGB color model with gamma 2.2 is   
assumed.  
  
Negotiation  

The use of a UA-attrib 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.)    
  
  
Notation  

UA-attrib related syntax is specified here relative to the definitions   
and rules of the HTTP specifications.  
  
Header fields  

UA-attrib defines 4 new specific header fields, UA-pixels, UA-  
resolution, UA-media, and UA-color to be added to HTTP/1.1.  These    
attributes may be used together or independently.  The header fields are   
defined as follows:  
  
UA-pixels	=	"UA-pixels" ":" horizontal "x" vertical  
UA-windowpixels	=	"UA-windowpixels" ":" horizontal "x" vertical  
UA-resolution	=	"UA-resolution" ":" ppi   
UA-media	=	"UA-media" ":" media  
UA-color	=	"UA-color" ":" ("grey" | "color") colorbits  
horizontal	=	1*DIGIT  
vertical	=	1*DIGIT  
ppi		=	1*DIGIT  
media		=	token | ("screen" | "stationary" | "transparency" |   
			"envelope" | "continuous-short")  
colorbits	=	1*DIGIT  
  
Examples of the above attributes:  

UA-pixels: 1024x768  
	indicates a 1024x768 display  
UA-windowpixels: 640x300  
	indicates a 640x300 display window  
UA-resolution: 72  
	indicates a 72 dpi display  
UA-media: stationary  
	indicates the display is a cut sheet of opaque material, such as   
	paper.  
UA-color: color24  
	indicates the display supports 24-bit (8-bit/channel) color.  
	
Acknowledgments   

This document has benefited from the comments of Ho John Lee, Brian Behlendorf 
and Koen Holtman.  

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." Work in progress." MIT/LCS,   
UC Irvine, May 1996.  
[5]	R. Braden.   
"Requirements for Internet hosts - application and support." STD 3,   
RFC 1123, IETF, October 1989.   
[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-20262026-04-23 17:51:22