Or, are you saying that the following specification:
Content-type: text/plain; charset=ASCII
Content-language: French
is better than:
Content-type: text/plain; charset=ISO646-FR
Yes! Actually I prefer a language= parameter, but I definitely want
to separate the language specification from the character set.
That's contradicts with the current policy to use the name US-ASCII
to the only true ASCII.
If the language is combined with a charset, then a decent mail reader has to
support LOTS of charsets. Especially when you start listing combinations of
languages -- say, to indicate a mixed English/Japanese text.
If the language is encoded in a charset, and if the receiver want
to display the charset correctly, the receiver should provide support
for the charset.
If the language is encoded in a charset, and if the receiver does not
want to display the charset correctly, the receiver does not have to
provide support for the charset.
If the language is not encoded in a charset, if no language information
is provided otherwise, and if the receiver want to display the charset
correctly, the receiver can't.
If language is a parameter to content-type, then a mail reader can display
the message (perhaps sub-optimally) if it knows the character set. If it's
smart enough to take the language parameter into account, the mail reader
can pick a font that is tuned to that language.
That is no different from the above examples.
Furthermore, separating the language parameter from the charset makes it
easier to do multilingual text using a construct similar to
multipart/alternative -- the mail reader can let the user choose to read the
French rather than the Spanish version of the text.
Then, you must provide very precise definitions of all the languages
in the world.
The
reader doesn't really care about the character set, as long as her mail
reader supports it.
So, let's encode language information into charset.
Masataka Ohta