ietf-822
[Top] [All Lists]

Re: Don't change RFC822 for the worse!

1994-12-12 04:12:18
So, don't try to pretend that MIME has solved the I18N issue and
let ISO-2022-INT-* address the untouched issue.

OK.  But when sending mail outside the subworld in which you can expect
ISO-2022-JP* to work, please continue to tag the message with a MIME
header so that readers can guess what's inside.

No. I don't need MIME header when sending the Korean sub-world
with ISO-2022-KR, either.

ISO-2022-INT-1 glues Japanese and Korean, and other sub-worlds
together, which will finally covers the world, while MIME charset
mechanism only distinguishes sub-worlds.

please continue to tag the message with a MIME
header so that readers can guess what's inside.

Impossible. I can't continue what I'm not doing.

And even if the other
IETF group ever reconciles ISO-2022-INT-* to the rest of the texts in
the Internet, it would still be appropriate to tag MIME messages to say
ISO-2022-whatever.  The cost is low.

Yes, MIME messages may, though not necessary.

I don't believe that it's necessary that an ISO-2022-JP* enclave has to
start using those tags internally, though it probably wouldn't hurt to
begin using them as convenient, and it would prevent oddities from
slipping out through unexpected gateways.  And when/if the entire world
uses ISO-2022-INT* kinds of encodings, MIME tags will still be useful
for designating the exceptions.

Can you show the examples of the exceptions?

As ASCII based exceptions are almost automatically compatible with
ISO-2022-INT-*, that is, mechanically distinguishable even if they
are mixed, I don't think there is real need for charset.

Are you suggesting EBCDIC or non-ASCII 646?

                                                Masataka Ohta