The RFC Archive
 The RFC Archive   RFC 1796   « Jump to any RFC number directly 
 RFC Home
Full RFC Index
Recent RFCs
RFC Standards
Best Current Practice
RFC Errata
1 April RFC



IETF RFC 1796

Not All RFCs are Standards

Last modified on Monday, April 24th, 1995

Permanent link to RFC 1796
Search GitHub Wiki for RFC 1796
Show other RFCs mentioning RFC 1796







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



Huitema, Postel & Crocker                                    PAGE 1 top


RFC 1796 Not All RFCs are Standards April 1995 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. Huitema, Postel & Crocker PAGE 2 top

RFC 1796 Not All RFCs are Standards April 1995 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. Huitema, Postel & Crocker PAGE 3 top

RFC 1796 Not All RFCs are Standards April 1995 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 Huitema, Postel & Crocker PAGE 4 top

Not All RFCs are Standards RFC TOTAL SIZE: 7049 bytes PUBLICATION DATE: Monday, April 24th, 1995 LEGAL RIGHTS: The IETF Trust (see BCP 78)


RFC-ARCHIVE.ORG

© RFC 1796: The IETF Trust, Monday, April 24th, 1995
© the RFC Archive, 2024, RFC-Archive.org
Maintainer: J. Tunnissen

Privacy Statement