William Allen Simpson wrote:
We covered these issues in great detail in the IETF over a decade ago. There was a lot of acrimonious argument then, too, but Hank (and others) did a great job drafting a technical solution that solved the transmission and editing problems.
(1) A canonical form for storage and transmission. In SMTP, all storage and transmission is LTR. I don't see why that couldn't apply here, too. Sure, it makes Hebrew appear backward in storage, but we usually don't look at the stored version.
(2) Display and edit as RTL. In practice, this turned out to be fairly simple by thinking about such things as opening and closing parentheses, rather than left and right. They simply are reversed on display.
(3) This allows all email to be parsed consistently, without change to the existing mail transmission programs, while specialized mail user agents (MUA) handle display of the text body.
Well, we work in a Unicode/XML/HTML context, and for better or for worse the W3C world has explicitly embraced bidirectional text stored in logical order.
Parsing of markup happens on text in logical order. Since the markup is very much embedded in the text and requires both exposure to human editors and consistent parsing by the machine, I'm not sure that e-mail is a good comparison. The 'markup' in e-mail is invisible to the user: headers, escape codes, MIME content part separators.
Our output is to HTML, and editing is done in a web browser. This is a heavily bidi-centric environment which I don't think we could really override if we wanted to.
-- brion vibber (brion @ pobox.com)