Re: LINK TYPE=override/type

Rob (
Fri, 23 Jan 1998 11:11:57 -0500

Message-Id: <>
From: "Rob" <>
To: (Ian Graham)
Date: Fri, 23 Jan 1998 11:11:57 -0500
In-reply-to: <>
Subject: Re: LINK TYPE=override/type

On 22 Jan 98, (Ian Graham) wrote:

> Neil said:
> > 
> > > that an author may want to process or view the resource by some
> > > mechanism other than the browser's default handling for the given
> > > type, is no argument for using TYPE to arbitrarily override the 
> > > server's information..
> > 
> > That is nice for HTTP, but HTML has no necessity to be delivered over 
> > HTTP, other protocols don't provide content type, and if TYPE is 
> > there it would be nice to have a consistant model.
> I agree with consistency -- but believe that the software that 
> assembles the message must be given higher priority, since it in principle
> has the 'latest' information available about the resource and its type. 

Disagreed. Very often the software DOES NOT have the latest information.
It must be updated by a smaller subset of users who have special access
permissions. (Interesting idea: HTTP servers that periodically check
with a trusted source on the network to update MIME configurations, or
at least notify administrators of an update, assuming the central 
source updates their information in a timely and accurate manner....)

There are times when a server cannot correctly determine the file type, 
with new document types or even obscure ones ("application/x-hpack"

> 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?

> [..]
> This assumes that you can self-consistently manage all linked documents,
> which is not the case.  For example, someone linking to your document might 
> specify the type of your document using TYPE. But, if you subseqently 
> change the type, their documents will break.   

Bad argument. Broken links are a more common (and unrecoverable) problem.

> 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 

> 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.


"The word to 'kill' ain't dirty    | Robert Rothenburg
 I used it in the last line        |
 but use the short word for lovin' |
 and Dad you wind up doin' time."  | PGP'd mail welcome (ID 0x5D3F2E99)