Not All RFCs are Standards
Publishing a document as an RFC does not make it an Internet Standard.
Huitema, C., Postel, J., and S. Crocker, "Not All RFCs are Standards", RFC 1796, DOI 10.17487/RFC1796, April 1995, <https://www.rfc-editor.org/info/rfc1796>.
@misc{rfc1796,
series = {Request for Comments},
number = 1796,
howpublished = {RFC 1796},
publisher = {RFC Editor},
doi = {10.17487/RFC1796},
url = {https://www.rfc-editor.org/info/rfc1796},
author = {C. Huitema and J. Postel and S. Crocker},
title = {{Not All RFCs are Standards}},
pagetotal = 4,
year = 1995,
month = apr,
} RFC text
Contents
Network Working Group C. Huitema
Request for Comments: 1796 INRIA
Category: Informational J. Postel
ISI
S. Crocker
CyberCash
April 1995
Not All RFCs are Standards
Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Abstract
This document discusses the relationship of the Request for Comments
(RFCs) notes to Internet Standards.
Not All RFCs Are Standards
The "Request for Comments" (RFC) document series is the official
publication channel for Internet standards documents and other
publications of the IESG, IAB, and Internet community. From time to
time, and about every six months in the last few years, someone
questions the rationality of publishing both Internet standards and
informational documents as RFCs. The argument is generally that this
introduces some confusion between "real standards" and "mere
publications".
It is a regrettably well spread misconception that publication as an
RFC provides some level of recognition. It does not, or at least not
any more than the publication in a regular journal. In fact, each
RFC has a status, relative to its relation with the Internet
standardization process: Informational, Experimental, or Standards
Track (Proposed Standard, Draft Standard, Internet Standard), or
Historic. This status is reproduced on the first page of the RFC
itself, and is also documented in the periodic "Internet Official
Protocols Standards" RFC (STD 1). But this status is sometimes
omitted from quotes and references, which may feed the confusion.
There are two important sources of information on the status of the
Internet standards: they are summarized periodically in an RFC
entitled "Internet Official Protocol Standards" and they are
documented in the "STD" subseries. When a specification has been
adopted as an Internet Standard, it is given the additional label
"STD xxxx", but it keeps its RFC number and its place in the RFC
series.
It is important to note that the relationship of STD numbers to RFC
numbers is not one to one. STD numbers identify protocols, RFC
numbers identify documents. Sometimes more than one document is used
to specify a Standard protocol.
In order to further increase the publicity of the standardization
status, the IAB proposes the following actions:
Use the STD number, rather than just the RFC numbers, in the cross
references between standard tracks documents,
Utilize the "web" hypertext technology to publicize the state of
the standardization process.
More precisely, we propose to add to the current RFC repository an
"html" version of the "STD-1" document, i.e., the list of Internet
standards. We are considering the extension of this document to also
describes actions in progress, i.e., standards track work at the
"proposed" or "draft" stage.
A Single Archive
The IAB believes that the community benefitted significantly from
having a single archival document series. Documents are easy to find
and to retrieve, and file servers are easy to organize. This has
been very important over the long term. Experience of the past shows
that subseries, or series of limited scope, tend to vanish from the
network. And, there is no evidence that alternate document schemes
would result in less confusion.
Moreover, we believe that the presence of additional documents does
not actually hurt the standardization process. The solution which we
propose is to better publicize the "standard" status of certain
documents, which is made relatively easy by the advent of networked
hypertext technologies.
Rather Document Than Ignore
The RFC series includes some documents which are informational by
nature and other documents which describe experiences. A problem of
perception occurs when such a document "looks like" an official
protocol specification. Misguided vendors may claim conformance to
it, and misguided clients may actually believe that they are buying
an Internet standard.
The IAB believes that the proper help to misguided vendors and
clients is to provide them guidance. There is actually very little
evidence of vendors purposely attempting to present informational or
experimental RFCs as "Internet standards". If such attempts
occurred, proper response would indeed be required.
The IAB believes that the community is best served by openly
developed specifications. The Internet standardization process
provides guarantees of openness and thorough review, and the normal
way to develop the specification of an Internet protocol is indeed
through the IETF.
The community is also well served by having access to specifications
of which have been developed outside the IETF standards process,
either because the protocols are experimental in nature, were
developed privately, or failed to achieve the acquire the degree of
consensus required for elevation to the standards track.
The IAB believes that publication is better than ignorance. If a
particular specification ends up being used in products that are
deployed over the Internet, we are better off if the specification is
easy to retrieve as an RFC than if it is hidden in some private
repository.
Security Considerations
Security issues are not discussed in this memo.
Authors' Addresses
Christian Huitema
INRIA, Sophia-Antipolis
2004 Route des Lucioles
BP 109
F-06561 Valbonne Cedex
France
Phone: +33 93 65 77 15
EMail: Christian.Huitema@MIRSA.INRIA.FR
Jon Postel
USC/Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292
Phone: 1-310-822-1511
EMail: Postel@ISI.EDU
Steve Crocker
CyberCash, Inc.
2086 Hunters Crest Way
Vienna, VA 22181
Phone: 1- 703-620-1222
EMail: crocker@cybercash.com
AI ELI5
On this page
§1The Misconception
The RFC series is the official publication channel for Internet standards documents and other publications of the IESG, IAB and Internet community. About every six months in recent years, someone has questioned publishing both standards and informational documents as RFCs, on the argument that it confuses "real standards" with "mere publications".
The memo calls it a regrettably wide-spread misconception that publication as an RFC provides some level of recognition. It does not, or at least not any more than publication in a regular journal.
Some people think that if a paper is in the RFC collection, it must be an official rule. That is not true, just as not every journal article is a law.
§2Status and STD Numbers
Each RFC has a status relative to the standardization process: Informational, Experimental, Standards Track (Proposed Standard, Draft Standard, Internet Standard), or Historic. The status is on the RFC's first page and in the periodic "Internet Official Protocols Standards" RFC (STD 1), but quotes and references often leave it out.
When a specification becomes an Internet Standard it gets the extra label "STD xxxx" but keeps its RFC number and its place in the series. STD numbers identify protocols, and RFC numbers identify documents, so the relationship is not one to one.
To publicize standards status, the IAB proposes to use STD numbers in cross references between standards track documents, and to add an html version of STD-1 using "web" hypertext technology.
Every RFC wears a name tag saying what kind it is. The official rules also get a second tag, STD, but they keep their old number.
§3Why Keep One Archive
The IAB believes the community benefited from a single archival series, where documents are easy to find and retrieve. It says that subseries tend to vanish from the network and that there is no evidence alternate schemes would cause less confusion. Additional documents do not hurt standardization, and the proposed solution is better publicity.
The memo accepts that an informational document can "look like" an official specification, and that vendors might claim conformance to it. The IAB's answer is guidance rather than hiding such documents: there is little evidence of vendors purposely presenting informational or experimental RFCs as Internet standards, and if it happened a proper response would be required.
Keeping every paper on one shelf makes them easy to find. It is better to label the shelf clearly than to hide papers in different rooms.
§4Publication Over Ignorance
The IAB believes the community is best served by openly developed specifications, and that the normal way to develop an Internet protocol specification is through the IETF. It also values access to specifications developed outside the IETF process, because they are experimental, were developed privately, or did not reach the consensus needed for the standards track.
Its position is that publication is better than ignorance: if a specification ends up in products deployed over the Internet, it is better as an easily retrieved RFC than hidden in a private repository. The Security Considerations section says security issues are not discussed.
It is better to share a recipe openly, even if it is not the official one, than to keep it secret.