home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_n_r / draft-rfced-info-tamaru-01.txt < prev    next >
Text File  |  1997-10-08  |  10KB  |  263 lines
  1.  
  2. INTERNET DRAFT               EXPIRES APR 1998            INTERNET DRAFT
  3. Network Working Group                              MicrosoftCorporation
  4. Internet Draft                                                 K.Tamaru
  5.  
  6.  
  7.               Japanese Character Encoding for Internet Messages
  8.             <draft-rfced-info-tamaru-01.txt>
  9.  
  10.  
  11.  
  12.  
  13.  
  14. Status of This Memo
  15.  
  16.     This document is an Internet-Draft.  Internet-Drafts are working
  17.     documents of the Internet Engineering Task Force (IETF), its
  18.     areas, and its working groups.  Note that other groups may also
  19.     distribute working documents as Internet-Drafts.
  20.  
  21.     Internet-Drafts are draft documents valid for a maximum of six
  22.     months and may be updated, replaced, or obsoleted by other
  23.     documents at any time.  It is inappropriate to use Internet-
  24.     Drafts as reference material or to cite them other than as
  25.     ``work in progress.''
  26.  
  27.     To learn the current status of any Internet-Draft, please check
  28.     the ``1id-abstracts.txt'' listing contained in the Internet-
  29.     Drafts Shadow Directories on ftp.is.co.za (Africa),
  30.     nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
  31.     ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
  32.     Distribution of this document is unlimited.
  33.  
  34. 1. Abstract
  35.  
  36.     This memo defines an encoding scheme for the Japanese Characters,
  37.     describes "ISO-2022-JP-1", which is used in electronic mail
  38.     [RFC-822], and network news [RFC 1036]. Also this memo provides a
  39.     listing of the Japanese Character Set that can be used in this
  40.     encoding scheme.
  41.  
  42. 2. Requirements Notation
  43.  
  44.     This document uses terms that appear in capital letters to
  45.     indicate particular requirements of this specification. Those terms
  46.     are "MUST", "SHOULD", "MUST NOT", "SHOULD NOT", and "MAY". The
  47.     meaning of each term are found in [RFC-2119]
  48.  
  49. 3. Introduction
  50.  
  51.     RFC 1468 defines the way Japanese Characters are encoded, likewise
  52.     what this memo defines. It defines the use of JIS X 0208 as the
  53.     double-byte character set in ISO-2022-JP text.
  54.  
  55.     Today, many operating systems support proprietary extended Japanese =
  56.  
  57.     characters or JIS X 0212, This includes the Unicode character set,
  58.     which does not conform to JIS X 0201 nor JIS X 0208. Therefore,
  59.     this limits the ability to communicate and correspond precise
  60.     information because of the limited availability of Kanji
  61.     characters. Fortunately JIS(Japanese Industry Standard) defines
  62.     JIS X 0212 as "code of the supplementary Japanese graphic character
  63.     set for information interchange". Most Japanese characters which
  64.     are used in regular electronic mail in most cases can be
  65.     accommodated in JIS X 0201, JIS X 0208 and JIS X 0212.
  66.  
  67.     Also it is recognized that there is a tendency to use Unicode,
  68.     however, Unicode is not yet widely used and there is a certain
  69.     limitation with old electronic mail system. Furthermore, the
  70.     purpose of this comment is to add the capability of writing out
  71.     JIS X 0212.
  72.  
  73.     This comment does not describe any representation of iso-2022-jp-1
  74.     version information in addition to JIS X 0212 support.
  75.  
  76. 4. Description
  77.  
  78.     In "ISO-2022-JP-1" text, the initial character code of the message
  79.     is in ASCII. The "double-byte-seq"(see "Format Syntax" section)
  80.     (ESC "$" "B" / ESC "$" "@" / ESC "$" "(" "D") is the only
  81.     designator that indicates that the following character is
  82.     double-byte, and it is valid until another escape sequence appears.
  83.     It is very discouraged to use (ESC "$" "@") for double byte
  84.     character encoding, new implementation SHOULD use only
  85.     (ESC "$" "B") for double byte encoding instead.
  86.  
  87.     The end of "ISO-2022-JP-1" text MUST be in ASCII. Also it is
  88.     strongly recommended to back up to the ASCII at the end of each
  89.     line rather than JIS X 0201-Roman if there is any none ASCII
  90.     character in middle of a line.
  91.  
  92.     Since "ISO-2022-JP-1" is designed to add the capability of writing
  93.     out JIS X 0212, if the message does not contain none of JIS X 0212
  94.     characters. "ISO-2022-JP" text MUST BE used.
  95.  
  96.     JIS X 0201-Roman is not identical to the ASCII with two different
  97.     characters.
  98.  
  99.     The following list are the escape sequences and character sets
  100.     that can be used in "ISO-2022-JP-1" text. The registered number in
  101.     the ISO 2375 Register which allow double-byte ideographic scripts
  102.     to be encoded within ISO/IEC 2022 code structure is indicated as
  103.     reg# below.
  104.  
  105.     reg# character set     ESC sequence                  designated to
  106.     6    ASCII             ESC 2/8 4/2                   ESC ( B    G0
  107.     42   JIS X 0208-1978   ESC 2/4 4/0                   ESC $ @    G0
  108.     87   JIS X 0208-1983   ESC 2/4 4/2                   ESC $ B    G0
  109.     14   JIS X 0201-Roman  ESC 2/8 4/10                  ESC ( J    G0
  110.     159  JIS X 0212-1990   ESC 2/4 2/8 4/4               ESC $ ( D  G0
  111.  
  112.     Other restrictions are given in the Formal Syntax below.
  113.  
  114. 5. Formal Syntax
  115.  
  116.     The notational conventions used here are identical to those used in
  117.     STD 11, RFC 822 [RFC822].
  118.  
  119.     The * (asterisk) convention is as follows:
  120.            l*m something
  121.     meaning at least l and at most m something, with l and m taking
  122.     default values of 0 and infinity, respectively.
  123.  
  124.     iso-2022-jp-1-text  =3D *( line CRLF ) [line]
  125.  
  126.     line                =3D (*single-byte-char *segment
  127.                          single-byte-seq *single-byte-char) /
  128.                          *single-byte-char
  129.  
  130.     segment             =3D single-byte-segment / double-byte-segment
  131.  
  132.     single-byte-segment =3D single-byte-seq *single-byte-char
  133.     double-byte-segment =3D double-byte-seq *(one-of-94 one-of-94)
  134.  
  135.     reset-seq           =3D ESC "(" ( "B" / "J" )
  136.     single-byte-seq     =3D ESC "(" ( "B" / "J" )
  137.     double-byte-seq     =3D (ESC "$" ( "@" / "B" )) /
  138.                            (ESC "$" "(" "D" )
  139.  
  140.     CRLF                =3D CR LF
  141.                                                   ;( Octal, Decimal.)
  142.     ESC                 =3D <ISO 2022 ESC, escape>     ;( 33,   27.     =
  143. )
  144.     SI                  =3D <ISO 2022 SI, shift-in>    ;( 17,   15.     =
  145. )
  146.     SO                  =3D <ISO 2022 SO, shift-out>   ;( 16,   14.     =
  147. )
  148.     CR                  =3D <ASCII CR, carriage return>;( 15,   13.     =
  149. )
  150.     LF                  =3D <ASCII LF, linefeed>       ;( 12,   10.     =
  151. )
  152.     one-of-94           =3D <any one of 94 values>     =
  153. ;(41-176,33.-126.)
  154.     one-of-96           =3D <any one of 96 values>     =
  155. ;(40-177,32.-127.)
  156.     7BIT                =3D <any 7-bit value>          ;( 0-177,0.-127. =
  157. )
  158.     single-byte-char    =3D <any 7BIT, including bare CR & bare LF,
  159.                 but NOT including CRLF, and not including ESC, SI, SO>
  160.  
  161. 6. Security Considerations
  162.  
  163.     This draft does not address security issues.
  164.  
  165. 7. MIME Considerations
  166.  
  167.     The name to be used for the Japanese encoding scheme in content is
  168.     "ISO-2022-JP-1". When this name is used in the MIME message form,
  169.     it would be:
  170.  
  171.         Content-Type: text/plain; charset=3Diso-2022-jp-1
  172.  
  173.     Since the "ISO-2022-JP-1" is 7bit encoding, it will be unnecessary
  174.     to encode in another format by specifying the "Content-Transfer-
  175.     Encoding" header. Also applying Based64 or Quoted-Printable
  176.     encoding MAY cause today's software to fail to decode the message.
  177.  
  178.     "ISO-2022-JP-1" can be used in MIME headers. Also "ISO-2022-JP-1"
  179.     text can be used with Base64 or Quoted-Printable encoding.
  180.  
  181. 8. Additional Information
  182.  
  183.     As long as mail systems are capable of writing out Unicode, it is
  184.     recommended to also write out Unicode text in addition to "ISO-
  185.     2022-JP-1" text. Also writing out "ISO-2022-JP" text in addition to =
  186.  
  187.     "ISO-2022-JP-1" is strongly encouraged for backward compatibility
  188.     reasons.
  189.  
  190.     Some mail systems write out 8bits characters in 'parameter' and
  191.     'value' defined in [RFC 822] and [RFC 1521]. All 8bit characters
  192.     MUST NOT be used in those fields. The implementation of future
  193.     mail systems SHOULD support those only for interoperability
  194.     reasons.
  195.  
  196. 9. References
  197.  
  198. [ISO2022]
  199.           International Organization for Standardization (ISO),
  200.           "Information processing -- ISO 7-bit and 8-bit coded
  201.           character sets -- Code extension techniques",
  202.           International Standard, Ref. No. ISO 2022-1986 (E).
  203.  
  204. [ISOREG] International Organization for Standardization (ISO),
  205.           "International Register of Coded Character Sets To Be Used
  206.           With Escape Sequences".
  207.  
  208. [RFC-822]
  209.           Crocker, D., "Standard for the Format of ARPA Internet
  210.           Text Messages", RFC 822 August, 1982.
  211.  
  212. [2022JP]
  213.           Murai, J., Crispin, M., and E. van der Poel, "Japanese
  214.           Character Encoding for Internet Messages", RFC 1468, June
  215.           1993.
  216.  
  217. [RFC-1766]
  218.           Alvestrand, H., "Tags for the Identification of
  219.           Languages", RFC 1766, March, 1995.
  220.  
  221. [RFC-2045]
  222.           Freed, N. and Borenstein, N., "Multipurpose Internet Mail
  223.           Extensions (MIME) Part One: Format of Internet Message
  224.           Bodies", RFC 2045, Innosoft, First Virtual Holdings,
  225.           December 1996.
  226.  
  227. [RFC-2046]
  228.           Freed, N. and Borenstein, N., "Multipurpose Internet Mail
  229.           Extensions (MIME) Part Two: Media Types", RFC 2046,
  230.           Innosoft, First Virtual Holdings, December 1996.
  231.  
  232. [RFC-2047]
  233.           Moore, K., "Multipurpose Internet Mail Extensions (MIME)
  234.           Part Three: Representation of Non-ASCII Text in Internet
  235.           Message Headers", RFC 2047, University of Tennessee,
  236.           December 1996.
  237.  
  238. [RFC-2048]
  239.           Freed, N., Klensin, J., Postel, J., "Multipurpose
  240.           Internet Mail Extensions (MIME) Part Four: MIME
  241.           Registration Procedures", RFC 2048, Innosoft, MCI, ISI,
  242.           December 1996.
  243.  
  244. [RFC-2049]
  245.           Freed, N. and Borenstein, N., "Multipurpose Internet Mail
  246.           Extensions (MIME) Part Five: Conformance Criteria and
  247.           Examples", RFC 2049, Innosoft, FIrst Virtual Holdings,
  248.           December 1996.
  249.  
  250. [RFC-2119]
  251.           Bradner, S., "Key words for use in RFCs to Indicate
  252.           Requirement Levels", RFC 2119, March 1997.
  253.  
  254. Author's Address
  255.             Kenzaburo Tamaru
  256.             Microsoft Corporation
  257.             One Microsoft Way
  258.             Redmond, WA 98052-6399
  259.  
  260.             E-Mail: kenzat@microsoft.com
  261.  
  262. INTERNET DRAFT        EXPIRES APR 1998        INTERNET DRAFT
  263.