Masataka Ohta <mohta(_at_)necom830(_dot_)cc(_dot_)titech(_dot_)ac(_dot_)jp>
writes:
ISO-2022-JP as is without any encoding is ACTUALLY WORKING NOW completely
well for unstructured message headers. So is ISO-2022-INT-*.
It's "actually working now" in Japan only.
That's pointless. The point is ISO-2022-INT-* works without modifying
any transport.
Anyway, you are wrong even in your wrong way of reasoning.
7bit ISO 2022 based encoding without assuming any non-ASCII designation
are working in Japan, in Korea, in Taiwan....
ISO-2022-JP encoding is used worldwide outside Japan with fj.* newsgroup
hierarchy.
In Japan, there are 8bit encoding systems such as EUC-UJIS or Shited JIS.
They are known to be incapable to interoperate with other encoding systems.
In Europe, iso-8859-1 is
"working completely well" in message headers. In Russia, koi8-r is
"working completely well" in message headers.
They are known to be incapable to interoperate with other encoding systems.
The problem is in assuming some non-ASCII designation.
Each of these approaches only works within its particular enclave.
Except for ISO-2022-JP, ISO-2022-KR, ISO-2022-JP2 and ISO-2022-INT-*.
None of these work outside their enclave, in a global Internet.
So, ISO-2022-JP was designed based on long experience on various
actual encoding systems including 8 bit ones.
These various enclaves are going to be no less resistant to switching
to anything else (Such as ISO 2022) as they are to switching to
1522. It is, however, necessary for them to switch to something in
order to interoperate in a global context.
Switching by charset is a lot worse than switching by escape sequences
in all respects.
The only thing I can think of to ease the pain of 1522 is to add an
"8" encoding.
8bit encoding makes encoding a little shorter but ease nothing.
widely on all Internet-connected computers. Conversion to local
encoding is necessary anyway.
Then what's the big deal with about decoding MIME 1522-words?
Do you think there is some big deal with about decoding MIME 1522-words?
There is none.
Why do
you instead expect every one else on the planet to switch to using
ISO-2022
No, I don't. ISO-8859-1 and KOI8-R are both ISO 2022.
Thus, using ISO-2022-INT-* does not add anything about the complexity
of local decoding.
As I've mentioned in private communication, ISO-2022-INT-* is a very
complex thing to parse.
You mentioned your finite state machine generator can't handle the
very simple grammer of ISO-2022-INT-*. That's your problem.
The published formal grammar for it isn't
even context free.
No, it properly isn't linear bounded, it properly isn't even context
free. It is simply finite state.
Masataka Ohta