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.
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.
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.
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.
- 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>
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.
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.
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.
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.
20 comments
[ 2.8 ms ] story [ 33.0 ms ] threadhttps://datatracker.ietf.org/doc/html/rfc2468
There's quiet genius in that choice of number by the way. 2, 4, 6, 8, who do we appreciate?
Related: https://www.internetsociety.org/grants-and-awards/postel-ser...
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.
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.
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.
- 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>
EDIT: jibal pointed that out 30 minutes ago, didn't see that.
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).
It's always a humbling experience to read the ones about the technology that powers the internet and they are older than me.
That being said, https://datatracker.ietf.org/doc/html/rfc6238 is a delight.
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.".
The whole collection is here: https://en.wikipedia.org/wiki/April_Fools'_Day_Request_for_C.... And as other people mentioned, some are really funny.
<https://packages.debian.org/search?keywords=rfc>
And for dwww: <https://packages.debian.org/trixie/dwww>
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.