In hindsight I wish that text/plain had been specified as being
canonicalized using newline conventions particular to the character set,
and that charsets had been required to specify a canonical newline
convention before they could be registered (naturally, anything derived
from US-ASCII would use 0D 0A).
I not so sure it would have been worth it. Sure, it might have made text/plain
more compatible with some hypothetical future usage, but there's really no
problem with registering additional types and subtypes in the future to
accomodate this. But the increase in complexity to handle present-day mail
properly would have been substantial.
Frankly, the best thing about this is that it would have avoided some of the
issues we now have to clarify in the conversion between different encodings.
You might say in response that this is too much of a burden on MUAs,
because they would have to know the newline conventions for a multitude of
character sets. My answer is, if simple MUAs chose to always assume that
the newline convention was 0D 0A and ignore the charset parameter, we'd be
no worse off than we are today in terms of interoperability.
Such an MUA is not MIME-compliant. See appendix A of RFC1521.
In fact, we'd be better off because more sophisiticated MUAs would have the
option of using text/plain to communicate with each other. Yes, for maximum
interoperability, people would still be forced to use an ASCII-derived
charset, because of MUAs that always assumed the newline convention was 0D
0A. But that is the situation we are in today. And the MIME standard would
have been capable of supporting better MUAs.
There is no loss of capability because MIME is _always_ extensible to handle
additional types with new canonicalization rules.
As time goes on, if Unicode or another non-ASCII character set catches on,
MIME would have been able to handle it. As things stand now, we'll have to
define another content type.
Non-ASCII is one thing. We have lots of non-ASCII character sets in use now and
they work fine. Non-ASCII-compatible in the sense of line termination is quite
another. I have grave doubts about the viability of any proposal to use
non-ASCII-compatible in anything but the longest of terms. It would be nice if
the national 7-bit variants would go away too, and we certainly tried to
discourage them in RFC1521, but this has had little if any effect thus far.
Ned