Summary
- RFC 1523 deliberately limited
text/enriched: an ASCII or compatible body was meant to remain tolerable when shown raw, while a minimal MIME reader could strip formatting commands and recover readable prose. - That fallback was a controlled projection, not equivalence. Unknown effects, hidden parameters, receiver-chosen rendering and a different
multipart/alternativeselection could disappear even when every visible word survived.
A format designed to lose something safely
Rich text usually advertises what it can add. RFC 1523, published as Informational in September 1993, is more revealing for what it expected a recipient to remove. Its text/enriched media type refined the earlier text/richtext of RFC 1341. The aim was not to reproduce a word processor. It was to carry a modest vocabulary of emphasis, layout and appearance through Internet mail without making every reader equally sophisticated.
The specification imposed an unusual test: a teletype-oriented system should be able to delete the formatting and leave understandable text. If the charset was ASCII or an eight-bit superset, even a non-MIME reader displaying the raw data should encounter something reasonably legible. Capability was kept deliberately narrow because a smaller vocabulary was more likely to be rendered correctly by the recipient's ordinary tools.
This was not a claim that formatting was ornamental. It was an engineering decision about which losses should be survivable. A sender could ask for bold, centred, fixed-width or indented text. A weak reader could discard the request and still expose the enclosed words. Interoperability came from defining a degraded view, not from making all displays identical.
Angle brackets carried a small grammar
Commands were case-insensitive ASCII names enclosed in angle brackets and limited to 60 characters. A literal less-than sign was written as <<. Most formatting environments required a matching closing command, and pairs had to be balanced and properly nested.
That discipline moved work toward the composer. The RFC acknowledged the extra burden, then explained the return: a displayer could maintain a stack. An opening command pushed a state; the corresponding close restored the previous one. A malformed crossing of environments might still be handled reasonably, but it was not part of the promised syntax.
Line endings also had semantic rules. One CRLF became a space. A run of N consecutive CRLF sequences became N−1 displayed line breaks. A transport system could therefore wrap a long physical line without necessarily creating a new paragraph in the rendered message. Blank lines still survived as visible separation.
The rule looks like typography, but it also defined an evidence boundary. The received octets, reconstructed logical text and displayed paragraph layout were related records, not interchangeable ones. If a gateway inserted a wrap or a parser mishandled a run of CRLFs, the final screen alone could not explain which actor changed the structure.
Ignoring a command was specified behaviour
RFC 1523 required an unknown formatting command to act as a no-op. Its enclosed material remained available; the requested effect did not. Names beginning X- were reserved for private experiments, while a formal addition required another Internet document.
This made extension safer than treating every unfamiliar token as fatal. An older reader could pass through text written for a newer one. Yet the success was bounded. A red warning, a specialised annotation or a future semantic distinction could collapse into ordinary prose. The reader had preserved characters while losing the author's intended signal.
Parameters made the distinction sharper. A <param> environment supplied data to another command. A reader could interpret that data or ignore it, but it was not supposed to display it to the user. A minimal implementation therefore removed both formatting tokens and parameter contents. The visible fallback might be fluent while an extension-specific value vanished completely.
That is why “the message was readable” is not a complete provenance claim. One must ask which parser recognised which commands, what it did with parameters, and which display decisions it made locally.
The receiver still chose the page
The format did not fix one visual result. Font availability, line width, indentation increments, justification and combinations of effects depended on the receiving environment. When a reader could not honour simultaneous instructions, it could prefer the innermost recognised command. Correct parsing could therefore lead to several legitimate screens.
Two special environments show that even plain-text recovery required state. nofill disabled normal filling and CRLF processing while leaving other enriched commands active. verbatim went further: it suppressed filling, justification and embedded formatting interpretation until its own closing token. A tool could not safely delete every angle-bracketed string in one blind pass; it had to know when the grammar itself had changed.
The RFC specified a minimal conformance path: recognise the literal delimiter and relevant environments, remove parameters and formatting commands, and apply the line-break rules. That was a useful lower bound. It did not certify preservation of emphasis, page geometry, hidden values or human interpretation.
Alternative parts made unequal views explicit
For content beyond the small enriched vocabulary, RFC 1523 pointed toward multipart/alternative. A sophisticated composer could include a broadly readable text/enriched part and a richer representation such as ODA. A capable recipient could select the richer part; another could select the enriched one.
Both might have received the same multipart object successfully while reading different representations. The selected alternative, capability negotiation and rendering path were therefore part of the historical event. Saying only “delivery succeeded” erases the decision that determined what the person actually saw.
The document itself said the mechanism introduced no security issues. That sentence belongs to its 1993 assessment. It is not proof that later extensions, MIME handlers, parser implementations or surrounding applications were universally safe. The defensible historical claim is narrower: RFC 1523 bounded a presentation language and defined how weak recipients could fall back.
RFC 1563 obsoleted RFC 1523 within months, and RFC 1896 later obsoleted RFC 1563. That lineage shows revision of the specification, not simultaneous replacement of deployed software.
The frozen sources identify no named reader, deployment or message. They measure no adoption level or user response and report no observed malformed-input outcome. They establish the format rules and documentary lineage, not the behaviour of a particular installation.
The durable record is layered. Preserve the source bytes and charset; physical line structure; parsed command stack; supported and unknown command decisions; parameter values and whether they were hidden or ignored; selected multipart alternative; rendered output; and the recipient's interpretation. A readable fallback is valuable precisely because it survives loss. It should never be mistaken for proof that nothing important was lost.
Sources
- RFC Editor record for RFC 1523
- RFC 1523 — The text/enriched MIME Content-type
- RFC 1341 — MIME
- RFC 1521 — MIME Part One
- RFC 1563 — The text/enriched MIME Content-type
- RFC 1896 — The text/enriched MIME Content-type
- RFC 2046 — MIME Part Two
- Heng Lu — Running-Code Primacy
- Heng Lu — Minimum Initial Specification
- Heng Lu — On Reality Layers
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
