doc: Add RFC documents

1 files changed, 339 insertions, 0 deletions

diff --git a/doc/rfc/rfc1468.txt b/doc/rfc/rfc1468.txt
new file mode 100644
index 0000000..e8cb5b8
--- /dev/null
+++ b/doc/rfc/rfc1468.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                           J. Murai
+Request for Comments: 1468                               Keio University
+                                                              M. Crispin
+                                                       Panda Programming
+                                                         E. van der Poel
+                                                               June 1993
+
+
+           Japanese Character Encoding for Internet Messages
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard.  Distribution of this memo is
+   unlimited.
+
+Introduction
+
+   This document describes the encoding used in electronic mail [RFC822]
+   and network news [RFC1036] messages in several Japanese networks. It
+   was first specified by and used in JUNET [JUNET]. The encoding is now
+   also widely used in Japanese IP communities.
+
+   The name given to this encoding is "ISO-2022-JP", which is intended
+   to be used in the "charset" parameter field of MIME headers (see
+   [MIME1] and [MIME2]).
+
+Description
+
+   The text starts in ASCII [ASCII], and switches to Japanese characters
+   through an escape sequence. For example, the escape sequence ESC $ B
+   (three bytes, hexadecimal values: 1B 24 42) indicates that the bytes
+   following this escape sequence are Japanese characters, which are
+   encoded in two bytes each.  To switch back to ASCII, the escape
+   sequence ESC ( B is used.
+
+   The following table gives the escape sequences and the character sets
+   used in ISO-2022-JP messages. The ISOREG number is the registration
+   number in ISO's registry [ISOREG].
+
+       Esc Seq    Character Set                  ISOREG
+
+       ESC ( B    ASCII                             6
+       ESC ( J    JIS X 0201-1976 ("Roman" set)    14
+       ESC $ @    JIS X 0208-1978                  42
+       ESC $ B    JIS X 0208-1983                  87
+
+   Note that JIS X 0208 was called JIS C 6226 until the name was changed
+
+
+
+Murai, Crispin & van der Poel                                   [Page 1]
+
+RFC 1468   Japanese Character Encoding for Internet Messages   June 1993
+
+
+   on March 1st, 1987. Likewise, JIS C 6220 was renamed JIS X 0201.
+
+   The "Roman" character set of JIS X 0201 [JISX0201] is identical to
+   ASCII except for backslash () and tilde (~). The backslash is
+   replaced by the Yen sign, and the tilde is replaced by overline. This
+   set is Japan's national variant of ISO 646 [ISO646].
+
+   The JIS X 0208 [JISX0208] character sets consist of Kanji, Hiragana,
+   Katakana and some other symbols and characters. Each character takes
+   up two bytes.
+
+   For further details about the JIS Japanese national character set
+   standards, refer to [JISX0201] and [JISX0208].  For further
+   information about the escape sequences, see [ISO2022] and [ISOREG].
+
+   If there are JIS X 0208 characters on a line, there must be a switch
+   to ASCII or to the "Roman" set of JIS X 0201 before the end of the
+   line (i.e., before the CRLF). This means that the next line starts in
+   the character set that was switched to before the end of the previous
+   line.
+
+   Also, the text must end in ASCII.
+
+   Other restrictions are given in the Formal Syntax below.
+
+Formal Syntax
+
+   The notational conventions used here are identical to those used in
+   RFC 822 [RFC822].
+
+   The * (asterisk) convention is as follows:
+
+       l*m something
+
+   meaning at least l and at most m somethings, with l and m taking
+   default values of 0 and infinity, respectively.
+
+
+   message             = headers 1*( CRLF *single-byte-char *segment
+                         single-byte-seq *single-byte-char )
+                                           ; see also [MIME1] "body-part"
+                                           ; note: must end in ASCII
+
+   headers             = <see [RFC822] "fields" and [MIME1] "body-part">
+
+   segment             = single-byte-segment / double-byte-segment
+
+   single-byte-segment = single-byte-seq 1*single-byte-char
+
+
+
+Murai, Crispin & van der Poel                                   [Page 2]
+
+RFC 1468   Japanese Character Encoding for Internet Messages   June 1993
+
+
+   double-byte-segment = double-byte-seq 1*( one-of-94 one-of-94 )
+
+   single-byte-seq     = ESC "(" ( "B" / "J" )
+
+   double-byte-seq     = ESC "$" ( "@" / "B" )
+
+   CRLF                = CR LF
+
+                                                    ; ( Octal, Decimal.)
+
+   ESC                 = <ISO 2022 ESC, escape>     ; (    33,      27.)
+
+   SI                  = <ISO 2022 SI, shift-in>    ; (    17,      15.)
+
+   SO                  = <ISO 2022 SO, shift-out>   ; (    16,      14.)
+
+   CR                  = <ASCII CR, carriage return>; (    15,      13.)
+
+   LF                  = <ASCII LF, linefeed>       ; (    12,      10.)
+
+   one-of-94           = <any one of 94 values>     ; (41-176, 33.-126.)
+
+   7BIT                = <any 7-bit value>          ; ( 0-177,  0.-127.)
+
+   single-byte-char    = <any 7BIT, including bare CR & bare LF, but NOT
+                          including CRLF, and not including ESC, SI, SO>
+
+MIME Considerations
+
+   The name given to the JUNET character encoding is "ISO-2022-JP". This
+   name is intended to be used in MIME messages as follows:
+
+       Content-Type: text/plain; charset=iso-2022-jp
+
+   The ISO-2022-JP encoding is already in 7-bit form, so it is not
+   necessary to use a Content-Transfer-Encoding header. It should be
+   noted that applying the Base64 or Quoted-Printable encoding will
+   render the message unreadable in current JUNET software.
+
+   ISO-2022-JP may also be used in MIME Part 2 headers.  The "B"
+   encoding should be used with ISO-2022-JP text.
+
+Background Information
+
+   The JUNET encoding was described in the JUNET User's Guide [JUNET]
+   (JUNET Riyou No Tebiki Dai Ippan).
+
+   The encoding is based on the particular usage of ISO 2022 announced
+
+
+
+Murai, Crispin & van der Poel                                   [Page 3]
+
+RFC 1468   Japanese Character Encoding for Internet Messages   June 1993
+
+
+   by 4/1 (see [ISO2022] for details). However, the escape sequence
+   normally used for this announcement is not included in ISO-2022-JP
+   messages.
+
+   The Kana set of JIS X 0201 is not used in ISO-2022-JP messages.
+
+   In the past, some systems erroneously used the escape sequence ESC (
+   H in JUNET messages. This escape sequence is officially registered
+   for a Swedish character set [ISOREG], and should not be used in ISO-
+   2022-JP messages.
+
+   Some systems do not distinguish between ESC ( B and ESC ( J or
+   between ESC $ @ and ESC $ B for display. However, when relaying a
+   message to another system, the escape sequences must not be altered
+   in any way.
+
+   The human user (not implementor) should try to keep lines within 80
+   display columns, or, preferably, within 75 (or so) columns, to allow
+   insertion of ">" at the beginning of each line in excerpts. Each JIS
+   X 0208 character takes up two columns, and the escape sequences do
+   not take up any columns. The implementor is reminded that JIS X 0208
+   characters take up two bytes and should not be split in the middle to
+   break lines for displaying, etc.
+
+   The JIS X 0208 standard was revised in 1990, to add two characters at
+   the end of the table. Although ISO 2022 specifies special additional
+   escape sequences to indicate the use of revised character sets, it is
+   suggested here not to make use of this special escape sequence in
+   ISO-2022-JP text, even if the two characters added to JIS X 0208 in
+   1990 are used.
+
+   For further information about Japanese character encodings such as PC
+   codes, FTP locations of implementations, etc, see "Electronic
+   Handling of Japanese Text" [JPN.INF].
+
+References
+
+   [ASCII] American National Standards Institute, "Coded character set
+   -- 7-bit American national standard code for information
+   interchange", ANSI X3.4-1986.
+
+   [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.
+
+   [ISO2022] International Organization for Standardization (ISO),
+   "Information processing -- ISO 7-bit and 8-bit coded character sets
+
+
+
+Murai, Crispin & van der Poel                                   [Page 4]
+
+RFC 1468   Japanese Character Encoding for Internet Messages   June 1993
+
+
+   -- Code extension techniques", International Standard, Ref. No. ISO
+   2022-1986 (E).
+
+   [ISOREG] International Organization for Standardization (ISO),
+   "International Register of Coded Character Sets To Be Used With
+   Escape Sequences".
+
+   [JISX0201] Japanese Standards Association, "Code for Information
+   Interchange", JIS X 0201-1976.
+
+   [JISX0208] Japanese Standards Association, "Code of the Japanese
+   graphic character set for information interchange", JIS X 0208-1978,
+   -1983 and -1990.
+
+   [JPN.INF] Ken R. Lunde <lunde@adobe.com>, "Electronic Handling of
+   Japanese Text", March 1992,
+   msi.umn.edu(128.101.24.1):pub/lunde/japan[123].inf
+
+   [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.
+
+   [MIME1] Borenstein N., and N. Freed, "MIME (Multipurpose
+   Internet Mail Extensions): Mechanisms for Specifying and
+   Describing the Format of Internet Message Bodies", RFC 1341,
+   Bellcore, Innosoft, June 1992.
+
+   [MIME2] Moore, K., "Representation of Non-ASCII Text in Internet
+   Message Headers", RFC 1342, University of Tennessee, June 1992.
+
+   [RFC822] Crocker, D., "Standard for the Format of ARPA Internet
+   Text Messages", STD 11, RFC 822, UDEL, August 1982.
+
+   [RFC1036] Horton M., and R. Adams, "Standard for Interchange of USENET
+   Messages", RFC 1036, AT&T Bell Laboratories, Center for Seismic
+   Studies, December 1987.
+
+Acknowledgements
+
+   Many people assisted in drafting this document. The authors wish to
+   thank in particular Akira Kato, Masahiro Sekiguchi and Ken'ichi
+   Handa.
+
+Security Considerations
+
+   Security issues are not discussed in this memo.
+
+
+
+
+
+Murai, Crispin & van der Poel                                   [Page 5]
+
+RFC 1468   Japanese Character Encoding for Internet Messages   June 1993
+
+
+Authors' Addresses
+
+   Jun Murai
+   Keio University
+   5322 Endo, Fujisawa
+   Kanagawa 252 Japan
+
+   Fax: +81 466 49 1101
+   EMail: jun@wide.ad.jp
+
+
+   Mark Crispin
+   Panda Programming
+   6158 Lariat Loop NE
+   Bainbridge Island, WA 98110-2098
+   USA
+
+   Phone: +1 206 842 2385
+   EMail: MRC@PANDA.COM
+
+
+   Erik M. van der Poel
+   A-105 Park Avenue
+   4-4-10 Ohta, Kisarazu
+   Chiba 292 Japan
+
+   Phone: +81 438 22 5836
+   Fax:   +81 438 22 5837
+   EMail: erik@poel.juice.or.jp
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Murai, Crispin & van der Poel                                   [Page 6]
+
\ No newline at end of file