Time Horizon
Multi-year
Within the Time Horizon facet, Multi-year time-horizon intelligence organises articles by the period over which a signal is expected to matter. The page helps readers distinguish immediate operational changes from longer-cycle governance, investment, standards, and infrastructure shifts that may unfold across quarters or years. It connects timing assumptions with public evidence, related actors, market context, customer exposure, policy pressure, and infrastructure planning so readers can judge whether a development is urgent, strategic, or still waiting on confirming evidence. The page also explains how time horizon changes the meaning of a signal, which organisations may be exposed, and which infrastructure decisions require short-term action or long-cycle monitoring.
History
The Gateway Could Carry the Bytes. It Could Not Invent the Missing Meaning: How RFC 875 Challenged Protocol Translation
A rectangle labelled “gateway” made incompatible networks look one arrow apart. RFC 875 asked what the rectangle had to remember: two address models, two acknowledgements, two flow-control contracts and exceptional signals that did not command the same actor. Moving data was the…
IETF
Hannes Tschofenig and the Authority ID That Was Not the Token Signer
A measured component can name the key that signed its firmware and still say nothing about the key that signed the enclosing attestation token. RFC 10013 makes that boundary explicit. The identifier, the measurement, the EAT signature and the relying party’s decision are four…
History
The Master File Could Be Current. The Network Could Still Be Stale: How RFC 849 Split Push from Poll
In May 1983, Mark Crispin described a naming failure that could survive a perfectly updated master file: a host that never learned the file had changed. RFC 849 treated freshness not as a property of the registry alone, but as a chain of version evidence, delivery, integrity…
IETF
Corey Bonnell and the CRL Signature Whose Key Was Not Authorized
A certificate revocation list can carry a flawless digital signature and still be signed by the wrong certified key. RFC 10007 closes that uncomfortable gap by requiring a version 3 CRL issuer certificate to say, explicitly, that its key may sign CRLs. The change turns a skipped…
IETF
Kireeti Kompella and the Echo Reply That Did Not Prove the Service
An MPLS Echo Reply can show that one carefully constructed probe reached a router able to account for a particular forwarding equivalence class. That is a precise and valuable result. It does not show that every equal-cost path worked, that a dormant backup was usable, that the…
History
The Host Table Said TCP. The Socket Had to Answer: How RFC 832 Measured Running Code
In December 1982, the Internet already had a list of machines said to support TCP. David Smallberg did not treat the list as deployment. He used it as a set of claims, tried the service ports, named the different ways a connection could fail, retried negative observations, and…
IETF
Eliot Lear and the Device Policy That Was Never an Attestation
A limited-purpose device can tell a network which communications it needs without proving what the device is, who currently controls it, or whether it will behave as described. RFC 8520 makes that narrow statement useful through Manufacturer Usage Description, then leaves the…
History
The Client Became the Service: How RFC 818 Put User Telnet Behind Port 107
A client normally knocks; a server normally listens. RFC 818 made that picture deliberately unreliable. On a small terminal concentrator, the useful application was the Telnet program that opened connections outward. By placing that User Telnet capability behind a well-known…
History
The Name Service Was Almost a Negotiator: How RFC 830 Separated Domains from Capabilities
A file-transfer program asks for NIFTP. The destination has no NIFTP implementation, but it does offer FTP. In the architecture proposed by RFC 830, that mismatch did not have to end the attempt. One part of the name service found the destination domain; another part asked what…
IETF
Tero Kivinen and the New IKE SA That Inherited Live Child SAs
In IKEv2, the word “rekey” can describe two materially different successions. Replacing the protected control association creates a new IKE SA, yet the Child SAs carrying ESP or AH traffic can remain exactly the ones already in service. The distinction documented in RFC 7296…
IETF
The Old Segment Killed the New Connection: TCP's TIME-WAIT Assassination
A TCP connection can close before every copy of its packets has disappeared. TIME-WAIT is the protocol's quarantine between incarnations of the same conversation; RFC 1337 showed how an old segment could provoke the reset that ended that quarantine early.
History
The Number Did Not Make It a Standard: How RFC 825 Made Intent Part of the Record
A procurement clause says a product is “RFC 825 compliant.” The number looks precise, the link is public and the document is real. Yet none of those facts tells the buyer whether the cited memo was a standard, a discussion, a status report or merely information. In 1982, RFC 825…
IETF
Roy Fielding and the Method That Named an Intention, Not a Permission
An HTTP request begins with a compact public word. That word can tell a client, cache or intermediary what kind of result is being sought. It cannot say who is entitled to obtain it, whether the target will comply, or what happened after a connection failed. The architecture…
History
The Layer Was Not the Module: How RFC 817 Cut Across the Stack
One typed character could make three answers leave a server: a TCP acknowledgement, a window update and a Telnet echo. The protocol layers were each behaving correctly. The implementation was still wasting packets. RFC 817 used that small inefficiency to make a larger…
IETF
Mark Nottingham and the User Agent That Could Not Speak for Every User
The browser can deny a service direct access to a person's machine, carry a narrow preference and make another implementation possible. Those powers make the user agent a valuable intermediary. They do not turn software, its vendor or a standards entity into the authorized voice…
History
The Error Message Was Advice, Not a Verdict: How RFC 816 Layered Failure Decisions
A gateway that has crashed cannot send the error message explaining why packets disappear into it. RFC 816 began with that silence and built a layered answer: let routing repair distant failures, make the host replace a dead first hop, let TCP expose retransmission and timeout…
History
The Missing Segment Did Not Stop the Next One: How RDP Separated Reliability from Order
In 1984, the Reliable Data Protocol made a choice that still unsettles casual descriptions of transport: a later message could be safely received, individually acknowledged and even handed to an application while an earlier message was still missing. Reliability described whether…
IETF
Dieter Sibold and the Cookie That Let the Time Server Forget
Network Time Security performs its expensive act first: authenticate a key-establishment service, derive two directional keys and close the TLS connection. Later NTP requests carry the missing association state back inside an opaque encrypted cookie. RFC 8915 made forgetting…
History
The Name Was Not the Address: How RFC 814 Kept Identity Separate from Route
In 1982, a stale host table could send queued mail to an unexpected machine after the intended host had moved. RFC 814 treated that failure as more than bad data. It exposed four different references—name, address, route and port—and argued that an Internet host should translate…
IETF
David Lawrence and the DNS Answer That Outlived Its TTL
When a DNS answer reaches the end of its TTL, a recursive resolver normally discards or refreshes it. RFC 8767 allows a narrower choice during failure: preserve the expired copy for a bounded time, return it only after a real refresh attempt cannot produce usable data, and keep…