6 RFCs for understanding how the internet works

And three for fun.

Image by:

Opensource.com

Reading the source is an important part of open source software. It means users have the ability to look at the code and see what it does.

But "read the source" doesn't apply only to code. Understanding the standards the code implements can be just as important. These standards are codified in documents called "Requests for Comments" (RFCs) published by the Internet Engineering Task Force (IETF). Thousands of RFCs have been published over the years, so we collected a few that our contributors consider must-reads.

6 must-read RFCs

RFC 2119—Key words for use in RFCs to indicate requirement levels

This is a quick read, but it's important to understanding other RFCs. RFC 2119 defines the requirement levels used in subsequent RFCs. What does "MAY" really mean? If the standard says "SHOULD," do you really have to do it? By giving the requirements a well-defined taxonomy, RFC 2119 helps avoid ambiguity.

RFC 3339—Date and time on the internet: timestamps

Time is the bane of programmers the world over. RFC 3339 defines how timestamps are to be formatted. Based on the ISO 8601 standard, 3339 gives us a common way to represent time and its relentless march. For example, redundant information like the day of the week should not be included in a stored timestamp since it is easy to compute.

RFC 1918—Address allocation for private internets

There's the internet that's everyone's and then there's the internet that's just yours. Private networks are used all the time, and RFC 1918 defines those networks. Sure, you could set up your router to route public spaces internally, but that's a bad idea. Alternately, you could take your unused public IP addresses and treat them as an internal network. In either case, you're making it clear you've never read RFC 1918.

RFC 1912—Common DNS operational and configuration errors

Everything is a #@%@ DNS problem, right? RFC 1912 lays out mistakes that admins make when they're just trying to keep the internet running. Although it was published in 1996, DNS (and the mistakes people make with it) hasn't really changed all that much. To understand why we need DNS in the first place, consider what RFC 289—What we hope is an official list of host names would look like today.

RFC 2822—Internet message format

Think you know what a valid email address looks like? If the number of sites that won't accept a "+" in my address is any indication, you don't. RFC 2822 defines what a valid email address looks like. It also goes into detail about the rest of an email message.

RFC 7231—Hypertext Transfer Protocol (HTTP/1.1): Semantics and content

When you stop to think about it, almost everything we do online relies on HTTP. RFC 7231 is among the most recent updates to that protocol. Weighing in at just over 100 pages, it defines methods, headers, and status codes.

3 should-read RFCs

Okay, not every RFC is serious business.

RFC 1149—A standard for the transmission of IP datagrams on avian carriers

Networks pass packets in many different ways. RFC 1149 describes the use of carrier pigeons. They can't be any less reliable than my mobile provider when I'm more than a mile away from an interstate highway.

RFC 2324—Hypertext coffee pot control protocol (HTCPCP/1.0)

Coffee is very important to getting work done, so of course, we need a programmatic interface for managing our coffee pots. RFC 2324 defines a protocol for interacting with coffee pots and adds HTTP 418 ("I am a teapot").