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

From: Basem Emara <[email-masked]>
Date: Thu, 12 Jun 2014 11:14:33 +0000

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 <[email-masked]>. 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-
[email-masked]> 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: [email-masked]

Lou Montulli
Netscape Communications Corp.
501 E. Middlefield Rd.
Mountain View, CA 94043, USA
Phone +1 415 528 2600
Email: [email-masked]

Andrew H. Mutz
Hewlett-Packard Company
1501 Page Mill Road 3U-3
Palo Alto CA 94304, USA
Fax +1 415 857 4691
Email: [email-masked]

---

From: "Walter H." <[email-masked]>
Date: Thu, 12 Jun 2014 13:50:37 +0200

On Thu, June 12, 2014 13:14, Basem Emara wrote:

> 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 don't think that the screen dimsnsion is important, because this doesn't
say anything about the usable space; more interesting would be the real
space without scrolling (e.g. window size);

I'm not sure, some very old UserAgents (IE1.5?) of the first days
implemented this;

---

From: "Martin Nilsson" <[email-masked]>
Date: Thu, 12 Jun 2014 13:54:43 +0200

On Thu, 12 Jun 2014 13:14:33 +0200, Basem Emara <[email-masked]> wrote:

>
> Please see following contribution to the spec to handle different screen  
> sizes for a post mobile world (written in 1996!):
>
> 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.
>
>

While using the user agent header is not a workable solution (not only are  
there always new devices, some reuses the user agent header string of  
other devices), there are already methods available to do runtime  
detection of screen size using javascript or CSS.

/Martin Nilsson

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

---

From: Basem Emara <[email-masked]>
Date: Thu, 12 Jun 2014 12:00:39 +0000

Yes, but this is needed in the server-side to redirect a user to a mobile site for example. Otherwise, a client-side redirect is only possible which would cause a delay and a white flash of screen.

On Jun 12, 2014, at 7:58 AM, "Martin Nilsson" <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, 12 Jun 2014 13:14:33 +0200, Basem Emara <[email-masked]<mailto:[email-masked]>> wrote:

While using the user agent header is not a workable solution (not only are there always new devices, some reuses the user agent header string of other devices), there are already methods available to do runtime detection of screen size using javascript or CSS.

/Martin Nilsson

---

From: Francesco <[email-masked]>
Date: Thu, 12 Jun 2014 14:03:18 +0200

> While using the user agent header is not a workable solution (not only are there always new devices, some reuses the user agent header string of other devices), there are already methods available…

It also makes sense not to include unneeded information in the User-Agent field for privacy reasons: a couple of years ago research showed that the combination of user-agent and plugins along with their versions as exposed in the User-Agent was relatively unique across users.
I agree with Martin that that information belongs to the realm of the application, not to the protocol.

Kinkie

---

From: Michael Sweet <[email-masked]>
Date: Thu, 12 Jun 2014 08:19:07 -0400

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

> Full copy of the contribution draft below.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Julian Reschke <[email-masked]>
Date: Thu, 12 Jun 2014 14:31:19 +0200

On 2014-06-12 14:00, Basem Emara wrote:
> Yes, but this is needed in the server-side to redirect a user to a
> mobile site for example. Otherwise, a client-side redirect is only
> possible which would cause a delay and a white flash of screen.
> ...

Don't make a "mobile" site. Make a single site that adapts to different 
devices using CSS media queries.

Best regards, Julian

---

From: Basem Emara <[email-masked]>
Date: Thu, 12 Jun 2014 12:42:13 +0000

Responsive design is great and valid, but there are also mobile web app sites that would be vastly different than a desktop site - such as a jQuery Mobile site.

> On Jun 12, 2014, at 8:33 AM, "Julian Reschke" <[email-masked]> wrote:
> 
> Don't make a "mobile" site. Make a single site that adapts to different devices using CSS media queries.
> 
> Best regards, Julian

---

From: Roland Zink <[email-masked]>
Date: Thu, 12 Jun 2014 14:59:42 +0200

You may also look into the x-wap-profile header 
(http://openmobilealliance.org/wp-content/uploads/2012/12/wap-248-uaprof-20011020-a.pdf) 
for another approach.

Regards,
Roland

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 12 Jun 2014 11:42:08 -0400

Hi Basem,

There’s an active discussion around “Client Hints” in the Web Performance world that you might be interested in; see:
  https://www.igvita.com/2013/08/29/automating-dpr-switching-with-client-hints/
  https://docs.google.com/presentation/d/1y_A6VOZy9bD2i0VLHv9ZWr0W3hZJvlTNCDA0itjI0yM/edit
  http://tools.ietf.org/html/draft-grigorik-http-client-hints-00

Cheers,

--
Mark Nottingham   http://www.mnot.net/