When the Unix community merged with the culture of Internet engineers, it also inherited a mindset formed by the RFC standards process of the Internet Engineering Task Force (IETF). In IETF tradition, standards have to arise from experience with a working prototype implementation — but once they become standards, code that does not conform to them is considered broken and mercilessly scrapped.

This is not, sadly, the way standards are normally developed. The history of computing is full of instances in which technical standards were derived by a process that combined the worst features of philosophical axe-grinding with murky back-room politics — producing specifications that failed to resemble anything ever implemented. Worse, many were either so demanding that they could not be practically implemented or so underspecified that they caused more confusion than they resolved. Then they were promulgated to vendors who ignored them wherever they were inconvenient.

The IETF's philosophy has been famously summarized as “We reject kings, presidents, and voting. We believe in rough consensus and running code”.^[148] That demand for a working implementation first has saved it from the worst category of blunders. In fact its criterion is stronger:

All IETF standards pass through a stage as RFCs (Requests for Comment). The submission process for RFCs is deliberately informal. RFCs may propose standards, survey results, suggest philosophical bases for subsequent RFCs, or even make jokes. The appearance of the annual April 1st RFC is the closest equivalent of a high holy day observance among Internet hackers, and has produced such gems as A Standard for the Transmission of IP Datagrams on Avian Carriers (RFC 1149)^[149] the The Hyper Text Coffee Pot Control Protocol (RFC 2324),^[150] and The Security Flag in the IPv4 Header (RFC 3514).^[151]

But joke RFCs are about the only sort of submission that instantly becomes an RFC. Serious proposals actually start as “Internet-Drafts” floated for public comment via IETF directories on several well-known hosts. Individual Internet-Drafts have no formal status and can be changed or dropped by their originators at any time. If they are neither withdrawn nor promoted to RFC status, they are removed after six months.

Internet-Drafts are not specifications, and software implementers and vendors are specifically barred from claiming compliance with them as if they were specifications. Internet-Drafts are focal points for discussion, usually in a working group connected through an electronic mailing list. When the working group leadership deems fit, the Internet-Draft is submitted to the RFC editor for assignment of an RFC number.

Once an Internet-Draft has been published with an RFC number, it is a specification to which implementers may claim conformance. It is expected that the authors of the RFC and the community at large will begin correcting the specification with field experience.

Some RFCs go no further. A specification that fails to attract use and survive field testing can be quietly forgotten, and eventually marked “Not recommended” or “Superseded” by the RFC editor. Failed proposals are accepted as one of the overheads of the process, and no stigma is attached to being associated with one.

The steering committee of the IETF (IESG, or Internet Engineering Steering Group) is responsible for putting successful RFCs on the standards track. They do this by designating the RFC a ‘Proposed Standard’. For the RFC to qualify, the specification must be stable, peer-reviewed, and have attracted significant interest from the Internet community. Implementation experience is not absolutely required before an RFC is given Proposed Standard designation, but it is considered highly desirable, and the IESG may require it if the RFC touches the Internet core protocols or might be otherwise destabilizing.

Proposed Standards are still subject to revision, and may even be withdrawn if the IESG and IETF identify a better solution. They are not recommended for use in “disruption-sensitive environments”—don't put them in your air-traffic-control systems or on intensive-care equipment.

When there are at least two working, complete, independently originated, and interoperable implementations of a Proposed Standard, the IESG may elevate it to Draft Standard status. RFC 2026 says: “Elevation to Draft Standard is a major advance in status, indicating a strong belief that the specification is mature and will be useful”.

Once an RFC has reached Draft Standard status, it will be changed only to address bugs in the logic of the specification. Draft Standards are expected to be ready for deployment in disruption-sensitive environments.

When a Draft Standard has passed the test of widespread implementation and reached general acceptance, it may be blessed as an Internet Standard. Internet Standards keep their RFC numbers, but also get a number in the STD series. At time of writing there are over 3000 RFCs but only 60 STDs.

RFCs not on standards track may be labeled Experimental, Informational (the joke RFCs get this label), or Historic. The Historic label is applied to obsolete standards. RFC 2026 notes: “(Purists have suggested that the word should be ‘Historical’; however, at this point, the use of ‘Historic’ is historical.)”

The IETF standards process is designed to encourage standardization driven by practice rather than theory, and to ensure that standard protocols have undergone rigorous peer review and testing. The success of this model is evident in its results — the worldwide Internet.