Summary

  • RFC 5385 described a Word template whose print view could closely match RFC-compliant ASCII, but the compliant text remained a generated artifact produced through constrained styles, a text-printer file and a Perl post-processor.
  • Visual equivalence is therefore a rendering check, not proof of source identity, semantic completeness, editorial approval or archival authority. Modern RFC policy makes the distinction explicit by separating a definitive RFCXML version from rendered HTML, text and PDF publication versions.

The approval meeting that ends one step too early

Put a finished page on a large screen. The title sits where it should. The table of contents lines up. References carry the expected numbers. Nothing spills over a margin. To most people in the room, the document has passed the most intuitive test available: it looks finished.

RFC 5385 was built to make that intuition productive. Published in 2010 as an Informational Independent Submission, it described version 2.0 of a Microsoft Word template for Internet-Drafts and RFCs. The template could be viewed and printed so that the result was, with minor exceptions for smart punctuation, line for line and page for page like compliant ASCII output. Authors who preferred a familiar visual editor could work with an outline, numbered headings and defined reference styles without writing formatting commands directly.

That achievement deserves to be read on its own terms. It reduced authoring friction. It made structure visible. It gave an editor a close preview of a severe publication format.

But the same RFC documents why a visual check cannot close the evidence chain. The screen was not the compliant text file. Word first produced a printer file through a Generic/Text Only driver. A Perl program then removed carriage returns, normalized smart punctuation, stripped the space between one page's footer and the next page's header, inserted form-feed characters and checked for illegal bytes. The published-looking page and the publication artifact were connected by a transformation, not by identity.

That distinction has grown more important, not less. Modern organizations generate regulatory filings, network specifications, contracts, invoices, reports and public disclosures from rich authoring systems. A preview can be flawless while a link target, alt description, machine-readable identifier, Unicode sequence or hidden metadata field is wrong. Approval by sight proves what a particular viewer rendered at a particular moment. It does not prove what source was approved, which tools produced the file or what another reader will receive.

A template is a controlled environment, not a neutral sheet

RFC 5385 did not offer a blank canvas. It redefined Word's ordinary styles—Normal, Heading1 through Heading9, Header, Footer and Caption—and added special styles for figures, lists, references and appendices. Authors were warned that it was critical not to use styles outside the supplied set.

The restriction was functional. Word's built-in heading styles supported outline promotion, demotion and renumbering better than the custom heading scheme in the earlier RFC 3285 template. “Heading” was not merely a visual choice. It carried structural behaviour. A paragraph that looked like a heading but lacked the expected style could render plausibly while failing navigation, numbering or conversion.

This is the first governance lesson. Whenever a document system promises WYSIWYG, ask which parts of “what you see” are pixels and which are encoded structure. Font weight can imitate a heading. Indentation can imitate a list. Blue underlined text can imitate a link. None of those appearances proves that the underlying object has the semantics needed by a renderer, accessibility tool or archive.

The proper acceptance record therefore starts below the page. It identifies the editable source, template release, permitted styles, linked assets, fields, fonts and configuration. It records any warnings produced when visible formatting and structural markup disagree. Without that layer, the organization owns a convincing picture of a document but not a controlled document.

The conversion step is an editor with no byline

The post-processor in RFC 5385 performed apparently modest operations. It converted smart quotes and hyphens to ASCII forms. It changed line endings. It reconstructed page boundaries. It rejected characters outside the permitted set.

Each operation was necessary for the target format. Each also changed bytes selected by the authoring application. The conversion program therefore participated in the publication, even though it did not write the argument.

Calling such a program a neutral converter hides its decision rights. What happens when a curved apostrophe is replaced? Usually the result is obvious. What happens when a non-ASCII character carries a name, equation or protocol token? What happens when a page header resembles body content? What happens when two inputs collapse to the same normalized output? A transformation policy decides what survives, what changes and what fails.

RFC 5385 wisely made some of those decisions inspectable by including the Perl post-processor as an appendix. Yet an operational receipt still needed the exact script actually run, its version, the environment, the input printer file, the output text, and the warnings or exit status. A source document plus an assurance that “the standard converter was used” is not enough when the converter or template can evolve.

For today's document systems, preserve the transformation as evidence. Hash the approved source, tool package and generated artifact. Record configuration and generation time. Keep the validation report. If the process is intentionally not byte-for-byte reproducible—for example because timestamps or identifiers are inserted—explain which fields may differ and compare semantic structure separately.

The moving template and the fixed explanation

RFC 5385 contains a small but revealing security note. The template had no macros as developed and deployed. The author considered placing MD5 signatures for the .dot template and .pl processor in the RFC. The processor could be fixed, but the template changed to track current boilerplate requirements, so the template digest could not sensibly be frozen in the explanatory RFC; a current digest was instead posted with the external tool.

MD5 is historical here, not a recommendation. The enduring point is about life cycles. A stable document described an evolving implementation artifact. Saying “RFC 5385 template” was not enough to identify which template bytes, boilerplate or behaviour an author had used.

This pattern appears everywhere. A policy names a “standard form”, “approved generator” or “official model”, while the referenced asset changes in place. Teams record the stable label and omit the release. Months later they cannot reconstruct why two documents built under the same label differ.

Every mutable template needs its own release identity, digest, effective date and change record. The approved document should retain that identity. If a template inserts legal boilerplate, a reviewer must verify the expanded text as well as the template reference. Authority cannot flow from a name whose content is allowed to move invisibly.

References reveal the difference between appearance and structure

The revised template changed reference handling for a practical reason. In the earlier endnote-based approach, the first citation effectively defined the reference. Deleting that first citation could remove the endnote even when later cross-references remained. RFC 5385 moved numbered references into body-text paragraphs and also supported name/year labels through bookmarks.

On a printed page, the old and new references could look similar. Under editing, they had different failure modes. The example is a compact demonstration of structural risk: two artifacts can be visually equivalent at one checkpoint and behave differently after the next edit.

Acceptance tests should therefore exercise the document, not merely photograph it. Delete and move citations. Promote and demote headings. Change a figure caption. Regenerate the table of contents. Export to every promised format. Inspect navigation order and machine-readable links. A static screenshot cannot reveal whether the structure survives change.

The same rule applies to automated reports. A generated total may look correct today because the input happens to avoid a defect. Change the number of rows, the character set or the order of sections. The quality of a template is measured by invariants across transformations, not by one polished specimen.

From one severe output to one definitive semantic source

The RFC Series later changed its publication architecture. RFC 6949 described why ASCII-only documents no longer met every need. RFC 7990 laid out a structured-source model. RFC 9720, published in 2025 and now governing the format vocabulary, calls RFCXML the definitive format. A published RFC in that format is a definitive version. HTML, plain text and PDF are publication formats; the corresponding files are publication versions.

The vocabulary matters because it refuses to let every rendering claim equal authority. The definitive version holds all information intended for the RFC and must contain what is needed to produce the specified publication versions. A reader may prefer HTML. A lawyer may cite PDF pages. An operator may search plain text. Those are legitimate uses, but questions about intended publication content are answered from the definitive RFCXML.

This is not a claim that RFC 5385 secretly anticipated the current model or that its Word files were definitive sources. The later policy belongs to a different era. The connection is analytical: RFC 5385 exposed a source/view/output separation in practice; RFC 9720 later gave the Series a formal authority model for source and renderings.

Modern leadership should do the same for every important document class. Name one authoritative layer. Define which renderings are official distributions. State how discrepancies are resolved. Do not allow a CMS preview, PDF export, signed copy and database row to compete silently for primacy.

Reissue is not permission to rewrite history

RFC 9720 also complicates the comforting phrase “published documents never change”. It permits definitive and publication versions to be reissued for narrow reasons, including schema corrections and new rendering tools, while requiring semantic content to be preserved to the greatest extent possible. Earlier versions are archived, reissue dates are recorded and the reason must be public.

This is a stronger control than immobility because it recognizes operational reality. Software changes. Rendering defects are discovered. Formats age. A publisher may need to regenerate files without pretending that the act is risk-free.

The security section of RFC 9720 states the danger plainly: editing mistakes or regeneration can introduce unintended changes and corrupt a standard, practice or critical protocol information. Consistent appearance is not enough. A reissued page can look cleaner while meaning has shifted.

A defensible reissue record therefore contains before-and-after definitive versions, every regenerated publication version, hashes, tool releases, semantic comparison, reviewer identity, reason, approval and durable access to the superseded set. If only the newest PDF survives, history has been replaced rather than maintained.

RFC 9920, the current RFC Editor Model, adds the institutional side. Policy definition and approval are separated from implementation by the RFC Production Center, and responsibility for publication tools is explicit. The toolchain has an owner; the owner does not acquire unilateral authority to change semantics merely because it operates the tools.

The four receipts a screenshot cannot provide

An organization that wants reliable document automation needs at least four independent receipts.

The first is an intent receipt: the approved semantic source, the author, the scope and the decision that the content is ready. The second is a transformation receipt: exact inputs, tools, configuration, warnings and produced hashes. The third is a publication receipt: the authority that assigned the public identifier, status, location and effective time. The fourth is an archive receipt: retained versions, reissue history and a tested retrieval path.

A visual review sits between the first two. It confirms that a chosen rendering expresses the expected layout. It is valuable, especially for tables, artwork and pagination. It simply cannot substitute for the other receipts.

Nor can a hash substitute for them. A hash can prove that two byte sequences match. It cannot show that those bytes were approved, that they contain all intended semantics or that the public authority designated them as definitive. Evidence must be matched to the claim it can actually support.

An acceptance test for the page and the record

Begin with a controlled source containing headings, numbered and named references, non-ASCII names, a code block, a figure with alternative text, links, a table and deliberate page-boundary stress. Record the exact source and template release.

Generate every promised output in a clean environment. Save tool versions, configuration, standard output, standard error and exit status. Compare visible layout, but also extract headings, links, identifiers, reading order, alt text and normative terms. Confirm that no unsupported character disappeared and no repeated header entered the body.

Rebuild on a second machine or container. Explain any byte differences. Then change one semantic element and prove that each publication version changes in the expected place. Change only a presentation rule and prove that semantic extraction remains stable.

Finally simulate a reissue. Preserve the old set, produce the new set, document the reason and make both retrievable. Ask a reviewer who did not operate the tool to identify the definitive record and reconstruct how each public copy was produced.

If the answer is merely “they look the same”, the test is not complete. The page may be excellent. The institution still does not know what it approved.

Sources