[0]: RFCs 1459, 2810 - 2813, 7194.
Besides, a lot of these walled chat gardens roll their own XMPP/Jabber thingy behind the scenes.
Just because it's not well-known doesn't mean it's not widely used
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.
(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.)
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.
Doubly so for the "meta" RFCs (eg 1925).
It's not "I tend to not want to work with people who name-drop RFCs", it's "people I don't want to work with tend to name-drop RFCs".
And PKI engineers are cool (and a lot smarter than me).
I think most people here can agree that seniors should be aware of standards for recording time. If you know you should write a date as "yyyy-MM-dd hh:mm:ss" (add precision or timezone information as required) then congratulations you are aware of the necessary standards.
I’d love to read it, but I don’t have the time.
____
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.
RFCs are generally easy to read but there’s a meaningful chasm between understanding the RFC and what actually gets implemented in practice.
(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.)
Can a hedgehog fly? Yes, if you kick it.
Dropped some toothpaste in my eye
Me no care, me no cry
Me just glad that cows don’t fly
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...
P.S. Another RFC memorializing Jon: https://www.rfc-editor.org/rfc/rfc2441
The most recent picture of him on the Wikipedia article was at 74 and he still looked fairly spry.
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.
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.
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.
[1] https://www.ietf.org/process/rfcs/#statuses
But sorry for trying to be helpful. No good deed goes unpunished, as they say.
If that was your intention, I apologize. I misunderstood what you were trying to say. But looking at the score on that comment, I don't think I'm the only one who misunderstood it. These comments may need a bit more effort to avoid this confusion. Meanwhile, please don't take it personally - I wasn't trying to insult or be disrespectful. I was just trying to convey that it was annoying. Anyway, thanks for the pointer! I will check it out.
BTW, you might want to look at a recent comment of mine,
https://news.ycombinator.com/item?id=45636185
It's because of my familiarity with RFCs and Steve Crocker, who originated the idea, that I had a recollection that he had discussed why they were called that, and prompted the LLM for details.
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.
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.
Thanks for reading my post. If you notice any incorrect information, please let me know anytime and I’ll update it
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."
"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."
"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."
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.
- 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.
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.
mlhpdx•3mo ago