describing browser capabilities (was: Content negotiation)

Shel Kaphan (
Fri, 10 Nov 1995 14:13:27 -0800

M. Hedlund writes:
> At 10:03 AM 11/9/95, Shel Kaphan wrote (quoting me):
> >Are you saying that there is a universal repository
> >of DTD's out there somewhere? If you don't have the description, you
> >have to get it *somewhere*, don't you?
> If you send _one_ URL that describes browser PopuBrowser's capabilities,
[ ... bad things happen ... ]
> One the other hand, if you send a document identifier,
[ ... good things happen ... ]

I see what you mean now. This is pretty close to what I suggested the
other day: there should be replicated databases, indexed by
HTTP_USER_AGENT string, that return *something* describing the
browser. I agree that the DTD could and probably should be among
those things, but see no reason why it must be limited to that.
Returning a text document that describes, in simple terms, something
like the contents of
David Ornstein's Browser Caps database</A> for the browser in question
also seems potentially useful. Nobody is required to use it -- only
people who really want to. It's not pretty, it's not nice, it's just
something you need if you want to get this level of control.
It's a way to represent not just features, but bugs too. DTD's don't
do that. Whether you wish to exercise this level of control is
between you and your library functions.

I am not at all sure I believe style sheets have much of a part in
this right now. The reason is that the installed base of browsers
knows nothing about them. This is not to knock style sheets at all --
it is just my view that a solution to this problem has to help in the
present world, not just "the glorious future".

> >And no, I don't think any of this kind of information should be sent
> >on every request. I already proposed one method, using the existing
> >Redirect machinery, for servers to "request" this information from clients.
> Yeah, that would be a good idea if the info is coming from the browser.
> But does it need to?
No -- it appears it shouldn't. I disavow any previous comments to the

> 1. If you want to send _one_ page that just about anybody can read,
> send HTML/2.0. (This is no negotiation.)
> 2. If you want to take advantage of HTML/3.0, send it only to those
> browsers that include "text/html;version=3.0" in their Accept header.
> (This is Internet Media Type negotiation.)
> 3. If you want to take advantage of experimental tags and
> particular versions of draft standards, get the browser's DTD and see if it
> can render those tags. (This is DTD negotiation.)
> 4. If you want to influence the presentation of those tags, issue a
> site-wide style sheet. (This is one part of cascading style sheets (CSS);
> some other parts include the user's own preferences, which aren't for you
> to worry about.)
> 5. If you want still-finer negotiation, write a page for every
> browser about which you care. (This is user-agent negotiation.)
> 6. If you want absolute control, send PDF. (This is no negotiation.)

> Obviously, this structure is not in place today. #1, #5, & #6 are not
> protocol issues; nor are they desirable. The rest need to be implemented
> in order to work. If they are implemented, I think this structure would be
> a complete solution.

Seems entirely reasonable, except for what you said about 5.
A case in point is the handling of multiple submit buttons.
It is entirely conceivable for a DTD to specify that a name field
occurs in this element, however the browser may fail to send that name.
It's a bug, but it needs to be represented somewhere, hopefully not by
a case statement for that browser in my code.

> M. Hedlund <>
> [1]<URL:>.

Shel Kaphan