Re: Including screen size to header messages (extending UserAgent)

[Michael Sweet <[e-mail]>]

I think this should just be a separate draft since it applies equally to HTTP/1.1 and HTTP/2.

On Jun 12, 2014, at 7:14 AM, Basem Emara <[e-mail]> wrote:

> Please see following contribution to the spec to handle different screen sizes for a post mobile world (written in 1996!):
> http://www.watersprings.org/pub/id/draft-mutz-http-attributes-00.txt
>  
> It was intended for HTTP/1.1, but did not make it. It should be reconsidered for HTTP/2.
>  
> Current UserAgent is supplied in the header message, but this is insufficient in deducing the screen size. We are forced to look into a table of all possible UserAgents and their screen specs to come up with the screen size. This is maintenance nightmare since ne mobile devices and UserAgents are introduced every day. Servers need to know the screen size rather than the device type to serve different content or redirect to a site more tailored to their screen dimensions.
>  
> I posted this as an issue to the http2-spec GitHub:
> https://github.com/http2/http2-spec/issues/520
>  
> Full copy of the contribution draft below.
>  
> -Basem
>  
> ----------------------------------------------------------------------------------------------------------------------
> 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 <[e-mail]>. 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- 
> [e-mail]> 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: [phone] 
> Fax [phone] 
> Email: [e-mail]  
>   
> Lou Montulli 
> Netscape Communications Corp. 
> 501 E. Middlefield Rd. 
> Mountain View, CA 94043, USA 
> Phone [phone] 
> Email: [e-mail] 
>   
> Andrew H. Mutz 
> Hewlett-Packard Company 
> 1501 Page Mill Road 3U-3 
> Palo Alto CA 94304, USA 
> Fax [phone] 
> Email: [e-mail] 
>  

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair