- From: M. Hedlund <hedlund@best.com>
- Date: Wed, 8 Nov 1995 18:38:37 -0700
- To: Shel Kaphan <sjk@amazon.com>, Brian Behlendorf <brian@organic.com>
- Cc: www-talk@w3.org
Shel writes:
>I think we should separate content negotiation from the issue of
>browser capabilities. Content-negotiation should be more for
>user-preferences, presence or absence of certain helper apps, and
>other coarse grained and dynamic decisions that occur at a fairly high
>level. Browser capabilities are (a) certain to be too voluminous to
>encode in anything like the Accept header mechanism, and (b) are
>constant properties of given browsers (down to the platform and
>version).
Does "browser capabilities" == "HTML tags and attributes recognized"?
If so, can't we just derive this information from DTD's[1]? DTD's already
exist for Mozilla and Hotjava -- see <URL:http://www.halsoft.com/html/>.
Internet Media Type negotiation ("course grained" in Shel's message above)
is done through Accept. Language is done through Accept-Language.
Although we may want to make recommendations as to how helper apps should
appear in Accept, basically none of the Accept-* stuff changes.....
.....except, in the Accept header, something of this sort appears:
Accept: text/html;DTD="-//IETF//DTD HTML 2.0//EN"
or
Accept: text/html;DTD="-//Netscape Comm. Corp.//DTD HTML 2.0b2//EN"
("text/html;version=2.0" can be a synonym for the first example above.)
Anyone who cares can get that DTD. Servers can provide utilities to deal
with the information given in the DTD. Other servers (or
server-maintainers) might value performance over fine-grained negotiation
and may ignore the DTD.
If a browser author wants to add experimental tags to their browser's
parser, they are strongly encouraged to publish a DTD describing their
experiment. If they do not, anyone else who wants to, can.
Good?
M. Hedlund <hedlund@best.com>
[1] See <URL:http://www.sgmlopen.org/sgml/docs/library/getstart.htm> for
more info.
Received on Wednesday, 8 November 1995 21:37:37 UTC