Subject: Accept- & Content-Resolution headers proposal

From: Nicholas Shanks <[email-masked]>
Date: Thu, 7 Jun 2007 14:27:20 +0100

It has been mentioned on the Safari WebKit development mailing list  
that a HTTP header which specified a document's target resolution  
would be useful to allow clients to negotiate for high-res or low-res  
artwork and CSS referring to such (background-image, and the like),  
depending on their screen pixels, printer resolution, etc.
I would like to propose this to the Working Group.
My ideas are as follows:

The client (a laptop, say) requests -

GET /style/default HTTP/1.2
Host: example.com
Accept-Content: text/css, text/dsssl, text/xsl
Accept-Resolution: 116.66 dpi

The server has the following to choose from:

default.72dpi.css
default.144dpi.css
default.288dpi.css
default.2400dpi.css

In this instance, the 144 DPI stylesheet would be returned, because  
it is the next size up, with a header:

Content-Resolution: 144 dpi

The client would thus know there was a resolution mis-match and  
(optionally) perform a correction on the CSS values.
(the mechanism assumes higher is better, and scaling down is  
preferable to scaling up from 72 dpi. Apple's iPhone has a screen  
resolution of 160dpi, and so would get the 288dpi stylesheet, even  
though the 144 is a closer match, and the laptop with a web page zoom  
of 200% would request 233.33 dpi)

Furthermore:

• Images served with a Content-Resolution header could have their  
resolution trusted (most web browsers today display one pixel on  
screen per pixel in the bitmap, and ignore the image's internal  
resolution parameter, if one exists). If they don't match, probably  
best to use the image's internal one. There could also be a special  
"Content-Resolution: auto-adjust" header meaning that the server  
doesn't know the resolution at content-negotiation time, but wants  
the client to scale it according to the image's internal value  
anyway, and not do a pixel-to-pixel mapping.

• A "dpcm" (dots per centimetre) parameter could also be understood  
by both ends and converted as necessary.

What do people think? I've only spent an hour or so pondering this,  
so it won't be bulletproof yet.

- Nicholas.

---

From: Peter Speck <[email-masked]>
Date: Thu, 07 Jun 2007 15:29:10 +0000

Hi,

> ...
> though the 144 is a closer match, and the laptop with a web page  
> zoom of 200% would request 233.33 dpi)

Why force a "next size up" if most UAs prefer a dpi which is "close  
enough"?

All the other Accept-XXX headers (except Accept-Ranges) uses a  
wildcard if other values are accepted, e.g. (RFC 2616)
   section 14.2:  Accept-Charset: iso-8859-5, *
   section 14.3:  Accept-Encoding: gzip, *
   section 14.4:  Accept-Language: da, en, *

All 3 supports adding a "quality value which represents the user's  
preference for that charset/...".  Could this be used to allow the UA  
to tell the server if it wants a "higher up" or "closest"?

I assume this would be used too when printing a web-page, so the  
printed output can use high-resultion images.  (I've implemented a  
page which uses high-resolution GIFs for icons, and it is a pita to  
maintain).

But how are the browser going to know which files it should re- 
request when printing the page? All, or only those with a "Content- 
Resolution"?

> by both ends and converted as necessary.

As a web-server implementor, I would prefer keeping the standard as  
simple as possible (i.e. KISS), especially with options almost no  
browsers are going to use. Your scheme for selecting the proper css  
file works spendid with dpcm values converted to dpi.  If a webserver  
wants to support .css files named using dpcm, e.g. "default. 
30dpcm.css", that's fine, but don't make the protocol more complex.  
Continuing with this, I would remove "dpi" from the header value, and  
simply define both headers value to be dpi.

----
    - Peter Speck

---

From: Rob Burns <[email-masked]>
Date: Thu, 07 Jun 2007 15:31:59 +0000

On Jun 7, 2007, at 8:27 AM, Nicholas Shanks wrote:

> would be useful to allow clients to negotiate for high-res or low- 
> res artwork and CSS referring to such (background-image, and the  
> like), depending on their screen pixels, printer resolution, etc.

That's a responsive proposal process. Thanks for picking up on that.  
Let me just add a few of my own thoughts on how I think this should  
work.  Imagine three different clients all loading the same document  
over http. Also imagine that all dimensions are specified in physical  
dimensions (pixels complicate things and they're a moving target in  
terms of software interpretation)..

* The document includes an image with dimensions 6 inches by 4 inches.
* The clients are
     - 1200 DPI printer printing via url request at 100% zoom
     - Firefox on a 96dpi display at 67% zoom
     - Safari on an iPhone with 160dpi display at 50% zoom

Each cleint calculates the resolution based on its current zoom (in  
other words base magnification) level (clients could get more  
sophisticated and request based on expected zoom level if it expects  
to change while displaying the image; but that should probably be  
left out of the spec). Following your suggestion, each client always  
rounds up to the next integer value and returns the pixel dimensions  
(both width and height). So for each client

     - 4 inches at 100% on a 1200 dpi display equates to 4800 pixels
     - 6 inches at 100% on a 1200 dpi display equates to 7200 pixels

     - 4 inches at 67% on a 96 dpi display equates to 258 pixels
     - 6 inches at 67% on a 96 dpi display equates to 386 pixels

     - 4 inches at 50% on a 160 dpi display equates to 320 pixels
     - 6 inches at 50% on a 160 dpi display equates to 480 pixels

Basically each client multiplies its device resolution by its base  
zoom level and returns its effective ppi resolution.

So I think the content negotiation should look more like (for the  
iPhone for example):

GET /style/default HTTP/1.2
Host: example.com
Accept-Content: text/css, text/dsssl, text/xsl
Accept-Resolution: 80 ppi

So for resolution independence we want authors to specify dimensions  
in absolute (physical) units. However content negotiation of bitmap  
related content should be based on ppi. If the display is stretched  
in any way perhaps the protocol should allow for two ppi dimensions  
to reflect the different horizontal and vertical ppi resolutions.

Hope this is clear.

Take care,
Rob

---

From: Julian Reschke <[email-masked]>
Date: Thu, 07 Jun 2007 17:54:15 +0200

Nicholas Shanks wrote:
> It has been mentioned on the Safari WebKit development mailing list that 
> a HTTP header which specified a document's target resolution would be 
> useful to allow clients to negotiate for high-res or low-res artwork and 
> CSS referring to such (background-image, and the like), depending on 
> their screen pixels, printer resolution, etc.

How is "Accept-Content" different from "Accept" 
(<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.1>)?

Also, I find talking about resolution-dependent stylesheets about 
surprising, as a CSS can be written in a resolution-independent way, 
right? Maybe you should only use bitmap images as examples.

Best regards, Julian

---

From: Nicholas Shanks <[email-masked]>
Date: Thu, 7 Jun 2007 17:00:50 +0100

Sorry,

> Accept-Content: text/css, text/dsssl, text/xsl

should of course have referred to "Accept-Type"  :-)

- Nicholas.

---

From: Travis Snoozy <[email-masked]>
Date: Thu, 7 Jun 2007 09:06:47 -0700

On Thu, 7 Jun 2007 14:27:20 +0100, Nicholas Shanks
<[email-masked]> wrote:

<snip>
> resolution parameter, if one exists).

This is of concern to HTML and CSS, the former of which I know properly
handles this with the "width" and "height" parameters in <img> and
(IIRC) <object>. If the designer wants an image to be a specific,
pixel-perfect size, he should use this mechanism. If CSS does not have
a similar mechanism, it really should.

<snip> 
> so it won't be bulletproof yet.

The browser knows what the user wants to see, and the graphic artist
has a series of layouts. It should be up to the browser and the CSS to
determine what the page layout is going to be. Now CSS may need to grow
some new features (e.g., the ability to replace the contents of an
<img> or <object> tag; the ability to @include on DPI; etc.), but that
would still be very much in the problem-space for that technology.

I don't see any benefit to putting this information in the
transport, except for the fact that you could have the server do the
work instead of the client. IMHO, the appropriate place for all of this
_is_ the client -- the client knows the most about its presentation
environment, and the server shouldn't have to know or care about every
little detail (although the content author might). Taking this idea to
a silly extreme, we could tweak HTTP to send oodles and oodles of
information to the server, and have the server resolve the
whole presentation layer. The server could custom-render a great big
(png|jpg|gif) that gets sent back to the client, along with a linkmap.
Or, the server could render the HTML to ascii, and send that back (in
the case of a text browser). It would be far better, though (again,
IMHO), to let the clients grab a blob from the server, pick over that
blob, and make further fetch decisions based on the contents. That keeps
the server dumb and generic, and the clients can be as dumb or smart as
the authors want to make them -- without requiring any special, extra
support from the server/proxies.

-- 
Travis

---

From: "Mike Dierken" <[email-masked]>
Date: Thu, 7 Jun 2007 09:09:07 -0700

Where did the "/style/default" URI come from to begin with?
If from a document of some sort, could that document describe the
choices right there with distinct URI for each supported resolution?
Adding that description of resolution specific resources only requires
updating the definition of those document formats, rather than
updating a protocol that is device and document format independent.

---

From: Nicholas Shanks <[email-masked]>
Date: Thu, 7 Jun 2007 17:09:57 +0100

On 7 Jun 2007, at 16:54, Julian Reschke wrote:
>
> How is "Accept-Content" different from "Accept" (<http:// 
> greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.1>)?

> should of course have referred to "Accept-Type"  :-)

don't i look like a plonker now!
maybe i'll go do some gardening instead...

The header is just confusingly named, i keep thinking it's the  
"Accept-content-type-header-formats thing"

> surprising, as a CSS can be written in a resolution-independent  
> way, right? Maybe you should only use bitmap images as examples.

Images, and anything that refers to images would need to support it.
You may have existing content that is named foo-hires.jpeg and foo- 
lowres.jpeg and want to switch between them without doing the  
negotiation on the images themselves (so that old references don't  
need to be fixed)

- Nicholas.

---

From: "Mike Dierken" <[email-masked]>
Date: Thu, 7 Jun 2007 09:17:17 -0700

> negotiation on the images themselves (so that old references don't

Ahh, well there's yer problem right there...
The "... so that old references don't need to be fixed..." is the
issue. It turns out that on the Web it's much better to have two
references and work on 'fixing up' the sources that point to one or
the other. One concrete example is a caching proxy that has been
taught to only look at the URI - without updating the implementation
of all those existing caching servers, the wrong bits will be returned
to clients that ask for "foo.jpg" because the cache hasn't been taught
to look for this new header. In this case perhaps using the Vary
header in a response may help, but I believe there are other areas
where having different representations for the same URI may create
problems.

---

From: Nicholas Shanks <[email-masked]>
Date: Thu, 7 Jun 2007 17:20:02 +0100

On 7 Jun 2007, at 17:06, Travis Snoozy wrote:

> (IIRC) <object>.

I was referring to images outside of HTML, in that instance (where  
the browser doesn't scale).

> Now CSS may need to grow

That's already happening, which is why I didn't refer to it. See  
below for why both are preferable to CSS alone.

> little detail

The reason for putting it in the transport is to reduce bandwidth  
overhead whilst still giving a crisp presentation.
You could send all screen clients the 288dpi version and print  
clients the 4800dpi version of whatever resource it is, but you'd be  
wasting a lot of bandwidth. Also this is needed for all images, not  
just those referred to by CSS or HTML (HTML has no way other than the  
poorly supported LOWSRC attribute to select on resolution anyway)

- Nicholas.

---

From: Nicholas Shanks <[email-masked]>
Date: Thu, 7 Jun 2007 17:29:21 +0100

On 7 Jun 2007, at 17:14, Jim Gettys wrote:

> Heh.
>
> DPI is a useless measure of resolution, unless it is based on an
> expected distance to the screen.

Oh, I wholly agree. But that information generally isn't available to  
the client anyway, so we have to do with the next best thing.
One can presume that a presentation is taking place in an auditorium,  
that a TV is across a living room and a computer screen "at arm's  
length" (as I believe CSS defines it) and the client can guess based  
on the current CSS media style how far away the viewers are,

> As it stands now, we have to
> use Gecko's new scaling features to have decent behavior.

Something Opera has had for a while

- Nicholas.

---

From: Travis Snoozy <[email-masked]>
Date: Thu, 7 Jun 2007 10:04:43 -0700

On Thu, 7 Jun 2007 17:20:02 +0100, Nicholas Shanks
<[email-masked]> wrote:

<snip>
> overhead whilst still giving a crisp presentation.

Well, then, I don't get it. Explain it to me like I'm dumb. :)

> wasting a lot of bandwidth.

This confused me at first, but then I realized you were talking about
CSS media types. I'm betting that CSS doesn't have anything to switch on
DPI yet. As a totally fictional example:

@media screen.300dpi {
@import url('/300dpi.css');
}

@media print.1200dpi {
@import url('/1200dpi.css');
}

Syntax, of course, would be up to negotiation, but this provides a
general idea. The DPI switching should be done in CSS.

> Also this is needed for all images, not  
> just those referred to by CSS or HTML (HTML has no way other than
> the poorly supported LOWSRC attribute to select on resolution anyway)

(I've never, ever heard of "LOWSRC"; is it even part of HTML? In any
case, presentational differences should be handled in CSS, not HTML
directly.)

Yes, but the respective clients should be responsible for coming up
with a way to determine which resource to choose. HTTP is, after all,
the _HyperText_ Transport Protocol first and foremost -- it absolutely
supports transferring any and all other file formats, but "dpi" doesn't
make sense in the context of retrieving an HTML file*. It also is
not universal; it would be nonsense for an ISO image, or a vector
graphics file, or an MP3, etc., etc. If it's not good for HTML
specifically, and it's not good for all files generically, why does it
belong in the transport?

For example -- you can vary on language. Language is clearly important
to all the contents of the HTML file, and is generally applicable (to
some degree) to all files. Media type is, again, generally applicable
to all types -- given an abstract thing, you can oftentimes represent
the same idea with different concrete instances. Content encoding
applies to all files; it's just a filter. Bandwidth? Q-values! Is there
a counter-example that's only relevant to a subset of file types?

-- 
Travis

* Given that the primary role of HTML is to encode structure and
semantics, not presentation. I argue that DPI selection is a quality of
presentation.

---

From: Nicholas Shanks <[email-masked]>
Date: Thu, 7 Jun 2007 18:18:54 +0100

> Why force a "next size up" if most UAs prefer a dpi which is "close  

Do they? I guess it depends. I don't mind spending the bandwidth for  
better looking graphics, but someone on a pay-as-you-download phone  
most likely would.

> preference for that charset/...".  Could this be used to allow the  
> UA to tell the server if it wants a "higher up" or "closest"?

something like "Accept-Resolution: 200; allow-closest" to allow  
180dpi images to be sent, and "Accept-Resolution: 200" to get the  
240dpi images? I can't see a way to shoe-horn q= parameters into  
doing this in any meaningful way.

An asterisk would be implied because there will always be a closest  
match, even if the only resolution is lower than a client requested.  
(i.e. There would be no 406 errors because of this header)

> page which uses high-resolution GIFs for icons, and it is a pita to  

I'd be interested in seeing that, just for curiosity's sake.

>> • A "dpcm" (dots per centimetre) parameter could also be  
>> understood by both ends and converted as necessary.
>
> file works spendid with dpcm values converted to dpi.  If a  
> webserver wants to support .css files named using dpcm, e.g.  
> "default.30dpcm.css", that's fine, but don't make the protocol more  
> complex. Continuing with this, I would remove "dpi" from the header  
> value, and simply define both headers value to be dpi.

Yeah, you're probably right, but we're supposed to be moving to  
metric at some point in the 1970s, which i'm looking forward to. Did  
you hear the U.S. plan on landing men on the moon?!

- Nicholas.

---

From: Stewart Brodie <[email-masked]>
Date: Thu, 7 Jun 2007 18:18:43 +0100

Travis Snoozy <[email-masked]> wrote:

> I'm betting that CSS doesn't have anything to switch on DPI yet. As a
> totally fictional example:
> 
> @media screen.300dpi {

It can.  CSS Media Query:  http://www.w3.org/TR/css3-mediaqueries/

@media screen and (resolution: 300dpi) { @import url(/300dpi.css); }
@media screen and (resolution: 1200dpi) { @import url(/1200dpi.css);}

Where appropriate, media query keywords can take an optional min- or max-
prefix to convert the equality comparison into a greater than or equal, or
less than or equal.  e.g.

@media screen and (min-resolution: 1200dpi) { @import url(/1200+dpi.css); }

-- 
Stewart Brodie
Software Engineer
ANT Software Limited

---

From: Jim Gettys <[email-masked]>
Date: Thu, 07 Jun 2007 16:14:14 +0000

Heh.

Take a projector: maybe 10-20DPI, but viewed from 3-20 meters.

Take the OLPC screen: 200DPI, 1200x900, 7.5" diagonal.  But 8 year old
kids are much smaller than we are, so they will be somewhat closer to
the screen.  Still effectively a bit higher resolution than most
people's big laptops, but not radically.  As it stands now, we have to
use Gecko's new scaling features to have decent behavior.

If you are going to deal with this, note that the *number of pixels*,
and the *angular resolution* are the parameters needed to actually
choose a style sheet reasonably. DPI by itself is useless. You just
aren't going to get as much on a high resolution, but very small screen
as you do on a big one with 4-10x the number of pixels.  And you may
need to do very different layout and font choices.
                                 - Jim

-- 
Jim Gettys
One Laptop Per Child

---

From: Peter Speck <[email-masked]>
Date: Thu, 07 Jun 2007 17:48:20 +0000

On 07/06/2007, at 19:18, Nicholas Shanks wrote:

>> Why force a "next size up" if most UAs prefer a dpi which is  
>> "close enough"?
>
> Do they? I guess it depends. I don't mind spending the bandwidth  
> for better looking graphics, but someone on a pay-as-you-download  
> phone most likely would.

But the UA should be able to tell this in the header, so normal  
browsers have more leeway in scaling up, but phones can prefer low- 
resultion.

> doing this in any meaningful way.

If we leave out the "dpi" tag and allow the value to be a range, it  
could be specified as:
	Accept-Resolution: 70-80;q=3, 50-150;q=2, 150-400;q=1

(note that comma separates the items in an accept header, not  
semicolon.)

A high-resolution for printing would use e.g.:
	Accept-Resolution: 300-400;q=3, 200-600;q=2, 50-2000;q=1

> match, even if the only resolution is lower than a client  
> requested. (i.e. There would be no 406 errors because of this header)

If we allow a range, why not? Then the UA would be able to say: "I  
dont want any media for dpi > 100". Cell phones could use this to  
avoid download of huge files.

>> page which uses high-resolution GIFs for icons, and it is a pita  
>> to maintain).
>

A summer rental house:
http://www.dancenter.co.uk/house/11508/20071110

If you click on the "Print page" you get a page using higher- 
resolution media:

1) The red icons to the right on the page, e.g. "grocer's shop", are  
sent as 150 dpi versions. I fould that 150 dpi was sufficient for  
pretty output, and 300 dpi was not needed.

2) Photos are sent in a slightly larger version.

(the page lack a lot of text (and might have really bad English) as  
the site is provided primarly in German and Scandinavian due to the  
market).

----
    - Peter Speck

---

From: "Robert Brewer" <[email-masked]>
Date: Thu, 7 Jun 2007 11:46:07 -0700

Peter Speck wrote:
> > An asterisk would be implied because there will always be
> > a closest match, even if the only resolution is lower than
> > a client requested. (i.e. There would be no 406 errors
> > because of this header)
> 

If the proposal exists to minimize bytes transferred, wouldn't a new
"Accept-Length" header be more appropriate and useful for a wider set of
media types? The server could then vary the representation returned in
order to meet the restriction given by the client (or return 406 Not
Acceptable).

If the issue is actually image resolution and not octets, a media-range
parameter in the Accept header seems to be a more appropriate place to
implement it; for example:

    image/jpeg;max-dpi=100;q=0.5

Regardless, I don't see how either one should involve any changes to the
request for a CSS file. The user-agent will fetch the CSS resource,
execute the CSS rules, and then fetch additional resources in separate
HTTP requests. Those latter requests seem to me to be the appropriate
place to specify restrictions on the representations returned. I can't
think of any precedent for using the headers of request A to influence
the characteristics of the response to request B--that's too tight a
coupling between HTTP and CSS, in my humble opinion.

Robert Brewer
System Architect
Amor Ministries
[email-masked]

P.S. Hello, ietf-http-wg list, I'm the author of CherryPy 3, which
includes an HTTP server that is arguably the most used in the Python
web-framework space these days. I'll try to keep quiet and learn from
here on out. ;)

---

From: Nicholas Shanks <[email-masked]>
Date: Thu, 7 Jun 2007 20:04:54 +0100

Hello Peter, thanks for the reply. some good ideas there.

> browsers have more leeway in scaling up, but phones can prefer low- 

how do you suggest they do that then? a different header perhaps. "i  
prefer smaller files to higher quality" could be stated something like:
Accept-Length: 0-5000, 5000-10000;q=0.5, 10001+;q=0.2
then if there are two versions, a low bandwidth one at 2000 bytes and  
a high bandwidth one at 8000 bytes, the smaller one gets sent if it's  
"qs" value isn't too low. What figures the client sends would be  
based on some kind of 'conserve my bandwidth' preference.

(Robert Brewer suggested the same thing as i was writing this!)

> 	Accept-Resolution: 70-80;q=3, 50-150;q=2, 150-400;q=1

allowing ranges is something that hadn't occured to me. yes, this  
would allow what you suggest.
q-values should remain in the range 0 to 1 to stay compatible (e.g.  
with things that check for "q=1")

> (note that comma separates the items in an accept header, not  

(i know, that's why i used a semicolon!)

** OFF TOPIC BITS FOLLOW **

> 1) The red icons to the right on the page, e.g. "grocer's shop",  
> are sent as 150 dpi versions. I fould that 150 dpi was sufficient  
> for pretty output, and 300 dpi was not needed.

those are prime examples of where vector images should be used, where  
the client supports them. same with the DanCenter logo which doesn't  
get a high-res bitmap. the map of denmark could also be vector, or at  
least higher res bitmap.

if you supply those icons as image/pdf and use negotiation, even  
ancient versions of Safari can use them for printing.
if you supply them in SVG too, IE would still get the png version but  
FF and Opera would be upgraded to vector too.
make sre you set source quality on the bitmap versions to 0.25 or  
something, so they don't get picked by things that support other mime  
types.

> the site is provided primarly in German and Scandinavian due to the  

yeah, lots of mistakes :)

- Nicholas.

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 07 Jun 2007 21:15:34 +0200

> request when printing the page? All, or only those with a "Content- 

I would say all with a "Vary: Accept-Resolution" in the response header
if the new output resolution differ.

Regards
Henrik

---

From: Nicholas Shanks <[email-masked]>
Date: Thu, 7 Jun 2007 20:21:08 +0100

> Well, then, I don't get it. Explain it to me like I'm dumb. :)

I think you do get it.
We all want to avoid scaling up small bitmaps, and provide high res  
art for those who can display it
We all want to reduce bandwidth costs by sending as little data as is  
necessary, whilst maintaining a professional look as above (both for  
the host and the user who pays for/has restricted bandwidth)

> I'm betting that CSS doesn't have anything to switch on
> DPI yet.

not yet but it's coming... some implementations have it already.  
other people have replied to that effect.

> The DPI switching should be done in CSS.

which is great until CSS is not available.  The point of this is to  
provide such switching where it's not already available.
This header would be most important when no CSS is involved (e.g.  
directly accessing a resource outside of HTML/CSS context, or  
selecting a css file in the first place, though this could be done  
with a css switcher file that loads the appropriate sub-resource).

> Content encoding

One of the things i didn't make clear was that this would only apply  
to images and/or files that reference images (and i suppose only  
those that don't have inherent DPI selection for such references,  
e.g. XSL)

Reviewing the feedback so far, it looks like this use case (switching  
DPI) is too narrow to bother changing the spec for as CSS can fill  
95% of the use cases, but that there *is* a need for preferring  
smaller files even if they are of lower quality. I suggest thought be  
focused on that.

- Nicholas.

---

From: Nicholas Shanks <[email-masked]>
Date: Thu, 7 Jun 2007 20:17:45 +0100

>     image/jpeg;max-dpi=100;q=0.5

That seems to differ from current practice, e.g. we don't have:
Accept: text/html;lang=fr
but use a separate header. Content-Language isn't appropriate for  
many types of resource, but still it's there.

> place to specify restrictions on the representations returned.

the later requests *are* the appropriate place (I shouldn't have used  
CSS as an example in the original suggestion) but also the author of  
the referring file (could be a javascript, for example) may not have  
control over the images' server (e.g. adverts loaded from third party)

> I can't

it wouldn't. the headers for A would influence what resources were  
requested for B, because different images would be referenced in the  
file returned by request A.

- Nicholas.

---

From: Maciej Stachowiak <[email-masked]>
Date: Thu, 7 Jun 2007 12:58:32 -0700

> like), depending on their screen pixels, printer resolution, etc.

I don't think it's a good idea to handle this at the HTTP level,  
because that requires server-side changes and approaches are possible  
which handle things purely on the client side.

> Accept-Resolution: 116.66 dpi

This is a bad idea for a number of reasons:

1) CSS already has media queries to select from multiple stylesheets  
in HTML/XML, or to select from multiple blocks in a single stylesheet.

2) DPI is not really the relevant factor to make the decision, what's  
important is the UI scale factor. If I'm running at 144 DPI but at 1x  
scale, I want the same images as at 72 dpi 1x scale.

3) Passing the resolution to the server forces the selection logic to  
be on the server side, not the client. But that's not really sensible  
- if the server has multiple  resolution versions of a resource, such  
as an image, it should advertise them to the client and let the client  
choose. For example, at 1.5 UI scale factor, if the server has 3x and  
2x images available the client could reasonably choose 2x (the next  
scale up) or 3x (since it is an integer multiple of the scale factor).

> zoom of 200% would request 233.33 dpi)

This doesn't make sense with the way clients actually work. What you  
care about with images embedded in web content is the relative scale  
of CSS pixels relative to device pixels, which does not have any  
necessary direct relation to the physical DPI. You don't actually want  
to serve different images to different DPI screens if they are both  
running at the same scale factor.

> so it won't be bulletproof yet.

I think the whole design of it is wrong. It's based on DPI instead of  
scale factor, it pushes the decision to the server when it should be  
made on the client side, and it handles things at the HTTP level that  
should be (and indeed are) handled by CSS media queries.

Regards,
Maciej

---

From: Maciej Stachowiak <[email-masked]>
Date: Thu, 7 Jun 2007 13:00:39 -0700

> should of course have referred to "Accept-Type"  :-)

Actually it should have been "Accept:". There is no Accept-Type header.

  - Maciej

---

From: Peter Speck <[email-masked]>
Date: Thu, 07 Jun 2007 18:53:38 +0000

Hi,

More systematic description of idea with using ranges:

The Accept-Resolution header has the same overall syntax as the other  
accept headers to simplify parsing (and reduce bugs in web-servers).  
Each item-value is a range of non-negative integer dpi values. The  
range includes both values and the two values are separated by a  
dash. A range with the first number larger than the second is empty/ 
invalid and is ignored.
If multiple medias match a range, the media closest to the range's  
midpoint is selected.

If the header is not specified, it is equvalent to:
	Accept-Resolution: 70-80;q=3, 50-150;q=2, *;q=1
so the server defaults to send media fitted for most computer displays.

If the header is specified, no default value/asterix is assumed. If  
no range match the available media, a 406 error is returned.

To get normal usage for a desktop browser:
	Accept-Resolution: 70-80;q=3, 50-150;q=2, *;q=1

A high-resolution for printing would use e.g.:
	Accept-Resolution: 250-400;q=3, 150-600;q=2, *;q=1

A phone could use:
	Accept-Resolution: 70-80;q=3, 10-120;q=2
as the phone doesn't specify the asterix, no media of dpi=200 is  
allowed to be sent to it. The phone UA might ask the user if it  
should retry and allow higher-resolution.

If the server response does not include a "Content-Resolution"  
header, it is assumed that only one version of the media is  
available.  So only for reponses including the header should the  
browser try to obtain high-resolution media for printouts.

----
    - Peter Speck

---

From: Nicholas Shanks <[email-masked]>
Date: Thu, 7 Jun 2007 21:53:29 +0100

On 7 Jun 2007, at 20:58, Maciej Stachowiak wrote:

> 2) DPI is not really the relevant factor to make the decision,  
> what's important is the UI scale factor. If I'm running at 144 DPI  
> but at 1x scale, I want the same images as at 72 dpi 1x scale.

I presume you meant "72 dpi 2x scale" there. In that case just ask  
for 144 in the request. The server doesn't need to know whether it's  
a high res screen or a low res one zoomed in, only how many pixels  
you've got to fill so it can pick the 2 MB photo or the 30 MB photo.

> I think the whole design of it is wrong. It's based on DPI instead  
> of scale factor,

It is based on both, the client apply the scale to the output dpi  
before making the request, so it doesn't ignore scale factor, it's  
pre-multiplied beforehand.

> it pushes the decision to the server when it should be made on the  
> client side

This is a good example and something that cannot easily be done at  
present - client-side selection.
The only way i see to do that would be to preflight each request with  
a GET with "Accept: *;q=0" header, wait for the 406 response, and  
make a second request by selecting from the list given. The server  
would also need to provide the DPI of the images. The problem here is  
for most resources there is only one choice, but you have to make two  
trips to the server for it.

I know of no means for a client to say "I want this resource, send me  
a list of choices if there are any, or the resource otherwise".  
Perhaps there ought to be a CHOICES method that either returns a 406  
list if there are choices, or returns the 200 result like GET would  
have done if and only if there was one choice. CHOICES would never do  
server-side content selection. Then you would only have one request  
for most resources, and two for the negotiable ones, yet do the  
selection on the client side. The problem with GET is it might  
succeed in selecting a resource that you didn't want, and when it  
does, the Vary header isn't detailed enough to tell you what else  
might be more appropriate.

Also bear in mind it's infinitely easier for an administrator wanting  
to deploy high-res images to update his server software than to  
persuade all his users to upgrade theirs! Whilst I can't see a way of  
getting the result without updating both, further refinements on the  
server can improve all clients that send the new header, without them  
needing to update too.

> and it handles things at the HTTP level that should be (and indeed  
> are) handled by CSS media queries.

What about when CSS is not available?
What about when you don't control either the CSS or the image  
resource? (e.g. adverts on a 3rd party server)
What about when you don't know what variants of a resource there may  
be now or in the future?

> What you care about with images embedded in web content

And what about images not in web content?
I agree, use media queries where HTML+CSS is available and you can  
control both the CSS and the images, but you need to fall back to  
content negotiation otherwise.

- Nicholas.

---

From: Nicholas Shanks <[email-masked]>
Date: Fri, 8 Jun 2007 00:08:29 +0100

On 7 Jun 2007, at 23:07, Rob Burns wrote:

> PS, again my suggestion is for the client to request specific pixel  
> dimensions for the media not the ppi/dpi/cmpi) If the the UA is in  
> an environment with multiple displays or multiple resolution output  
> of any kind it can use that in determining the pixel dimensions to  
> request. Otherwise, it can re-request the image for the new output  
> device..

Yeah, your earlier example used ppi, not dimensions. Could you please  
provide a new example of what you envisage, with all the relevant  
back-and-forth headers enumerated, although I think what I suggest  
below is better than sending any pixel data to the server. Let me  
know what you think on this, Rob:

On my previous CHOICES suggestion:

Thinking further about caching, creating a new request type that was  
a hybrid of GET and HEAD was a bad idea. A better way would be to use  
GET but supply a new header that disables content negotiation (which  
is what I was really trying to do, though I didn't quite realise it),  
forcing a 406 if any content negotiation would otherwise have been  
performed. The 406 would then be automatically handled (not presented  
to the user). It puts all choice in the hands of the client/user and  
not the server/author.

I expect it would go something like:

"Negotiation: disable"

So what happens now still works:

Old client requests image /foo and provides no disabling header
Server sends back 'optimum' resource foo, as best it can determine,  
taking into account quality-of-source and file length
Object is cached by proxy
Client uses result returned

New behaviour also works:

New client requests /foo and asks for content negotiation to not  
occur by including a new header.
Server responds without negotiation because there's only one choice.
Response is cached as normal by proxy.
Result is used by client.

-or-

New client requests /foo and asks for content negotiation to not  
occur by including a new header.
Server detects multiple resources to choose from, sends back a 406  
immediately
Result is not cached by intermediate proxies.
	(A smart proxy could even clear it's cache whenever it sees a URI  
return a 406,
	as it now knows that there are multiple representations for that  
resource and
	that it's previous cached object would not be valid for all clients!)
Client parses (scrapes) the 406 response body (which will have to be  
more clearly spec'ed)
Client issues a new request for the choice it wants, using exact URI,  
can omit new header this time
Server responds without negotiation because there's only one choice.
Response is cached as normal by proxy.
Result is used by client.

The cost is one round-tip to the server per negotiable URI + one  
header on all initial resource requests.
The saving is no need to send any Accept-* headers anymore.

So basically:
• Content negotiation is a good thing for users
• Server-side negotiation defeats caching and gets so long-winded  
that usually a wildcard is sent anyway (e.g. Accept-Encoding)
• Client-side negotiation allows caching of the final URI, as long as  
the negotiable URI is not cached and a bad choice returned by the proxy.
• Client-side negotiation can be transparent to the user, a 406  
response doesn't need to be presented
• This can all be implemented as an extension to HTTP 1.1, and in a  
future version of HTTP, the new header can be made implicit.
• Whilst there could also be a "Negotiation: enable" for HTTP 1.2 or  
2.0, simply sending the Accept-* headers would be enough to indicate  
that you wanted server-side negotiation.
• The response could also include a Suggest-Location: header for  
clients that aren't able to/don't want to parse the choices and  
select one. This would probably be what the server would have picked  
if it had done negotiation anyway.
• Also, a new response code (418 Client Selection Required) could be  
used instead of a 406, with an XML body that the client is not  
allowed to show to the user. This would be much better than scraping  
a 406, more extensible in future etc etc. Clients without an XML  
parser just use the server's suggestion.

- Nicholas.

---

From: "Larry Masinter" <[email-masked]>
Date: Thu, 7 Jun 2007 17:03:33 -0700

Content negotiation for HTTP based on parameters beyond MIME types
was the focus of a significant amount of IETF work, including 
RFC 2295 ("Transparent Content Negotiation in HTTP")
RFC 2296 ("HTTP Remote Variant Selection Algorithm -- RVSA/1.0")
and a set of 'media features' (including resolution, screen
size, pixel depth, etc.) in a Media Feature registry
(RFC 2506, BCP 31).

The protocol documents are experimental, but there are experimental
implementations.

In addition, the media feature tags originally targeted for use
in HTTP were used in Internet Fax (for negotiation of resolution
of scanned document images) and are being used in SIP and 
IMAP extensions.

There are other ways of describing target device capabilities,
constraints and preferences (such as screen resolution) that have
been proposed in other organizations (W3C CCPP, for example),
but I think you'd be better off starting with something that's
already been worked on than trying to invent yet another namespace
of things like "resolution".

Larry
--
http://larry.masinter.net

---

From: Nicholas Shanks <[email-masked]>
Date: Fri, 8 Jun 2007 01:28:34 +0100

sorry for more spam people :-)
a couple of things i don't have time to write about before i go to  
bed (tis gone 1am here)

http code 300 is what i was wanting, not 406 or making up a new one
	http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.1

the "Suggest-Location" param already exists, and is just called  
"Location"
	(same url)

agent-driven negotiation is already suggested by HTTP 1.1:
	http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html
except that:
	1) the format of a 300 response is not defined and in fact doesn't  
make it clear whether UAs should look in the headers or body for the  
list of choices
	2) there seems to be no way to make apache (v1.3) generate a 300  
response, it does server-side negotiation with all the things i tried  
(which is where my new header would apply - make it generate a 300!).
	3) i've never seen a 300 response from any web server in the wild.  
if it's not even implemented, i'm not surprised no client apps do  
their own negotiation.

I am intrigued by what larry just write, and will look at it either  
tomorrow or in 10 days, as am away next week.
i'm sure all the HTTP boffins already knew this and are lookin  
skyward right now. sorry folks!

- Nicholas.

---

From: Travis Snoozy <[email-masked]>
Date: Thu, 7 Jun 2007 19:45:15 -0700

> provide such switching where it's not already available.

No matter what, the client is going to have to support something -- be
it this, or (more appropriately) a higher-layer method for determining
which resource to pick.

> with a css switcher file that loads the appropriate sub-resource).

I think that, while things other than HTML can be transferred over
HTTP, they're somewhat out of scope. It is, after all, the HyperText
Transfer Protocol -- though a command extension, as you have suggested,
could certainly be used to create a HyperImage Transfer Protocol.

> those that don't have inherent DPI selection for such references,  

I'm glad you cleared that up -- because it was exactly the point I
was driving at. :)

The server should not have to discriminate "images" and (even worse)
"image-referencing-files" and make the DPI selector work for only those.
If the selector doesn't have at least the potential to make sense for
all files (or, at a bare minimum, HTML files), then should it really
be in the transport?

> Reviewing the feedback so far, it looks like this use case
> (switching DPI) is too narrow to bother changing the spec for as CSS
> can fill 95% of the use cases, but that there *is* a need for
> preferring smaller files even if they are of lower quality. I suggest
> thought be focused on that.

Q-values (as mentioned elsewhere) already do exactly that -- albeit
with limited control, but with the benefit of taking only one trip.
Having a way to see all the varies (also mentioned elsewhere) would
probably more generally useful, but will require up to three trips.

If we're going the latter route, the problem can be solved above the
transport level, by writing up an RFC for, e.g., "automatic location of
multiple resource representations using RDF." Have a scheme similar to
the robots.txt or favicon.ico -- files with multiple representations can
be detected by appending .multi (or whatever). Given that the .multi
file is present, process it and make your choice. Existing servers
can support it, lots of clients already have all the technology they
need to implement it, and it'll play nice with proxies and caches (!).

The worst-case scenario would be getting a full 404 hit, which could be
mitigated by doing a HEAD before a full GET (under the assumption that
_most_ files will not use this mechanism). This would require two
or three round trips for most media-esque files -- HEAD->404->GET the
original file, or HEAD->200->GET the .multi->200->GET the chosen file.
There might even be some fancy-dancy conditional GET you could use to
reduce it to one trip -- but I haven't read the spec in a while, so no
promises. :)

-- 
Travis

---

From: Nicholas Shanks <[email-masked]>
Date: Fri, 8 Jun 2007 12:07:33 +0100

Hi Peter.

I recommend you take a look at what Larry Masinter pointed out. It  
becomes clear that all of this has already been solved 9 years ago,  
but because it (apparently) isn't enabled in Apache by default, I and  

> size, pixel depth, etc.) in a Media Feature registry

http://www.ietf.org/rfc/rfc2295

Basically the client adds a "Negotiate: trans" header to the GET  
request, and initiates transparent (to the user) content negotiation  
(TCN). The server sends back a 300 response with a list of choices in  
an Alternates header, the format of which is defined in the RFC. The  
client then issues a new GET request for the one it wants, without  
having to send any environment information (dpi, &c.) to the server.

Clients can also send a few (small) Accept-* headers and ask the  
server to take an educated guess, but still return the list of  
Alternates along with it's guess, which could save round trips if the  
client decides that the server's guess was good enough ("the 150dpi  
would have been best for me, but I'll just use this here 200dpi image  
you've already sent"). If the resource is non-negotiable, the  
Negotiate header is ignored by the server and nothing changes.

In light of this, I suggest that WebKit developers (including me if I  
get the time) look into implementing this set of RFCs, and ignore all  
previous suggestions.
It seems we've been in the classic chicken-and-egg situation since  
1998, where clients don't implement it because servers don't have it  
turned on by default, and servers don't have it enabled because there  
are no client implementations to test against. Website owners are  
left none the wiser, and while a few server-side negotiation, most  
don't find it reliable enough to use, and have things like flag icons  
on their home page to choose your language.

Apple members should discuss with the IETF the addition of device- 
pixel-ratio to the Media Feature registry. This will allow TCN for  
<img> and <object> elements containing visual media, and anywhere  
else where CSS does not apply.
I also suggest a "High-Res: Part III" blog post on webkit.org to draw  
attention to this feature and get more web developers aware of and  
using TCN, which I think is the biggest hurdle (implementing it won't  
be as hard).

- Nicholas.

---

From: Peter Speck <[email-masked]>
Date: Fri, 08 Jun 2007 12:04:07 +0000

On 08/06/2007, at 13:07, Nicholas Shanks wrote:

> [...]
> In light of this, I suggest that WebKit developers (including me if  
> I get the time) look into implementing this set of RFCs, and ignore  
> all previous suggestions.
> 1998, where clients don't implement it because servers don't have  
> it turned on by default, and servers don't have it enabled because  
> there are no client implementations to test against.
> [...]
>

This sounds good. I've read the RFC and cannot find any problems, so  
I dully agree to drop prior proposals. What's the ETA for WebKit  
implementation?

----
    - Peter Speck