RFC (Request for Comments), Request for Comments. Series of Internet Notes that began in 1969 . Each one of them individually is a document whose content is an official proposal for a new protocol for the Internet network (originally from ARPANET), which is explained in detail so that if it is accepted it can be implemented without ambiguity.
Summary
[ hide ]
- 1 History
- 2 Features
- 3 Obtaining RFC
- 4 Status
- 1 “Informational” status
- 2 “Experimental” state
- 3 “Current best practice” status
- 4 “Historical” state
- 5 “Unknown” status
- 5 See also
- 6 References
- 7 External links
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 IETF ( Internet Engineering Task Force ), the Internet Architecture Board (IAB) , and – to some extent – the global community of computer network researchers in general.
The authors of the first RFCs typed their papers and distributed copies to ARPA researchers. Unlike modern RFCs, many of the first RFCs were requests for comments. The RFC leaves open questions and is written in a less formal style. This less formal style characterizes Internet document projects, the precursor step before being approved as an RFC.
In December 1969, researchers began distributing new RFCs through the new operational ARPANET. RFC 1 , entitled “Host Software”, was written by Steve Crocker of the University of California at Los Angeles (UCLA), and published on April 7, 1969. Although written by Steve Crocker, the RFC emerged from a group discussion earlier working between Steve Crocker, Steve Carr and Jeff Rulifson. (The document lists Bill Duvall as present only the last meeting of the task force before publication.)
In RFC 3 that first defined the RFC series, Crocker began to attribute the RFC series to the “Network Working Group”. This group seems 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 grant, but also because UCLA was one of the first message interface processors (PIMs) on the ARPANET.
characteristics
Each RFC has a title and a number assigned, 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 question 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).
The RFCs are written in English according to a specific structure and in ASCII text format .
Before a document is 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 has become practically obsolete, since criticism and suggestions occur in the previous phases. However, the RFC name is retained for historical reasons.
Obtaining RFC
The official source for the RFC 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 they may also be available in other formats. However, as of 2008 the final version of any standard track is the ASCII version.
To facilitate access to the metadata of an RFC, including abstract, keywords, author (s), publication date, errata, status and especially latest updates, the RFC Editor site offers a search engine with many features. A redirect sets some efficiency parameters, for example: http://purl.net/net/rfc/5000
State
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. Standard Clues documents are divided into Proposed Standard, Exposure Draft, and Internet Standard Documents. The term historical applies to obsolete standard documents or obsolete RFCs that were published before the standards track was established. Only the IETF, represented by the Internet Engineering Steering Group (IESG), can approve RFC standards. Each RFC is static, if the document is changed, it is confirmed again and a new RFC number is assigned. 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 is simply refers to another RFC or set of RFCs. A given Internet standard, STD n, can be RFC x or y at one point, but later the same standard can be updated to be compatible with RFC z instead. For example, in 2007 RFC 3700 was an Internet Standard-STD 1- and in May 2008was superseded by RFC 5000, so RFC 3700 changed to historical, 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 that the standard track has been completed, but will still be an STD. Best Current Practices work in a similar way; BCP n refers to a certain RFC or set of RFCs, but that the RFC or RFCs may change over time.
The definitive list of Internet Standards itself is an Internet standard, STD 1: Official Internet Standards Protocol.
“Informational” status
An informational RFC can be just about anything from proprietary protocol jokes to widely recognized essential RFCs like Domain Name System Structure and Delegation (RFC 1591). Some informational RFCs form the substring for information (FYI). While they are rarely added to this day, some older FYIs are still interesting, for example, FYI 18 (RFC 1983), Internet User 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 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 current best practices subseries (BCP) collect administrative documents and other texts that are considered as official rules and not only for information, but which do not affect the cable data. The boundary between the 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 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 the current Internet, or has been removed from the standard track for other reasons. Some outdated RFCs are not classified as historical, as the Internet standards process generally does not allow regulatory references from one RFC standard track to a lower status track. Furthermore, few are interested in working through the procedural details required to obtain a historical classified RFC and update all RFCs normatively accordingly.
Status “unknown”
Unknown status is used for some very old RFCs, where it is not clear what status of the document would be obtained if it is published today. Some of these RFCs would not be published at all today; one of the early RFCs was often just that: a simple request for comment, not wanting to specify a protocol, administrative procedure, or whatever else the RFC series is used for today.
