Content Type
Analysis
Within the Content Type facet, Analysis intelligence gathers BTW.MEDIA articles that share the same editorial format, helping readers compare briefings, profiles, risk notes, market analysis, and event coverage without mixing different kinds of evidence. The page explains how this content type frames internet infrastructure events, company movements, governance decisions, operational signals, and public evidence across the site. Readers can compare which actors or infrastructure systems appear most often, how source quality changes interpretation, and whether the material is a durable profile, a time-sensitive event, a strategic market signal, or a governance development. The result is a useful search page for operators, investors, customers, analysts, and policy stakeholders who need to understand the consequence, timing, and evidence behind similar article formats.
History
The Banner Marked the Screen. It Did Not Make the Policy: RFC 933 and Telnet's Display Boundary
A security banner could be sent once and kept visible by the workstation instead of being mixed into every screenful of application output. RFC 933 made that presentation bargain explicit—and left the security level, access decision and truth of the label outside the banner…
History
The NAK Rejected the Port, Not the Packet: RFC 938 and the Boundary Between Delivery and Dispatch
In an experimental 1985 Internet protocol, a receiver could say two things at once: the next packet number had been received in sequence, and the local port named in that packet was not known. RFC 938 called that reply `PORT NAK`. Its precision is a useful warning against…
History
The UUID Crossed the Connection. Authority Stayed Put: RFC 927 and the Double-Login Bargain
A TAC could check a name and password once, then send a four-octet user number to the next host. RFC 927's useful restraint lay in what did not travel with that number: the target still decided whether the first host's authentication was good enough for its own service.
Asia-Pacific Cloud Services
Velo Technologies expands its infrastructure business from Cyberjaya
The Malaysian private company spans data-centre capacity, cloud, managed security, networks and IT outsourcing. Its partnerships are increasingly visible, but its ownership names, absolute financial scale and the economics behind some of its infrastructure commitments remain…
History
The Branch Said “Nobody Below”: RFC 1075 and DVMRP’s Expiring Non-Membership Report
In 1988, experimental multicast routing had to decide when not to send a group’s traffic down a branch. RFC 1075 offered a deliberately limited answer: a downstream router could say that it had no descendant members for one multicast group, and its upstream neighbor could stop…
History
The Keystroke Cost Four Octets: How RFC 916 Let State Replace Repetition
One typed character once faced a seven-octet packet around it. RFC 916 cut that packet to four octets by moving the character into the header position that would otherwise say how long the data was. The saving worked only because the connection had already made the missing facts…
History
The Name That Did Not Report a Reading: RFC 1065 and the Shape of Manageable Things
In 1988, Internet management needed a way to describe what could be observed without pretending that a description was already an observation. RFC 1065 supplied that restraint: a managed entity type could have a stable name, syntax, encoding and access category, while the live…
History
The Byte That Meant “Start Over”: SLIP, RFC 1055, and the Cost of Recovering a Serial Frame
On a quiet serial line, the difference between a valid packet and yesterday’s noise could be one byte. RFC 1055’s SLIP convention used `END` to finish an IP datagram, but it also recommended an `END` before the next datagram. That extra byte did not repair the wire or certify the…
History
The Cutover Was Not One Cutover: How RFC 897 Separated Renaming from DNS Resolution
On 14 March 1984 a host could acquire an official name ending in `.ARPA` while the program using that name still consulted a local copy of a centrally maintained table. The new namespace could arrive through the old lookup machinery. RFC 897 made that apparent contradiction a…
History
The LANs the Host Was Not Meant to See: RFC 925 and the Cost of Hiding a Topology
An early Internet site could either expose every cable to the wider network or arrange its cables so that a host believed it lived on one large local network. RFC 925 chose the second illusion. It kept the host's ARP unchanged and made an intermediary discover, remember and…
History
The Carrier Was Not the Connection: How RFC 892 Separated Transport State from the Network Path
One network connection could carry several transport conversations. One transport conversation could, in the most capable class, ride several network connections. RFC 892 treated those as inverse mappings rather than a contradiction: the carrier moved protocol units, while peer…
History
The Fastest Path Carried the Clock. It Did Not Choose the Master: How RFC 891 Bound Routing and Time to One HELLO
In the Fuzzball network, one HELLO could change both the route to a host and the clock offset associated with that route. The economy was deliberate, but authority remained divided: measured delay selected a path, configuration named the master, and the local clock decided…
History
The Frame Was Longer Than the Datagram: How RFC 894 Kept Ethernet Padding Out of IP
An Ethernet interface could deliver 46 data octets even when the IPv4 datagram inside it ended sooner. RFC 894 did not resolve the mismatch by stretching IP. It assigned two rulers to two layers: Ethernet supplied enough zeroes to satisfy its physical minimum, while the IP Total…
History
The First Answer Was Not the Last Word: How RFC 887 Separated Discovery from Confirmation
A host in 1983 could ask an entire local network who provided a service. Yet RFC 887 refused to treat the first name it heard as final truth. Broadcast discovery, an explicit negative answer, a third-party hint and a provider’s own confirmation were four different kinds of…
History
The List Called It Official. It Still Did Not Call It Implemented: How RFC 880 Separated Status from Running Code
One row in RFC 880 called the Gateway Gateway Protocol experimental. The same row said it was then used in the core gateways. The apparent contradiction was the point: classification, deployment and fitness were different facts, and the Internet's official catalogue kept them in…
History
The Back Door Was Not a Route: How RFC 831 Reached a Partitioned SATNET
The emergency machine was allowed to behave like a gateway, but it was forbidden to become one. That distinction carried the whole proposal in RFC 831. A multihomed host at UCL could rewrite a chosen maintenance exchange around a broken SATNET path, yet it would send no routing…
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…
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…
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…
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…