[Top] [All Lists]

Re: Forcible addition to mailing list

1995-05-25 14:46:00
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
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;

Chris Newman <chrisn+(_at_)cmu(_dot_)edu>,

<Prev in Thread] Current Thread [Next in Thread>
  • Re: Forcible addition to mailing list, Chris Newman <=