[standards-jig] sending mime-type during filetransfer

Richard Dobson richard at dobson-i.net
Mon Jan 12 17:43:00 UTC 2004


> I am trying to forecast a problem here...

And im trying to show you that there isnt much of a problem to get worked up
about.

> A binary chunk of data is preety useless without information of the type
> of the data.

Thats what file extensions are used for.

> Todays OS'es relies on the so called "extension" of the file to guess
> mime-type of the file
> or the magic-file to determine the type from the contents of the file.
> It's a very error prone method.

I didnt say it wasnt error prone, but if the vast majority of OS's are not
going to take advantage of it whats the point of sending it?

> But modern OS'es like BeOS, AtheOS, Cosmoe, Syllable, MacOS etc. stores
> the mime-type
> alongside the file in so called "attributes" and use them to determine
> the file type. Name of the file
> is purely human oriented. There is no such concept of file "extension"
> there.

Well BeOS is no longer being produced is it? (didnt the company go
bankrupt?), the latest version of MacOS (MacOS X) is moving away from using
"resource-forks", in favor of file extensions, and I havent heard of most of
the others so I would guess that they do not have a very significant user
base.

> The web servers are doing the same thing. And it's the way to go.

Webservers themselves internally do not necessarly use mime types, on
Unix/Linux/Windows the webserver uses the file extension (or one set in
script) to send out the "Content-Type" i.e. the mime info.

> Sending mime-type alongside the binary stream is usefull. The sender
> almost certainly knows what is
> the type of the data it is sending. And guessing it on the reciever side
> can be misleading.

It might be useful sometimes but my argument is that in the vast majority of
cases unless you are automatically opening the file it will just be saved to
the HDD and the mime info that was sent will be discarded, so whats the
point in adding it if its only going to be discarded.

Richard




More information about the Standards mailing list