RFC:以編号排定的文件-中文百科頻道

編輯機制

RFC（Request For Comments）意即“請求評論”，包含了關于Internet的幾乎所有重要的文字資料。如果你想成為網絡方面的專家，那麼RFC無疑是最重要也是最經常需要用到的資料之一，所以RFC享有網絡知識聖經之美譽。通常，當某家機構或團體開發出了一套标準或提出對某種标準的設想，想要征詢外界的意見時，就會在Internet上發放一份RFC，對這一問題感興趣的人可以閱讀該RFC并提出自己的意見；絕大部分網絡标準的制定都是以RFC的形式開始，經過大量的論證和修改過程，由主要的标準化組織所指定的，但在RFC中所收錄的文件并不都是正在使用或為大家所公認的，也有很大一部分隻在某個局部領域被使用或并沒有被采用，一份RFC具體處于什麼狀态都在文件中作了明确的标識。

RFC由一系列草案組成，起始于1969年（第一個RFC文檔發布于1969年4月7日，參見“RFC30年”，RFC2555”），RFC文檔是一系列關于Internet（早期為ARPANET）的技術資料彙編。這些文檔詳細讨論了計算機網絡的方方面面，重點在網絡協議，進程，程序，概念以及一些會議紀要，意見，各種觀點等。

“RFC編輯者”是RFC文檔的出版者，它負責RFC最終文檔的編輯審訂。“RFC編輯者”也保留有RFC的主文件，稱為RFC索引，用戶可以在線檢索。在RFC近30年的曆史中，“RFC編輯者”一直由約翰·普斯特爾（Jon Postel）來擔任，而“RFC編輯者”則由一個工作小組來擔任，這個小組受到“互聯網協會”（Internet Society）的支持和幫助。

RFC編輯者負責RFC以及RFC的整體結構文檔，并維護RFC的索引。Internet協議族的文檔部分（由Internet工程委員會“因特網工程師任務組”IETF以及IETF 下屬的“因特網工程師指導組”IESG 定義），也做為RFC文檔出版。因此，RFC在Internet相關标準中有着重要的地位。

RFC編輯者的職責是由Internet 中的大家提議形成的，所出版的語言也就和Internet一樣。IETF和ISOC是代表了世界各地的國際性組織，英語是IETF的第一工作語言，也是IETF的正式出版語言。RFC 2026 "The Internet Standards Process -- Revision 3" 允許RFC翻譯成其他不同的語言。但是不能保證其翻譯版本是完全正确的。因此，RFC編輯不對非英語的版本負責，而隻是指明了哪裡有非英語的版本，将這些信息列在WEB頁上。

處理過程

一個RFC文件在成為官方标準前一般至少要經曆4個階段（RFC2026）：因特網草案、建議标準、草案标準、因特網标準。

第一步RFC的出版是作為一個Internet 草案發布，可以閱讀并對其進行注釋。準備一個RFC草案，我們要求作者先閱讀IETF的一個文檔"Considerations for Internet Drafts". 它包括了許多關于RFC以及Internet草案格式的有用信息。作者還應閱讀另外一個相關的文檔RFC 2223 "Instructions to Authors"。

一旦文檔有了一個ID号後，你就可以向rfc-editor @rfc-editor. org發送e-mail ，說你覺得這個文檔還可以，能夠作為一個有價值或有經驗的RFC文檔。RFC編輯将會向IESG請求查閱該文檔并給其加上評論和注釋。你可以通過RFC隊列來了解你的文檔的進度。一旦你的文檔獲得通過，RFC編輯就會将其編輯并出版。如果該文檔不能出版，則會有email通知作者不能出版的原因。作者有48個小時的時間來校對RFC編輯的意見。我們強烈建議作者要檢測拼寫錯誤和丢字的錯誤，應該确保有引用，聯系和更新相關的信息。如你的文檔是一個MIB，我們則要你對你的代碼作最後一次檢測。一旦RFC文檔出版，我們就不會對其進行更改，因此你應該對你的文檔仔細的檢查。

有時個别的文檔會被正從事同一個項目的IETF工作組收回，如是這種情況，則該作者會被要求和IETF進行該文檔的開發。在IETF中，Area Directors （ADs）負責相關的幾個工作組。這些工作者所開發的文檔将由ADs 進行校閱，然後才作為RFC的出版物。

如要獲得關于如何寫RFC文檔和關于RFC的Internet标準制定過程的更多詳細信息，請參見：

1、RFC 2223 "Instructions to RFC Authors"。

2、RFC 2026 "The Internet Standards Process -- Revision 3"。

實際上，在Internet上，任何一個用戶都可以對Internet某一領域的問題提出自己的解決方案或規範，作為Internet草案（Internet Drafts，ID）提交給Internet工程任務組（IETF）。草案存放在美國、歐洲和亞太地區的工作文件站點上，供世界多國自願參加的IETF成員進行讨論、測試和審查。最後，由Internet工程指導組（IESG）确定該草案是否能成為Internet的标準。

如果一個Internet草案在IETF的相關站點上存在6個月後仍未被IESG建議作為标準發布，則它将被從上述站點中删除。事實上，在任何時候，一個Internet 草案都有可能被新的草案版本所替換掉，并重新開始6個月的存放期。

如果一個Internet草案被IESG确定為Internet的正式工作文件，則被提交給Internet體系結構委員會（IAB），并形成具有順序編号的RFC文檔，由Internet協會（ISOC）通過Internet向全世界頒布。每個Internet标準文件在被批準後都會分配一個獨立于RFC的永久編号，這就是STD編号。有一個不斷被更新的文件RFC-INDEX.TXT按照RFC的編号來索引所有的文件，對于因特網标準文件還列出了其相應的STD編号。

RFC文檔必須被分配RFC編号後才能在網絡上發布。例如，RFC2026的内容是“Internet标準進程-修訂版3”、RFC1543的内容為“RFC作者指導”等等。需要時，可以複制或打印這些聯機文檔。用戶也可以通過遍布全世界的數個聯機資料數據庫中獲得RFC文檔。

作為标準的RFC又分為幾種，第一種是提議性的，就是說建議采用這個作為一個方案擺出來，Draft是已經有一部分在用了，希望被采用為正式的标準，還有一種就是完全被認可的标準，這種是大家都在用，而且是不應該改變的。還有一種就是最佳實踐法，它相當于一種介紹。這些文件産生的過程是一種從下往上的過程，而不是從上往下，也就是說不是一個由主席，或者由工作組負責人的給一個指令，說是要做什麼，要做什麼，而是有下邊自發的提出，然後在工作組裡邊讨論，讨論了以後再交給剛才說的工程指導委員會進行審查。但是工程指導委員會隻做審查不做修改，修改還是要打回到工作組來做。IETF工作組文件的産生就是任何人都可以來參加會議，任何人都可以提議，然後他和别人進行讨論，大家形成了一個共識就可以産出這樣的文件。

曆史

RFC文件格式最初作為ARPA網計劃的基礎起源于1969年。如今，它已經成為IETF、Internet Architecture Board （IAB）還有其他一些主要的公共網絡研究社區的正式出版物發布途徑。

最初的RFC作者使用打字機撰寫文檔，并在美國國防部國防前沿研究項目署（ARPA）研究成員之間傳閱。1969年12月，他們開始通過ARPANET途徑來發布新的RFC文檔。第一份RFC文檔由洛杉矶加利福尼亞大學（UCLA）的Steve Crocker撰寫，在1969年4月7日公開發表的RFC 1。當初Crocker為了避免打擾他的室友，是在浴室裡完成這篇文檔的。

在1970年代，很多後來的RFC文檔同樣來自UCLA，這不僅得益于UCLA的學術質量，同時也因為UCLA是ARPANET第一批Interface Message Processors （IMPs）成員之一。

由Douglas Engelbart領導的，位于Stanford Research Institute的Augmentation Research Center （ARC）是四個最初的ARPANET結點之一，也是最初的Network Information Centre，同時被社會學家Thierry Bardini記錄為早期大量RFC文檔的發源地。

從1969年到1998年，Jon Postel一直擔任RFC文檔的編輯職務。随着美國政府贊助合同的到期，Internet Society（代表IETF），和南加州大學（USC）Information Sciences Institute的網絡部門合作，（在IAB領導下）負責RFC文檔的起草和發布工作。Jon Postel繼續擔任RFC編輯直到去世。随後，由Bob Braden接任整個項目的領導職務，同時Joyce Reynolds繼續在團隊中的擔任職務。

慶祝RFC的30周年的RFC文件是RFC 2555。

文件架構

RFC文件隻有新增，不會有取消或中途停止發行的情形。但是對于同一主題而言，新的RFC文件可以聲明取代舊的RFC文件。RFC文件是純 ASCII文字檔格式，可由電腦程序自動轉檔成其他檔案格式。RFC文件有封面、目錄及頁首頁尾和頁碼。RFC的章節是數字标示，但數字的小數點後不補零，例如4.9的順序就在4.10前面，但9的前面并不補零。RFC1000這份文件就是RFC的指南。

RFC文件是由Internet Society審核後給定編号并發行。雖然經過審核，但RFC也并非全部嚴肅而生硬的技術文件，偶有惡搞之作出現，尤其是4月1日愚人節所發行的，例如RFC 1606: A Historical Perspective On The Usage Of IP Version 9 （參見IPv9）、RFC 2324: “超文本咖啡壺控制協議”（Hyper Text Coffee Pot Control Protocol，乍有其事的寫了HTCPCP這樣看起來很專業的術語縮寫字）。以及如前面所提到紀念RFC的30周年慶的RFC文件。

發展曆程

在Internet從誕生到不斷發展壯大的過程中，出現過各種各樣的協議和思想讨論，從最初的NCP協議到現代Internet的基石TCP/IP協議族，無一不閃耀着研究人員的智慧光芒，正是這些成百上千各種協議的發明、讨論和完善，才使得人類社會逐步進入到互聯網時代。而這些閃耀着人類智慧結晶的思想成果大都以一種稱為RFC的文檔格式記錄起來。

1969年，S·Crocker首先建立了RFC機制，其目的是建立一種快速共享Internet網絡研究思想的方式，最初RFC是以書面形式分發的，後來有了FTP、Email，RFC就以在線電子文本的形式提供，當然通過WWW在很多站點可以很方便地訪問RFC文檔。RFC一直以來主要是用于Internet的标準化，RFC是Internet開放性的産物，任何人都可以訪問RFC，Internet這一緻力于信息共享的網絡首先共享的就是以RFC形式出現的涉及其自身研究、設計和使用的信息。這一獨特的方式對于Internet的發展、完善具有相當關鍵的作用。RFC文檔已不僅僅是關于Internet标準的文檔了，而且也不局限于TCP/IP範圍，它幾乎包含了與計算機通信有關的任何内容，全面反映Internet研究、發展的過程。RFC主要是IAB、IETF、IESG、ISOC的工作成果，主要由IETF起草，由IAB指導下的RFC 編輯（Editor）直接負責RFC的發表。每一個RFC文檔有一個編号，這個編号永不重複，也就是說，由于技術進步等原因，即使是關于同一問題的RFC，也要使用新的編号，而不會使用原來的編号，至2015年2月2日，RFC編号已經排到7443，在查找RFC時，一定要注意最新的RFC。

特點

Internet的所有标準都是以請求評論文檔( Request For Comment，RFC)的形發布的，TCP/IP協議也不例外。首先由ITF讨論後對協議進行标準化，然後把備标準化的協議轉變成RFC在 Internet上公布。另外，RFC不僅包含RFC性能格書，還包括與實際安裝和應用有關的信息，以及與協議的試驗有關的信息。

人們對RFC進行編号，例如把确定IP性能指标的協議編号為RFC791，把确定TCP性能指标的協議編号為RFC793。RFC是按照協議制定的順序進行編号的且一旦成為RFC，就不容許再做任何修改。如果需要擴展協議的性能，則必須便新的編号來定義該協議的擴展部分。當一個協議的性能指标發生變化時，要發行的RFC，同時廢除舊的RFC。在新的RFC中，标明了該協議是從哪一個協議擴來的，以及哪個協議被廢除了。

使用

Internet所有技術标準都是以RFC文件形式公布的，但這不是所有的RFC文件。RFC還包括政策研究報告，技術部門的工作總結，研讨會的成果綜述和網絡使用指南等。每一份RFC文件都有一個唯一的編号，當某一文件産生了更新版本時，就為新的版本指派新的RFC編号。任何用戶都可通過E-mai向RFC編委會投寄文稿申請作為RFC文件發表。全套RFC文件由 DDN NIC的 SRI Internet負責維護。以RFC文件公布的網絡協議又可用以下方式進行分級：

1、依據是否标準化：标準協議；标準草案；建議标準；試行标準；曆史标準。

2、依據是否必須采納：必須采納；推薦采納；選擇采納；不推薦采納。

（1）必須采納的标準協議是聯網的任何一台主機所必須遵循的（如RFC-791）。

（2）推薦采納的标準則是聯網主機應該實現的，缺少時雖仍然能聯網，但可能運行不正常

（3）選擇采納的建議标準則是還在小範圍試用的網絡協議。

分類

RFC文檔大緻可以分為以下幾類。

STD RFC

按照RFC1311的定義，STD RFC是指那些已經或者緻力于成為Internet标準的RFC。隻有經過完全Internet标準化過程的RFC才可以有STD編号，STD編号是不變的，而其涉及到的 RFC文檔可能不隻一個，其RFC編号也會更新。如STD13（Domain Name System）就涉及RFC1034和RFC1035。STD的标準化過程要經過幾個步驟，首先由IETF起草标準（也可能是其他組織和個人，但一般都是和IETF共同完成的），形成Internet Draft（ID），ID沒有RFC編号。如果ID在6個月内IESG沒有建議成為RFC，則取消此ID。成為RFC後，還要經過一系列的審查、修訂、測試等才能最終成為Internet标準。

BCP RFC

由于Internet應用領域廣泛，各種不同的組織有不同的使用目的和使用規則，IETF除了建議STD以外，也有必要對于Internet的使用和管理提供一些一般性的指導，同時也為IETF、IAB、IESG提供一種渠道，以便推動某一方面的工作，反映其技術趨向，反映這些組織本身的工作進展。于是，1995年以RFC1818定義了BCP，即Best Current Practice。BCP同時有一個BCP編号和一個RFC編号，一旦約定了一個BCP編号，就不會再變，而其RFC編号則可能會經過修訂不斷更新。例如反映Internet标準化工作程序的BCP9的RFC編号就從RFC1602上升到RFC2026，相應地就廢棄了RFC1602。BCP在發表以前，以電子郵件的形式廣泛征求IETF的意見，經過IESG的審查，通過後即正式發表。但是BCP本身不是Internet标準。

FYI RFC

FYI是For Your Information的簡寫，1990年發表的RFC1150（FYI1）定義了FYI，FYI也同時有一個FYI編号和一個RFC編号，FYI編号是固定的。FYI主要是提供有關Internet的知識性内容。所有的FYI在提交到RFC編輯以前，必須先經過IETF的User Services WorkingGro up審查。

其他RFC

除了STD、BCP、FYI以外還有其他一些RFC。從RFC899開始，所有以99結尾的RFC都是對此前99個RFC的一個概括。如RFC1999就是對RFC1900到RFC1999的一個簡單概括。除了上述分類以外，還有一些描述RFC的方法。與Internet标準化過程（Internet Standards Process）有關的規範可以分為兩類，即 Technical Specification（TS），Applicability Statement（AS）。

TS是對協議、規則、格式、實用程序的描述。AS是描述在何種環境，以及怎樣在Internet中使用TS；AS所涉及的并不一定全是Internet标準，比如IEEE、ITU、ISO組織的一些标準，大家所熟悉的ASCII标準就是一例。AS應該對其涉及的TS規定相應的級别"Requirement Level"，這些"Require ment Level"如下：Required（Req），相當于必須實現，如IP、ICMP；Recommended（Rec），鼓勵使用，如TELNET；Elective（Elc），可選擇的； Limited Use，隻限于特定的用戶，一般說來用于對一些新的協議做試驗； ·Not Recommended，不要使用，很可能是過時的。"Maturity Level"也是用來描述TS和AS的一種方式，它反映這些标準是否成熟。對于緻力于成為STD的TS和AS有三種"Maturity Level"。Proposed Standard，基本成熟，但還需要進一步的試驗證實其可行性。除非是用來驗證該協議的可行性，不要将其視為标準實現。Draft Standard，需要兩個獨立的，而且具有相互操作性的實例驗證該協議的每一個方面。可以将其視為最終的标準草案；Internet Standard，最終的Internet标準，同時賦予一個STD編号。除此之外的TS和AS分為以下幾種"Maturity Level"。Experimental，一般是反映一些研究和開發的成果，隻應将此看作是一般性的信息。Informational，反映與Internet标準有關的一般性信息。有些也是有關非Intern et組織開發的一些協議，但必須得到協議開發者的許可。Historic，是一些被新的标準取代或者是已經過時廢棄不用的标準。STD1（RFC2200）——Internet Official Protocol Standards，定期更新，反映最新的 Internet标準。另外，對于關注Internet的人來說，應該經常注意查閱BCP9的最新内容。