Request for comments

from Wikipedia, the free encyclopedia

The Request for Comments ( RFC ; English for request for comments ) is a series of technical and organizational documents on the Internet (originally Arpanet ) that have been published by the RFC editor since April 7, 1969 . If the documents were originally submitted for discussion in the literal sense of the word, the discussion takes place today while the drafts are being drawn up, so that a published RFC usually represents an appraised technical specification.

Some, but not all, RFCs are Internet standards. RFCs standardize the Internet protocol family , such as IPv6 ( RFC 8200 ), TCP ( RFC 793 ), UDP ( RFC 768 ), SMTP ( RFC 5321 ), and HTTP / 2 ( RFC 7540 ), and thus form the technical basis of Internet applications such as e-mail or the World Wide Web .

Publication Process

All RFCs are reviewed prior to publication. The publication process and the requirements specified therein differ depending on whether an Internet standard is sought or not. Future Internet standards have to meet high requirements and represent a community consensus of the Internet Engineering Task Force (IETF).

All drafts submitted are published by the IETF under the name " Internet Draft " (ID). Internet drafts are considered unfinished and should not be used as a reference. They expire after six months (but remain archived online) unless a new draft version is submitted or the publication process is initiated.

The RFC editor issues new RFCs with consecutive numbering as an ASCII text file and in other document formats. Once an RFC is published, the content is never changed. Corrections of editorial or technical errors are published as errata ; however, the incorrect RFC remains unchanged. If an obsolete specification is to be replaced, the new specification runs through the usual process and is published under a new RFC number. The new document references the old RFC and declares it obsolete. A new RFC can also update or add to just a part of an existing RFC without invalidating the entire document.

Series of documents

Selected RFCs are also published in other series of documents, each with its own numbering.

  • Internet Standard (STD)
Internet standards with the highest degree of maturity are also published in the STD document series.
The BCP series was introduced in 1995 for RFCs that contain technical information or administrative specifications that have been approved by the IETF. This differentiates BCPs from purely informative RFCs, on which the IETF does not take a position. Publication as an Internet standard is ruled out because BCPs are not network protocols .
  • For Your Information (FYI)
The FYI series was introduced in 1990 to make informative RFCs known to a wide audience, specifically including beginners. The series was discontinued in 2011.

Individual RARE Technical Reports (RTR) were also published as RFC.

Approval process

There are different approval procedures for RFCs, depending on where the document comes from. Such a process is known as a stream . RFC 4844 defines the following streams:

  • IETF
The document comes either from an IETF working group or from an Area Director of the Internet Engineering Steering Group . This stream is the only one allowed to submit emerging internet standards and best current practices . RFC 2026 and others describe the procedure.
  • IAB
The document is from the Internet Architecture Board . RFC 4845 describes the procedure.
  • IRTF
The document is from the Internet Research Task Force . RFC 5743 describes the procedure.
  • Independent submission
The document is from an independent contributor who submits it directly to the RFC editor. No technical consensus is required within the IETF, which means that publication as an Internet standard is excluded. RFC 4846 describes the procedure.

RFC status

Each RFC has a document status which, in contrast to the content, can be changed later.

  • Unknown (unknown)
No status is assigned to the RFC. This is true of some early RFCs.
  • Draft (Draft)
No RFC, as it is still in the drafting stage.
  • Informational (informative)
Informative document of any kind, for example terminology explanations, usage notes, problems or new ideas. There are also occasional answers to general questions or obituaries.
  • Experimental (experimental)
Protocol specification that was created as part of a research or development project. The purpose is to gain further experience within the network community in order to develop an Internet standard on this basis in the future if necessary. For example, the Sender Policy Framework began as an experimental RFC 4408 and entered the standardization process with RFC 7208 .
  • Best Current Practice (best current practice)
A technical document which becomes binding through publication in the BCP series of documents.
  • Proposed Standard , Draft Standard, and Internet Standard
Different levels of maturity of an internet standard . Proposed standards are specifications that have undergone rigorous assessment and consensus finding by the relevant IETF working group. Draft Standard is no longer used as a status. Internet standards have the highest maturity and are also published in the STD document series.
  • Historic (historical) and Obsolete (outdated)
Outdated specifications are marked as Historic by the IESG when their use is no longer recommended. If a specification is replaced by a new RFC, however, the status Obsolete is used. The latter has the purpose of identifying outdated specifications that are still relevant, for example because they are still widespread.

formalism

The IETF and the RFC editor attach great importance to formalism:

  • Proposals for new or changed RFCs are clearly documented in all changes before the formal publication.
  • An RFC once finally published is forever public and permanent. It cannot be corrected either; it can only be replaced by newer RFCs.
  • The structure and style of an RFC are specified by RFC 7322 .
  • RFC 2119 (BCP 14) specifies the terminology of requirements, the meaning of which is clearly defined in order to avoid misunderstandings in their interpretation.
MUST and MUST NOT (equivalent: SHALL and SHALL NOT ) indicate that a requirement must be met.
SHOULD and SHOULD NOT (equivalent: RECOMMENDED and NOT RECOMMENDED ) indicate that a requirement is recommended, but can be deviated from in justified cases.
MAY (equivalent: OPTIONAL ) specifies an option that can be implemented at the manufacturer's own discretion.
  • Character strings and their composition are formalistically represented using the Backus-Naur form (BNF). This ensures a clear interpretation, helpful, for example, when building URLs and URIs.

All these formalisms ensure the avoidance of misunderstandings in the interpretation and implementation and thus for the success of the operation of the Internet. Examples of this and their success are RFC 2822 (e-mail) and RFC 2616 (HTTP).

Humor in RFC

Between the RFCs that describe Internet standards or best current practices, there are always joking RFCs that should not be taken to the letter, often on the occasion of April 1st .

  • RFC 1925 , published April 1, 1996, lists The Twelve Networking Truths starting with the fundamental It Has To Work tenet .
  • As a parody of the MPLS routing protocol , RFC 3251 contains Mostly Pointless Lamp Switching .
  • RFC 2795 deals with the Infinite Monkey Theorem and describes how an infinite number of monkeys can be coordinated to produce the works of Shakespeare.
  • But also real works of art can be identified, such as a hymn of praise to the Arpanet ( RFC 527 ), history of science in verse ( RFC 1121 ) or The Twelve Days of Christmas from the perspective of a stressed network admins ( RFC 1882 ).
  • On April 1, 2001, the combinations of “foo” and “bar” or their variants were etymologically determined in RFC 3092 .
  • On April 1, 2003, an RFC ( RFC 3514 ) was published which calls for a corresponding bit to be set in the header of IP packets that are in any form "evil" in order to filter these packets out more easily on firewalls to be able to. This is because a bit in IPv4 headers that indicates the “Type of Service” is normally set to 0, but is set to 1 by some modern applications. Some firewalls rely on this to be 0 and just rate the packet as bad because it is an unsupported service type.
  • On April 1, 2004, an omniscience protocol was developed to enable the American government to detect and prevent all forms of computer crime ( RFC 3751 ). After the requirements for this protocol had not proven to be feasible, the text ends with the words: "Good luck."
  • On April 1, 2005, a new standard was presented which enables morally impeccable routing ( RFC 4041 ). Furthermore, the very old UTF-8 , which uses 8 bit wide units , has been replaced by UTF-9, which allows 9 bits (3 × 3) per byte ( RFC 4042 ).
  • On April 1, 2007 a method for the transmission of IP using the winker alphabet was presented ( RFC 4824 ).
  • On April 1, 2010, the Transmission Control Protocol was expanded: The mood of the transmitted segment can be determined by emoticons in the header . For example, a segment can be happy or frustrated ( RFC 5841 ).

Realized April Fools' Day

However, the RFC does not always stick to theory on April 1st. On March 6, 2001, an implementation of the RFC 1149 A Standard for the Transmission of IP Datagrams on Avian Carriers (the transmission of IP datagrams by carrier pigeon ) was presented. However, the average response time to a ping was 45 minutes, so that regular use in real use cannot be expected. However, this led to a further development of RFC 2549 IP over Avian Carriers with Quality of Service , but this use is also unlikely.

The Emacs editor has had a complete implementation of RFC 2324 for years : The Hyper Text Coffee Pot Control Protocol (HTCPCP) is used for remote control and monitoring of coffee machines.

At the Hacking in Progress event , RFC 2322 , Management of IP numbers by Peg DHCP , was formulated. It defines how IP numbers are written on wooden clothespins with a felt pen and how these are clipped to the corresponding cable. Although this RFC was intended as a joke, it is used regularly.

With gpigen, there is also a free implementation for several platforms for the Pi Digit Generation Protocol .

Web links

Individual evidence

  1. ↑ H. Flanagan (Ed.): RFC 8700 - Fifty Years of RFCs . IETF. December 2019. Retrieved December 26, 2019.
  2. ↑ C. Huitema, J. Postel, S. Crocker: RFC 1796 - Not All RFCs are Standards . IETF. April 1995. Retrieved December 26, 2019.
  3. ↑ RFC 1818 . - Best Current Practices . [Errata: RFC 1818 ]. August 1995. (English).
  4. ↑ RFC 1150 . - FYI on FYI . [Errata: RFC 1150 ]. March 1990. (English).
  5. ^ R. Housley: RFC 6360 - Conclusion of FYI RFC Sub-Series . IETF. August 2011. Retrieved December 26, 2019.
  6. ^ RTR index . RFC editor. Retrieved December 26, 2019.
  7. ^ R. Housley, D. Crocker, E. Burger: RFC 6410 - Reducing the Standards Track to Two Maturity Levels . IETF. October 2011. Retrieved December 26, 2019.