idnits 2.17.1 draft-rfced-info-tamaru-01.txt: ** The Abstract section seems to be numbered 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-20) 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 262 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. ** There are 8 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 2 instances of lines with control characters in the document. ** The abstract seems to contain references ([RFC1036], [RFC-822]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 1036' is mentioned on line 32, but not defined ** Obsolete undefined reference: RFC 1036 (Obsoleted by RFC 5536, RFC 5537) == Missing Reference: 'RFC822' is mentioned on line 111, but not defined ** Obsolete undefined reference: RFC 822 (Obsoleted by RFC 2822) == Missing Reference: 'RFC 822' is mentioned on line 185, but not defined ** Obsolete undefined reference: RFC 822 (Obsoleted by RFC 2822) == Missing Reference: 'RFC 1521' is mentioned on line 185, but not defined ** Obsolete undefined reference: RFC 1521 (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) == Unused Reference: 'ISO2022' is defined on line 192, but no explicit reference was found in the text == Unused Reference: 'ISOREG' is defined on line 198, but no explicit reference was found in the text == Unused Reference: '2022JP' is defined on line 206, but no explicit reference was found in the text == Unused Reference: 'RFC-1766' is defined on line 211, but no explicit reference was found in the text == Unused Reference: 'RFC-2045' is defined on line 215, but no explicit reference was found in the text == Unused Reference: 'RFC-2046' is defined on line 221, but no explicit reference was found in the text == Unused Reference: 'RFC-2047' is defined on line 226, but no explicit reference was found in the text == Unused Reference: 'RFC-2048' is defined on line 232, but no explicit reference was found in the text == Unused Reference: 'RFC-2049' is defined on line 238, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO2022' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISOREG' ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Downref: Normative reference to an Informational RFC: RFC 1468 (ref. '2022JP') ** Obsolete normative reference: RFC 1766 (Obsoleted by RFC 3066, RFC 3282) ** Obsolete normative reference: RFC 2048 (Obsoleted by RFC 4288, RFC 4289) Summary: 20 errors (**), 0 flaws (~~), 16 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT EXPIRES APR 1998 INTERNET DRAFT 2 Network Working Group MicrosoftCorporation 3 Internet Draft K.Tamaru 5 Japanese Character Encoding for Internet Messages 6 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 12 areas, and its working groups. Note that other groups may also 13 distribute working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet- 18 Drafts as reference material or to cite them other than as 19 ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check 22 the ``1id-abstracts.txt'' listing contained in the Internet- 23 Drafts Shadow Directories on ftp.is.co.za (Africa), 24 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 25 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 26 Distribution of this document is unlimited. 28 1. Abstract 30 This memo defines an encoding scheme for the Japanese Characters, 31 describes "ISO-2022-JP-1", which is used in electronic mail 32 [RFC-822], and network news [RFC 1036]. Also this memo provides a 33 listing of the Japanese Character Set that can be used in this 34 encoding scheme. 36 2. Requirements Notation 38 This document uses terms that appear in capital letters to 39 indicate particular requirements of this specification. Those terms 40 are "MUST", "SHOULD", "MUST NOT", "SHOULD NOT", and "MAY". The 41 meaning of each term are found in [RFC-2119] 43 3. Introduction 45 RFC 1468 defines the way Japanese Characters are encoded, likewise 46 what this memo defines. It defines the use of JIS X 0208 as the 47 double-byte character set in ISO-2022-JP text. 49 Today, many operating systems support proprietary extended Japanese = 51 characters or JIS X 0212, This includes the Unicode character set, 52 which does not conform to JIS X 0201 nor JIS X 0208. Therefore, 53 this limits the ability to communicate and correspond precise 54 information because of the limited availability of Kanji 55 characters. Fortunately JIS(Japanese Industry Standard) defines 56 JIS X 0212 as "code of the supplementary Japanese graphic character 57 set for information interchange". Most Japanese characters which 58 are used in regular electronic mail in most cases can be 59 accommodated in JIS X 0201, JIS X 0208 and JIS X 0212. 61 Also it is recognized that there is a tendency to use Unicode, 62 however, Unicode is not yet widely used and there is a certain 63 limitation with old electronic mail system. Furthermore, the 64 purpose of this comment is to add the capability of writing out 65 JIS X 0212. 67 This comment does not describe any representation of iso-2022-jp-1 68 version information in addition to JIS X 0212 support. 70 4. Description 72 In "ISO-2022-JP-1" text, the initial character code of the message 73 is in ASCII. The "double-byte-seq"(see "Format Syntax" section) 74 (ESC "$" "B" / ESC "$" "@" / ESC "$" "(" "D") is the only 75 designator that indicates that the following character is 76 double-byte, and it is valid until another escape sequence appears. 77 It is very discouraged to use (ESC "$" "@") for double byte 78 character encoding, new implementation SHOULD use only 79 (ESC "$" "B") for double byte encoding instead. 81 The end of "ISO-2022-JP-1" text MUST be in ASCII. Also it is 82 strongly recommended to back up to the ASCII at the end of each 83 line rather than JIS X 0201-Roman if there is any none ASCII 84 character in middle of a line. 86 Since "ISO-2022-JP-1" is designed to add the capability of writing 87 out JIS X 0212, if the message does not contain none of JIS X 0212 88 characters. "ISO-2022-JP" text MUST BE used. 90 JIS X 0201-Roman is not identical to the ASCII with two different 91 characters. 93 The following list are the escape sequences and character sets 94 that can be used in "ISO-2022-JP-1" text. The registered number in 95 the ISO 2375 Register which allow double-byte ideographic scripts 96 to be encoded within ISO/IEC 2022 code structure is indicated as 97 reg# below. 99 reg# character set ESC sequence designated to 100 6 ASCII ESC 2/8 4/2 ESC ( B G0 101 42 JIS X 0208-1978 ESC 2/4 4/0 ESC $ @ G0 102 87 JIS X 0208-1983 ESC 2/4 4/2 ESC $ B G0 103 14 JIS X 0201-Roman ESC 2/8 4/10 ESC ( J G0 104 159 JIS X 0212-1990 ESC 2/4 2/8 4/4 ESC $ ( D G0 106 Other restrictions are given in the Formal Syntax below. 108 5. Formal Syntax 110 The notational conventions used here are identical to those used in 111 STD 11, RFC 822 [RFC822]. 113 The * (asterisk) convention is as follows: 114 l*m something 115 meaning at least l and at most m something, with l and m taking 116 default values of 0 and infinity, respectively. 118 iso-2022-jp-1-text =3D *( line CRLF ) [line] 120 line =3D (*single-byte-char *segment 121 single-byte-seq *single-byte-char) / 122 *single-byte-char 124 segment =3D single-byte-segment / double-byte-segment 126 single-byte-segment =3D single-byte-seq *single-byte-char 127 double-byte-segment =3D double-byte-seq *(one-of-94 one-of-94) 129 reset-seq =3D ESC "(" ( "B" / "J" ) 130 single-byte-seq =3D ESC "(" ( "B" / "J" ) 131 double-byte-seq =3D (ESC "$" ( "@" / "B" )) / 132 (ESC "$" "(" "D" ) 134 CRLF =3D CR LF 135 ;( Octal, Decimal.) 136 ESC =3D ;( 33, 27. = 137 ) 138 SI =3D ;( 17, 15. = 139 ) 140 SO =3D ;( 16, 14. = 141 ) 142 CR =3D ;( 15, 13. = 143 ) 144 LF =3D ;( 12, 10. = 145 ) 146 one-of-94 =3D = 147 ;(41-176,33.-126.) 148 one-of-96 =3D = 149 ;(40-177,32.-127.) 150 7BIT =3D ;( 0-177,0.-127. = 151 ) 152 single-byte-char =3D 155 6. Security Considerations 157 This draft does not address security issues. 159 7. MIME Considerations 161 The name to be used for the Japanese encoding scheme in content is 162 "ISO-2022-JP-1". When this name is used in the MIME message form, 163 it would be: 165 Content-Type: text/plain; charset=3Diso-2022-jp-1 167 Since the "ISO-2022-JP-1" is 7bit encoding, it will be unnecessary 168 to encode in another format by specifying the "Content-Transfer- 169 Encoding" header. Also applying Based64 or Quoted-Printable 170 encoding MAY cause today's software to fail to decode the message. 172 "ISO-2022-JP-1" can be used in MIME headers. Also "ISO-2022-JP-1" 173 text can be used with Base64 or Quoted-Printable encoding. 175 8. Additional Information 177 As long as mail systems are capable of writing out Unicode, it is 178 recommended to also write out Unicode text in addition to "ISO- 179 2022-JP-1" text. Also writing out "ISO-2022-JP" text in addition to = 181 "ISO-2022-JP-1" is strongly encouraged for backward compatibility 182 reasons. 184 Some mail systems write out 8bits characters in 'parameter' and 185 'value' defined in [RFC 822] and [RFC 1521]. All 8bit characters 186 MUST NOT be used in those fields. The implementation of future 187 mail systems SHOULD support those only for interoperability 188 reasons. 190 9. References 192 [ISO2022] 193 International Organization for Standardization (ISO), 194 "Information processing -- ISO 7-bit and 8-bit coded 195 character sets -- Code extension techniques", 196 International Standard, Ref. No. ISO 2022-1986 (E). 198 [ISOREG] International Organization for Standardization (ISO), 199 "International Register of Coded Character Sets To Be Used 200 With Escape Sequences". 202 [RFC-822] 203 Crocker, D., "Standard for the Format of ARPA Internet 204 Text Messages", RFC 822 August, 1982. 206 [2022JP] 207 Murai, J., Crispin, M., and E. van der Poel, "Japanese 208 Character Encoding for Internet Messages", RFC 1468, June 209 1993. 211 [RFC-1766] 212 Alvestrand, H., "Tags for the Identification of 213 Languages", RFC 1766, March, 1995. 215 [RFC-2045] 216 Freed, N. and Borenstein, N., "Multipurpose Internet Mail 217 Extensions (MIME) Part One: Format of Internet Message 218 Bodies", RFC 2045, Innosoft, First Virtual Holdings, 219 December 1996. 221 [RFC-2046] 222 Freed, N. and Borenstein, N., "Multipurpose Internet Mail 223 Extensions (MIME) Part Two: Media Types", RFC 2046, 224 Innosoft, First Virtual Holdings, December 1996. 226 [RFC-2047] 227 Moore, K., "Multipurpose Internet Mail Extensions (MIME) 228 Part Three: Representation of Non-ASCII Text in Internet 229 Message Headers", RFC 2047, University of Tennessee, 230 December 1996. 232 [RFC-2048] 233 Freed, N., Klensin, J., Postel, J., "Multipurpose 234 Internet Mail Extensions (MIME) Part Four: MIME 235 Registration Procedures", RFC 2048, Innosoft, MCI, ISI, 236 December 1996. 238 [RFC-2049] 239 Freed, N. and Borenstein, N., "Multipurpose Internet Mail 240 Extensions (MIME) Part Five: Conformance Criteria and 241 Examples", RFC 2049, Innosoft, FIrst Virtual Holdings, 242 December 1996. 244 [RFC-2119] 245 Bradner, S., "Key words for use in RFCs to Indicate 246 Requirement Levels", RFC 2119, March 1997. 248 Author's Address 249 Kenzaburo Tamaru 250 Microsoft Corporation 251 One Microsoft Way 252 Redmond, WA 98052-6399 254 E-Mail: kenzat@microsoft.com 256 INTERNET DRAFT EXPIRES APR 1998 INTERNET DRAFT