Summary

  • RFC 1927 proposed electronic staples and paper clips to show how tightly multipart documents belonged together. The joke then loaded the same objects with appearance, workflow, accounting, recycling and positional meaning.
  • Later MIME specifications separated those concerns: Content-Disposition offered presentation hints, multipart/related defined a compound object and its root, and cid: or mid: supplied scoped references.
  • A durable relationship needs explicit semantics that recipients can validate. A familiar icon may explain a relation, but it should not acquire authority to move files, trigger a workflow or decide integrity.

One office object, too many kinds of together

The opening proposition in RFC 1927 is beautifully economical. Electronic staples and paper clips would indicate the “degree of binding” of multipart documents. Stapled documents should remain together on the desktop; clipped ones should be easy to spread apart. A person who has handled paper understands the distinction without consulting a grammar.

The memo immediately makes that simplicity unstable. Large and small clips might describe document size or hierarchical assembly. A certificate attached to every clip might support charging and detect patent violations. A recycler might recover the fastener when a folder was deleted. Color and shape could change the icon, a src= attribute could load an image, and silver or gold could select different office workflows. A clip might mark a page, paragraph or sentence. It could even remember how often it had been bent and eventually fail.

These are not variations of one relation. They are separate claims about containment, order, presentation, identity, authorization, accounting, lifecycle, anchoring and mutable state. The humor comes from treating all of them as natural properties of a thing that looks like a paper clip. The interoperability problem begins at the same point: what exactly must another program preserve when it copies, forwards, stores, opens or deletes the object?

RFC 1927 admits the danger in comic form. Staples and clips may break high-speed copying programs, and its security section says security is not discussed. The omission matters because one proposed appearance field also selects workflow. If a sender controls the color, has the sender merely decorated a document or issued a command?

Informational was a boundary, not an embarrassment

The document’s own status notice says that it provides information and specifies no Internet standard. The current RFC Editor record lists it in the Independent Stream, with one erratum. The date—1 April 1996—and the child-safety, floppy-disk and sculpture passages remove any serious doubt about the comic register.

That does not make the document analytically empty. Satire often finds design ambiguity by refusing to stop at the polite version. “Attachment” sounds precise until an implementation must decide whether it means display these parts together, store them together, prevent separation, preserve their order, verify their identity, or run an action when one arrives.

The verified erratum repairs “data flines” to “data files” and changes “very small children” to “very young children.” An editor can determine what words the joke intended. The correction does not define what a compliant electronic staple would do. Text maintenance and operational semantics remain different tasks.

MIME gave content parameters a smaller job

The revised MIME media-type specification arrived later in 1996. RFC 2046 says Content-Type declares the nature of a MIME body. Parameters modify a subtype but do not fundamentally change the nature of the content, and implementations must ignore parameters they do not recognize. Compound formats should use multipart or application types rather than smuggling another kind of data into a parameter.

That is a useful constraint on RFC 1927’s imaginary color=, shape= and src= surface. A presentation parameter can describe appearance. It should not also redefine containment, activate a workflow and become the only record of an internal dependency. Unknown parameters are routinely ignored for extensibility; a relation essential to correctness cannot safely depend on every recipient treating an ornamental field as a command.

multipart/mixed also supplies only a bounded promise. It transports an ordered set of independent body parts. The fact that parts crossed a boundary in one envelope does not say that they form one inseparable object. Co-location is evidence of packaging, not proof of dependency.

Presentation became a suggestion, not a command

RFC 2183 named the presentation layer explicitly through Content-Disposition. inline suggests immediate display; attachment suggests that the user take an additional action. A filename may be suggested if a body part is stored separately. These are useful instructions, but the vocabulary is deliberately modest: disposition conveys presentational information.

Its security rules show why the modesty matters. A receiving program must not blindly adopt a suggested filename, accept a directory path, overwrite an existing file or place executable content where it will run. The sender can propose a label. Local software decides whether that proposal is safe in the recipient’s filesystem and execution environment.

That boundary is the serious version of the gold-paper-clip problem. A gold icon can help a person recognize a local queue. It cannot be a portable authorization token merely because its meaning is obvious inside one office. Once appearance causes execution, the recipient needs an authenticated command vocabulary, an authorization decision and failure behavior—not a brighter decoration.

A compound object needed a root and explicit relations

RFC 2387 defines multipart/related for a stronger case: constituent parts are interrelated, and the object cannot be properly displayed by showing each part independently. The type parameter names the root part’s media type. The optional start parameter identifies that root by Content-ID; otherwise the first body part is the root. Links inside components express the relations to other components.

The root changes the question from “which pieces arrived together?” to “which component defines the object, and which resources does it require?” The processing application owns the interpretation. Within a recognized related object, Content-Disposition can be redundant or misleading, so related-object processing takes precedence over the presentation hint.

This is not merely richer syntax. It prevents a visible badge from becoming the system’s only source of structural truth. A recipient that understands the compound type can resolve dependencies according to the object’s defined semantics. A recipient that does not understand it falls back to treating the package as mixed parts rather than pretending that an unknown clip performed a binding operation.

References needed identity and context

A staple drawn across two icons still does not tell software which exact bytes depend on which. RFC 2392 supplies cid: references to MIME body parts and mid: references to messages or to a body part within a named message. Content-IDs are intended to be globally unique, but many stores do not index parts outside their message context. The longer mid: form carries that context for interoperability.

This is the difference between resemblance and addressability. A page flag that points to “the third paragraph” may drift after editing. A URL that points outside the package may change or disappear. A scoped identifier can at least tell the receiving application what object was named and where to resolve it. The identifier still does not confer permission to execute the target or prove that the target is trustworthy. Identity, integrity and authority remain separate.

The aggregate had to survive transmission intact

RFC 2557 applies the compound-object machinery to an operational problem: send a complete HTML document with its images and other subsidiary resources in one message. The result is a multipart/related aggregate with a text/html root and resources referenced through Content-ID or Content-Location.

The specification preserves distinctions that the staple metaphor blurred. The URI of an aggregate is not necessarily the URI of its root. A Content-Location may label a body part without making it globally retrievable. Existing HTML may be forwarded without rewriting its links, because rewriting can invalidate message-integrity checks. Structure, location, retrieval and integrity are related, but none substitutes for the others.

The result is less visually charming than an electronic fastener and much more useful. A recipient knows the root, the subsidiary parts, the reference mechanism and the application responsible for processing them. Copying the aggregate can preserve its defined relationships; displaying an attachment icon is no longer asked to carry the whole contract.

The minimum common layer is semantic, not decorative

Heng Lu’s Running-Code Primacy argues that publication becomes operationally real through implementation, validation, deployment and adoption. RFC 1927 is almost a laboratory demonstration of the inverse. A declared staple is not binding unless recipients implement the same semantics and preserve them through actual operations.

The companion design rule, Minimum Initial Specification, does not mean giving every field a vague optional meaning. It means specifying strictly only what must be common. For a compound document, that common layer may include a root, identifiers, relationship rules, integrity boundaries and safe behavior for unknown values. Icon color, desktop sculpture and local workflow taste can remain local.

The distinction between symbolic and executable layers completes the picture. A staple icon is symbolic power: it persuades a person that objects belong together. Executable power appears when software refuses separation, runs a workflow, deletes a resource or treats a reference as authoritative. Confusing the two makes a friendly interface into an unreviewed control surface.

RFC 1927’s best joke is therefore not that computers needed office supplies. It is that one familiar picture seemed able to eliminate the hard work of defining a relationship. It could not. A durable system lets the icon explain; it makes explicit semantics decide.

Sources

  1. RFC 1927 — Suggested Additional MIME Types for Associating Documents
  2. RFC Editor — RFC 1927 current record
  3. RFC Editor — RFC 1927 errata
  4. RFC 2046 — MIME Part Two: Media Types
  5. RFC 2183 — The Content-Disposition Header Field
  6. RFC 2387 — The MIME Multipart/Related Content-type
  7. RFC 2392 — Content-ID and Message-ID URLs
  8. RFC 2557 — MIME Encapsulation of Aggregate Documents
  9. Heng Lu — Running-Code Primacy
  10. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  11. Heng Lu — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile