Internet-Draft E. Wada
Fujitsu Laboratories
Expires in six months J. Murai
Keio University
K. Yamamoto
NAIST
November, 1997
Japanese Character Encoding for Internet Messages
<draft-yamamoto-charset-iso-2022-jp-00.txt>
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as ``work in
progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts
Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
Abstract
This memo describes the encoding used in electronic mail, NetNews,
and world wide web messages in Japanese networks. It was first
specified by and used in JUNET then described in RFC 1468. The name
of this encoding was originally known as ''JUNET code'' and is now
called ''ISO-2022-JP'' when used in the context of MIME.
In ISO-2022-JP text, both one 7-bit byte Latin script (ASCII or JIS
X 0201 Latin set) and two 7-bit bytes Kanji, Hiragana, Katakana and
some other symbols and characters (JIS X 0208) are employed.
Switching the graphic character sets is based on the extension
techniques defined in ISO 2022.
This memo eliminates some ambiguities of RFC 1468. However, it
NEVER introduces any essential changes against RFC 1468. Since the
encoding is now widely used in Japanese IP communities, backward
compatibility is most important in this revision.
This memo revises RFC 1468 on the following points:
1. It is clarified that ISO-2022-JP does NOT conform to ISO 2022.
2. The formal syntax is divided into two new yet compatible rules,
Yamamoto [Page 1]
Internet-Draft ISO-2022-JP CHARSET November 1997
namely, ISO-2022-JP decoding syntax and ISO-2022-JP encoding
syntax.
3. The bit combinations permitted in JIS X 0208 are explicitly
described in the syntax so that the invalid character positions
will be excluded in ISO-2022-JP text.
4. Recommended graphic character sets are specified. That is, ASCII
is RECOMMENDED rather than JIS X 0201 1976 Latin set. ONLY to
embed YEN SIGN and OVER LINE, JIS 0201 Latin set MAY be used.
Also, JIS X 0208 1983 (including 1990) is RECOMMENDED rather
than JIS X 0208 1978.
1. Introduction
Efforts to exchange Japanese text via electronic mail[MAIL] and
NetNews[NETNEWS] messages started in the early days of JUNET[JUNET],
consisted of networks arbitrarily connected by UUCP in Japan. There
was strong demand for exchanging ASCII[ASCII], JIS X 0201 Latin
set[JISX0201-76], and JIS X 0208 graphic character sets.
JIS X 0201 Latin set is identical to ASCII except for REVERSE
SOLIDUS (BACKSLASH) and TILDE. REVERSE SOLIDUS and TILDE are
replaced by YEN SIGN and OVER LINE, respectively. This set is
Japan's national variant of ISO 646[ISO646]. The JIS X 0208 graphic
character sets consist of Kanji, Hiragana, Katakana and some other
symbols and characters. Each character takes up two bytes.
At that time, some implementations of message transfer agents (MTA)
had 7-bit restriction in their transport connection. Moreover,
European countries used 8-bit text to convey their languages. It
was thus crucial to design a 7-bit safe format to carry Japanese
text both for robustness against such MTAs and for distinction from
European languages.
Popular encodings for Japanese graphic character sets were EUC-JP
and Shift_JIS. However, they were not chosen for a transfer form of
Japanese text because they are 8-bit. To encode ASCII, JIS X 0201,
JIS X 0208 1978[JISX0208-78] and 1983[JISX0208-83], JUNET code was
designed. It switches these four graphic character sets according
to the extension techniques defined in ISO 2022[ISO2022], which is
described later in this memo.
During JUNET days, some systems erroneously used the escape sequence
"ESC ( H" for JIS X 0201 1976 due to a typological error in the JIS
book. This escape sequence is officially registered for a Swedish
graphic character set[ISOREG] and MUST NOT have been used in JUNET
code. JUNET had difficulty in eliminating this misusage.
In 1993, the encoding was described in RFC 1468[OLDSPEC] and the
name "ISO-2022-JP" was given to identify it in the context of
MIME[MIME].
The word "encoding" is ambiguous because it is used for both the
extension techniques and for conversion of MIME's transport safe.
For this reason, "MIME-encoding" is used to identify content
Yamamoto [Page 2]
Internet-Draft ISO-2022-JP CHARSET November 1997
transfer encoding of MIME and "charset"[CHARSET] is introduced to
describe ISO-2022-JP. "ISO-2022-JP encoding" means creation of
ISO-2022-JP text by MIME composers while "ISO-2022-JP decoding"
refers to interpretation of ISO-2022-JP text by MIME viewers.
At the time of writing RFC 1468, one more revision for JIS X 0208,
namely 1990[JISX0208-90], was available. RFC 1468, however, does
NOT suggest using the revision identification sequence "ESC & @"
even if two characters added in JIS X 0208 1990 are used.
This choice was practical from the empirical point of view of JUNET
code but it was a departure from the ISO 2022 platform. Strictly
speaking, ISO-2022-JP does NOT conform to ISO 2022 though the name
is associated with ISO 2022.
The purposes of this memo are mainly to clarify ISO-2022-JP encoding
procedure and to fix a bug of ABNF[ABNF] in RFC 1468, which failed
to express null lines. To avoid confusion, no new escape sequence
for JIS X 0208 1990 nor for JIS X 0212 1990[JISX0212-90] is
introduced. Such efforts should be elaborated in other rich
charsets.
NOTE: One more revision for JIS X 0208, namely 1997, is available
[JISX0208-97]. Since it is not a new graphic character set, most
parts of this memo do NOT explicitly talk about it. Likewise, JIS X
0201 1997[JISX0201-97] does NOT appear in the main body of this
memo. For more information, see Historical Note.
2. Standard Keywords
This memo uses terms which are in capital letters. When the terms
"MUST", "SHOULD", "MUST NOT", "SHOULD NOT", "MAY", and "RECOMMENDED"
appear capitalized, they are being used to indicate particular
requirements, whose definitions are found in [KEYWORDS].
3. Description
For historical reasons, ISO-2022-JP can contain four graphic
character sets, ASCII, JIS X 0201 1976 Latin set, JIS X 0208 1978
and JIS X 0208 1983 (including 1990). A charset should start with
and should end in ASCII since many message systems assume so.
Moreover, each line should be self-composite so that lines can be
safely split. ISO-2022-JP was designed to satisfy these
requirements. Its definition is as follows:
ISO-2022-JP text MUST start with ASCII and MUST end with ASCII.
Each line of ISO-2022-JP text MUST end with ASCII or JIS X 0201 1976
(i.e. before CRLF). The next line starts in the graphic character
set that was switched to before the end of the previous line.
ISO-2022-JP is NOT completely self-composite because a starting
graphic character set of a line is not known if the previous line is
missing. This is one of the reasons to recommend ASCII, instead of
JIS X 0201 1976, in ISO-2022-JP.
Yamamoto [Page 3]
Internet-Draft ISO-2022-JP CHARSET November 1997
An escape sequence is used to specify a start boundary of a graphic
character set different form the preceding graphic character set.
The following table gives the escape sequences and the graphic
character sets used in ISO-2022-JP text. The "ISOREG" is the
registration number in ISO's registry[ISOREG].
ESC Seq Graphic Character Set ISOREG
ESC ( B ASCII 6
ESC ( J JIS X 0201 1976 (Latin set) 14
ESC $ @ JIS X 0208 1978 42
ESC $ B JIS X 0208 1983 87
For example, the escape sequence "ESC $ B" indicates that the bytes
following this escape sequence are some characters of JIS X 0208
1983. To switch back to ASCII, the escape sequence "ESC ( B" is
used.
If Japanese text represented within the four graphic character sets
is transferred by SMTP[SMTP] or NNTP[NNTP], it is STRONGLY
RECOMMENDED to be in ISO-2022-JP form.
Not all implementations distinguish JIS X 0208 1978 and 1983.
Moreover, if ISO-2022-JP text including both ASCII and JIS X 0201
1976 AND/OR ISO-2022-JP text including both JIS X 0208 1978 and JIS
X 0208 1983 is converted to EUC-JP or Shift_JIS, original
ISO-2022-JP text could not be re-produced.
So, to implement best interoperability, message composers SHOULD use
ASCII and JIS X 0208 1983 ONLY. However, message composers MAY use
JIS X 0201 1976 to embed YEN SIGN and OVER LINE. Message viewers
MUST accept all four graphic character sets. Please note that the
best strategy for interoperability is TO BE LIBERAL IN WHAT YOU
RECEIVE AND BE CONSERVATIVE IN WHAT YOU SEND.
JIS X 0201 Kana set MUST NOT be used in ISO-2022-JP text. It may
erroneously appear in ISO-2022-JP text with the following sequences:
<8-bit Kana set char>
SO <7-bit Kana set char> SI
SO <8-bit Kana set char> SI
ESC ( I <7-bit Kana set char> ESC ( B
ESC ) I <8-bit Kana set char>
JIS X 0212 1990 MUST NOT be embedded in ISO-2022-JP text. It may
erroneously appear following "ESC $ ( D" in ISO-2022-JP text. To
embed JIS X 0212 1990, other charsets such as ISO-2022-JP-2
[ISO-2022-JP-2] SHOULD be used.
IMPLEMENTATION NOTE: Even if a message composer does not provide any
input method for graphic character sets which is not used in
ISO-2022-JP, such as JIS X 0201 Kana set and JIS X 0212 1990, there
are ways to include them by accident. Typical cases are citing and
Yamamoto [Page 4]
Internet-Draft ISO-2022-JP CHARSET November 1997
forwarding a message including JIS X 0201 Kana set and/or JIS X 0212
1990 (but labeled as ISO-2022-JP).
IMPLEMENTATION NOTE ON CITATION: If JIS X 0201 Kana set is cited, it
MUST be removed anyway. One possible deletion is to convert the
characters to corresponding characters in JIS X 0208 1983. Please
note that as of this writing there doesn't exist a charset to
contain JIS X 0201 Kana set. When JIS X 0212 1990 is cited, MIME
composers MUST take one of the followings: (1) Remove all characters
in JIS X 0212 1990 and specify ISO-2022-JP for the charset
parameter. (2) Specify other richer charset such as ISO-2022-JP-2.
IMPLEMENTATION NOTE ON FORWARDING: Since this memo talks about
ISO-2022-JP text only, forwarding an entire message is outside the
scope. But MIME composers are REQUIRED to forward valid messages in
the context of MIME. Mismatch between the charset parameter and its
content body MUST be eliminated. The situation would be mixed up
when the invalid message was digitally signed. But again,
procedures to create valid messages are outside the scope of this
memo.
4. Formal Syntax
Two sets of formal syntax rules are defined in this memo. One is
ISO-2022-JP decoding syntax for message viewers and the other is
ISO-2022-JP encoding syntax for message composers. ISO-2022-JP
decoding syntax is designed to be redundant to maintain backward
compatibility with existing message composers while ISO-2022-JP
encoding syntax is designed to be necessary and sufficient. Readers
are assumed to be familiar with the notational conventions defined
in [ABNF] and [MAIL2].
4.1 Rules for decoding syntax
ISO-2022-JP decoding syntax that embeds ASCII, JIS X 0201 1976, JIS
X 0208 1978, JIS X 0208 1983 (including 1990) is defined as follows
(see also Figure 1):
iso-2022-jp-text-d = *( line-d CRLF ) line-d
; When text is terminated by CRLF, the last 'line-d' is empty.
line-d = *single-byte-char-d
*(*double-byte-segment-d single-byte-segment-d)
single-byte-segment-d = single-byte-designator-d *single-byte-char-d
single-byte-designator-d = %d27 %d40 ( %d66 / %d74 )
; ESC "(" ( "B" / "J" )
single-byte-char-d = %d0-9 / %d11-12 / %d14-26 / %d28-127
; All bit combinations of ASCII code excluding
; LF(%d10), CR(%d13), and ESC(%d27).
double-byte-segment-d = double-byte-designator-d *double-byte-char-d
Yamamoto [Page 5]
Internet-Draft ISO-2022-JP CHARSET November 1997
double-byte-designator-d = %d27 %d36 ( %d64 / %d66 )
; ESC "$" ( "@" / "B" )
double-byte-char-d = %d33-126.33-126
; All bit combinations of 94 x 94 graphic character set
NOTE: Though RFC 1468[OLDSPEC] allows bare CR and bare LF to be used
as single byte char, this memo explicitly prohibits use of those
characters as bare characters. This conforms to RFC 2045[MIME]
section 2.7. If a message viewer finds unsafe characters in
'single-byte-char-d' such as NUL(%d0), LF(%d10), CR(%13), SO(%d14),
SI(%d15), SS2(%d25), ESC(%d27), SS3(%d29), the viewer SHOULD ignore
them. If the message viewer finds invalid characters in
'double-byte-char-d', the viewer SHOULD also ignore them. For more
information, refer to 'double-byte-char-e'.
+---------------------->
| +----------> |
| +--+ | +--+ | |
+----------> | +->|1S|-> +->|1C|->->-> exit
| +--+ | | | +--+ | +--+ | |
line-d --> +->|1C|->-> | <-------+ v
| +--+ | | +----------> |
<-------+ | +--+ | +--+ | |
+->|2S|-> +->|2C|->->
| +--+ | +--+ | |
| <-------+ |
<--------------------+
Figure 1 'line-d' for decoding syntax
NOTE: 1S, 1C, 2S, and 2C stand for 'single-byte-designator-d',
'single-byte-char-d', 'double-byte-designator-d', and
'double-byte-char-d', respectively.
4.2 Rules for encoding syntax
To create ISO-2022-JP text or string, only characters in ASCII and
JIS X 0208 1983 (including 1990) SHOULD be used. But if YEN SIGN
and/or OVER LINE of JIS X 0201 1976 are to be used, the following
rules SHOULD be followed:
(1) It is RECOMMENTED to use YEN SIGN(%d33.111) and OVER
LINE(%d33.49) of JIS X 0208 1983 instead of YEN SIGN(%d92) and
OVER LINE(%d126) of JIS X 0201 1976, respectively.
(2) If sequences of JIS X 0201 1976 Latin set can be produced,
YEN SIGN and/or OVER LINE of the set MAY be used preceded by the
designator.
(3) Otherwise, YEN SIGN and OVER LINE of JIS X 0201 1976 SHOULD
be converted to REVERSE SOLIDUS and TILDE of ASCII,
respectively.
Yamamoto [Page 6]
Internet-Draft ISO-2022-JP CHARSET November 1997
IMPLEMENTATION NOTE: Display of YEN SIGN and OVER LINE of JIS X 0201
1976 is highly dependent on the receiving system. REVERSE SOLIDUS
and TILDE of ASCII may be displayed. And again, if ISO-2022-JP text
including both ASCII and JIS X 0201 1976 is converted to EUC-JP or
Shift_JIS, original ISO-2022-JP text could not be re-produced. This
would cause verification failure of digital signature.
The following is ISO-2022-JP encoding syntax to accomplish rule (1)
or (3) above (see also Figure 2)
iso-2022-jp-text-e = *( line-e CRLF ) line-e
line-e = *single-byte-char-e [*i-segment-e f-segment-e]
i-segment-e = double-byte-designator-e 1*double-byte-char-e
single-byte-designator-e 1*single-byte-char-e
f-segment-e = double-byte-designator-e 1*double-byte-char-e
single-byte-designator-e *single-byte-char-e
single-byte-designator-e = %d27 %d40 %d66
; ESC "(" "B"
single-byte-char-e = %d7-9 / %d11-12 / %d32-126
; BEL(%d7), BS(%d8), HT(%d9), VT(%d11), FF(%d12), SPC(%32), and
; all graphic characters.
double-byte-designator-e = %d27 %d36 %d66
; ESC "$" "B"
double-byte-char-e = %d33.33-126 /
%d34.(33-46 / 58-65 / 74-80 / 92-106 / 114-121 / 126) /
%d35.(48-57 / 65-90 / 97-122) /
%d36.33-115 /
%d37.33-118 /
%d38.(33-56 / 65-88) /
%d39.(33-65 / 81-113) /
%d40.33-64 /
%d48-78.33-126 /
%d79.33-83 /
%d80-115.33-126 /
%d116.33-38
; The valid bit combinations of JIS X 0208 1990.
Yamamoto [Page 7]
Internet-Draft ISO-2022-JP CHARSET November 1997
+-------------------------------------->
| +----------> |
| | +--+ | |
+----------> | | +->|1C|->->-> exit
| +--+ | | +--+ +--+ +--+ | | +--+ |
line-e --> +->|1C|->->->->|2S|->->|2C|->->|1S|-> <-------+
| +--+ | | +--+ | +--+ | +--+ | +--+
<-------+ | <-------+ +-->->|1C|->->
| | +--+ | |
| <-------+ |
<------------------------------------+
Figure 2 'line-e' for encoding syntax
NOTE: 1S, 1C, 2S, and 2C stand for 'single-byte-designator-e',
'single-byte-char-e', 'double-byte-designator-e', and
'double-byte-char-e', respectively.
5. MIME Considerations
This section discusses how to use ISO-2022-JP text or string
(i.e. excluding CRLF) in the context of MIME. The scope is limited
to the case where messages are transferred by SMTP[SMTP] or
NNTP[NNTP]. Other protocols are outside the scope of this memo.
5.1 The Charset Parameter
To identify the charset described in this memo, "ISO-2022-JP" MUST
be used for the charset parameter wherever it is allowed. Please
note that the charset parameter is case-insensitive.
For the charset parameter, MIME composers SHOULD choose as small
charset as possible. For example, if a content body is ASCII,
US-ASCII SHOULD be specified instead of ISO-2022-JP. This rule
improves interoperability with other MIME viewers which do not
support various charsets.
To the contrary, MIME viewers SHOULD be able to handle text labeled
ISO-2022-JP even if its content is ASCII only. Remember to "be
liberal in what you receive and be conservative in what you send".
5.2 Content Transfer Encoding
ISO-2022-JP text is already in 7-bit form and MIME-encoding, such as
Base64 and Quoted-Printable, makes ISO-2022-JP text unreadable for
non-MIME viewers. For this reason, MIME composers SHOULD choose
"7bit" (case-insensitive) and SHOULD NOT MIME-encode ISO-2022-JP
text with Base64 nor Quoted-Printable.
Note that "7bit" means that no MIME-encoding is applied and its
syntax is in 7-bit form. MIME defines that "7bit" MIME-encoding is
assumed if content transfer encoding is not present. So, this field
Yamamoto [Page 8]
Internet-Draft ISO-2022-JP CHARSET November 1997
can be omitted.
In certain situation, Base64 or Quoted-Printable MAY be used.
Base64 is RECOMMENDED to MIME-encode ISO-2022-JP text rather than
Quoted-Printable. This is because Base64 encoding is considered
more suitable for ISO-2022-JP text than Quoted-Printable encoding
for the following reasons: (1) Quoted-Printable encoding is designed
for text which is mostly ASCII but ISO-2022-JP text is NOT. (2)
Quoted-Printable encoding produces various results while Base64
encoding creates a unique output if folding is ignored. This means
that it is easier to implement interoperability for Base64 encoding
than for Quoted-Printable encoding.
IMPLEMENTATION NOTE: The keyword "=" of Quoted-Printable encoding is
used in JIS X 0208 (see 'double-byte-char-e'). If only the ASCII
portion of ISO-2022-JP text is MIME-encoded with Quoted-Printable,
it is likely that such text cannot be MIME-decoded to the original
since the "=" characters in JIS X 0208 portion are considered to be
the keyword of Quoted-Printable. If ISO-2022-JP text needs to be
MIME-encoded with Quoted-Printable, the entire text must be
MIME-encoded. Some old implementations made this mistake.
MIME viewers MUST be able to handle ISO-2022-JP text even if it is
encoded with Base64 or Quoted-Printable. Also, MIME viewers SHOULD
be able to handle ISO-2022-JP text even if its MIME-encoding is
specified as "8bit".
5.3 Header Extensions
In a header or in MIME content headers where `encoded-word's are
allowed, Japanese string (i.e. excluding CRLF) which consists of the
four graphic character sets MUST be in the form defined in RFC
2047[MIME]. For "charset", "ISO-2022-JP" (case-insensitive) SHOULD
be specified. ISO-2022-JP string MUST end with ASCII (see 'line-e').
Message composers SHOULD use "B" encoding for ISO-2022-JP string,
however, message viewers MUST be able to handle both "B" and "Q"
encoding.
IMPLEMENTATION NOTE: It should be noted that these requirements
above apply to any fields in MIME content headers. For example, RFC
2047 mechanism MUST be used to represent ISO-2022-JP string when
embedded in Content-Description: content header in a part of a
multipart.
ISO-2022-JP string MUST NOT be embedded directly in a header nor in
MIME content headers. EUC-JP string and Shift_JIS string SHOULD NOT
be inserted even if they are in the form defined in RFC 2047.
The reason why ISO-2022-JP string and "B" encoding is recommended to
embed Japanese string in header fields is that RFC 1468 defines so.
For historical reasons, not many message viewers support EUC-JP,
Shift_JIS, and "Q" encoding,
Yamamoto [Page 9]
Internet-Draft ISO-2022-JP CHARSET November 1997
5.4 MIME Parameter Extensions
With RFC 2184[PARAMETER] extensions, charsets other than US-ASCII
can be embedded in values of MIME parameters. As of this writing,
the Japanese community does NOT have enough experience for RFC 2184
extensions. Thus, this memo does NOT define any requirements to
embed Japanese string in the MIME parameters. However, Japanese
string MUST NOT be directly embedded in MIME parameters
6. Requirements for Message Transfer Agents (MTA)
Several MTAs automatically convert any message to a local charset.
This means that it is very likely that a charset other than
ISO-2022-JP is converted to the local charset by a routine which
assumes that incoming data is ISO-2022-JP text. MTAs SHOULD NOT
convert charsets in general. If MTAs need to convert charsets, they
MUST do so according to the charset parameter of MIME messages.
Actually, some MTAs convert "ESC ( B" into "ESC ( J" and "ESC $ B"
into "ESC $ @" interchangeably. Gateways SHOULD NOT convert in this
way. Such MTAs are the primary cause of verification failure in
digital signature.
7. Historical Note
The JUNET code was originally described in the JUNET User's Guide
[JUNET].
JIS X 0208, which was originally called JIS C 6226, was published in
1978. It was revised in 1983, 1990 and 1997.
The revision in 1983 was made because the Japanese Government
published the new Kanji graphic character set called "Joyo Kanji Hyo
(Kanji List for Daily Use)" for use in daily life, in the public
documents, in newspapers in 1981. Some of the character shapes were
modified or simplified. To harmonize JIS X 0208 1978 with Joyo
Kanji, pairs of characters were swapped in the code positions and
several characters had their shapes amended. Moreover, since new
characters were added to the Kanji set called "Jinmei You Kanji
Beppyo (Additional Kanji List for Use with People's Name)", four
characters were added to and a lot of special characters were
included in JIS X 0208 1983. This graphic character set was treated
as a new one and a new escape sequence "ESC $ B" was assigned.
Since the Kanji set for People's names was extended, two more Kanji
characters were added at the end of JIS X 0208 in 1990 and the
result is called JIS X 0208 1990. The revised graphic character set
is indeed backward compatible with the previous set. Leaving the
designation sequence unchanged, only the revision identification
sequence "ESC & @" was assigned.
To be strict, the designation sequence of JIS X 0208 1990 is "ESC &
@ ESC $ B". However, ISO-2022-JP encoding uses "ESC $ B" for
practical reasons even though the two additional Kanji characters
Yamamoto [Page 10]
Internet-Draft ISO-2022-JP CHARSET November 1997
are used.
The purpose of revision in 1997 is to clarify references of each
character. No new characters were introduced. As a graphic
character set, JIS X 0208 1997 is equivalent to JIS X 0208 1990.
The designation sequence is the same.
Therefore, among versions of JIS X 0208, the version of 1978 is of a
different graphic character set while the versions of 1983, 1990 and
1997 are regarded as a family.
JIS X 0201, originally called JIS C 6220, was published in 1976. It
was revised in 1997 but no change was introduced. They are thus the
same graphic character set.
8. Security Considerations
ISO-2022-JP is NOT believed to introduce any new security holes to
the Internet.
References
[ABNF] D. Crocker and Paul Overell, "Augmented BNF for Syntax
Specifications: ABNF", Internet-Draft,
draft-ietf-drums-abnf-05.txt, 1997.
[ASCII] American National Standards Institute, "Coded character set
-- 7-bit American national standard code for information
interchange", ANSI X3.4-1986.
[CHARSET] N. Freed and J. Postel, "IANA Charset Registration
Procedures", Internet-Draft, draft-freed-charset-reg-04.txt,
September 1997.
[ISO-2022-JP-2] M. Ohta and K. Handa, "ISO-2022-JP-2: Multilingual
Extension of ISO-2022-JP", RFC 1554, December 1993.
[ISO2022] International Organization for Standardization (ISO),
"Information technology -- Character code structure and
extension techniques", International Standard, Ref. No. ISO
2022-1991(E).
[ISO646] International Organization for Standardization (ISO),
"Information technology -- ISO 7-bit coded character set for
information interchange", International Standard,
Ref. No. ISO/IEC 646:1991(E).
[ISOREG] International Organization for Standardization (ISO),
"International Register of Coded Character Sets To Be Used With
Escape Sequences".
[JISX0201-76] Japanese Industrial Standards Committee, "Code for
information interchange", JIS C 6220 1976(aka JIS X 0201 1976).
Yamamoto [Page 11]
Internet-Draft ISO-2022-JP CHARSET November 1997
[JISX0201-97] Japanese Industrial Standards Committee, "7-bit and
8-bit coded character sets for information interchange", JIS X
0201 1997.
[JISX0208-78] Japanese Industrial Standards Committee, "Code of the
Japanese graphic character set for information interchange", JIS
C 6226 1978(aka JIS X 0208 1978).
[JISX0208-83] Japanese Industrial Standards Committee, "Code of the
Japanese graphic character set for information interchange", JIS
C 6226 1983(aka JIS X 0208 1983).
[JISX0208-90] Japanese Industrial Standards Committee, "Code of the
Japanese graphic character set for information interchange", JIS
X 0208 1990.
[JISX0208-97] Japanese Industrial Standards Committee, "7-bit and
8-bit double byte coded KANJI sets for information interchange",
JIS X 0208 1997
[JISX0212-90] Japanese Industrial Standards Committee, "Code of the
supplementary Japanese graphic character set for information
interchange", JIS X0212 1990.
[JUNET] JUNET Riyou No Tebiki Sakusei Iin Kai (JUNET User's Guide
Drafting Committee), "JUNET Riyou No Tebiki (Dai Ippan)" ("JUNET
User's Guide (First Edition)"), February 1988.
[KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[MAIL] D. Crocker, "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, August 1982.
[MAIL2] P. Resnick, "Message Format Standard",
draft-ietf-drums-msg-fmt-02.txt, June 1997.
[MIME] The primary definition of MIME. "MIME Part 1: Format of
Internet Message Bodies", RFC 2045; "MIME Part 2: Media Types",
RFC 2046; "MIME Part 3: Message Header Extensions for Non-ASCII
Text", RFC 2047; "MIME Part 4: Registration Procedures", RFC
2048; "MIME Part 5: Conformance Criteria and Examples", RFC 2049;
November 1996.
[NETNEWS] M. Horton and R. Adams, "Standard for Interchange of
USENET Messages", RFC 1036, December 1987.
[NNTP] B. Kantor and P. Lapsley, "Network News Transfer Protocol",
RFC 977, February 1986.
[OLDSPEC] J. Murai, M. Crispin, and E. van der Poel, "Japanese
Character Encoding for Internet Messages", RFC 1468, June 1993.
[PARAMETER] N. Freed and K. Moore, "MIME Parameter Value and Encoded
Yamamoto [Page 12]
Internet-Draft ISO-2022-JP CHARSET November 1997
Word Extensions: Character Sets, Languages, and Continuations",
RFC 2184, August 1997.
[SMTP] J. Postel, "Simple Mail Transfer Protocol", RFC 821, August
1982.
Acknowledgements
Many people contributed to RFC 1468. The original authors of RFC
1468 wished to thank in particular Akira Kato, Masahiro Sekiguchi
and Ken'ichi Handa.
The authors of this memo would acknowledge the original work of Erik
M. van der Poel and Mark Crispin. Our deep gratitude goes to
Noritoshi Demizu, Kenichi Handa, Jun'ichiro Ito, Shuhei Kobayashi,
Tomohiko Morioka, Erik M. van der Poel, Shigeya Suzuki, and Akira
Tanaka (in alphabetical order) for their contribution to this memo.
Authors' Addresses
Eiiti WADA
Fujitsu Laboratories, Ltd
4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki 211-88 JAPAN
Phone: +81-44-754-2608
FAX: +81-44-754-2580
EMail: wada@u-tokyo.ac.jp
Jun MURAI
Keio University
5322 Endo, Fujisawa 252 JAPAN
Phone: +81-466-47-5111
FAX: +81-466-49-1101
EMail: jun@wide.ad.jp
Kazuhiko YAMAMOTO
Graduate School of Information Science
Nara Institute of Science and Technology(NAIST)
8916-5 Takayama, Ikoma 630-01 JAPAN
Phone: +81-743-72-5111
FAX: +81-743-72-5329
EMail: Kazu@Mew.org
Yamamoto [Page 13]
Internet-Draft ISO-2022-JP CHARSET November 1997
Appendix
An example of a MIME text object is as follows:
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
ISO-2022-JP text comes here.
Another form of the example above is as follows:
Content-Type: Text/Plain; Charset=ISO-2022-JP
ISO-2022-JP text comes here.
The following is an example of RFC 2047 header encoding
To: june@wide.ad.jp
Subject: =?iso-2022-jp?B?GyRCJDMkTkZ8S1w4bCQsRkkkYSRsJFAbKEI=?=
OK
=?iso-2022-jp?B?GyRCJEckOSEjGyhC?=
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)
<Kazu@Mew.org>
Yamamoto [Page 14]