One of the arguments that has been suggested as a justification for a new
toplevel type by a number of people (including myself at one point) is the
"general-purpose" viewer idea. For example, we are seeing that there are
a number of general purpose image viewers showing up, so it is useful to
feed unknown image subtypes to such a viewer. It has been suggested that
this is a "default action" for the image type, and that other types with
general purpose viewers should have their own toplevel type.
After some thought, I believe this is not only an insufficient justification,
but that the general purpose viewer concept is actually orthogonal to the
concept of a media type and should not be part of the name. Take images as
one example. In addition to a general purpose image viewer, many image formats
may also be fed to a web browser application. That web browser application
can also accept text/html, a completely different media type.
Wordprocessors are also a type of general purpose viewer -- most wordprocessors
can read several different wordprocessor formats nowadays. They can interpret
both subtypes of application and text. Obviously creating a toplevel
"wordprocessor" type and moving all the types they can read under it is the
wrong thing to do, since this can include human-readable subtypes of text.
What this suggests to me is that it might be useful to create a new
Content-Disposition parameter to list general purpose viewer categories (I
note it is important to have a registered set of categories and not to list
application names for security/portability reasons). So you might have:
Content-Type: image/gif
Content-Disposition: inline; viewer=image,web-browser
or
Content-Type: application/rtf
Content-Disposition: inline; viewer=wordprocessor,desktop-publishing
-----
On the specific issue of the chemical/* type, I find the discussion of
default handling as referring specificly to this general purpose viewer issue,
and find it unconvincing as a reason for a new MIME type. I also find the
discussion of future hardware directions as unconvincing, as I believe a
top-level type needs specific hardware requirements as in:
text text device (e.g. vt100 terminal, CRT, printer)
image 2-d display device (e.g. CRT, printer)
video 2-d motion display device (e.g. CRT)
audio speaker (e.g. speaker, telephone)
What I do find convincing is the discussion of the need for interaction with
the chemical model. I believe this suggests a general purpose type:
model 2-d motion display device with 2-d input device
(e.g. CRT & mouse/tablet/trackball)
If the "model" top-level type existed, I would see no justification for
a more specific "chemical" type unless and until it was for formats
that were only useful when a chemical synthesizer was attached to the
computer. The MIME spec specificly states a desire to minimize
top-level types, and I find Mark Crispin's argument of why this desire
exists convincing. Since there is a need to accommodate the chemical
community, I would suggest:
Content-Type: model/cxf
Content-Disposition: attachment; filename=THC.cxf;
viewer=chemical
-----
Chris Newman <chrisn+(_at_)cmu(_dot_)edu>,
http://www.contrib.andrew.cmu.edu/~cn0h/