I had always assumed that HTML would be text/html. We have jumped
the gun and used that in WWW code for a year or so. To put it
as Application/ seems daft.
I may be way out of line on this, but personally I don't like
the Application/.... bag at all. Firstly, it doesn't mean
"application", it means "other". And one should be wary of
any system which files most things under "other".
All data has to be processed by some application.
It is was designed to be a derogatory "application-specific",
meaning "only one application", or "non-standard", or
"proprietory", or "non-rfc", then fair enough but nothing
common and well defined should go into it.
It is far more useful to talk about the data representation
than the application, of course.
I like the initial image/ or video/ or sound/ as that really
does tell me the data type, and I can chose an icon
for it even if I don't understand the rest. We're not talking
about whether it would frighten someone if put on a screen,
but rather what *class* of object it is. I expect to be
able to interconvert between different conetnt-types in
the same class. Like I can convert postscript to gif.
So I would want image/postscript. I guess that has been said
so many times before. Not because it looks like an image, but
because the abstract object which it renders is an image.
If MIME puts HTML under
"application" but "enriched" under "text", then the initial
part of the type has become meaningless.
Tim Berners-Lee
Begin forwarded message:
To: ietf-822(_at_)dimacs(_dot_)rutgers(_dot_)edu
Subject: Query on a nit: Application vs. Text conten-type
Contact: phone: +1 408 246 8253; fax: +1 408 249 6205
Date: Mon, 25 Oct 93 07:12:10 -0700
From: Dave Crocker <dcrocker(_at_)mordor(_dot_)stanford(_dot_)edu>
X-Mts: smtp
I notice that the tendency with nearly all of the specifications
produced in recent months is to class a new subtype under
Content-type:Application. Some of these involve data that are
text (usually standard, simple ASCII) and would be moderately (or
even highly) understandable to a human if the content were
presented to their screen.
I wonder whether such data would not be better classed under
Content-type: Text?
Not a big deal? Probably not.
However under Content-type:Application typical mail readers will
take the most conservative stance, restricting all handling of the
data to processing it through a separate program; hence if they don't
know the sub-type, they won't process it. Under Content-type:text,
minimal handling, by displaying to the screen, would seem entirely
reasonable.
Do folks care about this? Any suggestion for language to give
guidance
to Mime body-part spec writers?
Dave