Re: Don't change RFC822 for the worse!

[Masataka Ohta <mohta@xxxxxxxxxxxxxxxxxxxxxxxx>]

> > 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