- 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