for what it's worth (which might not be much)
just as a strawman example of another possible content-type suffix:
(I thought of this a few years ago, but it's taken awhile to remember it
in the context of recent dicsussion.)
some binary-transparent mail transports are LF-native, others are CRLF-native.
And some are neutral and support multiple formats (not limited to these)
natively.
...
now if you have a MIME message with some of its contents labeleled
with content-transfer-encoding: binary, and it traverses the boundary
between an LF-native and CRLF-native transport, some of the
"binary" objects may need to be converted from LF to CRLF or
vice versa.
you can safely convert the text/* objects, because (IIRC) the definition
of text/* specifies that bare LF should not appear. but what
about application/*, audio/*, etc objects that just happen to
use text as an underlying format? can you convert these or not?
if you do convert, you will corrupt some objects that are not text.
if you don't convert, the recipient will get some objects that
are not in the right format for his platform.
the problem is that even though MIME specifies canonical format,
in practice, some content types use different canonical formats depending
on the transmission medium. you can gloss over these differences
unless you're using binary MIME.
one idea to solve this problem (not necessarily a good one)
was to define a content-type suffix (say -text) to denote
content-types that used text as their underlying format.
This was raised during the original design of MIME. But it didn't fly then,
for a variety of reasons.
For one thing, the answer to the "can I convert" question isn't necessarily
"yes" or "no". There may be specific conversions that are allowed and others
that aren't. This is especially true once you look at entire list of
formats, which includes LF, CR, CRLF, counted (with byte, word, longword,
big-endian, little-endian, and pading variations), fixed padded, and
some others I won't bother to describe. And what the answer can be depends
on the content-type and platform and a bunch of other stuff. So having
this information in the tag doesn't provide you with enough information
to actually *do* much of anything. Whereas the argument with the -xml tag
is that it *does* provide enough information to act.
But another, even more serious, problem is that the media types that you can
supposedly convert willy-nilly from one of these formats to another often
aren't so flexible once you get down to the details. The standard example of
this is PostScript -- sometimes conversions are OK, but other times there are
counted structures that break if you convert. So now this information turns out
to be instance-dependent rather than type-dependent.
Bottom line: I didn't see this as worth labelling back when we discussed
it circa 1991, and if anything experience with HTTP transport without
conversions has convinced me we were, if anything, worrying a nonissue.
Ned