Re: v10-spec-00 comments

On Tue, 21 Mar 1995, Owen Rees wrote:
> 5.4.1 Accept
> See my recent note about "*/*" meaning "not unusual" where the server 
> cannot know how to interpret "unusual" because it is customisable by 
> the user agent.  Encouraging user-agent authors to give users control 
> over media types is good; undermining the means by which this 
> information is passed to the server is bad.

A better definition of "unusual" is needed.  I agreed with Owen's earlier 
comments[1] and I agree with this one; I've whined and moaned about 
Accept before.  I think the offending text is in the last paragraph of 5.4.1:
	"If no quality factors have been set by the user, and the context 
	of the request is such that the user agent is capable of saving 
	the entity to a file if the received media type is unknown, then
	the only appropriate value for Accept is '*/*' and the list of 
	unusual types.  Whether or not a particular media type is 
	deemed 'unusual' should be a configurable aspect of the user agent."

Some examples:

	* It is neither configurable nor unusual for Netscape 1.1 to 
accept tables -- every copy of 1.1 does, and if you don't like it, stick 
to 1.0 or another browser.  Do tables constitute an 'unusual' media type 
because not every server uses them?  If so, why is 'unusual' determined 
on the browser's side?  Should Netscape 1.1 be sending 'Accept: */*; 
q=0.5, text/x-html-with-tables'?  If so, should other browsers be forced to 
save text/x-html-with-tables to a file?

	* It is not currently unusual for Lynx 2.3.8 to accept HTML 
without tables or math.  A year from now (or five) when HTML 3.0 has been 
released, should Lynx 2.3.8 start considering its requests for HTML, by 
which it means HTML 2.0, 'unusual'?  If the user hasn't the sense to 
upgrade, will the user nonetheless be expected to run Lynx in 
'anachronistic mode'?

	* I prefer HTML to PostScript, and let's pretend my browser knows that.
When downloading the HTML/1.0 draft to print out, however, I prefer 
PostScript to HTML.  Should I open my preferences, reset my quality 
values, make the request, and then return my quality values to their 
standard settings?

Some suggestions:

	* 'Unusual' should be defined more strictly.  One possibility 
would be in reference to IANA registered media types.

	* As new browsers implement wider acceptance of _usual_ media types 
(i.e., HTML 3.0, image/jpeg, whatever), they should be encouraged to 
explicitly list these media types in their accept headers.  This will 
allow server maintainers to avoid "saving to file" whenever possible 
(i.e., send gif unless they _say_ send jpeg).

	* The Content Negotiation section could remove its language about 
choosing from several acceptable media types "possibly at random," and 
instead suggest that when different versions of an entity exist, the 
default should be the version most likely directly viewable by the oldest 
browsers (text/html, text/plain, image/gif).

	* The browser should be able to indicate that it will accept */*, 
but if different versions exist, it specifically _wants_ a "300 Multiple 
Choices" response (if you have more than one version, let me see what 
you have).

	* Similarly, browser authors should be encouraged to allow 
changes to the Accept quality values on a per-request basis.

	* A browser should be allowed to specify a preference for certain 
"usual" media types without the user configuring it to do so!  The 
language I quoted above doesn't seem to allow for that.  For instance, 
the browser could check for the presence of external viewers to handle a 
variety of media types, and list those media types as preferred to media 
types neither the browser nor any of the user's external viewers can 
handle.  The browser would then ask for, in order, (1) types it can  
display directly, (2) types it has external viewers to display, and then 
(3) anything else (*/*).

The HTTP/1.0 draft approaches "Accept" at the literal level of "What 
_can_ this browser somehow take?"  Some of my suggestions above might be 
more appropriate for a header named "Prefer," but then, the only purpose 
of quality values is to express preferences between multiple choices.  
Maybe a separate preferences header would make this easier.  I agree 
that content negotiation should be structured to avoid "406 None 
Acceptable" whenever possible; but I would strongly prefer that Accept 
not be saddled with strict limitations on its content ("...the only 
appropriate value for Accept...").  Mandating "Accept: */*" makes 
content negotiation more difficult.

M. Hedlund <>

[1] <URL:>

Received on Tuesday, 21 March 1995 14:11:00 UTC