> It would be great if we could hash this out once and for all, and
> deploy the solution.
Absolutely. And it needs to get specified soon,
since (at least) NCSA and Mcom are planning new
releases shortly.
> But I don't think the technical details are the problem any more:
> we have to make it easy for information providers to _use_ format
> negociation.
How about parameters on the Accept: header?
User-Agent: NCSA-Mosaic/2.5
Accept: image/gif, image/jpeg,
text/html; tables=yes; forms=yes; images=yes,
audio/basic
(I *think* that's the right semicolon/comma precedence.)
This should require a minimal change to browsers,
as the HTML features supported by a browser are
more or less fixed.
Classifying things by feature will probably be more useful
than defining HTML levels for this purpose.
On the server side, the GET processing module could
pipe all HTML documents through a CGI filter that
selectively downgrades the document to eliminate
features that the browser doesn't support,
either replacing them with <PRE> (e.g., tables)
or a canned message saying that this part of the
document could not be viewed.
Any unlisted features should be assumed unsupported.
Accept: text/html with no parameters, or no
Accept: headers at all, could be interpreted to
mean "Send the document as-is." This would be
most useful for spiders and site indexers that are not
feature-dependant. (And curious users with older
browsers.)
(Thirty or forty Accept: headers with no quality parameters,
followed by Accept: */*, could be interpreted as a
request for a MIME multipart/alternative message (in
base64) containing a separate copy of the requested
document in every listed format which the server is
able to generate :-)
Plexus and CERN httpd have customizable hooks for GET
processing; it could be hacked into NCSA httpd by augmenting
the server-side include mechanism. Don't know about any others.
I think the only requirements here are:
* W30 or HTML-WG publishes an initial canonical HTML feature list;
* Browser authors send a suitable Accept: text/html header;
* Someone writes the CGI filter (second toughest part);
* Server maintainers install it at their discretion;
* Authors write more-or-less proper HTML, (i.e., it has to be
parseable by tools other than their favorite browser).
--Joe English