RFC 1556

Handling of Bi-directional Texts in MIME 🎀

okay bestie, so RFC 1556 💖 is titled Handling of Bi-directional Texts in MIME. It came from the Network Working Group, and H. Nussbacher from the Israeli Inter-University Computer Center wrote it in December 1993. It's in the Informational category, which means it's not an Internet standard (more on that below 👀). It doesn't obsolete or update anything, since neither field is listed in the header.

Status of This Memo ✨

This memo gives information to the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 🌸

Abstract 🦋

This doc explains the format and syntax of the "direction" keyword that you use with bi-directional texts in MIME.

Description 💅

okay so the MIME standards (RFC 1521 and 1522) figured out how to send non-ASCII data through a regular RFC822 email system. The Content-type field can hold basically any ISO language, like Arabic (ISO-8859-6) or Hebrew (ISO-8859-8). The problem is that these two languages get read right to left, and you can end up with bi-directional data, like Hebrew and English mixed on the same line. 😭

Luckily, ECMA (European Computer Manufacturers Association) already tackled this, and they put out a technical report called "Handling of Bi-Directional Texts." It's called ECMA TR/53 🧚. It was used to update Standard ECMA-48, and ECMA-48 became the basis for ISO/IEC 6429, which got in through a special "fast track procedure." Based on all that, a new character set is being defined that says whether the bi-directional message is encoded in implicit mode or explicit mode. The default is visual mode, which doesn't need any special character set beyond the standard ones already defined by ISO-8859. 🫶

Here are some examples of the new character sets for bi-directionality support:

Content-type: text/plain; charset=ISO-8859-6-e
Content-type: text/plain; charset=ISO-8859-6-i
Content-type: text/plain; charset=ISO-8859-8-e
Content-type: text/plain; charset=ISO-8859-8-i

The "i" suffix means implicit mode, and the "e" suffix means explicit mode. ✨

Implicit 🌈

Implicit directionality is a presentation method where the direction gets figured out by an algorithm. That algorithm looks at the type of each character, its position next to its neighbours, and their primary direction. It's honestly quite complex 😵‍💫, so sites that want to implement it should check the ECMA Technical Report for the full details.

Explicit 🔥

Explicit directionality is also a presentation method, but here the direction is spelled out directly using control sequences woven into the text. ECMA TR/53 also defines this method. It adds three new control functions and updates 22 existing control functions in the ECMA-48 standard. Iconic energy 👑

Visual 🍓

Visual directionality is a presentation method that only displays text according to the primary display direction, which is left to right. Everything is shown in that one direction. The displaying application has no idea what direction the content is, so it just shows the text like it's uni-directional. That means the composing application has to set up the text so it displays correctly. No control characters or algorithms decide how things get displayed. It's the simplest method of all, and it's the default for MIME encoded texts. 💜

References 📚

• [ECMA TR/53] Handling of Bi-Directional Texts, European Computer Manufacturers Association, 114 Rue du Rhone, CH-1204, Geneva, Switzerland, June 1992.
• [ISO-6429] Information Technology - Control Functions for Coded Character Sets, 3rd edition, December 15, 1992.
• [ISO-8859] Information Processing -- 8-bit Single-Byte Coded Graphic Character Sets, Part 6: Arabic alphabet, ISO 8859-6, 1988.
• [ISO-8859] Information Processing -- 8-bit Single-Byte Coded Graphic Character Sets, Part 8: Latin/Hebrew alphabet, ISO 8859-8, 1988.
• [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, August 1982.
• [RFC1521] Borenstein N., and N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", Bellcore, Innosoft, September 1993.
• [RFC1522] Moore K., "MIME Part Two: Message Header Extensions for Non-ASCII Text", University of Tennessee, September 1993.

Security Considerations 🙈

Security issues are not discussed in this memo. 💀

Author's Address 🫶

Hank Nussbacher Computer Center Tel Aviv University Ramat Aviv Israel

Fax: +972 3 6409118 Phone: +972 3 6408309 EMail: hank@vm.tau.ac.il