Summary

  • RFC 3391 divided MIME messages into numbered, length-delimited chunks and interleaved them so a referenced image could arrive immediately before or after the root-document passage that named it.
  • Proximity was a producer's schedule, not knowledge of the consumer: the format could not reveal layout, memory capacity, parsing order or discard time, and malformed schedules could make storage grow without a useful bound.

Picture a scanner feeding pages to a distant printer. The scanner discovers each image only as it reaches that page. A conventional compound MIME object offers an awkward choice: put every attachment before the main document, forcing the receiver to hold them, or put every attachment after it, forcing the receiver to wait. Either order is tidy on paper and poorly matched to a document that becomes known over time.

RFC 3391, published as an Informational document in December 2002, offered a third order. Its media type, application/vnd.pwg-multiplexed, allowed the producer to split several MIME messages into pieces and weave those pieces through one byte stream. The root document could advance until it was about to refer to an image; the image could then appear just before or just after that point. The distance between request and material became an object the producer could manage.

The proposal did not invent a new kind of compound document. It carefully separated the compound object from its representation. The object had a root component and other components referenced from it. multipart/related represented those components as sequential body parts divided by boundary strings. RFC 3391 represented them as MIME messages carried inside numbered chunks. Each reassembled message was intended to match, octet for octet, the body part that would have represented the same component in multipart/related.

The difference lay in scheduling. A chunk began with CHK, followed by a message number, a payload length and either MORE or LAST. The length made the payload self-delimiting; a CRLF provided visual separation from the next header. MORE promised another piece of the same message, while LAST closed it. Chunks belonging to different messages could alternate, yet the pieces of any one message had to remain in their original order.

Two boundaries kept the stream intelligible. The first chunk had to contain all or part of the root message. Even this rule allowed an empty payload, a convenience that let the first actual root bytes come later. At the other end, CHK 0 0 LAST closed the entity. Message number zero belonged to this sentinel. Seeing it too soon did not magically repair missing endings: the RFC says consumer behaviour is undefined if the final chunk appears before every message has received its last chunk.

Message numbers normally identified one message, but the format did not absolutely forbid reuse. If a number was reused, each earlier message with that number had to reach a LAST before the next began. That detail illustrates the design's temperament. It tolerated implementation convenience, including adjacent chunks with the same number and zero-length payloads, while retaining a precise reconstruction rule.

The required type parameter declared the media type of the root message. It gave a consumer a way to know the compound object's type before inspecting the enclosed root. If declaration and root disagreed, behaviour was undefined. Content-ID and Content-Location could connect references to components using established MHTML patterns; RFC 3391 did not claim authority over the relationship language itself.

Its printing examples explain why all this machinery existed. Suppose a long print stream names images as pages are generated. With multipart/related, images placed after the root cannot help until the root has ended; images placed before it require the producer to discover and the consumer to store them in advance. A multiplexed stream can pause the root, send the relevant image, then continue the root. A high-speed printer need not wait for the entire document to learn whether the material for its first page has arrived.

The scanning example reverses some pressures. Each scanned page may have one image and one root reference. Sending an image immediately before or after its reference lets the producer work progressively instead of buffering the whole job. This is locality in the literal sense: fewer octets stand between a name and the bytes it names.

But the third example turns the attractive diagram around. The consumer, not the producer, may own layout. Two images might sit side by side. Text may wrap around an image. The producer knows where it put the reference, but not where the consumer will finish a line, how much text it will retain, or when an image can be released.

If the producer interleaves bands from side-by-side images and memory runs out, a receiver may be left with alternating incomplete pictures. RFC 3391 advises against that schedule. If text wraps around an image, cutting the text chunk too early may force the consumer to buffer the whole image or end the wrap prematurely. Cutting it too late may make the receiver hold excess text or place the image later than intended. Because text usually costs less storage than image data, the document recommends erring toward more text before the image. This is not a universal optimum. It is a strategy under uncertainty.

The IESG placed that uncertainty at the front of the RFC. The media type was appropriate only when the producer fully understood the consumer's capabilities and limitations. Different consumers might need different components at different moments, and the representation offered no way to ask. When the receiver was unknown, the note recommended considering a bidirectional protocol such as BEEP.

That contrast is architectural. Multiplexing gives the producer a better one-way schedule. Bidirectionality lets the consumer express demand or exercise control. In RFC 3391's examples, BEEP channels could let a printer request an image when it encountered the reference, or request bands suited to its layout. That flexibility might introduce a wait that a high-speed printer wanted to avoid. The choice was not “new format good, old protocol bad.” It was a trade between predictive placement and observable demand.

Consumer authority appeared again in display rules. When an application understood both the multiplexed type and the root type, it presented components as part of the compound object. An embedded Content-Disposition suggestion could be redundant or misleading and had to be ignored for display. When the consumer understood the container but not the root, it could suppress the object or expose the messages as mixed attachments. A consumer that understood neither treated the entity as opaque. The same bytes therefore did not own their final presentation.

Security followed directly from scheduling power. A faulty or hostile producer could begin messages and postpone their final chunks across a huge number of octets. It could keep many messages open simultaneously. It could place references to messages that never arrived, or deliver many referenced messages before the receiver knew that it could discard them. Each individual chunk might have a valid length and plausible continuation flag while the aggregate storage obligation continued to grow.

That is the evidentiary limit of framing. A parser can verify the characters in a header, count the declared payload and join chunks with the same message number. It cannot derive a memory bound from those local successes. It cannot infer that every referenced component will eventually appear, that the root type is truthful, that layout will succeed or that the receiver was the consumer imagined by the sender.

Lu Heng's Minimum Initial Specification principle helps explain both the strength and the restraint. RFC 3391 standardized only what independent implementations needed in order to reconstruct the representation: numbers, lengths, continuation state, root identity and closure. It did not nationalize layout or storage policy. Future consumers could make different decisions without asking the media type for permission.

Running-Code Primacy supplies the corresponding burden. A registered media type and a valid test vector did not prove that an actual printer kept moving, that a scanner avoided buffering or that a hostile input was handled gracefully. Those claims belonged to observed implementations. The RFC supplied a grammar and a warning; running systems supplied—or failed to supply—the receipts.

RFC 3391 is therefore a history of distance, not clairvoyance. It let the sender move bytes close to the moment they seemed useful. It did not let the sender see that moment through the receiver's eyes. The image could arrive beside its reference and still occupy the wrong shelf, wait for the wrong layout or remain unfinished in memory. Proximity solved an ordering problem. Feedback remained a different capability.

Sources