Re: Parameters in Content-Type: headers; what the???

Marc VanHeyningen (mvanheyn@cs.indiana.edu)
Wed, 25 May 1994 13:30:50 -0500


Thus wrote: Larry Masinter
>Given how new the web is, and how wet the ink on the specification is,
>don't be surprised that the browsers don't conform to the
>specification. Usually, network protocol standards take years to shake
>out. That the web has grown as quickly as it has is phenomenal;
>however, I don't think we can avoid a year or two of shakeout (if not
>more) as the specs get re-written, browsers and libraries get brought
>into conformance, etc.

True, but it's not clear to me how readily it can be said that this
really applies here. The MIME spec for content-types hit RFC stage
(which HTTP, HTML, and URLs have not yet done) in June 1992 and is
progressing along the standards track nicely; syntax has been
unchanged since then. The idea of content-types was originally
proposed in RFC 1049, in which they too were fields delimited by
semicolons, in March 1988. This isn't some new, wild concept that
just popped up; it's one of the most stable aspects of the spec for
WWW stuff. We've had our year or two.

The root is that there's no good way to generate parameter information
given the current structure of most servers (e.g. how can a server
look at a given file and determine what its charset is?) Thus, few
servers produce documents with parameters, so clients that are
developed exclusively by testing with existing servers without
consulting the specs don't notice anything wrong. That's probably OK
in the early stages, but we're getting to the point where people
should be able to expect things to work the way it says they will.
Alas, this is in direct conflict with the prevailing idea that we
should build a taller skyscraper yesterday, and worry about pouring
the foundation later on.

--
<A HREF="http://www.cs.indiana.edu/hyplan/mvanheyn.html">Marc VanHeyningen</A>