Browse Prior Art Database

Handling of Bi-directional Texts in MIME (RFC1556)

IP.com Disclosure Number: IPCOM000002389D
Original Publication Date: 1993-Dec-01
Included in the Prior Art Database: 2019-Feb-13
Document File: 3 page(s) / 4K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

H. Nussbacher: AUTHOR

Related Documents

10.17487/RFC1556: DOI

Abstract

This document describes the format and syntax of the "direction" keyword to be used with bi-directional texts in MIME. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 59% of the total text.

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

Nussbacher [Page 1]

RFC 1556 Bi-directional Texts December 1993

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...

Processing...
Loading...