RFCs: Blueprints of the Internet

https://ackreq.github.io/posts/what-are-rfcs/

by ackreq • 9 months ago

118 92 9 months ago

ackreq.github.io

mlhpdx• 9 months ago

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• 9 months ago

Forgotten? No mention of why we should think they are forgotten outside the headline.

zaik• 9 months ago

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• 9 months ago

Since when became XMPP "the internet standard for chat"? What about IRC[0]? :(

[0]: RFCs 1459, 2810 - 2813, 7194.

lou1306• 9 months ago

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• 9 months ago

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

loeg• 9 months ago

XMPP has nothing going for it.

1970-01-01• 9 months ago

Clickbait gonna bait.

ackreq8• 9 months ago

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.

alterom2• 9 months ago

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.

woodruffw4• 9 months ago

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.)

James_K• 9 months ago

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• 9 months ago

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.

RHSeeger• 9 months ago

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• 9 months ago

Most things are now vendor proprietary and not designed for interoperability. RFCs are forgotten because you can't monetize an RFC.

lexszero_• 9 months ago

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.

woodruffw4• 9 months ago

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• 9 months ago

"With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea."

mkoubaa• 9 months ago

Reminds me of a Russian joke:

Can a hedgehog fly? Yes, if you kick it.

hinkley2• 9 months ago

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

ackreq8• 9 months ago

"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• 9 months ago

"with sufficient thrust, anything can fly -- it's the landing that can get messy"

znort_• 9 months ago

apropos of that: https://datatracker.ietf.org/doc/html/rfc2549

dcminter2• 9 months ago

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?

ackreq8• 9 months ago

Wow, never heard of this one before. Thanks for sharing!

dcminter2• 9 months ago

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.

hinkley2• 9 months ago

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.

jibal11• 9 months ago

gnarlouse• 9 months ago

Aren’t all PEPs, TC39s, and BIPs forms of RFCs?

woodruffw4• 9 months ago

They’re all forms of requests for comment, but people also typically mean RFC to mean IETF RFCs.

betaby2• 9 months ago

They surely are!

rednafi• 9 months ago

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• 9 months ago

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• 9 months ago

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.

CaptainOfCoit2• 9 months ago

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.

goku124• 9 months ago

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.

lanyard-textile• 9 months ago

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.

goku124• 9 months ago

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

jibal11• 9 months ago

Try this prompt: "I think there was a discussion that led to Steve Crocker naming "RFC" that ... do you have information on the discussion?"

ekr____3• 9 months ago

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.

jibal11• 9 months ago

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.

ackreq8• 9 months ago

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

jibal11• 9 months ago

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."

soneil• 9 months ago

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• 9 months ago

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• 9 months ago

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____3• 9 months ago

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• 9 months ago

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• 9 months ago

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• 9 months ago

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• 9 months ago

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).

ackreq8• 9 months ago

That’s exactly how you learn the depth of a specification.

placebo• 9 months ago

I actually did exactly that for a product back in the days when there was no open implementation. IRC, SMTP, POP3, DNS. Good times :)

17186274402• 9 months ago

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.

k__• 9 months ago

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• 9 months ago

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• 9 months ago

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.

dredmorbius• 9 months ago

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:

<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.

immibis• 9 months ago

RFCs are not special. They are merely one of many pathways through which information is published.

RFCs: Blueprints of the Internet

Related Stories