This is obviously a redux of the "chemical" primary MIME type proposal. As I
stated before, I was strongly opposed to "chemical", but would not object to
the addition of "model".
Unfortunately, although the proposal itself is alright, this document is not.
Perhaps it is "alright" to those who are used to reading pompous scientific
papers, but not as an IETF protocol.
It appears to place requirements on models (section 2, which supposedly only
discusses the need, section 4, and Appendix I) which seem to severely and
unnecessarily restrict the scope of this new primary type.
It makes numerous statements without any supporting evidence such as "these
various subtypes can be converted between each other with less loss of
information then to that of other primary types".
It contains a great deal of fluff e.g. sections 1, 2.1, 4(a),...
Section 2.2 goes to a great deal of effort to argue the benefits of "model"
over the multimedia types. It seemed rather pompous to me, as if "throw
enough bullshit to confuse the reader and he'll be shocked into a confused
silence." Yet expends only a single paragraph on the important issue, which
is "why not use application?"
Section 6 makes some (to me) unsupported assumptions -- "the data files are
``read-only'' and do not contain file system modifiers or batch/macro
commands." The existing proposed model subtypes may not do this, but this may
not be the case in general. It also describes a serious security risk --
"internal structure of the data files may direct agents to access additional
data from the network" which was glossed over.
RECOMMENDATIONS:
These recommendations, if followed, would result in a massively smaller
document and one which I feel would be accepted without much controversy. You
aren't out to get grant money, you're producing a technical proposal for
implementors who have remarkably little tolerance for verbiage.
Section 1 should be flushed.
Section 2 in its entirety can be flushed, and replaced with a single paragraph
that (a) defines a model succiently (e.g. "any kind of formal description of
an entity of state of affairs"), and (b) makes the statement that as such it
deserves a new top-level type co-equal with the multimedia types and should
not be shoehorned under application.
Section 3 should be rewritten to correspond closer to what other
specifications contain as their extension mechanism.
Section 4 needs to formally specify all initial parameters (and a Formal
Syntax section is needed). 4(c) needs to be moved to a more prominent place,
perhaps to the single-paragraph section 2 as suggested above. A great deal of
4(a) (note that the second paragraph of 4(a) seems to have been cut off)
should be flushed; it's verbiage and unnecessary for understanding of the
specification.
Section 6 (Security Considerations) needs to be rewritten, preferably by
someone in the security area instead of a scientist.
Section 5 and Section 6 got swapped. This should be fixed.
Appendix I should be flushed. Items 1-4 basically say that perception data
are not models. However, models can be made of any of these. For example, a
recording of an oboe may not be a model, but a model could be made of the
characteristics of the sound produced by an oboe. Item 5 is incomplete and
otherwise makes no sense. A model *is* application data, it's just that it is
special enough that it's being given its own top-level type. Items 6-7 are
just plain wrong, IMHO; if they are excluded from the scope of model the day
will come when we have to create yet another new type to put these in.
Appendix II should be flushed.
Appendix III should be moved to the main body as "initial models". The
qualifiers as filename extensions should be changed to a new parameter, e.g.
something like:
Content-Type: MODEL/IGES; QUALIFIER=igs
Additionally, the concept of "qualifier" needs definition. I have no idea if
this is the correct name, since the term is suddenly used without any good
idea of what it means other than it may be a DOS filename extension and/or a
program that reads it.
Appendix IV talks about how images and video aren't models, but the first
three examples are GIF or MPEG data. This does not support the contentsion
made earlier.