In <9309020758(_dot_)AA16109(_at_)daffy(_dot_)uii(_dot_)com> "Harald T.
Alvestrand" <Harald(_dot_)T(_dot_)Alvestrand(_at_)uninett(_dot_)no> writes:
FrameMaker suggests using .doc as the standard file type for
Since I started this thread, I'll add that a strictly pc extension scheme
is not a viable solution for us. Our e-mail system runs on HP3000 minicomputer
systems, where the "extension" portion of a name (i.e. ".doc") would be
interpreted as a group (directory level). Since emulators talking to our
package run in DOS, WINDOWS, OS/2, Unix, and on Macs, file extensions by
themselves don't mean much (in a general case).
What we ARE doing, is adopting a scheme which will utilize a standardized
table of types and mappable applications (per platform) which a user can
easily extend. We'll be using supported (and in cases hope to register new
MIME types/subtypes where it makes sense), but will also as a last resort
attempt to map "extensions" on application/octet types to appropriate
applications on some platforms -- not a perfect solution, and it obviously
won't work in many cases, but it does allow us to progress with registering
valid MIME types and still have a workable solution that will work with some
of the other implementations I've seen out there. At least a "guess" for
otherwise generic attachments is a step ahead of just forcing the user to
try and figure it out (of course, you have to give them the option of
overriding the "guess").
(We are also using an experimental X-subtype for HP3000 files which allows
us to identify those that have unique (non-portable) attributes not otherwise
representable via the content-type headers, so we KNOW not to try and handle
them as PC (or other platform) files. We plan to register the format and
subtype at a later date, along with an RFC describing the format.)
I think this works within the design and intention of MIME -- it provides
the functionality we desire without changing the structure of MIME.