Primary Domain
Internet Infrastructure
Within the Primary Domain facet, Internet Infrastructure intelligence groups reporting by primary domain so readers can follow a focused area of internet infrastructure, governance, connectivity markets, or digital capital. The page brings together related articles, public evidence, institutions, companies, people, regional exposure, operating dependencies, and market context that may otherwise sit across separate category pages. It explains the domain, the likely actor class, the market or governance context, and the source material readers should use when comparing signals. Operators, analysts, and governance readers can see how the same domain appears across events, profiles, market shifts, public-source evidence, regional dependencies, and longer-cycle infrastructure decisions over time.
History
The Hostname Was Valid. It Was Still a Bad Name: RFC 1178
In October 1989, RFC 1123 told host software to accept a hostname beginning with a digit. Ten months later, RFC 1178 told administrators not to choose one. The two instructions were not contradictory. One defined what compliant software had to parse; the other described what…
CASE FILE
The Field Parsed. It Did Not Decide the Request: RFC 9651’s Semantic Boundary
A machine-readable HTTP field can make a system easier to inspect without making it entitled to act. RFC 9651 is valuable precisely because it keeps that distinction visible: it gives HTTP a disciplined way to express a List, Dictionary or Item, then leaves the meaning and…
CASE FILE
The Client Had the Dictionary. It Did Not Have the Response: RFC 9842
RFC 9842 lets an HTTP client and server coordinate around a cached compression dictionary. That is a useful, tightly bounded fact. It is not proof that the server selected a particular response, that a cache variant was semantically current, that a decoder reached meaningful…
CASE FILE
The Federation Signed the Member. It Did Not Authorize the Session: RFC 9932’s MATF Boundary
A signed federation file can make a peer easier to recognize. It cannot make a service call permissible by itself. RFC 9932 is most useful when read as a deliberately bounded chain: it describes how a federation distributes metadata and pins, how a TLS peer can be identified, and…
History
The Requirement Was Firm. The Host Was Still Not Configured: RFC 1127
A capitalized MUST can settle an argument about software. It cannot reach into a machine room and choose a live value. In 1989, the Host Requirements effort made Internet interoperability more explicit by separating firm duties, reasoned recommendations and genuine options. RFC…
History
A Known DLCI Was Not Yet a Usable Neighbour: RFC 1293’s InARP Boundary
A network could announce a new Frame Relay circuit and give a station its DLCI, yet leave that station unable to address the peer at the far side. RFC 1293’s Inverse Address Resolution Protocol did not erase that gap by treating a virtual circuit as an endpoint identity. It made…
CASE FILE
The Client Sent the Bytes. The New Protocol Had Not Accepted Them: RFC 9931’s Optimistic-Transition Boundary
An HTTP/1.1 client can make a transition look nearly complete before the party that must interpret it has accepted anything. RFC 9931 is valuable because it refuses that compression: a request may be finished, a client may offer early bytes, and the server may still reject the…
History
A Catalog Was Not an Interoperability Verdict: RFC 1292’s X.500 Snapshot
An implementation catalog can lower the cost of asking a sensible question without answering the harder questions that follow it. RFC 1292 gathered descriptions of X.500 software in January 1992 and arranged them by availability, component type, transport, pilot connectivity…
History
The Line Was Complete. The Command Had Not Run: RFC 1116 and Telnet Linemode
In character-at-a-time Telnet, a typist could wait for the network to see each key return. Linemode made the nearby terminal feel immediate: editing and echo could happen before the line crossed the path. That improvement also created a durable evidentiary trap. The completed…
CASE FILE
The Inventory Found the Algorithm. It Did Not Migrate the System: RFC 9958 and Cryptographic Agility
An organisation can catalogue every algorithm name it knows and still be unable to say which cryptographic path protects a consequential transaction. RFC 9958 makes the inventory indispensable. It does not allow the inventory to pronounce a migration complete.
History
It Worked at NASA. That Did Not Make It Safe for the Internet: RFC 1106 and RFC 1110
June 1989 produced an unusually honest sentence in protocol history: two experimental TCP extensions had been implemented and shown to work using NASA resources. Two months later, another RFC explained why one of them still could not be adopted for the general Internet. The test…
CASE FILE
The UUID Sorted. The Event Was Not Proven: RFC 9562 and the Boundary Between Identifier Order and Evidence Time
At 14:03, a review screen puts two rows in an immaculate order. The smaller UUIDv7 belongs to `reversal-requested`; the larger one belongs to `reversal-completed`. It looks like a ready-made account of what happened. But the first identifier may have been allocated before a…
History
Changing the Route Was Not the Same as Filtering the Packet: RFC 1104
In June 1989, RFC 1104 divided “policy routing” into mechanisms that were already easy to confuse. A network could change which reachability it disclosed, inspect a particular packet, assign scarce bandwidth or buffers, and record usage for later accounting. Each act could be…
History
A SHUT State Was Not an Off Node: RFC 1289 Kept the Existing Links
The word “shutdown” invites a clean story: an operator chooses a state, a node stops, and the work is over. RFC 1289 preserves a more demanding chronology. Its DECnet Phase IV MIB did not treat every admission restriction as an OFF node. `SHUT` allowed no new logical links, but…
CASE FILE
The Collector Received a Delay. It Did Not Receive a Verdict: RFC 9951
At 09:17, a collector receives a Flow Record with a mean delay, a maximum delay and an identifier for the transit point that exported them. By 09:20, someone wants the record to settle three larger questions: whether a customer suffered, whether a path changed, and which team…
History
The Memo Called It a Standard. The Record Did Not: RFC 1097
On 1 April 1989, a three-page RFC proposed a Telnet option for flashing messages too quickly for a user to notice. Its joke is easy to recognize. Its more durable lesson is quieter: the memo could call itself a standard, but it could not confer that standing on itself; a Telnet…
History
The Display Location Crossed Telnet. Access Still Belonged to X: RFC 1096
In March 1989, a small Telnet option solved an awkward problem of divided context. A person logged in to a remote host could start an X application there, yet that host did not know where the person's screen was. RFC 1096 let the Telnet client supply a display locator. The…
CASE FILE
The Benchmark Found a Limit. It Did Not Grant a Capacity Claim: RFC 9971
A network benchmark often arrives in a meeting as a single number. That number then begins doing work it was never designed to do. It is used to imply that a cloud function has production headroom, that a supplier has met an obligation, that a release is safe, or that a customer…
History
Two Protocols Were “Recommended.” Only the Profile Said What Could Interoperate: RFC 1095 and CMOT
In April 1989, the Internet did not have one official answer to network management. CMOT and SNMP carried the same Draft Standard and Recommended labels, and both were meant to describe the same Internet MIB. Yet a shared catalogue of entities was not a shared system. RFC 1095…
CASE FILE
The Queue Found a Flow. It Did Not Find a Culprit: RFC 9957 and DOCSIS QProt
When a low-latency queue begins to grow, an operator wants a fast answer to a hard question: which traffic should lose the privileged path first? RFC 9957 describes a careful local answer for DOCSIS. It is not an answer to the wider and more tempting questions. A Queue Protection…