Summary

  • RFC 1556 described three ways to present mixed right-to-left and left-to-right mail: visual order prepared by the composer, implicit order resolved by an algorithm, and explicit order directed by controls inside the text.
  • MIME could preserve non-ASCII content without proving that a recipient would reconstruct the intended reading order; charset, direction mode and renderer context were separate parts of the receipt.
  • The memo was Informational, not an Internet Standard. Later HTML, Unicode and UTF-8 mail work show the boundary persisted, but do not prove a direct technical lineage or adoption of RFC 1556's labels.

Two readers received the same line

Imagine a 1993 mail message whose subject or body alternates between Hebrew and English, with a date and a product number in the middle. Its MIME transfer encoding is valid. The receiving system decodes every octet into the intended character. An archive retains the message without a damaged byte.

One reader shows the line as the writer expected. Another moves the English phrase, punctuation and number into a different visible relationship. A third appears correct until the text is copied into a new window, where its order changes again.

No transport checksum can settle the dispute. All three systems may possess the same characters. Their disagreement begins after delivery, when each decides how a stored sequence becomes a line for human eyes.

That was the boundary addressed by RFC 1556, Handling of Bi-directional Texts in MIME. Hank Nussbacher published the memo in December 1993. Its RFC Editor record and IETF record classify it as Informational. It explicitly specified no Internet standard.

Its proposal was small: describe a direction convention for bidirectional MIME text and distinguish three presentation modes. The problem behind that small syntax was larger. A network could deliver representation without delivering a unique rendering decision.

MIME solved the journey before it solved the line

RFC 1521 gave Internet mail a way to describe message bodies beyond flat ASCII. A body part could identify a media type and charset, then use Base64 or Quoted-Printable so its octets survived mail infrastructure built around older constraints. The record for RFC 1521 preserves that historical role.

RFC 1522 extended the arrangement to selected header fields. A composer turned non-ASCII text into an encoded-word. A supporting reader recognized it, reversed the transfer encoding and displayed the resulting text in the named character set. Its information page identifies it as the companion header specification.

These were major interoperability steps, but their receipts stopped at a boundary. A charset maps encoded values to characters. A transfer encoding protects those values through a constrained path. Neither fact alone says whether a mixed Arabic-and-English or Hebrew-and-English line should be displayed left-to-right, right-to-left, or with local reversals around embedded spans.

RFC 1556 therefore began where a successful MIME decoder could still fail the reader. It named Arabic ISO-8859-6 and Hebrew ISO-8859-8 as character sets that could carry right-to-left scripts and mixed-direction material. Getting the letters right was necessary. It was not the same as getting their visual relationships right.

The companion Hebrew memo exposed the separation

The adjacent RFC 1555, by Nussbacher and Yehavi Bourvine, specified Hebrew mail using MIME and ISO-8859-8. Its RFC Editor entry also marks it Informational.

The memo said the default directionality was visual. Hebrew text was encoded from left to right—even though it was entered and read from right to left—and then transmitted left to right by ordinary MIME mechanisms. The receiving display did not reconstruct an abstract logical sentence. The composer had already arranged the stored characters for the expected screen.

That design made a direction-unaware viewer possible, but it transferred fragility upstream. A visual-order archive carried the intended appearance only while later software refrained from reinterpreting it as logical-order text. Feed the same sequence into an implicit bidirectional engine and the engine may reorder what the composer already reordered.

RFC 1555 also described a more basic loss. Some Listserv configurations omitted the MIME headers when redistributing or archiving mail. Without those headers, encoded content could remain present while the information needed to interpret it disappeared. The file was not necessarily empty or corrupt. The contract around it had been stripped.

Its forecast was especially revealing. Transparent 8-bit mail might make Base64 or Quoted-Printable partly obsolete, the authors wrote, but Content-Type and directionality would still be needed. A cleaner pipe could remove a transfer burden without answering who owned presentation.

Visual mode made the composer responsible

RFC 1556's first mode was the default: visual directionality, using the ordinary ISO-8859 charset name rather than one of the new suffixed labels.

The display had one primary direction, left to right. The viewing application treated the text as unidirectional and did not know the direction of its contents. The composing application had to prepare the sequence so it would look correct when emitted in that fixed order. No direction control characters and no ordering algorithm intervened at display time.

The attraction is easy to see. A simple recipient can show the message. An old terminal does not need a linguistic model. What the sender sees can be serialized as an already arranged row.

The cost is hidden state. The intended order exists in the composer's preparation and in the assumption that the recipient will not reorder again. Editing, searching, cursor movement, line wrapping and copy-and-paste operate on a sequence whose stored order follows one anticipated display rather than the sentence's logical structure. Change the width or insert a Latin token and the old arrangement may no longer describe the new line.

Visual mode therefore did not eliminate directionality. It placed the decision before transmission and made a direction-blind viewer part of the contract.

Implicit mode made an algorithm responsible

For implicit directionality, RFC 1556 proposed i suffixed charsets: ISO-8859-6-i and ISO-8859-8-i.

Here the stored characters were not expected to carry every local display move. Presentation was determined by an algorithm using character types, positions relative to adjacent characters and a primary direction. The memo referred implementers to ECMA TR/53 because the full procedure was complex.

Responsibility moved downstream. The composer could retain a more logical sequence, but the recipient had to recognize the mode, assign compatible directional properties and resolve the same context. Base direction mattered. So did punctuation, numbers, neutral characters and the point at which a line was wrapped.

Implicit mode converted an invisible editorial assumption into an executable dependency. Two viewers could receive the same declared charset and still disagree if they implemented different rule revisions, supplied different paragraph direction or divided the text into lines differently. The correct receipt needed more than the payload hash. It needed the decision environment.

That does not make algorithms arbitrary. A shared algorithm can greatly improve interoperability. It means only that its output is an additional technical result, not a property already proven by transport.

Explicit mode made controls and their interpreters responsible

The other proposed labels were ISO-8859-6-e and ISO-8859-8-e. In explicit mode, control sequences were interleaved with the text to declare directional behavior.

This made the author's instruction more visible in the data stream. A sender could open or change a directional context rather than relying only on the types of surrounding characters. But explicitness added two preservation duties: the controls had to survive, and the renderer had to understand their scope.

A sanitizer that removed unfamiliar control functions might retain every visible letter while deleting the order instructions. A converter could preserve the controls as opaque data but place them in a renderer that ignored them. An unmatched or misplaced control could extend influence farther than intended. The displayed result depended on the token stream and a state machine interpreting tokens that themselves had no visible glyph.

RFC 1556 said the underlying ECMA TR/53 work introduced three control functions and modified 22 existing ECMA-48 functions. That scale is a warning against describing explicit mode as a single “right-to-left marker.” Direction affected active positions, movement and the relationship between stored data and presentation.

ECMA separated the data surface from the presentation surface

ECMA TR/53's device model makes the architectural issue clearer than the word “direction” does. A bidirectional imaging device received a stream of graphic characters and control functions. It could maintain a data component and a presentation component, then produce a human-readable graphic image according to the relevant writing convention.

Those components were not decorative abstractions. An active data position and an active presentation position could move according to different rules. Implicit, explicit and indirect movement had to be defined. A backspace, carriage return or cursor report could not be interpreted safely without knowing which component and which direction it concerned.

RFC 1556 compressed that deeper machinery into a MIME-facing distinction. The message needed to tell the viewing side which family of assumptions it was receiving. Without that, the same byte sequence could enter the wrong presentation machine.

This is why bidirectional text was never merely a choice of font. The font selects glyphs. The ordering contract determines which glyph appears beside which other glyph, and how a human reconstructs the sentence.

Four failures could preserve every visible character

The first failure is lost metadata. A gateway or archive retains the body but drops or normalizes its Content-Type. ISO-8859-8-i becomes ISO-8859-8, or the direction declaration disappears. The character values remain; the mode selection does not.

The second is double reordering. A composer stores visual order for a simple viewer. A modern renderer assumes logical order and applies an implicit algorithm. Both components perform the action they were designed to perform, and the line becomes wrong because they performed it twice.

The third is control stripping. Explicit directional instructions are removed as nonprinting or suspicious characters. A byte comparison after the sanitizer correctly shows a change, but a plain-text comparison of visible letters may falsely report equivalence.

The fourth is context drift. Two implicit renderers use different base direction, line break, markup boundary or algorithm revision. Their decoded character sequence is identical. Their resolved visual sequence is not.

Numbers and punctuation make these failures operationally significant. A reversed phrase is obvious; a punctuation mark attached to the wrong side of an identifier may not be. A user may copy a visually plausible address or reference number whose logical order differs from the screen. Correctness cannot be audited by asking only whether all characters are present.

Later systems kept the boundary and changed the machinery

Later specifications are useful only if their relationship is kept narrow. RFC 2070, published in 1997, added internationalization features to HTML, including a DIR attribute and a BDO override element. Its record belongs to web markup, not MIME charset suffix deployment.

An early version of the Unicode Bidirectional Algorithm described Unicode text in logical memory order and directional formatting codes as affecting display order rather than character interpretation. The current UAX #9 has evolved substantially and defines how higher-level protocols may establish context or impose directional behavior.

RFC 6532, whose information page dates it to 2012, later allowed direct UTF-8 in Internet message header values under an end-to-end UTF-8 model. That reduced the need for encoded-word indirection in such messages. It did not merge the stored-character layer with the display-order layer.

These documents do not prove that RFC 1556 became HTML directionality, the Unicode algorithm or SMTPUTF8. They show a recurring boundary: enlarging the character repertoire and protecting it in transit do not by themselves select one human-visible order.

One screenshot is not a conformance record

A useful investigation preserves three receipts.

The transfer receipt contains the original octets, content hash, transport encoding and decoded character sequence. It answers whether the representation changed on its journey.

The interpretation receipt preserves Content-Type, charset and direction mode; explicit directional controls; paragraph or base direction; higher-level markup and styling; and the renderer and algorithm version. It answers which rules the recipient believed it should apply.

The presentation receipt records line segmentation, resolved visual order, a screenshot and copy/paste or round-trip behavior. It answers what appeared and whether the apparent order survived reuse.

A screenshot without its input can prove that one screen once showed one arrangement. It cannot prove that the stored sequence was correct, that another width would behave the same or that copying the text would preserve meaning. A payload hash without a render record proves the complementary half and no more.

Paired fixtures should mix Arabic or Hebrew with Latin spans, numbers, punctuation, neutral characters, nested contexts and different line widths. They should compare the stored sequence and the resolved display separately. When a migration changes a renderer, both old and new results should be retained until the difference is explained; silently rewriting the archive destroys the evidence needed to reverse a bad choice.

Publication was not operational reality

Heng Lu's Running-Code Primacy provides a useful present-day discipline: a document is a coordination artifact whose claims still have to survive implementation, operation and use. RFC 1556's publication proves that a directionality convention was documented. It does not prove which mail systems implemented it or what readers saw.

Minimum Initial Specification, Localized Future Decision and Voluntary Adoption asks which common rules are truly required and locally verifiable. RFC 1556 reveals that equality of transmitted characters was too weak an invariant for readable bidirectional mail. Mode, preserved context and a compatible presentation procedure were also needed.

The reality-layer lens prevents one receipt from impersonating another. Representation, carriage, interpretation and visible outcome belong to separate layers. The later doctrine is not evidence of Nussbacher's or ECMA's intentions; it is a way to keep our own historical claims within what the sources prove.

The missing question was who had already acted

Visual, implicit and explicit directionality were not merely three rendering preferences. They were three answers to a responsibility question.

In visual mode, the composer had already acted. In implicit mode, the receiver's algorithm would act. In explicit mode, the sender supplied commands and the receiver executed them. A system that did not know which answer applied could be perfectly faithful to its own assumptions and still be wrong for the message.

The history of RFC 1556 is therefore not a tale of MIME failing to carry Hebrew or Arabic. MIME made the journey possible. The memo identified what the journey could not certify.

An intact message is a receipt for sequence preservation. A declared mode and retained controls are a receipt for interpretation context. A tested renderer is a receipt for one visible result. Only when all three are preserved can “it arrived correctly” mean more than “the bytes got here.”

Sources