6 must-read internet standards

6 RFCs for understanding how the internet works

And three for fun.

Subscribe now

Get the highlights in your inbox every week.

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.

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").

RFC 69—Distribution list change for M.I.T.

Is RFC 69 the first published example of a misdirected unsubscribe request?

What are your must-read RFCs (whether they're serious or not)? Share your list in the comments.

Topics

About the author

Ben Cotton - Ben Cotton is a meteorologist by training, but weather makes a great hobby. Ben works as a the Fedora Program Manager at Red Hat. He co-founded a local open source meetup group, and is a member of the Open Source Initiative and a supporter of Software Freedom Conservancy. Find him on Twitter (@FunnelFiasco) or at FunnelFiasco.com.

Footer

The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat.

Opensource.com aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. Red Hat and the Red Hat logo are trademarks of Red Hat, Inc., registered in the United States and other countries.