Re: Dual names, IDN and ASCII, in e-mail addresses?

> If you want to support a great number of coded character sets, I guess
> one approach would be to define a new media type that doesn't use a
> charset parameter, and instead provides its own internal charset tagging
> (so it would not merely support many coded character sets, but many
> character encodings).  Another approach is to create a general iso-2022
> charset that includes all registered 2022-compatible coded character
> sets.  Either way there would be a deployment hurdle to overcome.
The approach of a new media type that provides its own internal charset
tagging was tried in the very version of MIME. We called it text/richtext.
See RFC 1341 section 7.1.3.

Text/richtext was not successful.

As for the approach of creating a general iso-2022 charset, I again note this
idea was discussed at considerable length when MIME was first designed, and
rejected. I'm sure the discussion can be found in the list archives if anybody
cares.

It is also important to note that all this happened before Unicode, UTF-8, and
UTF-16. The need for multiple charset support was therefore much greater at the
time, and yet it was unsufficient to the task.

I again have to ask "where's the beef"? What vital piece of functionality is
provided by any of these schemes that cannot be accomplished with text/plain
and utf-8? We have a universal character set now that subsumes almost
previously defined charsets. While it is true that Unicode support is
nontrivial, it is axiomatic that supporting a vast array of charsets that
collectively provide about the same functionality piecemeal is even more
difficult.

                                Ned