8 ms·
RFCs: Blueprints of the Internet
- deleted 1y ago[deleted]
- mlhpdx 1y agoThese 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 1y agoForgotten? No mention of why we should think they are forgotten outside the headline.
- zaik 1y agoOutside 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 1y agoSince when became XMPP "the internet standard for chat"? What about IRC[0]? :( [0]: RFCs 1459, 2810 - 2813, 7194.
- lou1306 1y agoCome 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 1y agoWhatsapp, 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 1y agoWhatsapp used XMPP many years ago, not today though.
- alexchantavy 1y agoI 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 1y agoXMPP has nothing going for it.
- 1970-01-01 1y agoClickbait gonna bait.
- AungChoMin 1y ago[flagged]
- ackreq 1y agoNowadays, 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 1y agoYeah, 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.
- woodruffw 1y agoI 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 1y agoPersonally, 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 1y agoI 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.
- RHSeeger 1y agoAs 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 1y agoMost things are now vendor proprietary and not designed for interoperability. RFCs are forgotten because you can't monetize an RFC.
- lexszero_ 1y agoInterestingly, 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 1y agoThis 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 https://en.wikipedia.org/wiki/RSA_Security
- jeffreygoesto 1y ago"With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea."
- mkoubaa 1y agoReminds me of a Russian joke: Can a hedgehog fly? Yes, if you kick it.
- hinkley 1y agoBirdie, 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 1y 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 1y ago"with sufficient thrust, anything can fly -- it's the landing that can get messy"
- znort_ 1y agoapropos of that: https://datatracker.ietf.org/doc/html/rfc2549 https://datatracker.ietf.org/doc/html/rfc2549
- dcminter 1y agoNot forgotten, but this article did not mention my favourite and the most moving RFC: 2468 https://datatracker.ietf.org/doc/html/rfc2468 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-service-award https://www.internetsociety.org/grants-and-awards/postel-ser...
- ackreq 1y agoWow, never heard of this one before. Thanks for sharing!
- dcminter 1y agoIt'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 1y agoI 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 https://www.rfc-editor.org/rfc/rfc2441
- hinkley 1y agoVint 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 1y agoSee also https://www.rfc-editor.org/rfc/rfc2441 https://www.rfc-editor.org/rfc/rfc2441
- gnarlouse 1y agoAren’t all PEPs, TC39s, and BIPs forms of RFCs?
- rednafi 1y agoOh, 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 1y agoYep, 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 1y agoWhat 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 1y agoThe 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 1y agoThere 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 1y agoIt 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 1y agoThe 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.
- jibal 1y agoSteve 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 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 1y agoYou 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 1y agoPlease please please mention that https://en.wikipedia.org/wiki/Jon_Postel 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 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."
- spacebuffer 1y agoTangent 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 1y agoStart 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____ 1y agoAlmost 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 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 1y agoPeople 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 1y agoThe 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 1y agoMy 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 1y agoIf 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 1y agoThat’s exactly how you learn the depth of a specification.
- placebo 1y agoI actually did exactly that for a product back in the days when there was no open implementation. IRC, SMTP, POP3, DNS. Good times :)
- 1718627440 1y agoMaybe 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__ 1y agoI 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 1y agoI wish RFCs were more plain English. Some of them are just _whoosh_. That being said, https://datatracker.ietf.org/doc/html/rfc6238 https://datatracker.ietf.org/doc/html/rfc6238 is a delight.
- ale42 1y agoI 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 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_Comments https://en.wikipedia.org/wiki/April_Fools'_Day_Request_for_C.... And as other people mentioned, some are really funny.
- dredmorbius 1y agoOne 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 https://packages.debian.org/search?keywords=rfc> And for dwww: <https://packages.debian.org/trixie/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 11mo agoRFCs are not special. They are merely one of many pathways through which information is published.