Re: LINK TYPE=override/type

Ian Graham (
Fri, 23 Jan 1998 14:06:59 -0500 (EST)

From: (Ian Graham)
Message-Id: <>
To: (Rob)
Date: Fri, 23 Jan 1998 14:06:59 -0500 (EST)
In-Reply-To: <> from "Rob" at Jan 23, 98 11:11:57 am
Subject: Re: LINK TYPE=override/type

Rob wrote:
> On 22 Jan 98, (Ian Graham) wrote:
> > Neil said:
> > 
> .....
> > Certainly both MIME-HTML (smtp/nntp) and HTTP -- which are (or will be) 
> > the dominant protocols for delivering content, provide explicit MIME types. 
> What about FTP?

It does not make sense to distribute fully-functioning multimedia via 
protocols not designed to support multimedia --  we should expect some things
to break, such as typing, under these circumstances.

> > At the same time, I believe TYPE should play a role in error handling 
> > -- for example, if the HTTP-specified type seems to be in error, then 
> > the browser could fall back to the TYPE-specified value, and see if that
> In other words, you're saying that TYPE *should* override the HTTP header.

I am suggesting that the TYPE value might be tried, should the type specified
in the header be patently incorrect in some way.  Not that this would 
necessarily work, of course ;-)

> > works. And if that doesn't work, the browser could try heuristics on the
> > file, to try and determine the correct type (i.e. ... guess!)
> There's a problem with determining that "works". It "works" just fine for 
> a browser to display .ps (Postscript) files as "text/plain". Relying on 
> heuristics (especially vender-specific) will not lead to consistent 
> handling, moreso with new document types. No algorithm will be 100% 
> effective either (a Turing-limitation), so it's best (simpler)  to allow 
> the author to override the server using the TYPE attribute.

I see two issues being discussed -- determining the correct MIME type, and
deciding how to handle or view that type.   TYPE cannot do both.  If you 
want to download a postscript file, it should be typed as such, and te user
agent should be explicitly told how to handle that type (process as PS, view
as plain text, etc.) OBJECT provides a way of doing this, by specifying 
a handler for the data.

It is true that HTTP  server implementations limit user-control of 
typing -- but that is no reason to discard HTTP's ability to specify this
information.  Some of the current arguments should perhaps be raised in
an HTTP/server forum, since it would not be hard to adapt servers to allow
better control, by users, of the HTTP-defined types of their resources.
I argue for fixing HTTP server administration, as opposed to using HTML
to 'patch over' the problem.