ISO 2022 raises several additional problems, arising primary because
it is not a character set but a collection of separable rules. If we
can avoid providing for it in headers, we can avoid replaying all of the
arguments about it that ran through the list in the (northern
hemisphere) spring.
I do not think CJK would like that.
An email software developer that tries to sell a product in Japan that
does not support the JUNET profile of ISO 2022 is just being
incredibly stupid.
However, the question here is whether we can mandate their ISO 2022
profile in an Internet RFC. Apparently, some of the members of this
working group think the answer to this question is "No".
But it would be equally stupid to exclude a standard way of doing
non-standard things. The Japanese shall continue to use their 2022
profile no matter what this working group says.
Since email software that handles Japanese is going to have to deal
with their 2022 profile anyway, I would think that it is only natural
to provide for the use of 2022 in the headers, obviously through
further encoding and/or quoting to avoid the special 822 characters.
Cheers,
EvdP