Which RFCs should be cited as internet standards?

It's extremely common for RFCs to be cited in support of opinions (including Serverfault Q&A's), but the average IT employee has a very poor understanding in regards to which RFCs define standards and which ones are purely informative. This should be no surprise: system administrators of all experience levels typically avoid glazing their eyes at RFCs unless they have no choice but to.

On a site like ours, it is extremely important that we don't perpetuate common misunderstandings in our upvoted answers. Random users cruising in from search engines are going to assume that upvotes with no disputing comments are sufficient indicators of vetting. Recently I stumbled across an answer from 2011 making it apparent that this is definitely not getting caught in some cases as we upvote and probably warrants some efforts to inform our community and the internet at large.

So without further ado, how does one differentiate between a RFC that is quotable as an internet standard and one that is purely informative?

Solution 1:

Only RFCs on the standards track can be cited as defining a standard. For the reader in passing, these are the main points to understand:

• Some of the older RFCs are not clearly labeled. When in doubt, plug it into the search box at http://www.rfc-editor.org/ and pay attention to the Status column. Be very cautious with anything labeled as Unknown, as they are effectively abandoned and not considered relevant.

• Any RFC with a designation of Historic has been obsoleted, regardless of how it was originally classified.

• Any RFC with a status of Proposed Standard, or Internet Standard can be used as a technical reference for the applicable internet standard. This is somewhat counter-intuitive and will be touched on below.

• In all other cases, the RFC cannot be considered a binding, authoritative source of information relative to Internet Standards.

• That said, RFCs with a designation of Best Current Practice (BCP) should be considered as carrying significant advisory weight. They are not binding in the way that a standard is, but they are heavily vetted and undergo some of the same scrutiny that RFCs in the standards track receive. Ignoring them doesn't violate a standard, but usually it's a bad idea.

• Informational RFCs lacking the BCP identifier are best likened to an article you come across in an IT magazine. You wouldn't pull out an editorial piece out of your desk and tell a director that it defines a standard, right?

• Experimental RFCs can only be used as a reference for the experimental features that they describe, and not as a reference for the standard that they are associated with. They exist in a vacuum until promoted to the standards track.

• Occasionally a technical reference may be published as an Informational RFC prior to being incorporated as an Internet Standard. DMARC (RFC 7489) is one of the most widely known modern examples of this. For all intents and purposes, treat these as you would an Experimental RFC. They exist in a vacuum and describe an optional feature.

• Even once you've navigated this maze, be aware that newer RFCs may have obsoleted significant parts of the RFC that you are quoting from! It is strongly recommended to use tools providing hyperlinks to RFCs that update the one you're viewing, such as those provided by http://tools.ietf.org/ and http://www.rfc-editor.org/.

Those are the bullet points. Now we're going to get into specifics.

RFC 1796 is a good primer for most people who don't want to spend a day staring at RFCs. It clearly and concisely explains the common misconception of people assuming that a RFC is always defining an internet standard of some sort. Pay special note to the part where vendors are occasionally guilty of abusing this ignorance when pushing their products.

BCP 9 defines the internet standards track, most notably the progression from Proposed Standard to Internet Standard. It should be noted that this is a concatenation of several RFCs, beginning with RFC 2026.

Reading RFC 2026 by itself in a vacuum is common occurrence but also a terrible idea:

• RFC 6410 eliminates the concept of Draft Standards entirely.
• RFC 7127 is a more recent (2014) update to BCP 9 making it clear that many Proposed Standards are never promoted to Internet Standard despite widespread implementation and high stability. This is in large part due to the higher vetting standards that modern Proposed Standards are subjected to prior to being classified as such. This RFC effectively retracts the prior statement by RFC 2026 that "Implementors should treat Proposed Standards as immature specifications". Never quote that line to anyone.

In short, if a RFC document is on the internet standards track at all, it has sufficient maturity to be used as a technical reference until such a point that a future RFC updates it.

Disclaimer

As the above demonstrates, the internet standards track defined by BCP 9 is a moving target. This answer is a snapshot in time and may require updating in the future. Given its community wiki status, feel free to do so or improve upon it in any way.

Solution 2:

The previous answer lays out the categories of IETF documents pretty well. All of the standards track RFCs are listed here:

https://www.rfc-editor.org/standards

The process of advancing an RFC from proposed or draft to full standard is tedious enough that few authors bother to do it. That means that in practice even though a revised document like RFC 5322 is just a draft standard and its predecessor 822 is still the nominal internet standard, 5322 is the one people follow.