History of the Internet

Tunnel Was Media-Independent. Its Circuit Was Not: RFC 3070

The Tunnel Was Media-Independent. Its Circuit Was Not: RFC 3070

RFC 3070 made L2TP portable across a Frame Relay network, but portability did not make the bearer disappear. The tunnel still depended on a virtual circuit with its own endpoints, framing identifier, setup rules, packet-size limit and unresolved questions of service quality and security. The history matters because abstraction can move a dependency without eliminating it.

A Common Incident Object Was Not a Common Verdict: RFC 3067

RFC 3067 imagined a security-incident report that could cross organisational and national boundaries without losing the distinctions needed to act. Its strongest insight was not that every response team should reach the same conclusion. It was that they needed a common object capable of carrying different kinds of truth, different permissions and a visible history of changing judgment.

Tag Named the Content. It Could Not Certify Understanding: RFC 3066

The Tag Named the Content. It Could Not Certify Understanding: RFC 3066

In January 2001, RFC 3066 gave Internet protocols a compact way to say which human language an information object used. It also drew a line that systems still cross too casually: a valid label can guide selection and processing, but it cannot testify that a person will understand what arrives.

Gateway Owned the Milliseconds. The Call Agent Still Owned the Call: RFC 3064

The Gateway Owned the Milliseconds. The Call Agent Still Owned the Call: RFC 3064

When circuit telephony met packet control, distance became a design constraint. RFC 3064 put reactions measured in tens of milliseconds beside the wire, inside the media gateway. It did not surrender the larger decision: the Call Agent still decided what the call meant, and a released trunk was not yet a deleted network connection.

Labels Waited for the Thread to Rewind: RFC 3063

In a changing MPLS network, a route could point around a loop before a label-switched path was ready. RFC 3063 proposed a way to make the label wait: send a short-lived, colored control thread downstream, and do not advertise the mapping until that thread has returned through a loop-free path.

Missing Extension Was Not an Empty Answer: RFC 3059

The Missing Extension Was Not an Empty Answer: RFC 3059

RFC 3059 tried to save a round trip in service discovery: return each service URL with its attributes in the same reply. Its most durable lesson lies in the path where that optimization disappeared. No extension did not mean “no attributes.” It meant the client still owed the network another question.

Password Had No Directory Entry to Change: RFC 3062

The Password Had No Directory Entry to Change: RFC 3062

In 2001, LDAP's ordinary edit operation could not reach every password. RFC 3062 introduced a separate password-change request that could target a session's user or a non-DN identity, even when the credential lived outside the directory. Its success rule was strict; its view of what happened beyond the server was not.

OID Made IDEA Encodable. It Did Not Make the Cipher Available: RFC 3058

The OID Made IDEA Encodable. It Did Not Make the Cipher Available: RFC 3058

RFC 3058 gave IDEA two precise names inside CMS and a reproducible way to wrap a content key. It solved the problem of how conforming software should represent the cipher. It did not install IDEA at either end, grant permission to use it, select it for a message, or prove that the recipient could decrypt what arrived.

Model Could Describe the Rule. It Left the Result to Devices: RFC 3060

The Model Could Describe the Rule. It Left the Result to Devices: RFC 3060

RFC 3060 gave policy systems a shared vocabulary of groups, rules, conditions and actions. It did not give every router one shared interpreter. The standard could describe when a rule applied and even mark an action order as mandatory or recommended, while leaving the algorithm that turned those attributes into a decision to an implementation. That gap was not hidden in the schema; the RFC called it out as a design boundary.

D-Channel Stayed Put When Call Control Moved to IP: RFC 3057

The D-Channel Stayed Put When Call Control Moved to IP: RFC 3057

RFC 3057 did not drag the ISDN line into the Internet. It stopped at the boundary: the Signaling Gateway still terminated Q.921, while IUA carried the upper signaling relationship to a call-control process across SCTP. Its redundancy model could move signaling traffic when an application process failed, but it did not promise that every call in transition would survive.

Counter Said the Call Succeeded. It Could Not Say Whether a Person Heard It: RFC 3055

The Counter Said the Call Succeeded. It Could Not Say Whether a Person Heard It: RFC 3055

In 2001, the PINT working group gave operators a disciplined way to count Internet-triggered telephone services. RFC 3055 could distinguish received, successful and disconnected calls across users, clients and gateways. Its greater lesson lies in the distance it preserved: a server could count an outcome without observing the person, fax page or loudspeaker at the far end.

14 kHz Upgrade Kept a 16 kHz Door Open: RFC 5577

The 14 kHz Upgrade Kept a 16 kHz Door Open: RFC 5577

RFC 5577 widened the G.722.1 audio profile and added a faster sampling clock. Its most revealing migration rule was quieter: keep offering the 16 kHz configuration when older terminals still matter.

Phone Named Its Parts. The Controller Still Had to Ask What Was There: RFC 3054

The Phone Named Its Parts. The Controller Still Had to Ask What Was There: RFC 3054

RFC 3054 gave an Internet telephone a shared vocabulary for its display, keys, handset, speaker and media stream. The IPPhone profile let a remote controller begin with a known model instead of guessing a device from an arbitrary inventory. That shortcut reduced inference. It did not make a profile declaration, an audit result, a control command, an RTP packet and audible speech the same fact.

Root DSE Could Name Its Vendor. RFC 3045 Drew the Line at Capability Discovery.

The Root DSE Could Name Its Vendor. RFC 3045 Drew the Line at Capability Discovery.

An LDAP server could tell a client who made its software and which release string it reported. That was useful context for a human—or a narrowly targeted workaround—but it was not a feature list. RFC 3045 made the distinction explicit: a vendor label might help explain an anomaly, yet clients must not treat it as proof of what the server can do.

ISSN Stayed. The URLs Moved. RFC 3044 Built a Watcher Between Them

The ISSN Stayed. The URLs Moved. RFC 3044 Built a Watcher Between Them

In 2001, the ISSN International Centre showed how a familiar serial number could travel inside a URN. The harder part was never printing the number. It was keeping the route from that number to a journal’s changing web address honest. RFC 3044 said the identifier could persist; its URLs could not—and therefore needed an active watcher.

Broker Ordered the Tunnel. Another Machine Had to Carry It: RFC 3053

The Broker Ordered the Tunnel. Another Machine Had to Carry It: RFC 3053

RFC 3053 made an awkward early-IPv6 task look like a service: register, supply an IPv4 endpoint, receive configuration and connect. Its architecture also exposed a boundary that service language can hide. The Tunnel Broker made allocation and configuration decisions; a Tunnel Server terminated the tunnel; the client still had to apply its side; the network still had to carry the packets.

A Global Name, One Authoritative Resolver: The Promise and Limit of RFC 3043

In January 2001, Network Solutions proposed a durable Internet name for people and organizations. RFC 3043 made the reference portable across applications, but its own registration template placed authoritative interpretation inside the company’s resolver. The distinction still matters: a name can persist without making the power to resolve it portable.

Standard Recommended LDP. It Did Not Prove the Protocol Was Running: RFC 3037

The Standard Recommended LDP. It Did Not Prove the Protocol Was Running: RFC 3037

RFC 3037 recommended LDP for devices that carried MPLS traffic along normally routed paths. That sentence selected an appropriate protocol function; it did not certify a device, enable a feature, establish a TCP session, install a label or move a packet. The applicability statement is most useful when read as a map of those separate transitions.

Two Duplicate ACKs Could Send New Data, but Not Enlarge the Window: RFC 3042

A TCP sender with a three-segment congestion window loses one segment. The receiver can return only two duplicate acknowledgments for the later data, one short of the threshold that would trigger Fast Retransmit. In 2001, RFC 3042 proposed a narrow way to keep the feedback clock moving: send new data on those first two ACKs, while leaving the congestion window unchanged.

ATM Label Changed at Every Switch. LDP Needed One Both Ends Could Share

The ATM Label Changed at Every Switch. LDP Needed One Both Ends Could Share

An ATM circuit could keep carrying cells while the number printed in its VPI/VCI field changed at the next switch. LDP peers therefore needed more than the local label: they needed a shared identity for the virtual connection before they could bind it into MPLS.