home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / rfcs / rfc1796.txt < prev    next >
Text File  |  1996-05-07  |  7KB  |  132 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         C. Huitema Request for Comments: 1796                                         INRIA Category: Informational                                        J. Postel                                                                      ISI                                                               S. Crocker                                                                CyberCash                                                               April 1995 
  8.  
  9.                         Not All RFCs are Standards 
  10.  
  11. Status of this Memo 
  12.  
  13.    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. 
  14.  
  15. Abstract 
  16.  
  17.    This document discusses the relationship of the Request for Comments    (RFCs) notes to Internet Standards. 
  18.  
  19. Not All RFCs Are Standards 
  20.  
  21.    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". 
  22.  
  23.    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. 
  24.  
  25.    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 
  26.  
  27.  
  28.  
  29. Huitema, Postel & Crocker                                       [Page 1] 
  30.  RFC 1796               Not All RFCs are Standards             April 1995 
  31.  
  32.     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. 
  33.  
  34.    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. 
  35.  
  36.    In order to further increase the publicity of the standardization    status, the IAB proposes the following actions: 
  37.  
  38.       Use the STD number, rather than just the RFC numbers, in the cross       references between standard tracks documents, 
  39.  
  40.       Utilize the "web" hypertext technology to publicize the state of       the standardization process. 
  41.  
  42.    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. 
  43.  
  44. A Single Archive 
  45.  
  46.    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. 
  47.  
  48.    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. 
  49.  
  50. Rather Document Than Ignore 
  51.  
  52.    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. 
  53.  
  54.  
  55.  
  56. Huitema, Postel & Crocker                                       [Page 2] 
  57.  RFC 1796               Not All RFCs are Standards             April 1995 
  58.  
  59.     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. 
  60.  
  61.    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. 
  62.  
  63.    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. 
  64.  
  65.    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. 
  66.  
  67.  
  68.  
  69.  
  70.  
  71.  
  72.  
  73.  
  74.  
  75.  
  76.  
  77.  
  78.  
  79.  
  80.  
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  Huitema, Postel & Crocker                                       [Page 3] 
  94.  RFC 1796               Not All RFCs are Standards             April 1995 
  95.  
  96.  Security Considerations 
  97.  
  98.    Security issues are not discussed in this memo. 
  99.  
  100. Authors' Addresses 
  101.  
  102.    Christian Huitema    INRIA, Sophia-Antipolis    2004 Route des Lucioles    BP 109    F-06561 Valbonne Cedex    France 
  103.  
  104.    Phone: +33 93 65 77 15    EMail: Christian.Huitema@MIRSA.INRIA.FR 
  105.  
  106.     Jon Postel    USC/Information Sciences Institute    4676 Admiralty Way    Marina del Rey, CA 90292 
  107.  
  108.    Phone: 1-310-822-1511    EMail: Postel@ISI.EDU 
  109.  
  110.     Steve Crocker    CyberCash, Inc.    2086 Hunters Crest Way    Vienna, VA 22181 
  111.  
  112.    Phone: 1- 703-620-1222    EMail: crocker@cybercash.com 
  113.  
  114.   
  115.  
  116.  
  117.  
  118.  
  119.  
  120.  
  121.  
  122.  
  123.  
  124.  
  125.  
  126.  
  127.  
  128.  
  129.  
  130. Huitema, Postel & Crocker                                       [Page 4] 
  131.  
  132.