I know you hate CJK unification Masataka, but as I've pointed out in the
past, the language tag _can_ have something to do in deciding upon the
rendering of a character set to help disambiguate the unification for those
people who do choose to use a unified character set despite your objections.
I have never objected people use a unified character set, though
I have never recommended to do so.
As I pointed out in the past, use several different "charset" names
for the brain-dead unified character set, such as "ISO-10646-C",
"ISO-10646-J" or "ISO-10646-K", then.
It can't do everything of course as was pointed out in the original text,
but it helps in the most common situations.
Having different charset names do everything.
It is completely pointless to specify both "charset" and "Content-language"
parameter to incompletely help disambiguation.
Implementations should be free to choose whether to take the language tag
into consideration or not when choosing an appropriate font.
Implementations should not take the language tag into consideration
when choosing an appropriate font.
Your
requirement is too strict Masataka.
No. Instead, your requirement for Content-language is useless.
If you don't want to look at
Content-Language in your implementations, that's your decision. But
let the rest of us design our software the way we see fit.
That's a violation of MIME architecture on the role of "charset".
Let the Internet evolve to choose what it believes to be the correct way
to do things.
You may let the market decide IPng.
Maybe you'll be right and I'll be wrong,
Here, it is clear I'm right.
I certainly recognise your greater
experience in Asian language charsets, but that's no excuse to restrict
the flexibility of a perfectly valid tool before the market decides whether
the flexibility is needed or not.
"charset" is the mechanism to give the flexibility youu desire.
Don't confuse "charset" and "Content-language".
Masataka Ohta