From: kyuho(_at_)cosmos(_dot_)kaist(_dot_)ac(_dot_)kr (Kyuho Kim)
To: internet-drafts(_at_)nri(_dot_)reston(_dot_)va(_dot_)us,
iso2022(_at_)sran8(_dot_)sra(_dot_)co(_dot_)jp
Subject: Re: IETF-822 Extensions draft
Date: Tue, 21 Jan 92 15:36:47 KST
Thank you for everybody who commented to my message.
I read the specification , though I was late. :-)
I havn't a member of IETF discussion, so if I miss something, please
let me know.
My impression is that you promote common style of ISO-2022 encoding method
prohibiting the use of locking shifts(SI/SO/LS1/LS2). I agree with you.
Then why don't you adopt the mechanism like Compound Text which is more
strict form of ISO-2022 to avoid the confusion like this. It's for information
exchange and clean definition. It doesn't allow locking shifts as far as I know.
You may devise a mechanism like CT(7-bits version of CT) and register the
charset(or encoding methods)
as something like "ISO-2022-MIME". You may explicitly list the codesets
which is registered with IANA.
In summary, IETF needs to generalize ISO-2022 encoding methods
from ISO-2022-jp. Refer the following paragraph.
[on page 64]
Appendix F -- ISO-2022-jp
This appendix briefly describes the existing practice for
the use of ISO-2022 in Japanese electronic mail. This
description is for informational purposes only, and is not
intended to guide an implementation of ISO-2022-jp mail
senders or readers.
...
Degination sequences ESC 2/8 4/2, ESC 2/8 4/10, ESC 2/4 4/0 and
ESC 2/4 4/2 are allowed. No other designation sequences are allowed
As the paragraph says, ISO-2022-jp allows only ASCII and Japanese JIS
character sets. The implication is that there neee to be "ISO-2022-kr"
which allows Korean KS character sets. That's what you want to avoid.
7.1.1 The charset parameter
An initial list of predefined character set names can be
found at the end of this section. Additional *character sets*
may be registered with IANA, although the standardization of
their use requires the usual IAB review and approval.
I need more clarification. What's meant by *character sets*?
Does it mean the encoding methods like ISO-2022-jp style encoding?
or code sets like JIS0208 or KSC5601?
If it means the former(encoding method), I propose to devise "ISO-2022-MIME".
The defined charset values are:
...
ISO-2022-jp -- ISO-2022, as defined in [ISO-2022]
specifies ways of designating and accessing
character sets, rather than, itself, being a
character set. Its use in mail will probably
be strongly desired by communities who are
already using it locally to handle multiple
sets of characters and multi-byte characters.
It appears necessary to explicitly specify
the ISO-2022 methods that will be permitted
in text mail so as to avoid the need for
private agreements about, e.g., the specific
character sets being used in messages. A
specification corresponding to the existing
practice of ISO-2022 use in Japan is included
as Appendix F.
I propose to update document as follows:
ISO-2022-MIME -- ISO-2022, as defined in [ISO-2022]
specifies ways of designating and accessing
character sets, rather than, ...
-- Kyuho