Request for Comments

A Request for Comments (RFC) is one of a series of documents about the Internet, mostly technical, but some about policy issues. Some become de facto Internet standards, which set the engineering specifications for the internals of the Internet, while many others languish largely or completely ignored. The series was started in 1969 (before the Internet existed, when its predecessor, the ARPANET, was just being started). The RFC process arose from the Internet Engineering Task Force (IETF), part of the U. S. Advanced Research (ARPA) initiative funded in reaction to the Soviet launch of Sputnik. IETF and the RFC process led, eventually, to the development of the Internet.

Public collaboration in refining of RFC's, whereby literally any person could submit, or comment upon, an RFC, was remarkable, and the IETF proved to be about as effective as formally endorsed standards bodies at creating usable and widely adopted standards. The non-proprietary nature of the RFC process also foreshadowed the later development, in the 1980's, of the open source software movement.

Most RFCs are produced by Working Groups of the IETF, but an RFC document can also be submitted to the RFC Editor by anyone (after being published as an Internet Draft). It is up to the RFC editor (who usually checks with the IETF) to determine whether or not to accept it.

Each RFC is designated by an RFC number. Once published, an RFC never changes (although there are now errata sheets for them). Modifications to an original RFC are assigned a new RFC number.

Some examples :

• SMTP ["Simple Mail Transfer Protocol". Was RFC 821 (STANDARD), Obsoleted by RFC 2821 (PROPOSED STANDARD)]
• HTTP ["Hypertext Transfer Protocol" -- HTTP/1.1 RFC 2616]
• BGP-4 ["A Border Gateway Protocol 4" (BGP-4) RFC 4271]

RFC Categories

RFCs broadly divide into those intended as standards, and those issued other purposes. The type is listed on the first page.

Standards Track

Standards track RFCs go through an approval process. They almost always originate in a Working Group, in which a consensus is reached. To be accepted, they must be approved by an oversight panel, the Internet Engineering Steering Group. The first level of standardization is Proposed standard, which reflects a workgroup consensus and at least prototype implementations. Draft standard must reflect at least two independent implementations, built against the Proposed Standards plus any changes in the Draft Standard document, which have successfully executed the specified functions with each other. Full Standard requires more than two interoperable independent implementations, various supplementary RFCs giving guidance to implementers, and a stringent review by oversight panels.

Informational

A common category is Informational, which may be an individual or Working Group contribution. Some of these are designated, as well, Best current practice (BCP). BCPs most commonly refer to guidelines on the use of protocols or operational techniques in the Internet, as opposed to specifications of the protocols.

Some RFC's also result from a deliberate sharing of formerly proprietary specifications by industry participants, notably some of the open specifications leading to the industry-wide IBM compatible PC beginning in the early 1980's.

An IETF tradition is that a number of humorous RFCs are issued on April 1 of each year. These will be Informational, but some completely serious RFCs have been issued on April 1. Do not assume an April 1 date means the RFC is a joke. Some April 1 RFCs are more philosophical, describing sadly learned industry lessons.

Among the best known April 1 RFCs is RFC 1149, which explains how to carry Internet Protocol packets over carrier pigeons. Subsequently, RFC 2549 updated it to support quality of service. Never let it be said that actual knowledge cannot come from humor: TCP/IP over pigeons was eventually demonstrated.

Other types

Experimental RFCs are just as the name suggests; they provide information that defines a new technique, and experience with it, but are not intended for standardization. They are intended to encourage research into mechanisms that may later become part of Standards Track work.

Historic RFCs are obsolete and should not be used for any new development.