idnits 2.17.1 draft-rfced-info-tamaru-00.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-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 -- 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 97 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 3 pages 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 9 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 2 instances of lines with control characters in the document. ** The abstract seems to contain references ([RFC1036], [RFC822]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 822' is mentioned on line 182, but not defined ** Obsolete undefined reference: RFC 822 (Obsoleted by RFC 2822) == Missing Reference: 'RFC 1036' is mentioned on line 34, but not defined ** Obsolete undefined reference: RFC 1036 (Obsoleted by RFC 5536, RFC 5537) == Missing Reference: 'RFC822' is mentioned on line 113, but not defined ** Obsolete undefined reference: RFC 822 (Obsoleted by RFC 2822) == Missing Reference: 'MIME1' is mentioned on line 113, but not defined == Missing Reference: 'RFC 1521' is mentioned on line 182, 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 189, but no explicit reference was found in the text == Unused Reference: 'ISOREG' is defined on line 195, but no explicit reference was found in the text == Unused Reference: 'RFC-822' is defined on line 199, but no explicit reference was found in the text == Unused Reference: '2022JP' is defined on line 203, but no explicit reference was found in the text == Unused Reference: 'RFC-1766' is defined on line 208, 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 (~~), 18 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT EXPIRES FEB 1998 INTERNET DRAFT 3 Network Working Group MicrosoftCorporation 4 Internet Draft K.Tamaru 6 Japanese Character Encoding for Internet Messages 7 9 Status of This Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its 13 areas, and its working groups. Note that other groups may also 14 distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet- 19 Drafts as reference material or to cite them other than as 20 ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check 23 the ``1id-abstracts.txt'' listing contained in the Internet- 24 Drafts Shadow Directories on ftp.is.co.za (Africa), 25 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 26 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 28 Distribution of this document is unlimited. 30 1. Abstract 32 This memo defines an encoding scheme for the Japanese Characters, 33 describes 'ISO-2022-JP', which is used in electronic mail[RFC 822], 34 and network news [RFC 1036]. Also this memo provides a listing of 35 the Japanese Character Set that can be used in this encoding scheme. 37 2. Introduction 39 RFC 1468 defines the way Japanese Characters are encoded, likewise 40 what this memo defines. It defines the use of JIS X 0208 as the 41 double-byte character set in ISO-2022-JP text. 43 Today, many operating systems support proprietary extended Japanese 44 characters or JIS X 0212, This includes the Unicode character set, 45 which does not conform to JIS X 0201 nor JIS X 0208. Therefore, 46 this limits the ability to communicate and correspond precise 47 information because of the limited availability of Kanji characters. 48 Fortunately JIS(Japanese Industry Standard) defines JIS X 0212 as 49 "code of the supplementary Japanese graphic character set for 50 information interchange". Most Japanese characters which are used 51 regular electronic mail in most cases can be accommodated in 52 JIS X 0201, JIS X 0208 and JIS X 0212. 54 Also it is recognized that there is a tendency to use Unicode, 55 however, Unicode is not yet widely used and there is a certain 56 limitation with old electronic mail system. Furthermore, the 57 purpose of this comment is to add the capability of writing out 58 JIS X 0212. 60 This comment does not describe any representation of iso-2022-jp 61 version information in addition to JIS X 0212 support. 63 3. Description 65 In "ISO-2022-JP" text, the initial character code of the message is 66 in ASCII. The "double-byte-seq"(see "Format Syntax" section) 67 (ESC "$" "B" / ESC "$" "@" / ESC "$" "(" "D") is the only designator 68 that indicates that the following character is double-byte, and it 69 is valid until another escape sequence appears. 71 Internet Draft Japanese Character Encoding 73 The end of "ISO-2022-JP" text must also be in ASCII. Also it is 74 strongly recommended to back up to the ASCII at the end of each 75 line rather than JIS X 0201-Roman if there is any none ASCII 76 character in middle of a line. JIS X 0201-Roman is not identical 77 to the ASCII with two different characters. 79 The following list are the escape sequences and character sets that 80 can be used in "ISO-2022-JP" text. The registered number in the 81 ISO 2375 Register which allow double-byte ideographic scripts to be 82 encoded within ISO/IEC 2022 code structure is indicated as reg# 83 below. 85 reg# character set ESC sequence designated to 86 6 ASCII ESC 2/8 4/2 ESC ( B G0 87 42 JIS X 0208-1978 ESC 2/4 4/0 ESC $ @ G0 88 87 JIS X 0208-1983 ESC 2/4 4/2 ESC $ B G0 89 14 JIS X 0201-Roman ESC 2/8 4/10 ESC ( J G0 90 159 JIS X 0212-1990 ESC 2/4 2/8 4/4 ESC $ ( D G0 92 Other restrictions are given in the Formal Syntax below. 94 4. Formal Syntax 96 The notational conventions used here are identical to those used in 97 STD 11, RFC 822 [RFC822]. 99 The * (asterisk) convention is as follows: 101 l*m something 103 meaning at least l and at most m something, with l and m taking 104 default values of 0 and infinity, respectively. 106 message =3D headers 1*(CRLF text) 107 ; see also [MIME1] "body-part" 108 ; note: must end in ASCII 110 text =3D *(single-byte-char *segment 111 single-byte-seq *single-byte-char ) 113 headers =3D 116 segment =3D single-byte-segment / double-byte-segment 118 Internet Draft Japanese Character Encoding 120 single-byte-segment =3D single-byte-seq *single-byte-char 122 double-byte-segment =3D double-byte-seq *(one-of-94 one-of-94) 124 reset-seq =3D ESC "(" ( "B" / "J" ) 126 single-byte-seq =3D ESC "(" ( "B" / "J" ) 128 double-byte-seq =3D (ESC "$" ( "@" / "B" )) / 129 (ESC "$" "(" "D" ) 131 CRLF =3D CR LF 132 ;( Octal, Decimal.) 133 ESC =3D ;( 33, 27. ) 135 SI =3D ;( 17, 15. ) 137 SO =3D ;( 16, 14. ) 139 CR =3D ;( 15, 13. ) 141 LF =3D ;( 12, 10. ) 143 one-of-94 =3D ;(41-176, 33.-126.) 145 one-of-96 =3D ;(40-177, 32.-127.) 147 7BIT =3D ;( 0-177, 0.-127. ) 149 single-byte-char =3D 152 5. Security Considerations 154 This draft does not address security issues. 156 6. MIME Considerations 158 The name to be used for the Japanese encoding scheme in content is 159 "ISO-2022-JP". When this name is used in the MIME message form, it 160 would be: 162 Content-Type: text/plain; charset=3Diso-2022-jp 164 Internet Draft Japanese Character Encoding 166 Since the "ISO-2022-JP" is 7bit encoding, it will be unnecessary to 167 encode in another format by specifying the 168 "Content-Trasnfer-Encoding" header. Also applying Based64 or 169 Quoted-Printable encoding may cause today's software to fail to 170 decode the message. 172 "ISO-2022-JP" can be used in MIME headers. Also "ISO-2022-JP" text 173 can be used with Base64 or Quoted-Printable encoding. 175 7. 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 179 "ISO-2022-JP" text. 181 Some mail systems write out 8bits characters in 'parameter' and 182 'value' defined in [RFC 822] and [RFC 1521]. All 8bit 183 characters must not be used in those fields. The implementation 184 of future mail systems should support those only for 185 interoperability reasons. 187 8. References 189 [ISO2022] 190 International Organization for Standardization (ISO), 191 "Information processing -- ISO 7-bit and 8-bit coded 192 character sets -- Code extension techniques", 193 International Standard, Ref. No. ISO 2022-1986 (E). 195 [ISOREG] International Organization for Standardization (ISO), 196 "International Register of Coded Character Sets To Be Used 197 With Escape Sequences". 199 [RFC-822] 200 Crocker, D., "Standard for the Format of ARPA Internet 201 Text Messages", RFC> 822 August, 1982. 203 [2022JP] 204 Murai, J., Crispin, M., and E. van der Poel, "Japanese 205 Character Encoding for Internet Messages", RFC 1468, June 206 1993. 208 [RFC-1766] 209 Alvestrand, H., "Tags for the Identification of 210 Languages", RFC 1766, March, 1995. 212 Tamaru [Page =4] 213 Internet Draft Japanese Character Encoding 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 9. Author's Address 246 Kenzaburo Tamaru 247 Microsoft Corporation 248 One Microsoft Way 249 Redmond, WA 98052-6399 251 E-Mail: kenzat@microsoft.com