RFC 1556 INFORMATIONAL TEXT DIRECTION · MIME · INTERNATIONALIZATION

Handling of Bi-directional Texts in MIME

How to handle text that runs right-to-left (or switches direction) in email.

On rfc-editor.org ↗
PUBLISHED
December 1993
AUTHORS
H. Nussbacher
STREAM
Legacy
IMPLICIT MODE SUFFIX
-i
EXPLICIT MODE SUFFIX
-e
DEFAULT MODE
Visual
LANGUAGES ADDRESSED
Hebrew (ISO-8859-8), Arabic (ISO-8859-6)
DOI
10.17487/RFC1556

RFC text

Contents
Original text · RFC Editor View on rfc-editor.org ↗
Network Working Group                                      H. Nussbacher
Request for Comments: 1556                      Israeli Inter-University
Category: Informational                                  Computer Center
                                                           December 1993


                Handling of Bi-directional Texts in MIME

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Abstract

   This document describes the format and syntax of the "direction"
   keyword to be used with bi-directional texts in MIME.

Description

   The MIME standards (RFC 1521 and 1522) defined methods for
   transporting non-ASCII data via a standard RFC822 e-mail system.
   Specifically, the Content-type field allows for the inclusion of any
   ISO language such as Arabic (ISO-8859-6) or Hebrew (ISO-8859-8).  The
   problem is that the these two languages are read from right to left
   and can have bi-directional data such as mixed Hebrew and English on
   the same line.

   Fortunately, ECMA (European Computer Manufacturers Association) has
   tackled this problem previously and has issued a technical report
   called "Handling of Bi-Directional Texts".  ECMA TR/53, as it is
   called, was used to update the Standard ECMA-48 which in turn was
   used as the basis for ISO/IEC 6429 which was adopted under a special
   "fast track procedure". It is based on this information that a new
   character set is being defined which will indicate that the bi-
   directional message is either encoded in implicit mode or explicit
   mode.  The default is visual mode which requires no special character
   set other than the standard ones previously defined by ISO-8859.

   Examples of 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 refers to implicit mode and the "e" suffix refers to
   explicit mode.

Implicit

   Implicit directionality is a presentation method in which the
   direction is determined by an algorithm according to the type of
   characters and their position relative to the adjacent characters and
   according to their primary direction.   The complete algorithm is
   quite complex and sites wishing to implement it should refer to the
   ECMA Technical Report for further details.

Explicit

   Explicit directionality is a presentation method in which the
   direction is explicitly defined by using control sequences which are
   interleaved within the text and are used for direction determination.
   This presentation method is also defined in ECMA TR/53, which defines
   three new control functions and updates 22 existing control functions
   in the ECMA-48 standard.

Visual

   Visual directionality is a presentation method that displays text
   according to the primary display direction only, which is left to
   right.  All text is viewed in the same direction which is the primary
   display direction.  The displaying application is not aware of the
   contents direction and displays the text as if it were a uni-
   directional text.  The composing application needs to prepare the
   text in such a way that it will be displayed correctly.  No control
   characters or algorithms are used to determine how the data is to be
   displayed. This is the simplest of all methods and the default method
   for use with 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

AI ELI5

On this page
PROBLEMEmail standards assumed left-to-right text, but Hebrew and Arabic run right-to-left and can be mixed with English on the same line, requiring a way to specify directionality in MIME messages.
MECHANISMThe RFC defines character set suffixes (-i for implicit mode, -e for explicit mode) to indicate how bidirectional text should be interpreted, building on ECMA TR/53 standards for handling direction.
WHY IT MATTERSMail systems can now correctly display mixed-direction text by including directionality keywords in the Content-type header (ISO-8859-6-i, ISO-8859-8-e, etc.), or defaulting to visual mode.

§1The Problem of Bidirectional Text

MIME standards (RFC 1521 and 1522) allowed any ISO language character set including Arabic (ISO-8859-6) and Hebrew (ISO-8859-8) to be transported in email. However, these languages are read right-to-left and can contain bidirectional data such as mixed Hebrew and English on the same line. Mail systems needed a way to specify the directionality so that display applications could render the text correctly.

English goes left to right, but Hebrew and Arabic go right to left. Email needs to say which way to read.

§2Three Directionality Models

The RFC defines three presentation methods: Visual directionality displays text according to only the primary (left-to-right) direction and is the simplest and default method for MIME. Implicit directionality determines direction by an algorithm based on character type and position (complex, detailed in ECMA TR/53). Explicit directionality uses control sequences interleaved within text to determine direction. The RFC provides examples for each: Content-type: text/plain; charset=ISO-8859-6-i for Arabic in implicit mode, or ISO-8859-8-e for Hebrew in explicit mode.

Visual mode is simplest: just show the text as-is. Implicit and explicit modes use algorithms or codes to say which way each part reads.

§3Character Set Suffixes

To specify directionality in MIME headers, the RFC extends character set names with suffixes: -i for implicit mode and -e for explicit mode. For example, ISO-8859-6-i indicates Arabic in implicit mode, while ISO-8859-8-e indicates Hebrew in explicit mode. When neither suffix is present, the default is visual mode. This scheme allows mail systems to know which algorithm or control-sequence method to apply when rendering the message body.

You add -i or -e to the character set name to say which way the text should be read.

§4References

[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; Part 8: Latin/Hebrew alphabet, ISO 8859-8, 1988.
[RFC822]RFC 822Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, August 1982.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.