[HN Gopher] RFCs: Blueprints of the Internet
___________________________________________________________________
RFCs: Blueprints of the Internet
Author : ackreq
Score : 104 points
Date : 2025-10-19 15:03 UTC (7 hours ago)
(HTM) web link (ackreq.github.io)
(TXT) w3m dump (ackreq.github.io)
| mlhpdx wrote:
| 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.
| ErikCorry wrote:
| Forgotten? No mention of why we should think they are forgotten
| outside the headline.
| zaik wrote:
| 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 :(
| SunlitCat wrote:
| Since when became XMPP "the internet standard for chat"? What
| about IRC[0]? :(
|
| [0]: RFCs 1459, 2810 - 2813, 7194.
| lou1306 wrote:
| 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.
| MYEUHD wrote:
| 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
| betaby wrote:
| Whatsapp used XMPP many years ago, not today though.
| alexchantavy wrote:
| 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
| loeg wrote:
| XMPP has nothing going for it.
| 1970-01-01 wrote:
| Clickbait gonna bait.
| ackreq wrote:
| 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.
| alterom wrote:
| 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(tm)
| definitely(c) 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.
| woodruffw wrote:
| 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.)
| LambdaComplex wrote:
| 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.
| dehugger wrote:
| 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.
| rkomorn wrote:
| 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).
| woodruffw wrote:
| 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 :-)
| ellenhp wrote:
| Would you mind elaborating on why you believe people need
| to have that number memorized to deserve the title
| senior?
| worik wrote:
| Not the number
| Uehreka wrote:
| > 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.
| necovek wrote:
| I always thought RFC 2324 was more of an obligatory reading
| material.
| alterom wrote:
| I'd say the same of RFC 11491
|
| ____
|
| 1https://datatracker.ietf.org/doc/html/rfc1149
| James_K wrote:
| 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.
| Anon1096 wrote:
| 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.
| Demiurge wrote:
| 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.
| onraglanroad wrote:
| 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.
| vlovich123 wrote:
| 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.
| RHSeeger wrote:
| 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.
| candiddevmike wrote:
| Most things are now vendor proprietary and not designed for
| interoperability. RFCs are forgotten because you can't monetize
| an RFC.
| lexszero_ wrote:
| 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.
| woodruffw wrote:
| 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
| jeffreygoesto wrote:
| "With sufficient thrust, pigs fly just fine. However, this is not
| necessarily a good idea."
| mkoubaa wrote:
| Reminds me of a Russian joke:
|
| Can a hedgehog fly? Yes, if you kick it.
| hinkley wrote:
| 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
| ackreq wrote:
| "It is hard to be sure where they are going to land, and it
| could be dangerous sitting under them as they fly overhead."
| dc396 wrote:
| "with sufficient thrust, anything can fly -- it's the landing
| that can get messy"
| znort_ wrote:
| apropos of that: https://datatracker.ietf.org/doc/html/rfc2549
| dcminter wrote:
| 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...
| ackreq wrote:
| Wow, never heard of this one before. Thanks for sharing!
| dcminter wrote:
| 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.
| jibal wrote:
| 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
| hinkley wrote:
| 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.
| jibal wrote:
| See also https://www.rfc-editor.org/rfc/rfc2441
| gnarlouse wrote:
| Aren't all PEPs, TC39s, and BIPs forms of RFCs?
| woodruffw wrote:
| They're all forms of requests for comment, but people also
| typically mean RFC to mean IETF RFCs.
| betaby wrote:
| They surely are!
| rednafi wrote:
| 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.
| bazmattaz wrote:
| 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
| JaumeGreen wrote:
| 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.
| CaptainOfCoit wrote:
| 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.
| goku12 wrote:
| 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.
| CaptainOfCoit wrote:
| 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.
| lanyard-textile wrote:
| 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.
| goku12 wrote:
| 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
| jibal wrote:
| Try this prompt: "I think there was a discussion that led to
| Steve Crocker naming "RFC" that ... do you have information
| on the discussion?"
| jibal wrote:
| 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.
| ackreq wrote:
| 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
| jibal wrote:
| 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."
| ackreq wrote:
| Thanks a lot for sharing these informations. I'll update
| the post accordingly within 24 hours after I've read them.
| jibal wrote:
| You might want to read https://www.google.com/books/editi
| on/Where_Wizards_Stay_Up_L...
| ackreq wrote:
| Sure thing, I will. Thanks again for your previous
| comments. I'll do my best to include them in the post.
| jibal wrote:
| Also see https://datatracker.ietf.org/doc/html/rfc2441
| "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."
| ekr____ wrote:
| 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.
| jibal wrote:
| 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."
| soneil wrote:
| 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.
| spacebuffer wrote:
| 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>
| KylerAce wrote:
| 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).
| ekr____ wrote:
| 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.
| foo42 wrote:
| 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.
| mapn827 wrote:
| 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.
| afisxisto wrote:
| 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.
| progbits wrote:
| 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).
| ackreq wrote:
| That's exactly how you learn the depth of a specification.
| placebo wrote:
| I actually did exactly that for a product back in the days when
| there was no open implementation. IRC, SMTP, POP3, DNS. Good
| times :)
| k__ wrote:
| 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.
| 1a527dd5 wrote:
| 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.
| ale42 wrote:
| 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.
___________________________________________________________________
(page generated 2025-10-19 23:01 UTC)