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.
One of the more notorious examples of standards nonsense was the
Open Systems Interconnect networking protocols that briefly contended
with TCP/IP in the
1980s — its 7-layer model looked elegant from a distance but
proved overcomplicated and unimplementable in
practice.[147] The
ANSI X3.64 standard for video-display terminal capabilities is another
famous horror story; bedeviled by subtle incompatibilities between
legally conformant implementations. Even after character-cell
terminals have been largely displaced by bitmapped displays these
continue to cause problems (in particular, this is why the function
and special keys in your
xterm(1)
will occasionally break). The RS232 standard for serial
communications was so underspecified that it sometimes seemed that no
two serial cables were alike. Standards horror stories of similar
kind could fill a book the size of this one.
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:
|
[A] candidate specification must be implemented
and tested for correct operation and interoperability by multiple
independent parties and utilized in increasingly demanding
environments, before it can be adopted as an Internet
Standard.
|
|
| --
The Internet Standards Process — Revision 3 (RFC 2026)
|
|
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.
