Summary

  • RFC 3930 contrasted a quasi-static digital document perceived as a whole with an ephemeral protocol message assembled and consumed by stateful processes. The two views could converge, but they did not begin with the same object.
  • The distinction mattered most at the seams: asynchronous extensions, field-specific processing, canonicalization, selective authentication and identifiers that cease to be unique after messages are combined.

One screen, several processing histories

The title of RFC 3930 invites an easy misreading. “Document” does not mean the RFC specification, and “protocol” does not simply mean running code. Donald Eastlake contrasted two models of the digital object itself. In one, the important thing resembles paper: a complete object written and viewed by people, with presentation material treated as part of what the person receives. In the other, the important thing is an ephemeral composite built by a source process and consumed by one or more destination processes.

The RFC deliberately exaggerates both positions. Its official record classifies it as Informational, not an Internet Standard. It did not report a deployment or settle which format belonged forever on either side. XML was its central ambiguous example because it could carry a human-facing document or a machine message. The useful question was not the file extension. It was what actors did to each part.

A displayed whole can hide several processing histories. One field may be calculated from earlier messages. Another may come from local state. A third may be inspected only enough to forward it to a later recipient. A signature may cover current fields, remembered fields and locally calculated values. Treating all of that as one sheet receiving one uniform operation erases the graph that gives the message meaning.

This is why RFC 3470, the IETF’s XML guidance, discussed protocol-specific schema, extensibility and security rather than assuming that XML’s document appearance solved them. The media-type rules in RFC 3023 identified XML representations; they did not supply the state machine that interprets a field. A recognizable envelope is not an execution receipt.

Meaning did not have to travel inside every field

From the document viewpoint, a name, date or signature benefits from a human-readable label explaining whether it identifies an author, witness, subject, creation time or approval. From the protocol viewpoint, the specification and current state can already define who writes the slot, who reads it and what transition follows. Packing an open-ended vocabulary of every possible human meaning into each adjunct can enlarge the object without making the receiver’s behavior less ambiguous.

The reverse error is equally real. A protocol-defined slot does not prove that a person intended the legal or social meaning later attributed to it. RFC 3552 made threat analysis part of protocol design; it did not turn syntax into authorization. RFC 3852 defined a rich cryptographic message container, but the presence of a signer or recipient structure is still not a verdict about human authority or successful delivery.

RFC 3930 therefore belongs with a layered evidence discipline. A specification can define a slot. An implementation can support it. A process can emit or consume it. A trace can show the bytes. A verifier can accept selected data. An application can still reach a different outcome. None of those records should borrow the authority of the next one.

Extensions arrived unevenly

The document model can tempt designers to assume that a new version will be distributed synchronously to every participant. Protocol designers cannot safely assume that. RFC 3930 recommended explicit versions or feature labels, negotiation where possible, lengths or delimiters that let an older processor skip an unknown part, and destination labels that tell an intermediary to pass data onward rather than interpret it.

Those mechanisms do not make an extension succeed. They make mixed generations diagnosable. A field advertised by the sender may be skipped by one intermediary, consumed by another and rejected by the final application. The operational record must retain which implementation saw which version and which branch it took.

Later formats did not remove the problem. RFC 8259 standardized JSON while preserving representational choices that matter to comparison. RFC 8785 later defined the JSON Canonicalization Scheme for repeatable hashing and signing. RFC 8949 addressed deterministic CBOR encoding. These documents did not implement RFC 3930, but they show that a familiar serialized whole still needs rules for comparison and processing.

The narrow bridge of canonicalization

Authentication brought the two views into direct conflict. A document-minded signer may want the original object preserved exactly. A protocol process often reconstructs, re-encodes or normalizes data that no human ever sees. Without an agreed transformation, line endings, character encodings, namespace context, capitalization or numeric representation can break a signature even when the protocol considers the meaning unchanged.

RFC 3076 defined Canonical XML, RFC 3741 defined Exclusive XML Canonicalization, and RFC 3275 defined XML Signature processing. RFC 3930 framed the design choice sharply. Too little canonicalization makes authentication brittle under insignificant changes. Too much makes it insecure by allowing a signature to survive a change the application considers significant. The useful choice is neither maximum preservation nor maximum normalization; it is the application’s exact equivalence boundary.

That boundary also decides what is signed. A composite message may contain mutable hop counts, routing history or local forwarding tags. Signing the apparent whole can either fail at the next processor or freeze data that must change. Selective protection is not weaker merely because it is selective; it is defensible only when the signed set matches the claim the verifier intends to make.

The reference label that pointed to another document

RFC 3930 itself preserves a small example of why labels need resolution. Section 2.4.1 tells readers to see [RFC3076, RFC3741]. RFC 3741 is indeed the exclusive-canonicalization document. But RFC 3930’s bibliography expands [RFC3741] as L. Berger’s GMPLS signaling document, RFC 3471. The RFC Editor errata search showed no matching RFC 3930 erratum on 7 October 2026.

The typo does not defeat the argument. It bounds it. A readable label, a bibliography entry and the intended object can diverge inside one static artifact. A human can infer the target from context and look it up; an automated pipeline should record the exact identifier it resolved. Neither should report that a reference was verified merely because the label looked familiar.

Anchors changed when objects were combined

Internal identifiers exposed the same structural difference. A short ID can be unique inside one document and collide when pieces of several messages are combined. Rewriting the IDs can invalidate stored references and signed bytes. Hierarchical qualification can preserve local uniqueness while changing the external anchor when data moves. RFC 3930 judged long, randomly generated labels the strongest general option when a durable global anchor was actually needed.

The lesson was not that humans must stop reading digital objects. RFC 3930 described conditions under which the views converge: fewer parts, less mutation, fewer processors and more direct human consumption. Its advice was to begin with the protocol processing graph and add document needs, rather than begin with paper and discover later that the network was editing, splitting and forwarding it all along.

The modern RFC Series has its own archival document model under RFC 7990. That separate history helps preserve the distinction. Rules for publishing an RFC artifact are not the state machine of the protocol it discusses. Likewise, Heng Lu’s essays on minimum initial specification and voluntary adoption and running-code primacy supply an editorial test: publication can coordinate, but implementation, validation, operation and use determine what became real. RFC 3930 gives that test an object model. The surface may be one document; the evidence lives in the parts and transitions beneath it.