According to abbreviationfinder, RFC stands for Request for Comments. A series of notes on the Internet that began publication in 1969. Each of them individually is a document whose content is an official proposal for a new Internet protocol (originally from ARPANET), which is explained in detail so that if it is accepted it can be implemented without ambiguity.
History
The creation of the RFC format occurred in 1969 as part of the ARPANET project. Today, it is the official publication channel for the Internet Engineering Task Force (IETF), the Internet Architecture Board (IAB), and – to some extent – the global community of computer network researchers in general.
The authors of the early RFCs typed their papers and distributed copies to ARPA researchers. Unlike modern RFCs, many of the earliest RFCs were requests for comments. The RFC leaves open questions and is written in a less formal style. This less formal style characterizes draft Internet documents, the precursor step before being approved as an RFC.
In December 1969, researchers began distributing new RFCs through the newly operational ARPANET. RFC 1 entitled “Host Software”, was written by Steve Crocker of the University of California, Los Angeles (UCLA), and published on April 7, 1969. Although authored by Steve Crocker, the RFC grew out of a group discussion in the early of work between Steve Crocker, Steve Carr and Jeff Rulifson. (The document lists Bill Duvall as presenting only the last meeting of the task force before publication.)
In RFC 3 which first defined the RFC series, Crocker began attributing the RFC series to the “Network Working Group”. This group appears to have never had a formal existence, instead being defined as “this group of people”, but the attribution remains the RFC to this day.
Many of the later RFCs from the 1970s also came from UCLA, not only because of the quality of the scholarship, but also because UCLA was one of the first Message Interface Processors (MIPs) on the ARPANET.
Characteristic
Each RFC has a title and an assigned number, which cannot be repeated or deleted even if the document becomes obsolete. There are several categories, which can be informative (when it is simply a matter of assessing, for example, the implementation of a protocol), proposals for new standards, or historical (when they are made obsolete by more modern versions of the protocol they describe).
RFCs are written in English according to a specific structure and in ASCII text format.
Before a document can be considered an RFC, it must follow a very strict process to ensure its quality and consistency. When it succeeds, it is practically a formal protocol to which few objections are likely to be raised, so the meaning of its name as a request for comments is practically obsolete, since the criticisms and suggestions are produced in the previous phases. However, the RFC name is kept for historical reasons.
Obtaining RFC
The official source for RFCs on the World Wide Web is the RFC Editor.
Almost any published RFC, such as RFC 5000, can be obtained via a URL in the form of the following example: http://www.rfc-editor.org/rfc/rfc5000.txt
Each RFC is presented as plain ASCII text and published in that form, but may also be available in other formats. However, as of 2008 the definitive version of any standard track is the ASCII version.
To facilitate access to an RFC’s metadata, including abstract, keywords, author(s), publication date, errata, status, and most of all, latest updates, the RFC Editor site offers a feature-rich browser. A redirect sets some efficiency parameters, for example: http://purl.net/net/rfc/5000
Condition
Not all RFCs are standards. Each RFC is assigned a designation with respect to status in the Internet standardization process. This status is one of the following: Informational, Experimental, Best Current Practice (BCP), Standard Tracks, or Historical. Track Standard documents are divided into Proposed Standard, Draft Standard, and Internet Standard Documents. The term historical applies to obsolete standards documents or obsolete RFCs that were published before the standards track was established. IETF only, represented by the Internet Engineering Steering Group (IESG), can approve RFC standards. Each RFC is static, if the document is changed, it is committed again and assigned a new RFC number. If an RFC is converted to an Internet Standard (STD), it is assigned an STD number, but it retains its RFC number, however, when an Internet Standard is updated, its number remains the same and it is simply changed. refers to another RFC or set of RFCs. A given Internet standard, STD n, may be RFC x or y at one point, but later the same standard may be updated to support RFC z instead. For example, in 2007 RFC 3700 was an Internet standard-STD 1- and in May 2008 was superseded by RFC 5000, which is why RFC 3700 went historic, RFC 5000 became an internet standard, and as of May 2008 STD 1 is RFC 5000. When an STD is updated again, they simply refer to a Recent RFC’s have completed the standard track, but it will remain an STD. Current Best Practices work in a similar way; BCP n refers to a certain RFC or set of RFCs, but that RFC or RFCs may change over time.
The definitive list of Internet Standards itself is an Internet standard, STD 1: Internet Official Standards Protocol.
“informational” status
An informative RFC can be just about anything, from jokes about proprietary protocols to widely recognized essential RFCs like Structure and Delegation of the Domain Name System (RFC 1591). Some informational RFCs form the For Information (FYI) subseries. Although rarely added today, some old FYIs are still interesting, for example, FYI 18 (RFC 1983), Internet User’s Glossary. FYI 17, The Tao of the IETF, is now RFC 4677, published in 2006.
“experimental” state
An experimental RFC can be an IETF document or an individual submission to the RFC Editor. In theory it is experimental, in practice some documents are not promoted in the rules of the track because there are no volunteers to know the details of the procedure.
Status “current best practice”
The Best Current Practices (BCP) subseries contains the administrative documents and other texts that are considered to be the official rules and not only informative, but which do not affect the cable data. The border between standard track and BCP is often unclear. If a document only affects the Internet standardization process, such as BCP 9, or the administration of the IETF, that is clearly a BCP. If you only define the rules and regulations for the Internet Assigned Numbers Authority (IANA) register this is not so clear; most of these documents are on PCBs, but some are on standard tracks.
“historic” state
A historical RFC is one that has been made obsolete by a new version, the documents of a protocol that is not considered interesting in today’s Internet, or has been removed from the standard track for other reasons. Some obsolete RFCs are not classified as historic, since the Internet standards process generally does not allow normative references from one standard RFC track to another with lower status. Furthermore, few are interested in working through the procedural details required to get an RFC classified as historic and update all RFCs normatively accordingly.
“unknown” status
Unknown status is used for some very old RFCs, where it is not clear what status the document would get if it were published today. Some of these RFCs would not be published at all today; one of the first RFCs was often just that: a simple request for comments, not wanting to nail down a protocol, administrative procedure, or anything else that the RFC series is used for today.
