Request for Comments: Difference between revisions
imported>Pat Palmer mNo edit summary |
mNo edit summary |
||
| (6 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
{{subpages}} | {{subpages}} | ||
{{TOC|right}} | |||
A '''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 standard]]s, 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)<ref name="IETF">{{cite web|url=http://www.garykessler.net/library/ietf_hx.html|title="IETF: History, Background, and Role in Today's Internet"|publisher=Gary C. Kessler|year=1996|accessdate=2007-04-23}}</ref>, 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. | 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 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 | 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. | 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. | ||
| Line 14: | Line 14: | ||
*HTTP ["Hypertext Transfer Protocol" -- HTTP/1.1 RFC 2616] | *HTTP ["Hypertext Transfer Protocol" -- HTTP/1.1 RFC 2616] | ||
*BGP-4 ["A Border Gateway Protocol 4" (BGP-4) RFC 4271] | *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. <ref name=RFC1149>{{citation | |||
| title = Standard for the transmission of IP datagrams on avian carriers | |||
| first = D. | last = Waitzman | |||
| date = April 1 1990 | |||
| id = RFC1149 | |||
| url = http://www.ietf.org/rfc/rfc1149.txt | |||
| publisher = Internet Engineering Task Force | |||
}}</ref> Subsequently, RFC 2549 updated it to support [[quality of service]].<ref name=RFC2549>{{citation | |||
| title = IP over Avian Carriers with Quality of Service | |||
| first = D. | last = Waitzman | |||
| date = April 1 1999 | |||
| id = RFC2549 | |||
| url = http://www.ietf.org/rfc/rfc2549.txt | |||
| publisher = Internet Engineering Task Force | |||
}}</ref> Never let it be said that actual knowledge cannot come from humor: TCP/IP over pigeons was eventually demonstrated. <ref name=1149impl>{{citation | |||
| title = The highly unofficial CPIP WG | |||
| author = Bergen Linux Users Group | |||
| date = April 28 2001, 12:00 | |||
| url = http://www.blug.linux.no/rfc1149/ | |||
}}</ref> | |||
===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. | |||
==References== | |||
{{reflist|2}}[[Category:Suggestion Bot Tag]] | |||
Latest revision as of 11:00, 11 October 2024
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)[1], 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. [2] Subsequently, RFC 2549 updated it to support quality of service.[3] Never let it be said that actual knowledge cannot come from humor: TCP/IP over pigeons was eventually demonstrated. [4]
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.
References
- ↑ "IETF: History, Background, and Role in Today's Internet". Gary C. Kessler (1996). Retrieved on 2007-04-23.
- ↑ Waitzman, D. (April 1 1990), Standard for the transmission of IP datagrams on avian carriers, Internet Engineering Task Force, RFC1149
- ↑ Waitzman, D. (April 1 1999), IP over Avian Carriers with Quality of Service, Internet Engineering Task Force, RFC2549
- ↑ Bergen Linux Users Group (April 28 2001, 12:00), The highly unofficial CPIP WG