On Wed, 1 Sep 1993 15:40:10 -0500 you said:
At 2:21 PM 9/1/93 -0500, Rick Troth wrote:
If you stick with PC-to-PC scenarios, then keying off the
.EXT should work quite nicely...
I'd rather see this than a plethora of MIME types.
What this solution ignores is the fact that these extensions, used in
the suggested manner, are important type information, which would be
well-served by a registry. Without such a registry, this solution is
in fact a return to the pre-MIME world, ...
Good point, Steve. I don't know that I'd pin it all the way
back to the pre-MIME days, though. But it seems reasonable to me that
some things are wrapped-up in MIME who's processing, and registration,
is outside of MIME. In other words, MIME doesn't have to be all-things-
to-all-applications.
Let me state this a little more strongly: if someone tries to
grow MIME to cover too many bases, it will either become unused or
hated for its monstrous size. Keep it simple and people will love it.
These things need to be registered somehow. What is the objection to
using the existing MIME mechanisms?
I may not be grasping the big picture, or even exactly what
you mean. I don't object to using IANA. Would such use then label
said types as "MIME types"? My vocabulary would call a "MIME type"
something which fits on the Content-Type: header line, and I DO NOT
think it would be wise to use that for every last file type under the sun.
[did I miss a discussion about this?]
Say Chris wants to send a .ZIP between two PCs. If MIME is
being used solely for transport (where you could use FTP or 1440 or
any of several other mechanisms), then MIME doesn't care about the
meaning of the . Z I P on the end of the filename. MIME doesn't
even care about the contents; it's just binary. The unzipper on
the receiving end cares, and I think he wants to build an MUA that
will extract the binary content and offer to process it for the user.
But this doesn't seem to me to require a new MIME type anywhere,
especially since we're talking about something that is (today, anyway)
very platform specific.
--
Steve Dorner, Qualcomm Inc.
--
Rick Troth <troth(_at_)rice(_dot_)edu>, Rice University, Information Systems