idnits 2.17.1 draft-ietf-822ext-iso2022jp-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (December 1992) is 11455 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO646' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO2022' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISOREG' -- Possible downref: Non-RFC (?) normative reference: ref. 'JISX0201' -- Possible downref: Non-RFC (?) normative reference: ref. 'JISX0208' -- Possible downref: Non-RFC (?) normative reference: ref. 'JUNET' ** Obsolete normative reference: RFC 1341 (ref. 'MIME') (Obsoleted by RFC 1521) ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1036 (Obsoleted by RFC 5536, RFC 5537) ** Obsolete normative reference: RFC 1342 (Obsoleted by RFC 1522) Summary: 14 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Jun Murai 2 Internet Draft Mark Crispin 3 Erik van der Poel 4 1st December 1992 6 Japanese Character Encoding for Internet Message Bodies 8 Status of this Memo 10 This document is an Internet Draft. Internet Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its Areas, 12 and its Working Groups. Note that other groups may also distribute 13 working documents as Internet Drafts. 15 Internet Drafts are draft documents valid for a maximum of six 16 months. Internet Drafts may be updated, replaced, or obsoleted by 17 other documents at any time. It is not appropriate to use Internet 18 Drafts as reference material or to cite them other than as a "working 19 draft" or "work in progress." 21 Please check the I-D abstract listing contained in each Internet 22 Draft directory to learn the current status of this or any other 23 Internet Draft. 25 This draft document will be submitted to the RFC editor as an 26 informational document. This document will expire before 1st June 27 1993. Distribution of this memo is unlimited. Please send comments 28 to ietf-822@dimacs.rutgers.edu. 30 Introduction 32 This document describes the encoding used in electronic mail [RFC822] 33 and network news [RFC1036] message bodies in several Japanese 34 networks. It was first specified by and used in JUNET [JUNET]. The 35 encoding is now also widely used in Japanese IP communities. 37 This document names the encoding "ISO-2022-JP", which is intended to 38 be used in the "charset" parameter field of MIME [MIME] messages. The 39 use of ISO-2022-JP in RFC 1342 [RFC1342] headers is expected to be 40 the subject of a separate document. 42 This document only describes the encoding of plain text. The encoding 43 of other subtypes of text, such as richtext, is not discussed here. 45 Description 47 The message body starts in ASCII [ASCII], and switches to Japanese 48 characters through an escape sequence. For example, the escape 49 sequence ESC $ B (three bytes, hexadecimal values: 1B 24 42) 50 indicates that the bytes following this escape sequence are Japanese 51 characters, which are encoded in two bytes each. To switch back to 52 ASCII, the escape sequence ESC ( B is used. 54 The following table gives the escape sequences and the character sets 55 used in ISO-2022-JP messages. The ISOREG number is the registration 56 number in ISO's registry [ISOREG]. 58 Esc Seq Character Set ISOREG 60 ESC ( B ASCII 6 61 ESC ( J JIS X 0201-1976 ("Roman" set) 14 62 ESC $ @ JIS X 0208-1978 42 63 ESC $ B JIS X 0208-1983 87 65 Note that JIS X 0208-1983 was called JIS C 6226-1983 until the name 66 was changed in March 1987. Likewise, JIS C 6220 was renamed JIS X 67 0201. 69 The "Roman" character set of JIS X 0201 [JISX0201] is identical to 70 ASCII except for backslash (\) and tilde (~). The backslash is 71 replaced by the Yen sign, and the tilde is replaced by macron 72 (overline). This set is Japan's national variant of ISO 646 [ISO646]. 74 The JIS X 0208 [JISX0208] character sets consist of Kanji, Hiragana, 75 Katakana and some other symbols and characters. Each character takes 76 up two bytes. 78 For further details about the JIS Japanese national character set 79 standards, refer to [JISX0201] and [JISX0208]. For further 80 information about the escape sequences, see [ISO2022] and [ISOREG]. 82 If there are JIS X 0208 characters on a line, there must be a switch 83 to ASCII or to the "Roman" set of JIS X 0201 before the end of the 84 line (i.e. before the CRLF). This means that the next line starts in 85 the character set that was switched to before the end of the previous 86 line. 88 Also, the message body must end with CRLF, and there must be a switch 89 to ASCII before the last CRLF (if there are any non-ASCII characters 90 in the message body). 92 Other restrictions are given in the Formal Syntax below. 94 Formal Syntax 96 The notational conventions used here are identical to those used in 97 RFC 822 [RFC822]. 99 The * (asterisk) convention is as follows: 101 l*m something 103 meaning at least l and at most m somethings, with l and m taking 104 default values of 0 and infinity, respectively. 106 line = *text *1( *segment single-byte-seq *text ) CRLF 108 segment = single-byte-segment / double-byte-segment 110 single-byte-segment = single-byte-seq 1*text 112 double-byte-segment = double-byte-seq 1*( one-of-94 one-of-94 ) 114 single-byte-seq = ESC "(" ( "B" / "J" ) 116 double-byte-seq = ESC "$" ( "@" / "B" ) 118 ; ( Octal, Decimal.) 120 ESC = ; ( 33, 27.) 122 SI = ; ( 17, 15.) 124 SO = ; ( 16, 14.) 126 one-of-94 = ; (41-176, 33.-126.) 128 CHAR = ; ( 0-177, 0.-127.) 130 text = 133 MIME Considerations 135 The name given to the JUNET character encoding is "ISO-2022-JP". This 136 name is intended to be used in MIME messages as follows: 138 Content-Type: text/plain; charset=iso-2022-jp 140 The ISO-2022-JP encoding is already in 7-bit form, so it is not 141 necessary to use a Content-Transfer-Encoding header. It should be 142 noted that applying the Base64 or Quoted-Printable encoding will 143 render the message unreadable in current JUNET software. 145 Background Information 147 The JUNET encoding was described in the JUNET User's Guide [JUNET] 148 (JUNET Riyou No Tebiki Dai Ippan). 150 The encoding is based on the particular usage of ISO 2022 announced 151 by 4/1 (see [ISO2022] for details). However, the escape sequence 152 normally used for this announcement is not included in ISO-2022-JP 153 messages. 155 The so-called half-width (hankaku) Katakana, that is, the Kana set of 156 JIS X 0201, are not used in ISO-2022-JP messages. 158 In the past, some systems erroneously used the escape sequence ESC ( 159 H in JUNET messages. This escape sequence is officially registered 160 for a Swedish character set [ISOREG], and should not be used in ISO- 161 2022-JP messages. 163 Some systems do not distinguish between ESC ( B and ESC ( J or 164 between ESC $ @ and ESC $ B for display. However, when relaying a 165 message to another system, the escape sequences must not be altered 166 in any way. 168 The human user (not implementor) should try to keep lines within 80 169 display columns, or, preferably, within 75 (or so) columns, to allow 170 insertion of ">" at the beginning of each line in excerpts. Each JIS 171 X 0208 character takes up two columns, and the escape sequences do 172 not take up any columns. The implementor is reminded that JIS X 0208 173 characters take up two bytes and should not be split in the middle to 174 break lines for displaying, etc. 176 The JIS X 0208 standard was revised in 1990, to add two characters at 177 the end of the table. Although ISO 2022 specifies special additional 178 escape sequences to indicate the use of revised character sets, it is 179 suggested here not to make use of this special escape sequence in 180 ISO-2022-JP text, even if the two characters added to JIS X 0208 in 181 1990 are used. 183 References 185 [ASCII] American National Standards Institute, "Coded character set 186 -- 7-bit American national standard code for information 187 interchange", ANSI X3.4-1968 189 [ISO646] International Organization for Standardization (ISO), 190 "Information processing -- ISO 7-bit coded character set for 191 information interchange", International Standard, Ref. No. ISO 646- 192 1983 (E) 194 [ISO2022] International Organization for Standardization (ISO), 195 "Information processing -- ISO 7-bit and 8-bit coded character sets 196 -- Code extension techniques", International Standard, Ref. No. ISO 197 2022-1986 (E) 199 [ISOREG] International Organization for Standardization (ISO), 200 "International Register of Coded Character Sets To Be Used With 201 Escape Sequences" 203 [JISX0201] Japanese Standards Association, "Code for Information 204 Interchange", JIS X 0201-1976 206 [JISX0208] Japanese Standards Association, "Code of the Japanese 207 graphic character set for information interchange", JIS X 0208-1978, 208 -1983 and -1990 210 [JUNET] JUNET Riyou No Tebiki Sakusei Iin Kai (JUNET User's Guide 211 Drafting Committee), "JUNET Riyou No Tebiki (Dai Ippan)" ("JUNET 212 User's Guide (First Edition)"), February 1988 214 [MIME] Nathaniel Borenstein and Ned Freed, "MIME (Multipurpose 215 Internet Mail Extensions): Mechanisms for Specifying and Describing 216 the Format of Internet Message Bodies", Proposed (Internet) standard, 217 June 1992, rfc1341 219 [RFC822] David H. Crocker, "Standard for the Format of ARPA Internet 220 Text Messages", Internet standard, August 1982, rfc822 222 [RFC1036] M. Horton and R. Adams, "Standard for Interchange of USENET 223 Messages", December 1987, rfc1036 225 [RFC1342] Keith Moore, "Representation of Non-ASCII Text in Internet 226 Message Headers", Proposed (Internet) standard, June 1992, rfc1342 228 Security Considerations 229 Security considerations are not discussed in this memo. 231 Acknowledgements 233 Many people assisted in drafting this document. The authors wish to 234 thank in particular Akira Kato, Masahiro Sekiguchi and Ken'ichi 235 Handa. 237 Authors' Addresses 239 Jun Murai 240 Keio University 241 5322 Endo, Fujisawa 242 Kanagawa 252 Japan 244 Fax: +81 (466) 49-1101 246 EMail: jun@wide.ad.jp 248 Mark Crispin 249 Panda Programming 250 6158 Lariat Loop NE 251 Bainbridge Island, WA 98110-2098 252 USA 254 Phone: +1 (206) 842-2385 256 EMail: MRC@PANDA.COM 258 Erik M. van der Poel 259 A-105 Park Avenue 260 4-4-10 Ohta, Kisarazu 261 Chiba 292 Japan 263 Phone: +81 (438) 22-5836 264 Fax: +81 (438) 22-5837 266 EMail: erik@poel.juice.or.jp