Summary

  • RFC 4714 treated editorial cleanup after approval as a controlled change because grammar and readability edits could affect agreed wording or technical meaning.
  • Its 2006 proposals called for tracked changes and technical sign-off, restraint when clarity gains were small, and a separate approval path for technical corrections. The document describes requirements for future contracts; it does not audit the publisher’s performance.

Analysis

The issue is not whether an edit is well intentioned. It is whether the published wording remains tied to the approval that gave it authority.

The sentence after the vote

The risky moment in a technical document’s life is not always a disputed protocol decision. Sometimes it is the quiet interval after a group has approved text but before it appears as an RFC. RFC 4714, an October 2006 Informational document, examined what the IETF should expect from its technical publisher in that interval. Its question was narrow: how should editorial work proceed once the ordinary technical approval process has ended?

The answer began with a change in status. Copyediting can cover spelling, grammar, readability, formatting, boilerplate, and document structure. Before approval, such work can be reviewed with the technical text. After approval, it arrives from outside the normal path that produced the agreement. A change may be editorial in intent and still alter the force of a sentence, a condition, or a carefully negotiated phrase. The risk is not that editors should avoid improving prose; it is that intent alone cannot establish that meaning stayed put.

RFC 4714 says that stylistic editing had sometimes produced many changes across documents. Authors then had to vet the changes, accept or reject them, and review subsequent rounds. The document describes the result as a potentially substantial delay, to be weighed against the incremental improvement in communication. It gives no series-wide timing dataset and names no particular harmed document. The evidence is a process account, not a quantified performance study.

A visible delta and named authority

The proposed control was straightforward: record every post-approval edit and have the right technical representatives approve it. For IETF standards-stream documents, RFC 4714 names the authors, the document shepherd when one exists, and the Area Director. The Area Director is the authority for approval of all changes. The publisher’s job is editorial review, not a second technical review.

That distinction prevents two forms of role confusion. A publisher should not silently decide technical questions under the label of copyediting. And an author’s request to change a sentence after approval should not become an untracked route around the same approval process. The document separately tells the publisher to raise suspect or unreasonable proposed technical changes with the Area Director and pause further processing until the authority responds.

The rules also make room for language whose exact wording matters for reasons beyond style. RFC 4714 cites common boilerplate and text negotiated with another organization on a politically sensitive issue. In such cases, it says the text may need to appear verbatim; in the IETF standards process, the IESG may request that treatment. The exception is important because uniform prose is not the only value at stake. A sentence may carry a negotiated bargain that a later editor cannot reconstruct from grammar alone.

Two queues, not one

Section 3.7 separates editorial cleanup from technical corrections discovered after approval. A technical defect may need correction before publication, but it comes from outside the publisher’s editorial review. RFC 4714 proposes that authors and the Area Director approve such a correction, with the shepherd kept informed. The process is not a license to let copyediting become technical redesign; it is a separate path for a different class of change.

The distinction exposes a real trade-off. Refusing every post-approval edit can leave errors or awkwardness in a durable specification. Editing aggressively can reopen settled language, increase review rounds, and make the published text less clearly traceable to the approved version. RFC 4714 favors “light” editing and restraint where the clarity gain is incremental or a change could affect consensus wording. It also notes that pre-approval editing may be more efficient: a working group can review the changes before approval, without a separate post-approval control path.

This is not a verdict about whether a particular editor did good or bad work. RFC 4714 expressly says it aims to clarify the IETF’s consensus requirements for a technical publication service and to inform future contracts; it is not an assessment of how well the RFC Editor then met them. Its title sounds operational, but its evidentiary status is a proposed requirements record.

Later rules, different evidence

RFC 7322’s 2014 style guidance later states the central editorial limit plainly: do not change the intended meaning of text. It says that when safe editing cannot be assured, a document may be returned to the stream-approving body. That echoes a concern visible in RFC 4714, but the resemblance alone does not show that one document caused the other or that every proposed control was implemented.

The 2026 RFC Series model in RFC 9920 describes today’s allocation of policy and production responsibilities, including the RFC Production Center’s implementation role and a route for author–RPC disagreements. The institutional arrangement has evolved. It does not convert RFC 4714’s earlier requirements into proof of current practice.

The enduring point is smaller and more useful: after technical approval, a “mere edit” is still a change to a public record produced by a collective process. A change log makes the difference inspectable. Named approval keeps responsibility visible. Restraint controls the cost of reopening language. When the edit may change meaning, the decision belongs with the people authorized to resolve the technical text.

Sources