RFC1556 - Handling of Bi-directional Texts in MIME

王朝other·作者佚名  2008-05-31
宽屏版  字体: |||超大  

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 (RFC1521 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, RFC822, 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

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
© 2005- 王朝网络 版权所有