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.
Thanks for the summary of the document, but not quite what I asked for. Why would e.g. a VHDL engineer need to have read it to deserve the title senior?
Well you are kinda straw manning me, considering my own words were "that's a problem" and not "don't deserve a title senior engineer". I also specifically said "senior dev" and not "senior engineer", which are very different things. Maybe re-read the comment chain with fresh eyes, since you seem to have taken a very antagonistic interpretation?
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.
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.