On Mon, 22 May 1995 11:05:02 EDT, you said:
The IESG has received a request to consider "A Chemical Primary Content
Type for Multipurpose Internet Mail Extensions"
<draft-rzepa-chemical-mime-type-01.txt> as a Proposed Standard. This is
not the product of an IETF Working Group.
Ahh.. A controversial proposal indeed. On the one hand, the draft makes
a good case of why it should not be under application/. On the other hand,
there is the desire to restrict the number of different top-level types.
If we allow chemical/, we will then get to go through this again for each
new structured datatype - and as noted, this would apply whether the
user community numbered 10,000 or 10,000,000.
I hereby propose that a better way to address this issue would be as follows:
1) Create a new primary content-type 'Structured/'. This would be a
generic category, similar to Application/, but with a few minor
distinctions. The Application/ tree does not specify a structure, but
the subtype specifies what you feed the file to. Structured/ would
specify a structure, but not any specific program. For instance,
Postscript only really makes sense if fed to a Postscript interpreter,
whereas the various 'chemical' types could be fed into a wide array of
different processing programs.
2) Register a set of subtypes under the Structured/ tree, such as
Structured/Chemical-cxf, Structured/chemical-mif, Structured/Renderman,
and so on..
This would give the Chemical/ people essentially what they wanted, and
only require one more top-level type. The semantics of dealing with
unrecognized Structured/Wombat types is well understood, so that part
is not a major issue - only the addition of Structured/ once, after which
we can all go out for a <insert beverage here>...
Comments? Counter-proposals?
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech