DEV Community

Cover image for The graph I fell into
Hayati
Hayati

Posted on Originally published at hayatibis.dev

The graph I fell into

#networking #ai

Originally published on hayatibis.dev, where the figures move and the toys are interactive.

RFC stands for Request for Comments. The IETF,[1] the body that makes the Internet’s voluntary standards, says it plainly on its page about RFCs: “RFCs are the core output of the IETF.” They “describe the Internet’s technical foundations, such as addressing, routing, and transport technologies.” They’re numbered in order, starting with RFC 1 in 1969, anyone can read them for free, and once an RFC is published it never changes. A fix comes as a new RFC that points back at the old one. That last rule is why reading one pulls you into a graph.

TL;DR: This is a long story, from RFC 1 to Lynx and on to today. Where I’m really heading is the graph I fell into reading an RFC, and the little toy that draws it. If that sounds like a lot, skip straight there; nobody will mind :)

In 2017 and 2018 I was working on an EMVCo 3-D Secure 2.0 integration,[2] and it kept sending me to three documents: RFC 7515 (JWS), RFC 7516 (JWE) and RFC 7519 (JWT). I printed them. I remember going through them on paper, line by line, with a pen, trying to understand why a signature is laid out the way it is.

In the specification’s sections on how messages are handled and verified, JWS and JWE came up again and again. In the app-based flow, for example, “The 3DS SDK shall verify the JWS signature found in the ACS Signed Content”[3], and the SDK’s challenge messages to the ACS go out as JWE objects. I was trying to understand those two acronyms.

By the way, did you know the JWT library in your Go or Node.js service, the auth package really, is an implementation of exactly these RFCs? golang-jwt opens its README by calling itself a Go “implementation of JSON Web Tokens” and links that to RFC 7519; Node’s jsonwebtoken starts with “An implementation of JSON Web Tokens”, linked to the same RFC.

That was the first time I read RFCs on purpose. It wasn’t the first time they had been under my feet.

We use them every day

HTTP, TCP, TLS, DNS, the JWT in your login cookie: we say these names every day, and most of us have never opened the document behind them. I hadn’t either, until I stumbled into one. Each of those names is an RFC. RFC 791 is IP, from 1981. TCP is RFC 9293 now, rewritten in 2022, and HTTP’s meaning lives in RFC 9110.

They’re working for you right now, by the way. DNS (RFC 1035) turned hayatibis.dev into an address, TCP carried the bytes (or QUIC, RFC 9000, its younger cousin, if your browser picked HTTP/3), TLS 1.3 kept them private on the way, and HTTP asked for this page. So you’re reading an essay about RFCs thanks to a stack of RFCs :)

One Sunday I watched Ben Eater’s Networking tutorial, thirteen videos, the first one called “Sending digital information over a wire”. I remember being properly impressed. Sunday activities like that feel a bit nostalgic these days, but RFCs and deep dives like that have always mattered to me.

Lynx, from before even Netscape

It started earlier, at university. In our web programming fundamentals course, our much-valued teacher Gönenç told us about Lynx, a browser that runs in a terminal and shows the web as text. Through it I set off towards the foundations of the web and began poking at what’s underneath. Lynx is older than Netscape, think of it :) It began at the University of Kansas in 1992; Netscape Navigator came out in 1994.

RFC 1 in Lynx 2.9.3: a note from 1969 in a browser from 1992, and it still reads fine. A real Lynx screen, captured from a terminal.

RFC 1 in Lynx 2.9.3: a note from 1969 in a browser from 1992, and it still reads fine. A real Lynx screen, captured from a terminal. (interactive version)

Here’s a thread I only found while writing this. One of Lynx’s three authors, Lou Montulli, became a founding engineer at Netscape in 1994 and came up with the HTTP cookie there.[4] In 1997 the cookie became RFC 2109, and his name is on it; RFC 6265 is the version we use today. The text browser I met at university and the cookie in every browser now sit two nodes apart in the same graph.

What that journey gave me, more than any protocol, was a way to watch a world I wasn’t part of. I wasn’t there in 1969 or in 1992. Reading the notes, I could follow it from today, decision by decision.

RFC 1

Steve Crocker tells this story himself in RFC 8700, Fifty Years of RFCs, and it starts with a network that didn’t exist yet.

The ARPANET was a government procurement. The Advanced Research Projects Agency, ARPA (it became DARPA, the Defense Advanced Research Projects Agency, in 1972), started buying it in the summer of 1968 (“remember Vietnam, flower children, etc.?”, Crocker writes), and in his words “this was the first version to explore packet switching as a core part of the communication strategy”. The Internet, Crocker writes, “owes its beginning to the ARPANET”. The plan was to link four sites in the western United States, each running a different computer: UCLA, SRI in Menlo Park, UC Santa Barbara and the University of Utah.

The government’s request called for four packet-switching devices, one for each site, called Interface Message Processors, or IMPs. Building them was BBN’s job. Bolt Beranek and Newman, in Cambridge, Massachusetts, won the contract in late 1968 and started work in January 1969, with the first IMP due at UCLA at the beginning of September.

So in early 1969 there was no ARPANET yet. BBN was building the IMPs, and the protocols between the computers fell to “a small, fairly consistent set of graduate students and staff members” from the four sites. Crocker organised their notes. He was afraid the notes would look like a claim to authority the group didn’t have: “Finally, unable to sleep, I wrote a few humble words.” The ground rules were “that anyone could say anything and that nothing was official”, and Bill Duvall suggested the name: Request for Comments.

RFC 1, “Host Software”, is dated 7 April 1969, and its introduction ends like this: “Very little of what is here is firm and reactions are expected.” RFC 3 set the bar as low as it would go: “Notes are encouraged to be timely rather than polished.” The minimum length of a note was one sentence.

That’s the part I like most. The documents that run the Internet started as humble notes written at night, inviting anyone to answer.

The graph I fell into

You open one RFC to check one thing, and it sends you to another. RFC 9110 alone lists 83 references, most of them other RFCs, and it obsoletes nine RFCs, so an old link can drop you into text that no longer holds. The RFC Editor’s index[5] had 9,854 RFCs on 6 November 2026, and the numbering has passed five digits: the newest that day was RFC 10080.

For years I had an idea in the corner of my mind: read an RFC with that whole graph in view, so you can see where you are and what you skipped. It stayed an idea, the kind of hobby project you never find the evening for. Now that we build with AI, the project came together in less than an hour.

It’s rfc-graph (source). It starts at RFC 1 and fetches each RFC’s references live from the IETF Datatracker and the RFC Editor.[6] Each RFC is a star coloured by the year it came out, and light runs from an RFC to the ones that build on it. You can read the text beside the graph, and every “RFC nnnn” in it is a way in.[7]

RFC 9110 in rfc-graph: 64 RFCs it refers to, coloured by year, the obsoleted ones struck through.

RFC 9110 in rfc-graph: 64 RFCs it refers to, coloured by year, the obsoleted ones struck through. (interactive version)

And since we started in Lynx, here’s the same toy there. It needs JavaScript to draw the sky, so Lynx gets the buttons and five lonely stars :)

rfc-graph in Lynx: no JavaScript, no sky. A real Lynx screen.

rfc-graph in Lynx: no JavaScript, no sky. A real Lynx screen. (interactive version)

What RFCs are about now

There’s no RFC for MCP or for RAG.[8] MCP has its own process (more on that below), and it still stands on RFCs: its authorization spec says the mechanism “is based on established specifications listed below”, and six of the ten on that list are RFCs. Of the 152 RFCs published in 2026 up to November, 44 came from the security area, and a clear thread runs through them: getting ready for quantum computers, with post-quantum key exchange for TLS 1.3 and for SSH. We’re reading these and trying to understand them. Reading the past is fun, but trying to see and understand the future is quite a bit harder :) HTTP got a new method, QUERY, a safe request that can carry a body. The only RFC about AI so far is a report, RFC 9969, from an IAB workshop, AI-CONTROL,[9] on practical ways for a site to opt out of AI crawling.[10]

A new cycle, for agents?

This is the question I keep coming back to. Did that culture of open, numbered notes lead to the agents we have now, and is the AI shift starting a new cycle of RFCs?

Some of it is already happening. In October 2026 the IETF chartered a working group, Agent Communication Protocols, “to define a common baseline agentic dialog management protocol”. One of the drafts that led there, Framework, Use Cases and Requirements for AI Agent Protocols (October 2025), still opens with “Network Working Group”, the same words at the top of RFC 1. Another group, AI Preferences, is writing a vocabulary for saying how content may be used for AI.

Agent identity is taking the same road. A draft from the IETF’s Workload Identity in Multi-System Environments (WIMSE) group, AI Identity Management System, dated 2 November 2026, has a section titled “Agents are workloads” and says up front what it won’t do: “Rather than defining new protocols, this document describes how existing and widely deployed standards can be applied or extended to establish agent authentication and authorization.” And the week this essay goes out the IETF is meeting in San Francisco, by the way: IETF 127 “starts Saturday 14 November and runs through Friday afternoon, 20 November”.

Outside the IETF the habit gets copied. The Model Context Protocol changes through Specification Enhancement Proposals: a proposal “needs a working group to sponsor it before formal review”, and it only becomes Final with “Specification text, reference implementation and conformance test complete”. Write it down in the open, and show it running. That’s 1969 with a new kind of reader.

Back to the printed pages

The JWS, JWE and JWT I read on paper are 2015 documents, and they still sit in the graph: RFC 9964 brought a post-quantum signature to JOSE this year. That agent identity draft leans on them too: “In many deployments, access tokens are structured as JSON Web Tokens (JWTs)”, it says of the token an agent presents. These days, though, while we’re digesting ideas like the agent harness[11] and putting them to work, printing things out isn’t such a great idea anymore. Crocker expected reactions in 1969. The reader following those references now is often an agent, and sometimes, on a Sunday, still one of us with a pen.

Which RFC do you use every day and have never opened? :)

Specs referenced

Stands on

Notes

  1. The Internet Engineering Task Force. In its own words it “makes voluntary standards that are often adopted by Internet users, network operators, and equipment vendors”. Its mission statement, RFC 3935: “The goal of the IETF is to make the Internet work better.” And it’s open: “Any interested person can participate in the work.”
  2. In EMVCo’s words, EMV 3-D Secure “is a messaging protocol that promotes frictionless consumer authentication when making card-not-present (CNP) e-commerce purchases”. EMVCo calls itself “the global technical body that facilitates the worldwide interoperability and acceptance of secure payment transactions”. It released the 2.0.0 specification in October 2016 and 2.1.0 on 31 October 2017.
  3. ACS is the Access Control Server. The specification’s glossary: “A component that operates in the Issuer Domain, that verifies whether authentication is available for a card number and device type, and authenticates specific Cardholders.”
  4. He’s also the reason for the tag. Not everything from 1994 aged as well as the cookie.
  5. In its own words, the RFC Editor “is made up of several different groups who work together to edit, publish, and archive RFCs”.
  6. The IETF Datatracker “is the day-to-day front-end to the IETF database for people who work on IETF standards”.
  7. Early RFCs have almost no recorded references, so the “RFC nnnn” names in their text are drawn as edges too. RFC 1 refers to nothing; what it started shows up on the other side.
  8. MCP, in its own docs: “an open-source standard for connecting AI applications to external systems”. RAG, retrieval-augmented generation, comes from a 2020 paper on models “which combine pre-trained parametric and non-parametric memory for language generation”.
  9. The Internet Architecture Board. Its charter, RFC 2850: it “is chartered both as a committee of the IETF and as an advisory body of the Internet Society”, and “a major role of the IAB is long range planning and coordination between different areas of IETF activity”.
  10. Unless you count RFC 9405, “AI Sarcasm Detection: Insult Your AI without Offending It”, published on 1 April 2023. The first April 1st RFC was RFC 748, “Telnet randomly-lose option”, in 1978, and RFC 8700 says they “have a large following”.
  11. Anthropic describes its Claude Agent SDK as “a powerful, general-purpose agent harness adept at coding, as well as other tasks that require the model to use tools to gather context, plan, and execute”. It’s “the agent harness that powers Claude Code”.

A new essay every Sunday: get it by email. If you'd like more of these, you can support the writing on Patreon, or buy me a coffee once.

Top comments (0)