Request for Comments is a series of publications which define how the internet works. These are the papers that form our world. To my disbelief, a lot of developers have not read a single one.
Imagine how you would feel if the mechanic working on your car had not read a single workshop manual, but just tried playing around with the tools?
Most developers have not read a single one.
What’s a RFC?
RFCs are as old as the internet itself, it started out as hard copies of papers on which the author wanted input from other researches. Thus the name "request for comments". This legacy is clearly visible in the formatting of the documents, especially when viewed in txt mode. Todays RFCs are formal, while the less formal style is called Internet Draft.
RFC are managed by the IETF (Internet Engineering Task Force) and each one defines some sort of standard related to computer communication. They cover almost everything, there is even one on how to write one.
RFCs are referenced by numbers, and some are more known than others. One example is RFC 2616 which is the old definition of the HTTP/1.1 protocol, now split into several separated documents. Mark Nottingham has written about the split.
There's even a RFC on how to write a RFC
Besides a number, RFCs are classified as either Internet Standard (and proposed standard), Best Current Practice, Informational/Experimental and Historic. The whole process is described in RFC-2026 with updates. A RFC often starts out as an Internet Draft. An Internet Draft must be updated within 6 months to advance. An example of such is the Application-Level Profile Semantics ALPS. ALPS is quite interesting and a topic I will cover in a later post, until then you will have to read the RFC ;-).
Real life examples
The e-mail story###
Let's start with an obvious one, e-mail address validation. Having the correct e-mail address for your customer is somewhat important nowadays. A fairly common approach is to validate the address using regex. Which will fail. A regex such as this ^[_a-z0-9-]+(\.[_a-z0-9-]+)*@[a-z0-9-]+(\.[a-z0-9-]+)*(\.[a-z]{2,4})$ may seem to work, but if you take a closer look at http://tools.ietf.org/html/rfc5321 and https://tools.ietf.org/html/rfc5322#section-3.4.1 and then remember that you should support internationalized addresses http://tools.ietf.org/html/rfc6530, we suddenly see that regex is just not a good candidate. If deciding to go that way, at least now we know that we may fail on valid addresses. Another e-mail validation method is to do a DNS lookup on the hostname, so let's check for MX servers. Well, I thought that was enough until I read the RFC https://tools.ietf.org/html/rfc5321#section-5.1 and had to use the A RR record if there were no MX records.
API Warning###
I recently needed to notify API consumers on operational issues, and we would somehow like to signal this without having to modify our API responses. After having a look at the new HTTP/1.1 RFCs, in specific http://tools.ietf.org/html/rfc7231 we decided to use the warning header and add the URL to our status endpoint.
Funtime
Not all RFCs are as dry and boring as they might seem, there's plenty of humor to be found. I guess A Standard for the Transmission of IP Datagrams on Avian Carriers is one of the more known ones. It was even implemented in 2001 by Bergen Linux User Group http://www.blug.linux.no/rfc1149
Another one worth mentioning is Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) which defines the well known HTTP response code 418 - I'm a teapot.
You find more April Fools' Day RFCs here
Go read##
There's so much gold and valuable knowledge in RFCs. Yes, they are a bit tedious and sometimes dry, but reading RFCs on technologies you're working with is worth it. If you have not done it yet, I suggest you start reading on the new RFCs for the HTTP/1.1 protocol.