doc: Add RFC documents

1 files changed, 227 insertions, 0 deletions

diff --git a/doc/rfc/rfc1796.txt b/doc/rfc/rfc1796.txt
new file mode 100644
index 0000000..6e4a5a6
--- /dev/null
+++ b/doc/rfc/rfc1796.txt
@@ -0,0 +1,227 @@
+
+
+
+
+
+
+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]
+
+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]
+
+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]
+
+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]
+