Summary

  • RFC 1958 called itself an Informational snapshot, not a standard, dogma or invariant reference model; constant change was the only principle it tentatively allowed to survive indefinitely.
  • Its architecture was testable: essential communication state belonged at endpoints, unavoidable network state had to be minimal and self-healing, and real implementations outranked architectural maxims.
  • The memo could record a compatibility bargain, but change acquired force through interoperable implementation and adoption, not through the RFC number or a central command.

RFC 1958 arrived in June 1996 with a grand title and an immediate act of restraint. Architectural Principles of the Internet did not claim to specify an Internet standard. Its abstract called the text a snapshot for guidance and explicitly rejected a formal or invariant reference model. The opening section went further: it was not laying down dogma.

That disclaimer was not ceremonial modesty. It was part of the architecture. The Internet had grown through evolution rather than a master plan, the memo argued, and technical change would continue. Principles once thought inviolable had already been deprecated; principles that looked sacred in 1996 could follow them. The closest RFC 1958 came to an eternal rule was the principle of constant change.

The city analogy made the consequence concrete. Internet development resembled renewing streets and buildings while the city remained in use, not clearing the ground for a perfect reconstruction. A small spanning set of common rules could generate a wide and changing technical space. The purpose of a principle was therefore to keep reconstruction compatible, not to give its author permanent control of the city.

The memo then supplied tests. Connectivity was the goal, IP the common tool, and intelligence belonged at the ends rather than being hidden inside the network. One Internet-level protocol provided a narrow meeting point across competing vendors, providers and transmission media. Diversity could flourish above and below that point, and transitions could temporarily require more than one network protocol. The common layer was valuable because it was small enough to connect heterogeneous systems.

End-to-end state made the boundary observable. A function that required application knowledge could be completed correctly only with the endpoints' participation. Communication state should therefore share the fate of those endpoints instead of disappearing when an intermediate machine failed. This was not a fantasy of a stateless network. RFC 1958 named routes, quality-of-service commitments and compression histories as examples of state the network might need.

But it imposed a burden: such state should be minimized, derived and repaired adaptively, and its loss should cause no more than temporary denial of service where connectivity still existed. Manual configuration was the exceptional case.

Those details matter because they turn a slogan into a failure test. Ask where state lives, who can reconstruct it, what breaks when it disappears and whether an endpoint can still establish the truth it needs. A box in the middle is not wrong merely because it is in the middle. It becomes an architectural liability when hidden state makes recovery, substitution or independent evolution depend on that box's continued memory.

The same discipline shaped RFC 1958's general design advice. It favoured simplicity and modularity, but also required performance and cost to be considered. It preferred a good, nearly complete solution now to indefinite pursuit of perfection. These are tensions, not a ranking that diagrams can resolve. A clean boundary that doubles operating cost must show its value; an optimization that welds unrelated components together must show it can survive change.

RFC 3439 later updated this record with a carrier's account of complexity. It connected complexity to scaling, capital expense and operating expense, and examined how coupling between core and endpoint state can amplify cost. The update did not turn simplicity into a new sovereign rule. It supplied additional operational evidence against which an architecture could be judged.

RFC 1958 placed that evidence above itself. After observing that nobody owned the Internet and that there was no centralized control, it said evolution depended on rough consensus and running code. The next sentence made the hierarchy unmistakable: engineering feedback from real implementations was more important than any architectural principles. Later, it said standardization should wait for multiple instances of running code.

Running code is not a plebiscite. A deployed implementation can be unsafe, monopolistic, accidental or simply wrong. Nor does rough consensus prove that every operator consented. Their value is evidentiary: implementations expose ambiguity, cost, failure and incompatible assumptions that a document can conceal. Multiple independent implementations are stronger still because they test whether the written boundary can be reproduced without privileged knowledge.

Later IETF texts preserved that limited authority. RFC 3935 described a standard as the agreed description of how to do something according to that standard, not a mandate to use it or a licence to police its use. It joined engineering judgment to real-world implementation and deployment. RFC 7282 explained rough consensus as a way to address technical objections without kings, presidents or majority rule, while allowing actual engineering products to defeat designs made in a vacuum. The Tao archived in RFC 9592 stated the institutional consequence plainly: the IETF makes voluntary standards that shape the Internet, but does not run, control or patrol it.

This is where RFC 1958 meets Lu Heng's running-code argument without becoming identical to it. A minimum common specification can make interoperability and local validation possible. Later decisions can be adopted, refused or bounded to a compatibility set. Documentation can explain the choice; it cannot make an unimplemented choice operationally real by declaration. That is an interpretation of the historical text, not a claim that RFC 1958 specified a ledger, a fork protocol or a complete theory of governance.

The memo's lasting value is thus constitutional only in the sense that it limits constitutional temptation. It remembers useful constraints and then denies them a throne. It asks designers to protect a narrow common waist, locate knowledge where it can be completed, make state recoverable, separate components where evidence supports separation and listen when implementations contradict the plan.

A new architecture should not win because it cites RFC 1958. It should win because independent systems can implement it, operators can recover from its failures, incompatible choices remain visible, and adoption preserves useful connectivity. The memo can mark the bargain. The right to change remains with those who must make the network run.

Sources