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.
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.
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."
"One can also read that Jon was the editor of the RFC, and may think
that Jon checked only the grammar or the format of the RFCs. Nothing
could be further from the truth, not that he did not check it, but in
addition, being the corporate memory, Jon had indicated many times to
authors that earlier work had treated the same subject, and that
their work would be improved by learning about that earlier work."
...
" Our foundation and infrastructure of standards was the secret weapon
that won the war. Jon created it, using the RFC mechanism initiated
by Steve Crocker. It was Jon who immediately realized their
importance, and the need for someone to act as the curator, and
volunteered.
The lightning speed with which Microsoft joined the Internet was not
possible without the quality of the existing standards that were so
well documented.
During the transition from ARPA, through the NSF, to the commercial
world there was a point in which the trivial funding required for the
smooth operation of editing and distributing the RFCs was in doubt.
At that time the prospect of not having funds to run this operation
was very real. Finally the problem was solved and the process
suffered no interruption.
What most of the involved agencies and managers did not know is that
there was never a danger of any interruption. Jon would have done it
even with no external funding. If they did not pay him to do it, he
would have paid them to let him do it. For him it was not a job, it
was labor of love."
" When fancy formatting creeped into the Internet community, Jon
resisted the temptation to allow fancy formats for RFCs. Instead, he
insisted on them being in ASCII, easy to e-mail, guaranteed to be
readable anywhere in the world. The instant availability and
usability of RFCs was much more important to him than how fancy they
looked."
I think there's a fair argument to be made that this was a bad decision on Postel's part, because it made it harder to have good diagrams as well as mathematical formula, and of course it also meant that we couldn't render many people's names correctly. In any case, RFCs are now published in HTML and allow non-ASCII characters.
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.)
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.
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.
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
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.".
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).
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.
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.
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.
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].
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.
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:
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.
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.
You must have some amazing stories from back then! I’d love to read them if you ever feel like writing about it.
Thanks for reading my post. If you notice any incorrect information, please let me know anytime and I’ll update it
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.
Also:
https://en.wikipedia.org/wiki/ARPANET
"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."
Thanks a lot for sharing these informations. I’ll update the post accordingly within 24 hours after I’ve read them.
Note this in his WP article:
"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."
You might want to read https://www.google.com/books/edition/Where_Wizards_Stay_Up_L...
Sure thing, I will. Thanks again for your previous comments. I’ll do my best to include them in the post.
Also see https://datatracker.ietf.org/doc/html/rfc2441
..." Our foundation and infrastructure of standards was the secret weapon that won the war. Jon created it, using the RFC mechanism initiated by Steve Crocker. It was Jon who immediately realized their importance, and the need for someone to act as the curator, and volunteered.
" When fancy formatting creeped into the Internet community, Jon resisted the temptation to allow fancy formats for RFCs. Instead, he insisted on them being in ASCII, easy to e-mail, guaranteed to be readable anywhere in the world. The instant availability and usability of RFCs was much more important to him than how fancy they looked."I think there's a fair argument to be made that this was a bad decision on Postel's part, because it made it harder to have good diagrams as well as mathematical formula, and of course it also meant that we couldn't render many people's names correctly. In any case, RFCs are now published in HTML and allow non-ASCII characters.
Forgotten? No mention of why we should think they are forgotten outside the headline.
Most things are now vendor proprietary and not designed for interoperability. RFCs are forgotten because you can't monetize an RFC.
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.)
[1]: https://en.wikipedia.org/wiki/RSA_Security
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.
As part of my normal work, I linked and quoted part of an RFC just this week. They're not forgotten, just... less remembered, I guess.
Clickbait gonna bait.
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.
> That said; if a senior dev isn't aware of 3339, the holiest of RFCs, then that's a problem.
I’d love to read it, but I don’t have the time.
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.
Doubly so for the "meta" RFCs (eg 1925).
I understand that PKI engineers are not a very fun lot, but it seems unfair to blame them for having the various X.509 RFCs beaten into them :-)
Would you mind elaborating on why you believe people need to have that number memorized to deserve the title senior?
Not the number
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.
I always thought RFC 2324 was more of an obligatory reading material.
I'd say the same of RFC 1149¹
____
¹https://datatracker.ietf.org/doc/html/rfc1149
Yeah, as if reading and understanding RFCs was the pastime of the commoner in Ye Olde Dayse.
Or as if the vibe-coder of today would've totally™ definitely© be the type of person to peruse the RFCs.
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.
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 :(
Since when became XMPP "the internet standard for chat"? What about IRC[0]? :(
[0]: RFCs 1459, 2810 - 2813, 7194.
Whatsapp, Zoom and Kik Messenger use XMPP under the hood.
Just because it's not well-known doesn't mean it's not widely used
Whatsapp used XMPP many years ago, not today though.
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
XMPP has nothing going for it.
Come on, of course there will be some protocols that are more obscure than others, but the overall concept of RFCs is far from "forgotten".
Besides, a lot of these walled chat gardens roll their own XMPP/Jabber thingy behind the scenes.
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.".
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.
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).
I actually did exactly that for a product back in the days when there was no open implementation. IRC, SMTP, POP3, DNS. Good times :)
That’s exactly how you learn the depth of a specification.
Not forgotten, but this article did not mention my favourite and the most moving RFC: 2468
https://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...
Wow, never heard of this one before. Thanks for sharing!
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 knew and worked with both Vint and Jon at UCLA ... reading that (again) brings tears to my eyes.
P.S. Another RFC memorializing Jon: https://www.rfc-editor.org/rfc/rfc2441
See also https://www.rfc-editor.org/rfc/rfc2441
Vint is now 82 and I wonder when we’ll have a black bar for him.
The most recent picture of him on the Wikipedia article was at 74 and he still looked fairly spry.
I had to read a bunch RFCs in my career as technical writer.
It's always a humbling experience to read the ones about the technology that powers the internet and they are older than me.
I wish RFCs were more plain English. Some of them are just _whoosh_.
That being said, https://datatracker.ietf.org/doc/html/rfc6238 is a delight.
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.
Tangent questions:
- 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>
Almost none of them.
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.
Start with the rfc on udp since it's 4 pages long. Then you can pick from ipv4, ipv6, tcp, and then the html's (1, 1.1, 2, and 3).
Aren’t all PEPs, TC39s, and BIPs forms of RFCs?
They’re all forms of requests for comment, but people also typically mean RFC to mean IETF RFCs.
They surely are!
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.
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.
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].
[1] https://www.ietf.org/process/rfcs/#statuses
[2] https://www.rfc-editor.org/rfc/rfc2026#section-4.1
[3] https://www.rfc-editor.org/search/rfc_search.php
Try this prompt: "I think there was a discussion that led to Steve Crocker naming "RFC" that ... do you have information on the discussion?"
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.
My favourite still has to be RFC2549. I long for the days when a good April Fool's joke has that degree of effort put into it.
"With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea."
apropos of that: https://datatracker.ietf.org/doc/html/rfc2549
"with sufficient thrust, anything can fly -- it's the landing that can get messy"
Reminds me of a Russian joke:
Can a hedgehog fly? Yes, if you kick it.
Birdie, birdie in the sky
Dropped some toothpaste in my eye
Me no care, me no cry
Me just glad that cows don’t fly
"It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead."
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.
Yep, engineers pump out some many RFCs in our company that I first run it through an LLM to see if it’s worth reading