Summary

  • TCP’s base specification, RFC 793, dated to 1981. Over the following decades, standards-track changes, clarifications and errata accumulated across separate documents.
  • In 2022, RFC 9293 gathered that normative history into an updated TCP specification. It credits Wesley Eddy as editor and records IETF consensus, public review and IESG approval.
  • Its most useful boundary is what it did not absorb: design rationale and several complex algorithms remained in companion references. The result is a clearer common requirements document, not proof that all running TCP stacks implement every requirement alike.

A protocol can outlive its filing system

A TCP maintainer who opens an old specification and then finds later changes in several RFCs faces two related questions: which requirements are still current, and which surrounding passages explain why they exist? TCP had become widely implemented, but its written base still pointed back to RFC 793 and a growing set of updates. The cost here is documentary: a reader has to assemble the current rule set before judging a change or checking an implementation.

RFC 9293 describes that problem directly. It says that RFC 793 plus other documents had served as TCP’s core specification for decades, while updates to security, performance and other aspects remained piecemeal. Its stated purpose was to collect Standards Track changes and clarifications to the base functional specification and unify them in an updated version. The change was a maintenance intervention in the standard’s reference structure, not a new TCP architecture.

The scale is visible in the title block. RFC 9293 obsoletes RFC 793 and six documents that had updated parts of it: RFCs 879, 2873, 6093, 6429, 6528 and 6691. It also replaces TCP-requirement portions of RFCs 1011 and 1122. For implementers, the practical promise is not that every feature now fits in one file. It is that the common normative base has a current place to start.

The editor’s boundary is part of the result

RFC 9293 credits “W. Eddy, Ed.” Wesley Eddy’s supported role in this document is editor. The memo describes itself as an IETF Standards Track product, says it represents community consensus, and notes public review and IESG approval. Those details matter: the requirements are not presented as an individual’s private interpretation, and the editor credit does not make Eddy the author of TCP or every prior amendment.

The document also says what its consolidation leaves alone. RFC 793 had included design goals, examples and discussion of operation. RFC 9293 does not replicate or update that introduction and philosophy. Instead, it focuses on normative protocol behavior and points readers to documents that retain the theory, rationale and design discussion. That separation makes a useful distinction for a software maintainer: the rule to implement and the explanation for the rule are both important, but they are not the same kind of text.

The boundary is not a promise of zero semantic change. RFC 9293 says it updates RFC 5961 with a small clarification to reset handling in the SYN-RECEIVED state. It also updates the TCP header control bits based on RFC 3168. Calling the document a mere reformatting would erase these stated changes. A consolidated specification can both collect existing requirements and make a limited clarification; the change list is where that difference remains visible.

One base document cannot contain every algorithm

TCP’s common interoperability rules are not the whole transport protocol literature. RFC 9293 points to companion documents for algorithms such as congestion control, advanced loss recovery and multipath operation. It explains that the base can support multiple additional algorithms developed separately, and that some topics have become complex enough to warrant future consolidation of their own.

RFC 7414 provides a map through this larger record. It was co-authored by Martin Duke, Robert Braden, Wesley Eddy, Ethan Blanton and Alex Zimmermann. The roadmap groups documents by role, including required behavior, strongly encouraged enhancements and experimental work. It is informational, however: its own text says it is not a rigorous standard for what a TCP implementation must contain and should not alone determine implementation choices. The distinction prevents a reading guide from silently becoming a requirement.

RFC 9293 makes its normative text easier to audit in another way. It labels the capitalized BCP 14 terms and links them to Appendix B, which summarizes implementation requirements. The RFC says the specification can be used to check existing implementations and write new ones. That is an intended use, not a published conformance survey. A specification can reduce the number of documents a reader must reconcile while leaving actual code, tests and packet traces to establish what a particular stack does.

What consolidation can—and cannot—buy

For a team maintaining a long-lived transport implementation, a single current statement of common behavior can lower the search work required before a review. Engineers can locate a requirement, follow its cited rationale, and then test the implementation against the relevant clause. That is a plausible maintenance benefit of the document structure, not a measured saving reported by the RFC.

The remaining boundary is operational. A current standard does not attest that a kernel, appliance or middlebox conforms. Nor does it eliminate the need to follow later extensions, errata and companion specifications. A review that cites only “TCP” or RFC 793 can miss the update chain; a review that cites RFC 9293 alone can miss an algorithm-specific requirement. The useful practice is to record the exact RFC section and requirement, then connect it to the software version and test evidence being examined.

The editorial lesson is modest but durable. Consolidation can make a shared technical contract easier to inspect without pretending that one document contains every reason, extension or implementation fact. Wesley Eddy’s credited work on RFC 9293 sits at that boundary: gather the normative base, identify the limited changes, and keep the explanatory record available beside it. The standard organizes what implementations are expected to do; running code and tests show what they actually do.

Sources

Heng Lu’s “Running-Code Primacy” note is used only as an editorial lens for distinguishing a published specification from deployed software; it is not evidence about Eddy or TCP.