Handling of Bi-directional Texts in MIME
MIME character-set suffixes for visual, implicit, and explicit text direction.
Nussbacher, H., "Handling of Bi-directional Texts in MIME", RFC 1556, DOI 10.17487/RFC1556, December 1993, <https://www.rfc-editor.org/info/rfc1556>.
@misc{rfc1556,
series = {Request for Comments},
number = 1556,
howpublished = {RFC 1556},
publisher = {RFC Editor},
doi = {10.17487/RFC1556},
url = {https://www.rfc-editor.org/info/rfc1556},
author = {H. Nussbacher},
title = {{Handling of Bi-directional Texts in MIME}},
pagetotal = 3,
year = 1993,
month = dec,
} RFC text
Contents
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
ISO Plain Language
On this page
§1The Mixed-Direction Text Problem
MIME can transport non-ASCII character sets such as Arabic ISO-8859-6 and Hebrew ISO-8859-8. These languages are read right to left, and a line may mix them with English text.
The memo describes character-set names that indicate whether the text uses implicit or explicit direction. The default remains visual direction using the previously defined ISO-8859 character sets.
A message may contain both right-to-left and left-to-right text. A display system needs to know which direction method the text expects.
§2Three Presentation Methods
Visual direction displays all text according to the primary left-to-right display direction. The composing application must arrange the text so it displays correctly; the display application does not analyze its direction. This is the simplest method and the default for MIME text in this memo.
Implicit direction uses an algorithm based on character types and their positions. Explicit direction uses control sequences interleaved with the text. The RFC points implementers to ECMA TR/53 for the detailed rules.
Visual mode displays the prepared text as it is. Implicit mode works out direction from characters, while explicit mode marks direction with control codes.
§3Character-Set Suffixes
The examples append -i for implicit mode and -e for explicit mode to character-set names. Examples include ISO-8859-6-i and ISO-8859-8-e.
The RFC says these names identify the direction method to use with the character data. Without either suffix, visual direction remains the default.
The suffix -i identifies implicit direction, and -e identifies explicit direction. With no suffix, the memo specifies visual direction.