Summary

  • RFC 934 proposed a forwarding and bursting grammar in which a line beginning with a dash could delimit an enclosed message. When the payload itself began with that pattern, the forwarding agent inserted a dash and a space; the bursting agent removed that added prefix.
  • The transformation was reversible only layer by layer. A message forwarded again acquired another prefix on the same line, so recursive composition consumed line length and made the intermediate form operationally important.
  • MIME kept the need for unambiguous framing but moved the responsibility toward an explicitly declared multipart boundary that must not occur within a part. RFC 2046 expressly rejects RFC 934-style recursive hyphen quoting for deeply nested multipart bodies.

A character becomes a decision

An Internet message was already a structured object before RFC 934. RFC 822 separated header fields from the message body at the first empty line. Within the structured fields it also distinguished delimiters, quotation marks and backslashes from ordinary data. A character could be read as grammar in one place and payload in another. The rule did not make the character powerful everywhere. It gave the character a job within a particular parser.

The body was much less typed. RFC 822 described what followed the first null line as text. That was a practical strength for early mail, but it left a later forwarding agent with a question: how can a new outer message carry an older complete message so that a recipient can recover and process the older one again?

RFC 934 proposed two agents for that task. A forwarding agent composes the outer draft before posting; a bursting agent decomposes it after delivery. The outer body can contain introductory text, enclosed messages and final text. The proposal calls the separator an encapsulation boundary. In the initial convention, any line beginning with a dash is an encapsulation boundary.

That definition is intentionally modest. It does not say that a dash identifies a message in the abstract. It says that a bursting agent, scanning this kind of enclosing body at the beginning of a line, must treat the dash as a possible structural event. The exact location and parser state matter. Two adjacent boundaries can mark a null message; one boundary can close one inner message and open the next. The same byte has no independent authority outside that grammar.

This is the first discipline worth retaining. A delimiter is not a label attached to reality. It is a limited instruction to an interpreter that has entered the relevant state. Confusing the two creates the oldest kind of parser failure: information intended as data begins to issue commands because its surrounding context has been forgotten.

The collision was already in the payload

The boundary rule created an immediate collision. A forwarded message was itself made of lines of text. Some of those lines might begin with a dash without intending to end one message or begin another. A digest could contain a quotation, a command example, a sign-off or simply a sentence whose first character happened to be . Once placed inside the outer body, the line could be indistinguishable from the envelope’s structural marker.

RFC 934 noted that existing forwarding agents apparently ignored this situation. Its proposal did not pretend that the collision could be solved by naming the line more confidently. It supplied a transformation.

When the forwarding agent sees a line in the enclosed text that starts with the encapsulation boundary, it outputs a dash followed by a space before outputting the original line. A payload line beginning - notice therefore travels inside the wrapper as - - notice. On the way out, the bursting agent sees a dash followed by a space, decides that this is escaped data rather than a true boundary, removes the added prefix and emits the remainder. RFC 934 describes the result as a simple character-stuffing scheme that permits recursive forwarding.

The mechanism is useful precisely because it is not mystical. The outer writer does not decide what the inner line means. It only prevents the outer grammar from mistaking the line for one of its own control points. The outer reader reverses the exact intervention when it leaves that grammar. The data can recover its earlier form because the transformation carries a recognizable, local witness of what was added.

RFC 822 offers a related intuition in a different setting. Its discussion of network-specific transformations asks a message crossing a network boundary to return to canonical form before the next network’s local conventions are imposed. The important pattern is not that every transformation is harmless. It is that a transformation has an owner, a stated scope and a reversal point. The packet of meaning must not accumulate local conventions forever merely because it travelled.

Reversible does not mean free to compose

RFC 934’s own claim about recursive forwarding is true in the narrow, useful sense. One forwarding layer can quote a dangerous line; one bursting layer can remove the quote it added. A nested message can therefore survive a round trip if every participant applies the grammar correctly.

But recursive forwarding changes the intermediate representation. Suppose the protected inner line is already - - notice because one wrapper has escaped it. A second forwarding agent sees another line beginning with a dash. It adds its own dash-space. The new outer representation becomes - - - notice. A third layer makes it longer again. Each bursting layer removes only the prefix for which that layer is responsible.

Nothing is logically inconsistent about this. The original data can still be recovered after the corresponding number of inversions. The cost is physical and operational rather than purely grammatical: the line grows while it is in transit. A design that is perfectly invertible at one level can still become difficult to carry, inspect, relay or preserve when it is repeatedly embedded.

That distinction matters far beyond mail. A round-trip test proves only that an encoder and its matching decoder agree under the tested nesting. It does not prove that a relay will preserve the expanded representation, that a line budget remains adequate, that an intermediary will not wrap or normalize it, or that operators can determine which layer inserted which prefix. Intermediate state is not an embarrassment to be ignored. It is where systems actually interoperate.

RFC 934 itself did not hide the practical pressure of inherited behaviour. It was designed to minimize changes to existing forwarding agents. It recommends that implementers who want compatibility with existing bursting agents consider blank lines around boundaries, then immediately says a forwarding agent that strictly adheres to the proposal should not generate those blank lines. The document records a living compatibility field, not a clean room in which one published grammar could erase all prior practice.

That is running-code discipline in its ordinary, unglamorous form. The meaningful question is not whether a delimiter rule looks elegant on paper. It is what the writers, readers and relays can preserve together. A formal grammar matters because it coordinates actual transformations. It does not replace the transformations.

MIME moved the framing decision

Eleven years later, RFC 2045 described MIME as building on earlier work including RFC 934, RFC 822 and RFC 1049. MIME supplied typed entities, content descriptions and multipart bodies rather than treating every message body as one undifferentiated field of text. This was not a declaration that old mail stopped existing at publication. It was a new shared syntax for participants that elected to use it.

The multipart rule in RFC 2046 assigns responsibility differently. A multipart Content-Type declares a boundary parameter. The delimiter line begins with two hyphens and that declared value. The delimiter must not appear within an enclosed part, either as a line by itself or as the prefix of a line, and nested multipart entities must use distinct boundary values. The composing agent has a concrete obligation: choose a boundary that will not collide with the material it encloses.

This does not make a boundary a global truth either. Its authority comes from the enclosing entity’s declared parameter and the multipart grammar. A parser that sees the same characters in an unrelated plain-text body has no basis to treat them as an envelope. The header and body are cooperating to state both what is structural and where that claim applies.

RFC 2046 makes the historical comparison unusually explicit. It says the two leading hyphens are partly for rough compatibility with the RFC 934 method and to help implementations search for boundaries. It also says multipart messages are not completely compatible with RFC 934 encapsulations: they do not obey RFC 934’s convention for quoting embedded lines that begin with hyphens. The stated reason is exactly the composition problem. The older convention causes lines to grow at each level of quoting; paired with SMTP implementations that sometimes wrap long lines, that made it unsuitable for potentially deep multipart nesting.

The change is not an indictment of the earlier mechanism. RFC 934 solved a real collision with a small parser and an invertible local transform. MIME faced a broader, typed and potentially nested body model and chose to place the collision-avoidance work at boundary selection instead. The comparison exposes a design choice: modify ambiguous payload each time it enters a wrapper, or declare a wrapper-specific marker that is selected not to occur in the payload.

Both choices still require evidence. A writer must know enough about the data to avoid a MIME boundary collision. A receiver must parse the correct enclosing declaration before honoring a line as a delimiter. A gateway must preserve the relevant bytes and line endings. The new design changes the accounting of ambiguity; it does not abolish it.

The authority of a separator must expire

The useful lesson from RFC 934 is not that every system should use character stuffing, nor that every system should use MIME. It is a question to put to any layered format: when a symbol acquires structural authority, how precisely does it lose it again?

For RFC 934, the answer is visible. The forwarding agent puts a dash-space before a payload line so the enclosing burst parser will not misclassify it. The burst parser removes that prefix and returns the line to the inner message. The rule is reversible because the grammar makes the boundary between outer syntax and inner data explicit enough to undo.

For MIME, the answer begins earlier. The sender declares a boundary value for this multipart entity and is responsible for keeping it out of enclosed material. The receiver applies that declaration to the entity it is parsing. Structure is scoped by the enclosing header, not inferred from an arbitrary dash line in the wider world.

These are small mechanisms with a large governance consequence. A system becomes fragile when temporary markers outlive their jurisdiction: a transit escape is stored as canonical data, a cache entry is mistaken for a permanent identity, a parser rule is applied before its envelope has been established, or a presentation label is promoted into an executable instruction. The remedy is not ceremony. It is a narrow common rule, local validation, an observable transformation and a way back.

RFC 934’s expanding dash is a vivid reminder that reversibility also needs a budget. Ask whether a transformation grows under composition, who observes the growth, where it encounters limits, and whether another layer can safely normalize it without erasing the information required to reverse it. Those questions turn an abstract escaping convention into an operational design review.

Sources and evidence limits

The closed evidence set is RFC 822, RFC 934, RFC 2045 and RFC 2046. It establishes the historical formats, the stated forwarding and bursting rules, and MIME’s documented contrast with RFC 934. It does not establish universal deployment, the behaviour of any contemporary mail product, the safety of a particular parser, or a measured frequency of deeply nested mail.