RFC 1641

RFC 1641: Using Unicode with MIME 🦋

• Network Working Group 🎀
• RFC 1641, titled "Using Unicode with MIME" ✨
• Authors: David Goldsmith and Mark Davis, both at Taligent, Inc. 💖
• Category: Experimental 🧪
• Date: July 1994 🌸
• Obsoletes and updates: the header doesn't list either one 🙈

---

Status of this Memo ✨

Okay so this memo defines an Experimental Protocol for the Internet community 🧪. It does not set an Internet standard of any kind, so it's more of a "let's try this" situation. Distribution is unlimited, so share it with everyone 💅.

Abstract 🌈

Bestie, so the Unicode Standard, version 1.1, and ISO/IEC 10646-1:1993(E) together define a 16 bit character set (we'll call it Unicode from here on) that covers most of the world's writing systems 🌍✨. Internet mail, which is STD 11 and RFC 822, only supports 7-bit US ASCII as a character set 😭. MIME (RFC 1521 and RFC 1522) extends Internet mail to handle different media types and character sets, so it could support Unicode in mail messages 💌. The catch is that MIME doesn't define Unicode as a permitted character set, and it doesn't say how Unicode should be encoded. It does allow more character sets to be registered over time, though 🔑.

This document specifies how Unicode is used within MIME 🎀.

Motivation 💜

Unicode is getting real commercial adoption, so users are going to want to send it in mail messages and other Internet media 📬🔥. MIME was literally designed to allow extensions like this, and it's on the standards track for the Internet, so it's the most appropriate way to encode Unicode 👑. RFC 1521 and RFC 1522 don't define Unicode as an allowed character set, but they do allow registering new ones 🫶.

Another goal is to describe a way of using Unicode for text that's mostly, but not entirely, US-ASCII characters. The idea is that mail clients that don't understand Unicode can still read it 🧚. That fits the MIME philosophy perfectly 💅. This encoding is described in another document, "UTF-7: A Mail Safe Transformation Format of Unicode" [UTF-7] 🦋.

Overview 🌸

There are a few ways to use Unicode, and this document gives both guidelines for using Unicode within MIME and one specific usage 🍓. The specific usage is a straightforward use of Unicode as specified in "The Unicode Standard, Version 1.1" 💖.

This encoding is meant for situations where the sender and recipient don't want to do a lot of processing, where the text isn't mostly US-ASCII characters, or where both sides are known in advance to support Unicode 🤝.

Another encoding is meant for text that's mostly US-ASCII with the occasional character from other parts of Unicode ✨. That encoding lets every recipient read the US-ASCII portion without needing Unicode support 🫧. It's specified in "UTF-7: A Mail Safe Transformation Format of Unicode" [UTF-7] 🎀.

Finally, following the principles in RFC 1521, text that can be represented with the US-ASCII or ISO-8859-x character sets should be represented that way where possible, for maximum interoperability 🌈💅.

Definitions 💎

The definition of the character set Unicode goes like this:

The 16 bit character set Unicode is defined by "The Unicode Standard, Version 1.1" 📖. It has the same character repertoire and coding as the international standard ISO/IEC 10646-1:1993(E), with Coded Representation Form=UCS-2, Subset=300, and Implementation Level=3 🔥.

Note. Unicode 1.1 goes further than the ISO standard and specifies how these character codes are used and how they interact 🧠. Any valid 10646 BMP (Basic Multilingual Plane) sequence is a valid Unicode sequence, and the reverse is also true 🔁. Unicode also gives interpretations for sequences the ISO standard doesn't address 🙌.

This character set is encoded as sequences of octets, two octets per 16-bit character, with the most significant octet first. Text with an odd number of octets is ill-formed 🚫.

Rationale. ISO/IEC 10646-1:1993(E) says that when UCS-2 characters are serialized as octets, the most significant octet should come first 📏. That also matches common network practice of picking a canonical format for transmission 🌐.

General Specification of Unicode Character Sets Within MIME 🌟

The Unicode Standard is currently at version 1.1 📚. New versions should be compatible with old implementations as long as an implementation complies with the standard. Even so, some implementations may want to check which version of the character set is being used 🔍. So that some implementations can check the version number while others ignore it, all registrations of Unicode variants and versions for MIME usage should have MIME charset names that match one of these two patterns 🎯:

UNICODE-major-minor
UNICODE-major-minor-variant

Here, major and minor are strings of decimal digits (0 through 9) that give the major and minor version numbers of the Unicode standard the text conforms to 🔢. For interoperability, the lowest version number compatible with the text should be used 🫶. The lowest acceptable version number is UNICODE-1-1, which corresponds to "The Unicode Standard, Version 1.1" 🥇. The optional trailing string "variant" describes the particular transformation format of Unicode that the registration covers, and what goes in it is up to each registration 🎨. If there's no trailing variant string, the charset name refers to the basic two octet form of Unicode as described in "The Unicode Standard" 💅.

Example. A hypothetical charset that refers to the UTF-8 transformation format of Unicode/10646 (also known as UTF-2 or UTF-FSS) might be named UNICODE-1-1-UTF-8 🧁.

Encoding Character Set Unicode Within MIME 🦄

Character set Unicode uses 16 bit characters, so it would normally be used with the Binary or Base64 content transfer encodings of MIME 🫧. In header fields, it would normally be used with the B content transfer encoding 📨. The MIME character set identifier is UNICODE-1-1 🪪.

Example. Here's a text portion of a MIME message with the Japanese word "nihongo" (hexadecimal 65E5,672C,8A9E) written in Han characters 🇯🇵✨:

Content-Type: text/plain; charset=UNICODE-1-1
Content-Transfer-Encoding: base64
ZeVnLIqe

Example. Here's a text portion of a MIME message with the Unicode sequence A<NOT IDENTICAL TO><ALPHA>. (hexadecimal 0041,2262,0391,002E) 🔤💀:

Content-Type: text/plain; charset=UNICODE-1-1
Content-Transfer-Encoding: base64

AEEiYgORAC4=

Acknowledgements 🫶

Huge thanks to these people for their contributions, comments, and suggestions 💖. If anyone got left out, it was an oversight and not on purpose 🙏.

• Glenn Adams 🌷
• Harald T. Alvestrand 🌷
• Nathaniel Borenstein 🌷
• Lee Collins 🌷
• Jim Conklin 🌷
• Dave Crocker 🌷
• Steve Dorner 🌷
• Dana S. Emery 🌷
• Ned Freed 🌷
• John H. Jenkins 🌷
• John C. Klensin 🌷
• Valdis Kletnieks 🌷
• Keith Moore 🌷
• Masataka Ohta 🌷
• Einar Stefferud 🌷

Security Considerations 🔐

Security issues are not discussed in this memo. 😬 Nothing about security is covered here, so keep that in mind when you implement anything from this doc 🙈.

References 📚

• [UNICODE 1.1] "The Unicode Standard, Version 1.1": Version 1.0, Volume 1 (ISBN 0-201-56788-1), Version 1.0, Volume 2 (ISBN 0-201-60845-6), and "Unicode Technical Report #4, The Unicode Standard, Version 1.1" (available from The Unicode Consortium, and soon to be published by Addison-Wesley) 📘
• [ISO 10646] ISO/IEC 10646-1:1993(E) Information Technology--Universal Multiple-octet Coded Character Set (UCS) 🌏
• [UTF-7] Goldsmith, D., and M. Davis, "UTF-7: A Mail Safe Transformation Format of Unicode", RFC 1642, Taligent, Inc., July 1994 🦋
• [US-ASCII] Coded Character Set--7-bit American Standard Code for Information Interchange, ANSI X3.4-1986 🔤
• [ISO-8859] Information Processing -- 8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin Alphabet No. 1, ISO 8859-1:1987. Part 2: Latin alphabet No. 2, ISO 8859-2, 1987. Part 3: Latin alphabet No. 3, ISO 8859-3, 1988. Part 4: Latin alphabet No. 4, ISO 8859-4, 1988. Part 5: Latin/Cyrillic alphabet, ISO 8859-5, 1988. Part 6: Latin/Arabic alphabet, ISO 8859-6, 1987. Part 7: Latin/Greek alphabet, ISO 8859-7, 1987. Part 8: Latin/Hebrew alphabet, ISO 8859-8, 1988. Part 9: Latin alphabet No. 5, ISO 8859-9, 1990. 🧩
• [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, August 1982 📮
• [RFC-1521] 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 💌
• [RFC-1522] Moore, K., "Representation of Non-Ascii Text in Internet Message Headers" RFC 1522, University of Tennessee, September 1993 💌
• [UTF-8] X/Open Company Ltd., "File System Safe UCS Transformation Format (FSS_UTF)", X/Open Preliminary Specification, Document Number: P316. This information also appears in Unicode Technical Report #4, and in a forthcoming annex to ISO/IEC 10646 🗂️

Authors' Addresses 💌

David Goldsmith
Taligent, Inc.
10201 N. DeAnza Blvd.
Cupertino, CA 95014-2233

Phone: 408-777-5225
Fax: 408-777-5081
EMail: david_goldsmith@taligent.com


Mark Davis
Taligent, Inc.
10201 N. DeAnza Blvd.
Cupertino, CA 95014-2233

Phone: 408-777-5116
Fax: 408-777-5081
EMail: mark_davis@taligent.com

That's the whole RFC, bestie! 🌈💅✨