On Tue, 23 May 1995 12:55:46 -0400, Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu
wrote:
On the one hand, the draft makes
a good case of why it should not be under application/.
I don't think that this case has been made. The counter-example of EDI has
been given. No *technical* benefit is accrued from a "chemical/cxf" as
opposed to "application/chemical-cxf" or "application/chemical;chemtype=cxf".
However, a technical *cost* is paid by adding a new top-level type. Every
MIME application needs to be taught about top-level types. The authors of the
draft seem to think this is necessary and desirable: [page 5]
The over-riding concern is to
preserve this semantic interpretation of the presentation in any
default treatment of the message body.
In other words, no, you can't just ignore CHEMICAL or pretend it's an "other";
you have to read the CHEMICAL spec and implement its defined default action.
I read the arguments in the draft for why APPLICATION could not be used, and
remain unconvinced. The issue appears to be more of esthetics rather than
technical need (unless you want to be paranoid and take the quoted text as
saying that they seriously want to force everybody to implement their type).
The information can be carried in the subtype; furthermore the availability of
parameters provides abundant extension mechanisms.
1) Create a new primary content-type 'Structured/'.
2) Register a set of subtypes under the Structured/ tree
The problem with STRUCTURED is that there are already some forms under the
APPLICATION tree, such as EDI (and maybe POSTSCRIPT) that would have to be
moved. Nor am I sure this would necessarily satisfy the claimed benefit of a
specific CHEMICAL top-level type in terms of establishing default treatments.
It's possible to argue that this type of data could be a top-level class
called MODEL, but it's still not clear to me that that is needed. If it's
program-readable data (albeit perhaps textual in nature), it can go under
APPLICATION; if it's primarily human-readable, it can go under TEXT.
Other details:
Audeience. CHEMICAL seems to support a very limited audience (although
doubtless it is important to that audience). Contrary to its name, it is not
actually transmitting a chemical, and there is some question as to whether
there is sufficient information in the data to fabricate the chemical in the
absence of external information.
Implementation Cost. There is a significant implementation cost associated
with the addition of a primary type that is *NOT* incurred by secondary types
or by parameters. As was discussed in great detail in the IETF-822 list, it
is desirable to have a small, tightly bounded set of top-level data types that
permit classification and default handling in a very coarse and general
fashion. It is attractive, for example, to represent a primary data type as a
small integer rather than doing innumerable string comparisons; particularly
in distinguishing between TEXT, MULTIPART, MESSAGE, APPLICATION, and
AUDIO/VIDEO/IMAGE. Does CHEMICAL really add another such class, and if so,
can't the class be of wider range than "CHEMICAL"?
Precedent. Contrary to the claims of some, others have admitted that this
will open the floodgates to a plethora of new top level types. The purpose of
subtypes (refer to the IETF-822 archives) was to avoid this consequence.
Conclusion:
The road to hell is paved with good attentions.
The CHEMICAL community has a clearly defined need, and that need must be
addressed. However, they have not made the case that their suggested solution
is necessary, compared to alternatives which would impose a reduced burden
upon other communities. Nor have they made the case that they would have a
higher burden with an alternative solution.
I would prefer to nip all new top-level types in the bud; in fact, given my
druthers I would move AUDIO/VIDEO/IMAGE to be under APPLICATION. But if there
must be a new top-level type, a general class like STRUCTURED or MODEL which
has applicability to other communities is preferable to a special-purpose
class like CHEMICAL.