Steve Crocker hired me as a junior coder when I was a freshman at UCLA, Charley Kline who made the first ARPANET remote login (to SRI) mentioned in the article was my supervisor, Vint Cerf (aka "godfather of the Internet" and co-inventor of the TCP/IP protocols) was a cow orker, and Jon Postel (aka "god of the Internet" -- it's downright criminal that the article doesn't mention him as the RFC editor--RFCs would not have been successful without him) shared a cubicle wall with me. I managed to get a mention in RFC 57. Those were the days.
P.S.
"The goal was to create a reliable, distributed communication system that could continue operating even if parts of it were damaged by a nuclear attack."
This is a myth. The ARPANET was not hardened; quite the opposite. ARPA's goal was for their researchers located across the country to easily share their work ... initially it was just used to share papers, before Ray Tomlinson invented email. Beyond that, JCR Licklider who laid the conceptual foundations was looking toward something along the lines of today's Internet + AI:
P.P.S. Steve Crocker's MIT PhD thesis was on man-machine symbiosis. I know this because he mentioned it to me when I met him in the UCLA Computer Club which he came to because he wanted to teach an informal class on LISP and Theorem Proving, and the club organized such classes. We got to talking about his thesis, he posed some challenges to me that I got lucky in solving, and he immediately offered me a job (he was the head of the ARPANET project at UCLA, under Leonard Kleinrock) that shaped the rest of my life--I'm greatly indebted to him.
Y.A.P.S. Steve Crocker received the Jonathan B. Postel Award (created by Vint Cerf) last year.
Please please please mention that https://en.wikipedia.org/wiki/Jon_Postel (aka "god of the Internet") was the RFC editor--he did a huge amount of work to make it a success.
"The ARPANET was not started to create a Command and Control System that would survive a nuclear attack, as many now claim. To build such a system was, clearly, a major military need, but it was not ARPA's mission to do this; in fact, we would have been severely criticized had we tried. Rather, the ARPANET came out of our frustration that there were only a limited number of large, powerful research computers in the country, and that many research investigators, who should have access to them, were geographically separated from them."
"Postel was the RFC Editor from 1969 until his death, and wrote and edited many important RFCs, including RFC 791, RFC 792 and RFC 793, which define the basic protocols of the Internet protocol suite, and RFC 2223, Instructions to RFC Authors. Between 1982 and 1984 Postel co-authored the RFCs which became the foundation of today's DNS (RFC 819, RFC 881, RFC 882 and RFC 920) which were joined in 1995 by RFC 1591 which he also co-wrote. In total, he wrote or co-authored more than 20 RFCs.[12]"
And from the RFC article:
"From 1969 until 1998, Jon Postel served as the RFC editor. On his death in 1998, his obituary was published as RFC 2468.[12]" (written by Vint Cerf)
"Beginning with the ARPANET, an endless
stream of networks evolved, and ultimately were interlinked to become
the Internet. Someone had to keep track of all the protocols, the
identifiers, networks and addresses and ultimately the names of all
the things in the networked universe. And someone had to keep track
of all the information that erupted with volcanic force from the
intensity of the debates and discussions and endless invention that
has continued unabated for 30 years. That someone was Jonathan B.
Postel, our Internet Assigned Numbers Authority, friend, engineer,
confidant, leader, icon, and now, first of the giants to depart from
our midst."
"Bearded and sandaled, Jon was our
resident hippie-patriarch at UCLA. "
Actually, Jon often padded around the CompSci department at Boelter Hall barefoot.
"He leaves a legacy of edited documents that tell our collective Internet story, including not only the technical but also the poetic and whimsical as well."
My understanding is that the "nugget of truth" that birthed the "routing around nuclear attack" myth, is that it was a consideration in Paul Baran's packet-switching work at RAND.
So it wasn't a design consideration for ARPANET, but it would have shown up in enough early papers to give the myth some legs.
Interestingly, ISO standard documents are sold for a non-insignificant price and DRMed, while people writing them are volunteers and/or paid by their employers to participate in standardization committees. A company willing to build equipment for an industry running on ISO/IEC communication protocols (like electric power distribution) may have to pay thousands for relevant standards, or rely on someone's interpretation of said standards to implement the protocol before they even begin, not considering certification costs.
This is a very funny thing to assert on a forum that's entirely delivered via openly standardized (via IETF, W3C, etc.) technologies!
(Also, you certainly can monetize an RFC. In fact, that's the norm in a lot of RFC categories: the various PKCS-derived RFCs are a direct extension of various patented standards that RSA[1] sold software atop of.)
Outside of my friend group, no one uses XMPP, the internet standard for chat, they only know about walled gardens and custom protocols by VC startups now :(
I miss when Facebook Messenger let you connect to it with XMPP back in the day so you could have it together with your other msging services on Adium/Pidgin
Nowadays, my friend, people just copy, paste, or vibecode everything. If you (or anyone) think they’re not forgotten, you’re one of the few who still read and understand the RFCs. Said that in the post too.
The people building the infrastructure powering the internet at cloudflare, major cloud providers, isps, etc are all regularly reading and referencing RFCs (from experience). People who aren't reading them now weren't reading them in the past either, we don't need some RFC moral panic.
I agree. RFCs have a niche use case, like a manual, or a glossary. They're there, if you need them, but few people are supposed to be implementing RFCs or internet from "blueprints" all the time.
I don't think they're that niche. If you want to know what an email address can contain or what a cname should be, just read the RFC.
They're surprisingly easy to read and I'd encourage any younger readers to have a look at ones that are appropriate to your field. You'll almost certainly learn something new and it's good to have a grasp of these fundamentals.
Which RFC? The challenge as with all technical specifications is that you have revisions over time and even some times get split up into multiple RFCs. And then as with all interoper issues, is the RFC that you implement the one that other systems you’re interacting with also implementing that RFC. And then even after all of that, you have implementation differences where even if you follow the RFC to the letter, other implementations either made intentional alternate legal choices or had bugs.
RFCs are generally easy to read but there’s a meaningful chasm between understanding the RFC and what actually gets implemented in practice.
I don’t know what niche you inhabit, but anecdotally the overwhelming majority of engineers I know have consulted an RFC. RFCs are an active component in the Internet; you need to at least reference them (if not fully read them) to understand how various parts of the Internet interoperate.
(It seems extremely unlikely that the average non-junior engineer hasn’t opened up RFC 3339 or one of the HTTP caching RFCs, just for example.)
I dunno, I think many dev are aware of the existence of RFCs, but if your work occurs at higher levels of the stack there is frequently not a pressing need to read them.
For example, you don't have to read the specific RFC to know the difference between 200, 400, and 500 status codes. Any layman's blog post (or literally just reading the response messages accompanying those codes in actual use) is enough knowledge to get you real far.
That said; if a senior dev isn't aware of 3339, the holiest of RFCs, then that's a problem.
There's a strong inverse correlation in my career between how often a dev refers to RFCs by number alone and how much I ever want to interact (let alone work) with them again.
Personally, I have about a dozen related RFCs on my bookmarks toolbar due to a project that I worked on. I was referencing them constantly when I was actively working on that project.
It's like saying the the proof of, say, Seifert-van Kampen theorem is "forgotten" because nowadays, my friend, people ask ChatGPT to write out solutions to their math homework.
The fact that you are able to send this message over the internet is proof that a quite large population of people are still reading and still understand internet standards.
If you haven't done it before, I strongly recommend picking some RFC and implementing it, with no other references (you can of course look up language and library questions, just without referencing existing implementations or anything specific to that RFC).
It's really nice to have a complete and rigorous specification. It's quite common today for docs to be extremely incomplete or vague, especially as more and more teams use LLM to generate a lot of prose that is devoid of information.
For example 1495 is nice if you like IRC. You can pick to implement a server and try to connect with existing clients to validate your implementation, or make a client and join your favorite server (though test on some test server first).
Maybe it's just me, but sometimes you still don't understand how you should do something, even after having read the RFC multiple times, so you still need to look what other implementations are doing.
It's a treasure. I feel for those expressing their loss - and at the same time am slightly in awe that IANA used to be "just some guy" - this plus the April Fool tradition gives the RFC series a very approachable human feeling.
I started reading RFCs as a teenager when I stumbled upon an RFC collection on a CD-ROM distributed with a computer magazine. It didn't last long until I started implementing my own SMTP client.
And then I discovered this, and for a moment I was a bit afraid: TELNET SUBLIMINAL-MESSAGE Option
[https://www.rfc-editor.org/rfc/rfc1097.html]. I didn't immediately understand it was a 1st April's joke, and was thinking something like "how many other weird things nobody ever heard about are actually implemented into Internet software?". Also because, of course, I was regularly using Telnet at that time. Then I realized the date and the fact that the option number (which is supposed to be a byte) was defined as... 257. Later I discovered that of course 256 was already assigned to the Telnet Randomly-Lose option, the very first such RFC, a comment of which seems very contemporary despite having been written in 1978: "Several hosts appear to provide random lossage, such as system crashes, lost data, incorrectly functioning programs, etc., as part of their services.".
One of the many joys of Debian (and derived GNU/Linux distros) is the dwww information server, which provides (local-only, by default) Web-based access to system information (man and info pages, package documentation, various documentation-oriented packages, etc.), and the doc-rfc-* packages, see:
These provide you with your own locally-browseable and searchable versions of RFCs. The packages are split so that you need not install all RFCs if you prefer not to, with informational, experimental, old, and proposed being notable collections.
The part about ARPANET was created to withstand a nuclear attack, is a common myth. It was linked to the Cold War, yes, but was created to communicate betweeen different computer systems and sharing of information.
EDIT: jibal pointed that out 30 minutes ago, didn't see that.
People interested in the history of the internet may enjoy the book "Where wizards stay up late". I'm sure there are other good books on it too (perhaps others can recommend below), but that's the one I read and enjoyed.
- What RFCs are useful to read if I want to learn networking well
- I heard that the best way to learn low-level programming is by rebuilding already existing programs. what high quality RFCs can I use as a guide to code-my-own <so and so program>
There are a number of problems with trying to learn networking from the RFCs. First, they're specifications, not tutorials, so they just assume that you have a lot of background that you otherwise have to infer. Second, it's very common for a protocol to have been iteratively developed over the years and so split over a number of RFCs. In some cases, people will eventually try to consolidate things into a single document or document suite, but it's a big pain to do that, so it often doesn't happen.
Finally, a lot of the foundational RFCs were written long before we had a good understanding of how to design a robust networking protocol. For example, if you just implement TCP's original rate control algorithm [RFC 793] you get a system which is very vulnerable to congestion collapse (see https://ee.lbl.gov/papers/congavoid.pdf for more). Even with a more modern specification for RCP as in RFC 9293, you kind of have to work to piece together the shape of a working system. The QUIC RFCs are better because they were written all at once, but it's still not really designed to teach you.
IMO a better place to start is TCP/IP Illustrated by W. Richard Stevens. Volume 1 really explains the protocols. Volume 2 shows how to actually implement them.
These are the RFCs we know, and many others we don’t. The ones “lost” to obscurity generally deserve the fate but I enjoy reading them for the historical context. Fascinating stuff.
What I dislike of RFCs is that some are accepted, but still referred as RFC, for no apparent reason.
I specially dislike when some people try to do the same with internal documentation and still call "RFC 2029 Project Lifecycle" when it has been accepted by all the appropriate parties. It makes it harder to look for than needed, and it's not clear, by the name, if it has been passed or not.
They were going to have to choose a name for the entire document series, irrespective of the stage of evolution each document is in. I don't have a good answer to why they choose RFC for it, though a sibling comment does address that part. What you're looking for is an indicator for the stage in its evolution. That is fulfilled by the RFC's 'Status' [1][2]. You can use it as a search criterion on the rfc-editor website [3].
You wrote "I don't have a good answer to why they choose RFC for it" ... with that prompt you will get a summary of the reasons they chose it, with direct quotes from Steve Crocker and citations, all of which can be checked for accuracy.
But sorry for trying to be helpful. No good deed goes unpunished, as they say.
> But sorry for trying to be helpful. No good deed goes unpunished, as they say.
If that was your intention, I apologize. I misunderstood what you were trying to say. But looking at the score on that comment, I don't think I'm the only one who misunderstood it. These comments may need a bit more effort to avoid this confusion. Meanwhile, please don't take it personally - I wasn't trying to insult or be disrespectful. I was just trying to convey that it was annoying. Anyway, thanks for the pointer! I will check it out.
This is only a tiny part of the trainwreck that is IETF and IETF-adjacent document nomenclature.
IETF documents start as Internet-Drafts, which officially are just draft documents that can be changed at any time. As a practical matter, some I-Ds really have no status and some have been accepted by WGs to work on. You can tell which are which because (mostly) the latter are named draft-ietf-something. As WG documents progress, it's not uncommon to see very wide deployment based on an I-D (this was the situation for QUIC and TLS 1.3), whereas other drafts are just totally half-baked and nobody is deploying. There is no good way to know which is which without paying attention.
Inside the IETF, RFCs can be published be any of Standards Track, BCP, Informational, or Experimental. Nominally, the first group are really standards (see asterisk below), whereas the BCPs are normative but not really standards (e.g., they might describe how the IETF is supposed to run), whereas the latter two are not standards. Except sometimes they are de facto standards, like RFC 6962, specifying Certificate Transparency (note that there is another RFC for CT, RFC 9162, which nominally supercedes RFC 6962, but is not widely implemented). There are two standards levels, Proposed Standard, and Standard (there used to be a middle one, Draft Standard), but as a practical matter lots of specifications stay at PS forever because the WG or authors can't be bothered to get them promoted to full standard. QUIC, TLS, and HTTP are all Proposed Standards.
Moreover, there are other IETF-adjacent organizations that publish RFCs, such as the Internet Architecture Board (IAB) and the Internet Research Task Force (IRTF). These documents aren't standards at all. Finally, there is an Independent Submissions Editor (ISE), appointed by the IAB, who basically can publish whatever he/she wants on the Independent Stream. Note that this is different from an Individual Submission, which is a document processed by the IETF without going through a WG.
The discussion continues for the lifetime of an RFC, even after its acceptance. The idea is to continually keep it in a challenged state so that we remember anything can be possible.
If we desire something new, the RFC invites us to build upon it and not accept it as gospel.
Whether you, your project, or your organization accept it is completely disconnected with the concept of the RFC. You may procedurally accept it as unchallengeable gospel, but the truth remains that you can always have an opinion about it regardless.
The nicer format is "X Change/Improvement Proposal" or something similar, shorted to "XCP/XIP". Not sure where it originally comes from, but is pretty popular in various protocol circles, Bitcoin Improvement Proposal (BIP) is one example.
There are NIPs (for Nostr), PEPs (for Python)... But they all have the problem that parent is complaining about. The possibilities/proposal part of the names remain even after they have been accepted or rejected.
It kind of makes sense! First you make a proposal, and then it's a accepted proposal or rejected one. Just because it changed state doesn't mean it's no longer a "proposal".
Compared to a RFC. If it's accepted/rejected, it's still a RFC, which isn't really true anymore, comments are no longer requested.
Oh, RFCs aren’t forgotten. Every FAANG and wannabe FAANG has some form of RFC writing and reading culture baked in.
With AI, companies are forcing people to churn them out faster than ever. It’s gotten to the point where, to keep up with this slop, people are using LLMs to summarize LLM-generated RFCs.
P.S.
"The goal was to create a reliable, distributed communication system that could continue operating even if parts of it were damaged by a nuclear attack."
This is a myth. The ARPANET was not hardened; quite the opposite. ARPA's goal was for their researchers located across the country to easily share their work ... initially it was just used to share papers, before Ray Tomlinson invented email. Beyond that, JCR Licklider who laid the conceptual foundations was looking toward something along the lines of today's Internet + AI:
https://en.wikipedia.org/wiki/Man%E2%80%93Computer_Symbiosis
P.P.S. Steve Crocker's MIT PhD thesis was on man-machine symbiosis. I know this because he mentioned it to me when I met him in the UCLA Computer Club which he came to because he wanted to teach an informal class on LISP and Theorem Proving, and the club organized such classes. We got to talking about his thesis, he posed some challenges to me that I got lucky in solving, and he immediately offered me a job (he was the head of the ARPANET project at UCLA, under Leonard Kleinrock) that shaped the rest of my life--I'm greatly indebted to him.
Y.A.P.S. Steve Crocker received the Jonathan B. Postel Award (created by Vint Cerf) last year.