As per Relevance of the word direction, we have this rfc below:
Network Working Group H.
Request for Comments: 1556 Israeli Inter-
Category: Informational Computer
December 1993
Handling of Bi-directional Texts in
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
This document describes the format and syntax of the "direction
keyword to be used with bi-directional texts in MIME
The MIME standards (RFC 1521 and 1522) defined methods
transporting non-ASCII data via a standard RFC822 e-mail system
Specifically, the Content-type field allows for the inclusion of
ISO language such as Arabic (ISO-8859-6) or Hebrew (ISO-8859-8).
problem is that the these two languages are read from right to
and can have bi-directional data such as mixed Hebrew and English
the same line
Fortunately, ECMA (European Computer Manufacturers Association)
tackled this problem previously and has issued a technical
called "Handling of Bi-Directional Texts". ECMA TR/53, as it
called, was used to update the Standard ECMA-48 which in turn
used as the basis for ISO/IEC 6429 which was adopted under a
"fast track procedure". It is based on this information that a
character set is being defined which will indicate that the bi
directional message is either encoded in implicit mode or
mode. The default is visual mode which requires no special
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-
Content-type: text/plain; charset=ISO-8859-6-
Content-type: text/plain; charset=ISO-8859-8-
Content-type: text/plain; charset=ISO-8859-8-
Nussbacher [Page 1]
RFC 1556 Bi-directional Texts December 1993
The "i" suffix refers to implicit mode and the "e" suffix refers
explicit mode
Implicit directionality is a presentation method in which
direction is determined by an algorithm according to the type
characters and their position relative to the adjacent characters
according to their primary direction. The complete algorithm
quite complex and sites wishing to implement it should refer to
ECMA Technical Report for further details
Explicit directionality is a presentation method in which
direction is explicitly defined by using control sequences which
interleaved within the text and are used for direction determination
This presentation method is also defined in ECMA TR/53, which
three new control functions and updates 22 existing control
in the ECMA-48 standard
Visual directionality is a presentation method that displays
according to the primary display direction only, which is left
right. All text is viewed in the same direction which is the
display direction. The displaying application is not aware of
contents direction and displays the text as if it were a uni
directional text. The composing application needs to prepare
text in such a way that it will be displayed correctly. No
characters or algorithms are used to determine how the data is to
displayed. This is the simplest of all methods and the default
for use with MIME encoded texts
[ECMA TR/53] Handling of Bi-Directional Texts, European
Manufacturers Association, 114 Rue du Rhone, CH-1204,
Geneva, Switzerland, June 1992.
[ISO-6429] Information Technology - Control Functions for
Character Sets, 3rd edition, December 15, 1992.
[ISO-8859] Information Processing -- 8-bit Single-Byte
Graphic Character Sets, Part 6: Arabic alphabet,
8859-6, 1988.
Nussbacher [Page 2]
RFC 1556 Bi-directional Texts December 1993
[ISO-8859] Information Processing -- 8-bit Single-Byte
Graphic Character Sets, Part 8: Latin/Hebrew alphabet
ISO 8859-8, 1988.
[RFC822] Crocker, D., "Standard for the Format of ARPA
Text Messages", STD 11, RFC 822, UDEL, August 1982.
[RFC1521] Borenstein N., and N. Freed, "MIME (
Internet Mail Extensions) Part One: Mechanisms
Specifying and Describing the Format of
Message Bodies", Bellcore, Innosoft, September 1993.
[RFC1522] Moore K., "MIME Part Two: Message Header Extensions
Non-ASCII Text", University of Tennessee
September 1993.
Security
Security issues are not discussed in this memo
Author's
Hank
Computer
Tel Aviv
Ramat
Fax: +972 3 6409118
Phone: +972 3 6408309
EMail: hank@vm.tau.ac.
Nussbacher [Page 3]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
