In <9308262223(_dot_)AA20119(_at_)itgmsm> sukvg(_at_)microsoft(_dot_)com
I have had a few discussions on how useful it would be to have specific
content-type application subtypes that define the application that the data
are intended for, and I agree with Steve's comment that it is infact very
useful to know what the "incomprehensible gook" is when we get it, but that
it should not require that a MIME reader have to support displaying it
without any help.
A quick look at this seems to imply that the following information needs to
be carried in some field, (i.e. subtype):
Application Name == Application that the data are intended for
Environment == i.e. DOS, Windows, OS2 version of the product
Version Number == The product version number for that environment.
An example might look like this for an application called "FOO" where FOO is
the subtype of the application content type, and the Environment and Version
are parameters of this subtype.
Intended for a DOS version of this product
Application\FOO; Environment="DOS"; Version="3.24a"
Intended for a Windows version of this product
Application\FOO; Environment="WINDOWS"; Version="5.12"
We considered these possibilities as well in our implementation but came to
the conclusion that overqualifying the items in the headers really didn't help
a mime reader much. As an implementer, we could never hope to correctly
identify all the different types/environments/versions out there, and adding
these fields to the headers implies that the reader ought to know what's
relevant in (at least some) cases.
Personally, I think a better approach is to follow the current registration
procedures for MIME types, and let people that know the data files decide when
a type is portable by defining a new application subtype for filetypes that
are going to be portable. If wordperfect (for example) is deemed to be a
useful document type, and version x.1 documents are not compatible with
version y.2, then register a different subtype for each, and let the MIME
UAs pass them through the same type of generic viewer/lookup process we
do now. I think we get the desired functionality without changing the MIME
structure. For those packages that already implement the same format across
platforms, only one subtype would be needed and the generic MIME UA
neither knows nor cares. If the format is portable, I don't think the platform
or version would be of concern to either a user or UA.
For now we're going to do it that way, while adding the kludge to check
the ;NAME= to try and handle the exceptions by looking for .EXTensions.