Once again, I object vehemently to dropping 2022-JP while retaining 8859, if
that is construed to mean -- as certain individuals have declared -- that use
of 2022-JP is banned until a formal RFC defining it is in place.
Get real. 2022-JP is here in the RFC-822 world, today. The 8859 character
sets exist only among those sites which, in violation of the current RFC's,
are transmitting undeclared 8-bit data.
I would not object to wording which defines the ISO-2022-JP name but leaves
specification to another document, provided that it is clearly understood that
ISO-2022-JP can and will be deployed *immediately* while getting a formal
document that dots all i's and crosses all t's will take some time.
If this sets certain people off into temper tantrums, take the current
appendix which defines ISO-2022-JP and put it in another RFC, declaring this
as an `fyi' tentative description of the way most reasonable people understand
2022-JP, with the intention that it will be superceded later by a formal
document from the JUNET community.