Movatterモバイル変換


[0]ホーム

URL:


[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]

INFORMATIONAL
Network Working Group                                         C. HuitemaRequest for Comments: 1796                                         INRIACategory: Informational                                        J. Postel                                                                     ISI                                                              S. Crocker                                                               CyberCash                                                              April 1995Not All RFCs are StandardsStatus 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 beenHuitema, 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 1995Security 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.comHuitema, Postel & Crocker                                       [Page 4]

[8]ページ先頭

©2009-2025 Movatter.jp