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.
The question still remains on the level of information to provide for this
sub-type to be truly useful, (If that is the standard approach that is
accepted, or if an approach is accepted), since PC applications sometimes
are supported on multi-OS-Platforms and their file formats may potentially
differ i.e. DOS, OS2, WINDOWS, NT etc.. versions. So we could have
Wordperfect 5.0 for DOS or WINDOWS and the data would be different, also the
5.0 is significant in that versions for the same platform may differ in file
format. (I don't know whether this is the actual case for this product, but
I would think there are many applications that this statement does apply to)
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"
I'd like to see a standard method of doing this and I think there are many
other people who would like to be able to define the application that the
data are intended for, so I'd like to hear any ideas for achieving this
functionality, or any reasons for not doing something like this.
Any help on this matter would be greatly appreciated,
Thanks,
Suki
-----------------
Disclaimer:
These comments are my thoughts only at this stage, and do not reflect any
policy or an undertaking of direction by Microsoft.
Sukvinder Gill
Program Manager for SMTP Gateways
Microsoft Corporation.
Electronic Mail Address: sukvg(_at_)microsoft(_dot_)com
Telephone Number: 604-891-2398
----------
From: owner-ietf-822
To: ray; RCB
Cc: mmm-people; ietf-822; moore
Subject: Re: standards/suggestions for MIME transport of PC filetypes?
Date: Wednesday, August 18, 1993 16:01
Return-Path: <netmail!owner-ietf-822(_at_)dimacs(_dot_)rutgers(_dot_)edu>
Message-Id:
<199308182103(_dot_)AA04113(_at_)dorner(_dot_)slip(_dot_)uiuc(_dot_)edu>
X-Sender: sdorner(_at_)dorner(_dot_)slip(_dot_)uiuc(_dot_)edu
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 18 Aug 1993 16:01:32 -0500
To: ray(_at_)isi(_dot_)frontiertech(_dot_)com,
RCB(_at_)spsup-1(_dot_)navy(_dot_)mil (CHRIS R BARTRAM)
From: netmail!sdorner(_at_)qualcomm(_dot_)com (Steve Dorner)
Subject: Re: standards/suggestions for MIME transport of PC filetypes?
Cc: mmm-people(_at_)isi(_dot_)edu,
ietf-822(_at_)dimacs(_dot_)rutgers(_dot_)edu, moore(_at_)cs(_dot_)utk(_dot_)edu
----------------------------------------------------------------------------
--
At 2:44 PM 8/18/93 -0500, ray(_at_)rays(_dot_)frontiertech(_dot_)com wrote:
This is the way Super-TCP/NFS for Windows Email handles the non-MIME
specific file types. The user can set up associations for the standard
MIME
types (i.e. GIF<->".GIF", JPEG<->".JPG", etc.) and everything else uses the
application/octet-stream type.
Which is great for things for which real types don't exist. But lots of
documents are platform-independent nowadays, and getting these types
registered is important so that everyone can play rationally.
I'm sure you probably realize that, but I want to make it perfectly clear
(shake jowls :-)).
I think the sort of dual-level registry mentioned before has some merit.
One set of types for use when you want to be maximally interoperable with
mail readers, and another when you want simply to label file types for
transport over mail.
I want there to be a type for WordPerfect documents, so I know what this
incomprehensible gook is when I get it; but I don't want having such a type
to be tantamount to saying that a good MIME mail reader ought to be able to
display them without a lot of help.
--
Steve Dorner, Qualcomm Inc.