To: mmm-people(_at_)isi(_dot_)edu, ietf-822(_at_)dimacs(_dot_)rutgers(_dot_)edu
Subject: standards/suggestions for MIME transport of PC filetypes?
Date: Wed, 18 Aug 1993 11:57:55 -0400
Fellow netters;
We're working on a MIME implementation with extenstions to handle the
transport of PC files. Obviously the generic APPLICATION/ type will
transport them, but we want our user agent to be able to determine
what "application" generated the file, and further to do something
"intelligent" with it, including extracting the file into an appropriate
filename (with extension) onto the PC and potentially launching the
related application.
We have to use the PC extension as a guideline for identifying the
application (the user will still have to verify it since it's far from
100% accurate) but in any case, the only means we have come up with so
far is creating a separate APPLICATION/X-subtype for every pc application
file-type we can handle, including different subtypes for different
types of files handled by the same application (i.e. Excel .XLW, .XLS,
etc). This makes for a long list of subtypes, though I see no way around
it at this point.
I have seen the RFC which defined additional types for a few PC file
types, but we're looking at setting up a site-defined list which could
easily incorporate hundreds/thousands of types.
Any thoughts/suggestions? We're going to implement whatever we come
up with in the next few weeks, and I'd prefer to stick to what could
at least potentially be a potential standards track, and hope that as
a new standard is defined we can easily adapt to it.
My suggestions:
1. Please use standard MIME types wherever possible, say for ordinary
text or GIF files or whatever. If MIME mailers are to interoperate
we must avoid defining duplicate types for the same kind of object.
2. In addition, some non-standards-track MIME types have already been
defined; you can get a list by ftp-ing to venera.isi.edu, cd to
in-notes/mime. The file "mime-types" has the list, and the MIME
templates for each of these are in sub-directories named for the
top-level MIME type: application, audio, etc. If a suitable type
has already been defined, please don't define a new one.
3. Please *do* register new types that aren't equivalent to existing
types, and are likely to be widely used.
4. If you are going to use the PC file extension to determine the
file type anyway, why not just use application/octet-stream,
include the original file name, and let the recipient's UA do
that? Mapping a type to a file extension isn't adding any
information, and (except for well-defined types) isn't helping
interoperability with other platforms either. And this would
keep you from having to keep everyone's mapping tables in sync.
As an alternative you could do something similar to the MIME<->X.400
gateway approach: define an application/{x-}pc-file type and have the
file extension as a parameter. I strongly discourage this approach
except for types that are inherently PC-specific, but it's better
than having tons of application/X-* types.
5. If you are going to launch related applications, you need to seriously
consider the security risks involved with doing so. Given that a great
many file formats can contain commands to scribble over files or redefine
commands in an application, the potential for Trojan horses is immense.
Even innocuous-seeming applications like word processors or spreadsheets
can cause problems. And of course it's easy to forge mail, so it is unwise
to assume that you can trust a file because you know where it came from.
Keith Moore