Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
up vote 58 down vote accepted

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 accepted 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.
  • 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 frequently 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 update to BCP 9 (2014) 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.

share|improve this answer

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.

share|improve this answer
    
Just a FYI, the other answer is actually a community wiki post. Feel free to improve it. Also note that Draft Standard has been done away with and is no longer assigned. – Andrew B Feb 13 at 4:16
1  
Nevermind, you don't have the rep for that yet. Here's an upvote to help you along. – Andrew B Feb 13 at 4:22

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.