1/What is a request for comment

A Request for Comments (RFC) is a numbered document, which includes appraisals, descriptions and
definitions of online protocols, concepts, methods and programmes. RFCs are produced primarily by
the Internet Architecture Board (IAB), Internet Research Task Force (IRTF and administered by the
IETF (Internet Engineering Task Force). A large part of the standards used online are published in
RFCs. Some fundamental RFCs were officially adopted as standards. Nevertheless, a large proportion
of RFCs are not granted “Standard” status, but are still used as such all over the world. The reason
behind this is that the individuals or groups working on an RFC primarily use their time to improve
protocols, and not for the standardisation process. The first published RFCs open up technical
matters for discussion. But a Request for Comments can only be called such when it has achieved
general acceptance and developed into a quasi-standard. The numbering of an RFC can change if, for
example, a new document emerges with significant alterations or amendments, or that is a synthesis
of various previous documents. individuals or groups outside of the IAB, IRTF or IETF can submit RFCs
for review, although these types of "individual submissions" are not as common. After an RFC has
gone through the review and revision process, it receives a final review for errors, as well as for style
and editorial issues. Once a satisfactory document is produced, the RFC Production Center (RPC)
assigns a unique number to the RFC and publishes it through the RFC Editor.

RFC’s history

First, the distribution method change from postal mail to FTP and then to email. RFCs could not be
distributed electronically in the beginning, as the means to do that distribution would not be defined
until years after the first RFC was "published". Not all early RFCs were even created electronically;
some were written out by hand or on a typewriter. Eventually, the process for creating RFCs became
more structured; authors were provided guidance on how to write an RFC. The editorial effort went
from Steve Crocker to a more official model with a designated editor, Jon Postel, and later to a team
of five to seven individuals. The actual editing and publishing work split from the service for
registration of protocol code points. The whole RFC Editor structure was reviewed [RFC4844], refined
[RFC5620], and refined again [RFC6635]. And, in the last few years, the process to change the format
of the RFC documents themselves has started [RFC7990].

The RFC series has a long history. The series was originated in 1969 by Steve Crocker of UCLA, to
organize the working notes of the new ARPAnet research program. Online data access (e.g., FTP) was
defined in early RFCs, and the RFC series itself became the first online publication series. For 28
years, this RFC series was managed and edited by the Internet pioneer Jon Postel. The RFC Editor
operation was funded by the Defense Advanced Research Projects Agency (DARPA) of the US
government until 1998. From 1998 – 2018, the RFC Editor was funded by a contract with the Internet
Society, to continue to edit, publish, and catalog RFCs

The significance of the status of an RFC Every Request for Comments is attributed a certain status. An
RFC is “informational” if it contains information or an idea for the online community. An
“experimental” RFC is for the purposes of experimentation, or represents the initial stages of an
eventual standard. Other possible statuses include “draft” standard (for evaluation), “proposed”
standard (a proposal for a standard), “standard” (an official standard) or “historic” (no longer used).
RFCs with the status “required” must be complied with immediately, and “recommended” or
“suggested” RFCs are simply recommendations. The use of “elective” RFCs is at the discretion of the
individual user.

The formal nature of a Request for Comments Composing an RFC is a very formalised process. How
to write an RFC is described in RFC 2223. RFC 2119 sets out what significance is attached to certain
terms, such as “must” or “must not”. This aims to avoid any misinterpretations. How to put character
strings together is also clearly defined. If an RFC ends up being published, it can no longer be
amended. It can only be replaced by an updated RFC.

A socket is one endpoint of a two way communication link between

FYI sub-series
This memo is the first in a new sub-series of RFCs called FYIs (For Your
Information). This memo provides information for the Internet community. It
does not specify any standard

RFCs produced by the IETF cover many aspects of computer networking. They describe the Internet's
technical foundations, such as addressing, routing, and transport technologies. RFCs also specify
protocols like TLS 1.3, QUIC, and WebRTC that are used to deliver services used by billions of people
every day, such as real-time collaboration, email, and the domain name system.

Only some RFCs are standards. Depending on their maturity level and what they cover, RFCs are
labeled with different statuses: Internet Standard, Proposed Standard, Best Current Practice,
Experimental, Informational, and Historic.

The RFC Series includes documents produced by the IETF, the Internet Architecture Board (IAB), the
Internet Research Task Force (IRTF), and independent submitters. All RFCs are published by the RFC
Editor, which is the authoritative source for retrieving RFCs.

RFCs usually begin as Internet-Drafts (I-Ds) written by an individual or a small group. In the IETF,
these are then usually adopted by a working group, and improved and revised. Less often, I-Ds are
considered within the IETF as “individual submissions” sponsored by an Area Director. While not
every I-D becomes an RFC, a well-defined set of processes (also documented in RFCs) guides the
consideration and progression of a document. When they are published, RFCs are freely available
online. 
Software developers, hardware manufacturers, and network operators around the world voluntarily
implement and adopt the technical specifications described by RFCs.

The IETF recognizes that security vulnerabilities will be discovered in IETF protocols and welcomes
their critical evaluation by researchers. The Internet Engineering Steering Group has provided
guidance on how to report vulnerabilities believed to be discovered in IETF protocols.

The first document in this series, RFC 1, was written in 1969. It was soon followed by others,
including those that describe the core Internet Protocol (IP) still used in the Internet today. RFCs
started as informal technical notes and the name originally stood for “Request For Comments” but
now they are simply known as RFCs. The collaborative process used to develop early RFCs remains an
important part of the IETF spirit. Today, there are more than 9000 individually numbered documents
in the series.