RFC 1557

RFC 1557: Korean Character Encoding for Internet Messages 🎀

okay bestie, RFC 1557 is giving a full Korean character encoding for mail ✨ here's the tea from the title block 💅

• Network Working Group 🌸
• Request for Comments: 1557
• Category: Informational (it's info, not a standard, periodt)
• Date: December 1993
• Authors: Uhhyung Choi and Kilnam Chon (both from KAIST), and Hyunje Park (from Solvit Chosun Media) 🫶
• Obsoletes / Updates: the header doesn't list anything it obsoletes or updates 🦋

---

Status of This Memo 📜

This memo gives info to the Internet community. It does not specify an Internet standard of any kind, so no pressure. Distribution of this memo is unlimited, so share it with everyone 💖

Introduction 🌈

So this doc describes how to represent Korean characters in both the header and the body of Internet mail messages [RFC822]. The encoding method was specified in 1991 and has been used ever since. It's now widely used in Korean IP networks, which is so iconic 👑

The doc also covers the name of the encoding method, which is what you use to match the message header and body format of MIME [MIME1, MIME2] 🧚

Heads up: this doc only covers the encoding method for plain text. Other text subtypes, rich text, and similar forms of text are beyond its scope 🙈

Description 💅

Okay, the starting code of a message is assumed to be ASCII. ASCII and Korean characters can be told apart by the shift function. The SO code is the signal that the bytes coming next are a Korean character as defined in KSC 5601, and the SI code brings you back to ASCII ✨

So the escape sequence, shift function, and character set used in a message look like this:

           SO           KSC 5601
           SI           ASCII
           ESC $ ) C    Appears once in the beginning of a line
                            before any appearance of SO characters.

The KSC 5601 [KSC5601] character set has Hangul, Hanja (Chinese ideographic characters), graphic and foreign characters, etc. Each character is two bytes long 🍓

For more on Korean character sets, check the KSC 5601-1987 document. For more detail on the escape sequence and the shift function, look up the ISO 2022 [ISO2022] document 📚

Formal Syntax 🎀

If this doc's formal syntax doesn't match the description part, then priority should be given to the formal syntax. Noted, bestie 🫶

The notation in this section follows STD 11, RFC 822 [RFC822], with the same meaning.

The asterisk (*) works like this:

     l*m "anything"

That means "anything" has to show up at least l times and at most m times. The defaults for l and m are 0 and infinitive, respectively 🌀

Now for the grammar itself 🦋

   body            = *e-line *1( designator *( e-line / h-line ))

   designator      = ESC "$" ")" "C"

   e-line          = *text CRLF

   h-line          = *text 1*( segment *text ) CRLF




   segment         = SO 1*(one-of-94 one-of-94 SI

                                               ; ( Octal, Decimal.)

   ESC             = <ISO 2022 ESC, escape>    ; ( 33, 27.)

   SO              = <ASCII SO, shift out>     ; ( 16, 14.)

   SI              = <ASCII SI, shift in>      ; ( 17, 15.)

   SP              = <ASCII SP, space>         ; ( 40, 32.)
   one-of-94       = <any char in 94-char set> ; (41-176, 33.-126.)

   CHAR            = <any ASCII character>     ; ( 0-177, 0.-127.)

   text            = <any CHAR, including bare CR & bare LF, but NOT
                      including CRLF, and not including ESC, SI, SO>

MIME and RFC 1522 Considerations 🌸

The name for the Hangul encoding scheme in the contents is "ISO-2022-KR". When it's used in MIME message form, it looks like this:

             Content-Type: text/plain; charset=iso-2022-kr

Hangul encoding is 7-bit in nature, so the Content-Transfer-Encoding-header doesn't need to be used. BUT, the current Hangul message software doesn't support Base64 or Quoted-Printable encoding applied to already encoded Hangul messages. Bummer 😭

The Hangul in the header part of the message is Korean EUC [EUC-KR]. In EUC-KR, bytes with the 8th bit set are recognized as KSC-5601 characters. To use Hangul in the header part, the encoded Hangul gets "B" or "Q" encoded, following the method proposed in RFC 1522. When you do that, the name to use is EUC-KR ✨

Background Information 🧚

The Hangul encoding system is based on the ISO 2022 [ISO2022] environment, following its 4/4 announcement. The Hangul encoding doesn't include that announcement's escape sequence, though 🙈

The KSC 5601 used in this document is, by definition, identical to the 94x94 octet definition in KSC 5601-1987, KSC 5601-1989, and KSC 5601-1992. So any revision that refers to KSC-5601 after 1992 has the same meaning 💖

The Hangul encoding system comes from the experience people had with the formerly popular "N-Byte Hangul" among UNIX users. The "N-Byte Hangul" encoding, which used SO and SI, was the method used in SDN before KSC 5601 became a national standard. Historical moment 🍓

This code is meant for information interchange of Hangul messages. Any other use of the code isn't considered appropriate 🚫

References 📚

• [ASCII] American National Standards Institute, "Coded character set -- 7-bit American national standard code for information interchange", ANSI X3.4-1968
• [ISO2022] International Organization for Standardization (ISO), "Information processing -- ISO 7-bit and 8-bit coded character sets -- Code extension techniques", International Standard, 1986, Ref. No. ISO 2022-1986 (E).
• [KSC5601] Korea Industrial Standards Association, "Code for Information Interchange (Hangul and Hanja)," Korean Industrial Standard, 1987, Ref. No. KS C 5601-1987.
• [EUC-KR] Korea Industrial Standards Association, "Hangul Unix Environment," Korean Industrial Standard, 1992, Ref. No. KS C 5861-1992.
• [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, August 1982.
• [MIME1] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail Extensions): Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft, September 1993.
• [MIME2] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text", RFC 1522, University of Tennessee, September 1993.

Security Considerations 🔥

Okay, real talk: security issues are not discussed in this memo. Bestie, this is a big deal and you should go into it knowing that 💀

Acknowledgments 🫶

The authors want to thank everyone who helped write this doc. In particular, they thank Erik von der Poel, Felix M. Villarreal, Ienup Sung, Kyoung Namgoong, and Kyuho Kim. Iconic supporting cast 👑

Authors' Addresses 🦋

Uhhyung Choi Korea Advanced Institute of Science and Technology Department of Computer Science Taejon, 305-701, Republic of Korea

Phone: +82-42-869-8718 Fax: +82-42-869-3510 EMail: uhhyung@kaist.ac.kr

Kilnam Chon Korea Advanced Institute of Science and Technology Department of Computer Science Taejon, 305-701, Republic of Korea

Phone: +82-42-869-3514 Fax: +82-42-869-3510 EMail: chon@cosmos.kaist.ac.kr

Hyunje Park Solvit Chosun Media, Inc. 748-16 Yeoksam-Dong, Kangnam-Gu Seoul, 135-080, Republic of Korea

Phone: +82-2-561-0361 Fax: +82-2-569-4847 EMail: hjpark@dino.media.co.kr