Creating a new type

Ed Levinson (elevinso@Accurate.COM)
Wed, 22 Mar 1995 14:30:22 -0500

In several discussion threads the idea of creating another
Content-Type, not subtype, has been proposed. After reviewing
RFC1521 I finally understand what Keith has been asking. What
hardware requirements exist for the proposed type?

So here's a brief review with some idea of where we might go.
(including tongue-in-cheek ones <grin>)

The basic mime hardware: an ascii terminal (remember those TTYs).

Now what about the existing mime types

text: your basic terminal

audio: an audio output device

image: a display device (monocular)

video: moving image capability (monocular)

That leaves room for

image3D: a binocular display

video3D: moving 3D image capability

odor: smell-arama capability

taste: complements odor

feel: with subtypes for the various body parts and no doubt
the distinguished subtype, erotic. ;-)

I left out the obvious

stereo: this is the generic. monaural is subsumed by stereo,
the unspoken default(?) for audio.

Virtual reality is not included here because, "registered subtypes of
audio, image, text, and video, should not contain embedded information
that is really of of a different type" [RFC 1521, Sect 4]. I undersand
the four listed types to mean "not compound" (mutlipart or message) or not
application. Thus VirtualReality could be a mutlipart type, with perhaps
five mime entities, one for each sense. (If my machine is blind and
dumb I could at least feel, taste, and smell it).

Now "what is" does not mean "what must be" but in looking at how to decide
what deserves treatment as a new mime type, RFC1521 is our guide.

The hardware basis makes a lot of sense to me. It certainly
distinguishes "3D" from "Spreadsheet".

Does this clarify the issue for IGES and CGM? It points to image/ and
image3D/ IGES and CGM subtypes.