From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1556.txt | 171 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 171 insertions(+) create mode 100644 doc/rfc/rfc1556.txt (limited to 'doc/rfc/rfc1556.txt') diff --git a/doc/rfc/rfc1556.txt b/doc/rfc/rfc1556.txt new file mode 100644 index 0000000..228d721 --- /dev/null +++ b/doc/rfc/rfc1556.txt @@ -0,0 +1,171 @@ + + + + + + +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, 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. + + + + + +Nussbacher [Page 2] + +RFC 1556 Bi-directional Texts December 1993 + + + [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 + + + + + + + + + + + + + + + + + + + + +Nussbacher [Page 3] + \ No newline at end of file -- cgit v1.2.3