Re: LINK TYPE=override/type

On 22 Jan 98, igraham@smaug.java.utoronto.ca (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"
anyone?).

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

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

Rob
 

-----
"The word to 'kill' ain't dirty    | Robert Rothenburg wlkngowl@unix.asb.com
 I used it in the last line        | http://www.asb.com/usr/wlkngowl
 but use the short word for lovin' | http://www.wusb.org/mutant
 and Dad you wind up doin' time."  | PGP'd mail welcome (ID 0x5D3F2E99)

Received on Friday, 23 January 1998 11:24:39 UTC