1. application/latex, troff-*, etc. should be text/* instead. Something
should be supertype text when it can be treated as text/plain by default.
Note that this doesn't apply to Postcript, dvi, etc.
2. I like your archive supertype but if we go with it we should make sure
it gets into MIME proper. Note that creating a new supertype is much
harder than creating a new subtype.
3. The non-standard types should all have "x-" in front of them.
I can't decide whether to resist the use of all those new types; we can't
just union all the operating-system-specific, platform-specific,
software-vendor-specific, company-specific, day-of-the-week-specific
formats and make any progress toward interoperability. Seems to me this
long list could lead to two degenerate cases, at different parts of the
web at the same time:
a. a sophisticated browser with a rich set of builtin types and/or a
lengthy configuration of external viewers will describe its type
flexibility to servers in all its glory, in 20K chunks that take up
more bandwidth that a lot of document transfers;
b. with so many types and no clear priorities on which types to support,
simple browsers on improverished platforms with users who haven't bothered
to configure extended viewers will drive servers CRAZY trying to deliver
documents given a list of idiosynchatic formats.
Should we consider the danger of leaving image/cmu-raster (surely
sunraster is more ubiquitous) and archive/sv4cpio in the list?
Jay