Topic
Software Lifecycle and Lock-in
Within the Topic facet, Software Lifecycle and Lock-in topic intelligence connects articles that share a specific subject, signal focus, or monitoring theme. The page gives readers a richer path through related reporting, source evidence, market actors, and infrastructure implications, with enough context to understand why the topic matters across company movements, governance decisions, regional exposure, and operational risk. Readers can compare recurring signals, affected organisations, public evidence, market context, service continuity, procurement, competition, compliance, and strategic planning questions behind the subject instead of stopping at a thin list of matching articles. It explains what the topic covers, which infrastructure actors or policies are involved, what evidence supports the coverage, and why the subject may matter for operators, customers, investors, and policy readers.
History
The Sender Named the File. The Receiver Still Owned the Disk: RFC 1806
An attachment can arrive with a name and an instruction to stay closed until requested. Neither statement proves that a file was created, that the name is safe, or that the recipient surrendered control of the machine. Content-Disposition became durable because it carried intent…
CASE FILE
The Large BFD Packet Stayed Up. The Whole Path Was Not Proven: RFC 9764
A green BFD session can now say something useful about packet size, but only if the claim stays as narrow as the packets that earned it. RFC 9764 turns padded control traffic into a recurring lower-bound test. It does not turn one forwarding treatment into a certificate for every…
CASE FILE
The Packet Carried a Resource ID. The Path Did Not Promise to Obey
An IPv6 packet may name the resource partition it wants at every hop and still emerge without proof that every router recognized the request, used the intended queue or preserved the promised isolation.
History
The Provider Was Written into the Address. Then the Field Disappeared
IPv6 did not begin with a timeless answer to who should sit between a site and the global routing table. Its early documents tried several physical layouts for that authority—and left a remarkably frank account of who would pay when aggregation, portability and resilience pulled…
History
Three Telnet Options Made a Terminal. None Named the Session: RFC 1576
A standard had already designed one explicit switch into 3270 mode. Running systems chose three switches instead. By 1994, Terminal-Type, Binary and End of Record could make an ordinary Telnet connection carry a block-oriented IBM display stream, even though the client still…
CASE FILE
The Certificates Were Related. The Verifier Still Owned the Decision: RFC 9763
A certificate authority can attest that two credentials belong to the same end entity. It cannot make two private keys act in a live exchange, choose a peer’s trust anchors or decide whether one successful authentication is enough. RFC 9763 is valuable because it draws that line…
History
The New Root Address Took Most Queries. The Old One Stayed: Net 39
For 38 days in 1995, one root-server installation answered through an experimental address inside Net 39 as well as through its familiar address. Well over half of roughly 400 million queries reached the new interface. The striking fact is not only that the unfamiliar address…
CASE FILE
The Cache Could Stay. The Old Answer Could Not
An NFS client may re-read a busy directory, see the same names and still tell an application that a growing file has its old size. Revision 11 of a working-group draft answers that failure without pretending to abolish caching: it limits which answer the client may expose after…
CASE FILE
The Authorization Server Said Active. The Resource Server Still Had to Decide
One green boolean can look like permission. RFC 9767 is more disciplined: `active: true` is an authorization server’s answer to a resource server’s specific question about a token, a proof method and, sometimes, minimum access. The resource server still owns the application…
CASE FILE
One Subscription, Many Publishers: The Parent Owns the Split
A collector can ask one network node for one stream of updates and receive data from several publishing processes hidden behind the same address and subscription identifier. Revision 21 of the NETCONF distributed-notification draft corrects the authority that makes this possible…
History
The RFC Said Every Host Must Answer. Running Code Said Otherwise: RFC 1788
In 1995, an RFC said every host and router had to answer a new kind of name query. In 2013, another RFC recorded that the messages had never been widely implemented or deployed. Between those two sentences lies a useful history of how an Internet standard acquires—or fails to…
History
The Filter Looked Readable. The Server Executed a Predicate: RFC 1558
In one short LDAP expression, `*` could ask whether an attribute existed, widen a value into a substring pattern, or survive as a literal character only if the writer escaped it. The line was made for people to read. The server did not read it as prose. RFC 1558 gave executable…
CASE FILE
A SLSA Attestation Is Evidence, Not the Acceptance Decision
A SLSA provenance statement can say something precise about one artifact and the build that produced it. That precision matters. But it does not choose which builders a verifier trusts, define a package’s expected source and parameters, declare a release complete, or decide what…
CASE FILE
QUIC's Partial Reset Gained a Permission Gate. Its Delivery Promise Can Still Shrink
Revision 11 of QUIC Stream Resets with Partial Delivery closes an important permission gap: an endpoint may not send `RESET_STREAM_AT` unless its peer advertised support. That rule says the receiver can parse the extension. It does not make the sender's first Reliable Size…
CASE FILE
The Receiver Counted the Marks. It Did Not Choose the Sender’s Response
An acknowledgment disappears. The next one arrives with a three-bit counter advanced, but perhaps not by as little as it seems: the counter may have wrapped while the evidence was missing. RFC 9768 gives TCP a better congestion receipt, not an oracle. The receiver reflects marks…
History
The Octet That Changed Its Contract: From IPv4 Type of Service to DSCP and ECN
The second octet of the IPv4 header did not move, but its contract did. What began as precedence and desired service qualities became a configurable per-hop behavior selector plus an explicit congestion signal—a history of compatibility managed by redefining bits in place.
History
The Name Looked Complete. The Resolver Still Rewrote It: RFC 1535
`UnivHost.University.EDU` looks like an address already supplied. To one 1993 resolver, it was only the beginning of a search. Before asking for the rooted name the user appeared to mean, the software could manufacture three longer candidates, cross from a locally managed suffix…
History
The Length That Outranked the Frame: Why IPv4 Counts Its Own Header
An IPv4 packet can sit inside a link-layer frame that is longer than the packet itself. The small field that resolves the ambiguity does more than count payload: it declares the complete IP datagram, header included, so the network layer keeps its own boundary when the enclosing…
CASE FILE
The Beacon Anchor Became Verifiable. Its Quantum Timeline Still Needed Another Archive
Revision 01 of Wathīqa repairs an important weakness in its evidence record: the first beacon value is no longer merely a time-shaped field but a signed pulse tied to a pinned certificate, with an optional successor that can prove immediate chain continuity. The repair is real.…
CASE FILE
The Receiver Lowered the Window. The Sender Never Changed Its Algorithm
A small advertised TCP window is often read as proof that the receiving application cannot keep up. RFC 9840 makes that shortcut unsafe. It gives the receiver a second reason to limit the window—deliberate low-priority transport—while leaving the sender’s congestion-control…