Valdis;
MIME is too much e-mail centric.
For an E-mail centric protocol, it's worked pretty well on port 80....
MIME worked on port 80 only as well as pre-MIME 822.
MIME worked pretty badly with the rest of the OS.
All that was necessary is to document file name extensions such as
"tar", "uu" and "822" and email could have worked better with OS.
MIME complexities such as multipart and base64 is just a reinvention
of wheel.
On most OSes, including but not limited to UNIX, that's the way to
designate content types of files.
But it's not *universally* true, so you have to come up with some sideband
way of conveying information. And in fact, even if two systems both
support extensions as a *mandatory* flagging, you can still run into
trouble
No.
- what if the two systems don't use the *same* extension for
a filetype that should be portable?
It's just an issue of escaping.
Add, say, "X", if some extension is reserved on some OS.
Should a postscript file end in .PS,
.ps, .PST? Should a VisualBasic script be .VB or .VBS? Is a image/jpeg
file a .JPG or .JPEG?
Should a MIME content type of postscript file be "PS", "ps", "PST",
"postscript" or "PostScript"? Should a VisualBasic script be "VB", "VBS"
or "visual-basic"? Is a image/jpeg file a "JPG" or "JPEG"?
It's just an issue of registration and registration authority.
Instead, MIME developers arrogantly claimed that OSes should be
modified to support MIME content-type (and even that text files
on OSes should use MIME format to support other tags such as
charset).
No.
This claim is right up there with "SMTP developers arrogantly claimed
that OSs should be modified to support network-standard EOL".
Wrong. It is not a line format issue but an issue of OS internal features.
MIME developers arrogantly assumes OSes should support file type
using MIME content type.
And poor OS developers, such as Microsoft, actually did so.
And of course they didn't. They merely insisted that the user agent at
either end convert to/from the local format.
The local format does support ASCII file names but have no room
to store content type.
Masataka Ohta