RFC

RFC

目錄[隱藏]

    一、網絡中的RFC

       1. RFC及RFC編輯者
       2. RFC處理過程
       3. RFC的歷史
       4. RFC文件的架構
       5. RFC文件的產生
       6. 一些相關網址
       7. RFC發展歷程
       8. RFC的分類

    二、外貿中的RFC
    三、SAP中的RFC

       1. 四、 讀RFC文檔時，需要注意的問題

    五、二戰中的RFC
    六 射頻扼流圈

    一、網絡中的RFC

       1. RFC及RFC編輯者
       2. RFC處理過程
       3. RFC的歷史
       4. RFC文件的架構
       5. RFC文件的產生
       6. 一些相關網址
       7. RFC發展歷程
       8. RFC的分類

    二、外貿中的RFC
    三、SAP中的RFC

       1. 四、 讀RFC文檔時，需要注意的問題

    五、二戰中的RFC
    六 射頻扼流圈

一、網絡中的RFC
RFC及RFC編輯者
　　Request For Comments (RFC)，是一系列以編號排定的文件。文件收集了有關因特網相關資訊，以及UNIX和因特網社羣的軟件文件。目前RFC文件是由Internet Society（ISOC）所贊助發行。
　　基本的因特網通訊協定都有在RFC文件內詳細說明。RFC文件還額外加入許多的論題在標準內，例如對於因特網新開發的協定及發展中所有的記錄。因此幾乎所有的因特網標準都有收錄在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處理過程
　　一個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標準制定過程的更多詳細信息，請各位參見：
　　RFC 2223 "Instructions to RFC Authors"。
　　RFC 2026 "The Internet Standards Process -- Revision 3"。
　　實際上，在Internet上，任何一個用戶都可以對Internet某一領域的問題提出自己的解決方案或規範，作爲Internet草案（Internet Draffs，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/RFCnnnn.TXT通過FTP的方式從ds.internic.net站點獲得RFC，其中“nnnn”指的是RFC的編號。在這裏，使用FTP登錄時，所用的用戶名和口令分別爲“anonymous”和你的電子郵件地址。此外，用戶還可以通過Internet網絡信息中心（InterNIC）的目錄服務功能、電子郵件、WWW等方式獲得RFC文檔.
　　作爲標準的RFC又分爲幾種，第一種是提議性的，就是說建議採用這個作爲一個方案擺出來，Draft是已經有一部分在用了，希望被採用爲正式的標準，還有一種就是完全被認可的標準，這種是大家都在用，而且是不應該改變的。還有一種就是現在的最佳實踐法，它相當於一種介紹。這些文件產生的過程是一種從下往上的過程，而不是從上往下，也就是說不是一個由主席，或者由工作組負責人的給一個指令，說是要做什麼，要做什麼，而是有下邊自發的提出，然後在工作組裏邊討論，討論了以後再交給剛纔說的工程指導委員會進行審查。但是工程指導委員會只做審查不做修改，修改還是要打回到工作組來做。IETF工作組文件的產生就是任何人都可以來參加會議，任何人都可以提議，然後他和別人進行討論，大家形成了一個共識就可以產出這樣的文件。
RFC的歷史
　　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領導下）負責RFT文檔的起草和發佈工作。Jon Postel繼續擔任RFC編輯直到去世。隨後，由Bob Braden接任整個項目的領導職務，同時Joyce Reynolds繼續在團隊中的擔任職務。
　　慶祝RFC的30週年的RFC文件是RFC 2555。
RFC文件的架構
　　RFC文件只有新增，不會有取消或中途停止發行的情形。但是對於同一主題而言，新的RFC文件可以聲明取代舊的RFC文件。RFC文件是純 ASCII文字檔格式，可由電腦程式自動轉檔成其他檔案格式。RFC文件有封面、目錄及頁首頁尾和頁碼。RFC的章節是數字標示，但數字的小數點後不補零，例如4.9的順序就在4.10前面，但9的前面並不補零。RFC1000這份文件就是RFC的指南。
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文件。
一些相關網址
　　截至2001年中期，公佈的RFC大約有3000餘篇，以下是幾個較爲穩定的RFC網址，以及幾個重要的標準化組織的網站網址
　　http://www.rfc.net RFC的官方站點，可以檢查RFC最及時的更新情況
　　http://www.ietf.org 最重要的Internet組織之一
　　http://sunsite.dk RFC查詢非常強大(可以以FTP登錄下載全部RFC文檔)
　　http://www.iso.ch ISO-國際標準化組織
　　http://standards.ieee.org IEEE-電氣與電子工程師協會
　　http://web.ansi.org ANSI-美國國家標準化組織
　　http://www.itu.int ITU-國際電信同盟
　　中文網站:
　　http://www.cnpaf.net/ 中國協議分析網
　　http://www.cangfengzhe.com/cdrfc/list_67.html 中文RFC集合
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,也要使用新的編號,而不會使用原來的編號,時至今日,RFC編號已經排到2200多,在查找RFC時,一定要注意最新的RFC。
RFC的分類
　　RFC文檔大致可以分爲以下幾類。
　　1.STD RFC
　　按照RFC1311的定義,STD RFC是指那些已經或者致力於成爲Internet標準的RFC。只有經過完全Internet標準化過程的RFC纔可以有STD編號,STD編號是不變的,而其涉及到的 RFC文檔可能不只一個,其RFC編號也會更新。如STD13(Domain Name System)就涉及RFC1 034和RFC1035。 STD的標準化過程要經過幾個步驟,首先由IETF起草標準(也可能是其他組織和個人, 但一般都是和IETF共同完成的),形成Internet Draft(ID),ID沒有RFC編號。如果ID在6個月內IESG沒有建議成爲RFC,則取消此ID。成爲RFC後,還要經過一系列的審查、修訂、測試等才能最終成爲Internet標準。
　　2.BCP RFC
　　由於Internet應用領域廣泛,各種不同的組織有不同的使用目的和使用規則,IETF除了建議STD以外,也有必要對於Internet的使用和管理提供一些一般性的指導,同時也爲I ETF、IAB、IESG提供一種渠道,以便推動某一方面的工作,反映其技術趨向,反映這些組織本身的工作進展。於是,1995年以RFC1818定義了 BCP,即Best Current Practice。BCP同時有一個BCP編號和一個RFC編號,一旦約定了一個BCP編號,就不會再變,而其RFC編號則可能會經過修訂不斷更新。例如反映Internet標準化工作程序的BCP9的RFC編號就從RFC16 02上升到RFC2026,相應地就廢棄了RFC1602。 BCP在發表以前,以電子郵件的形式廣泛徵求IETF的意見,經過IESG的審查,通過後即正式發表。但是BCP本身不是Internet標準。
　　3.FYI RFC
　　FYI是For Your Information的簡寫,1990年發表的RFC1150(FYI1)定義了FYI,FYI也同時有一個FYI編號和一個RFC編號,FYI編號是固定的。FYI主要是提供有關Internet的知識性內容。如FYI4(RFC1594),"Answers to Commonly asked New Internet User Quest ions"。所有的FYI在提交到RFC編輯以前,必須先經過IETF的User Services WorkingGro up審查。
　　4.其他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的最新內容。

二、外貿中的RFC
　　外貿過程中墨西哥的客戶可能會給你提供一個他們的RFC號碼 根據網絡上的一些資料 RFC的全寫應該是西班牙語 “registro federal de causantes” 翻譯成英語是 “federal register of causes”。意思是企業在墨西哥政府的註冊登記號，相當於納稅登記號。
　　我在這裏加上主要是爲了以後有做外貿的同事們查詢的時候方便一點。
　　參考資料：
　　http://forum.wordreference.com/showthread.php?t=20004
　　鏈接是西班牙語的 大家可以用翻譯工具翻譯成英語看看

三、SAP中的RFC
　　RFC(遠程函數調用 Remote Function Call)是一個 SAP 的接口協議。它基於 CPI-C,很大程度上簡化了系統間通訊的編程工作。RFC 允許調用和執行一個遠程系統,或者是相同系統上的預定義函數。
四、 讀RFC文檔時，需要注意的問題
　　一是需要確定它是最新的文檔，二是需要注意RFC文檔的類別；
　　所有的RFC文檔都要經歷評論和反饋過程，並且在這一段時間內它們會被劃分爲不同的類別；
　　RFC文檔一旦被提交，IFTF和IAB組織將審查RFC文檔，通過後可以成爲一項標準；
　　RFC文檔按照它發展與成熟的過程可以分爲標準、草案標準、提案標準、實驗性的、信息性或歷史性的；
　　RFC文檔又可以分爲被要求、被推薦、被選擇、受限制使用或不被推薦；

五、二戰中的RFC
　　1934年，德國沃瑞爾協會生產了第一架碟形飛行器RFC-1，傳言RFC-1飛碟使用了外星人技術，卻在試飛時因故障頻發而損失慘重。
　　事實上，當時德國有三個獨立的飛碟研發中心，分別在佩內明德、佈雷斯勞、布拉格，這三個地方都在進行飛碟試驗。
　　當時，在德國的黑森林地區，無人碟形攔截機成功生產並試飛。這種碟形機，被英國、美國、蘇聯的情報機關命名爲V-7 。
　　梅塞施米特公司的飛機工廠成功研製出用於V-7的靜電場粒子武器，V-7無人碟形攔截機使用火箭動力飛行，盟軍官兵與飛行員給這個飛碟機取了一個綽號叫做“白天和黑夜都能噴火的飛碟武器”。
　　令人吃驚的是，從1944年11月到1945年4月，V-7飛碟機升空次數竟然多達415次。後來，這些飛碟產品在柏林飛機工廠改良後，被命名爲“球形閃電”。盟軍對飛碟機時而單機作戰，時而多機出擊的戰術感到十分困惑。德軍於是將計就計，把“球形閃電”故意和其他兩種型號的碟形機混淆使用，藉以迷惑盟軍的情報機構。其中一種碟形機經常拖曳巨大的球形金屬帶，造成飛碟機羣數量衆多的假象，以迷惑盟軍的雷達。
　　而另一種則經常突然快速飛到盟軍轟炸機附近，以恐嚇盟軍轟炸機上的飛行員和炮長，使他們心理恐慌、神經衰弱乃至精神發瘋，進而對飛機失去控制，以此達到破壞盟國空軍繼續攻擊的目的。
　　1945年，二戰即將結束，納粹飛碟機的許多科研計劃被迫終止。不過，仍然有部分V7 、V8甚至最終改進的V9碟形機在試飛。
　　1945年2月初，蘇聯空軍對德國的攻勢日益猛烈，盟軍部隊在各個戰場向德國步步進逼。從2月 17日開始，德軍在東、西兩線節節敗退。同時，德國空軍也已窮途末路，不過他們還在做着垂死掙扎，並妄圖利用新式武器挽救第三帝國的滅亡。德國祕密機構 “爆破手研究室—13”製造的“別隆採飛碟”更是在爭分奪秒做最後的衝刺。
　　兩天後，耗資數百萬馬克的“柏羅湟女戰神”飛碟終於進行了它的首次也是最後一次試飛。
　　某些資料透露，在短短3分鐘內，它就飛昇到了1萬5千米高空，平飛速度高達每小時2200公里。同時它還可以懸停在空中，無需轉彎便能向前或向後任意飛行。這是納粹德國研製的最後一種型號的飛碟，採用奧地利設計師弗·紹貝格爾發明的爆炸式“紹貝格爾”型發動機驅動，只需用水和空氣做燃料。
　　不久以後，研製飛碟的佈列斯拉工廠落入蘇軍手中，飛碟發明者紹貝格爾等人也爲了躲避蘇軍的追捕而逃往美國，其他工程技術人員下落不明。
　　1958年，紹貝格爾在給朋友的一封信中這樣寫道:“柏羅湟女戰神”飛碟，是同幾個一級*** 工程師合作共同研製的，後來他們都被關進了集中營。根據各方面的情況判斷，飛碟的主體樣機是按照希特勒的命令毀掉的，因爲一些主要負責專家，二戰結束前夕在一所工廠裏毀掉了這些屬於核心機密的尖端飛行器。
　　作家魯道夫·盧薩爾在他寫的一部書中也援引了這樣一段話:“美國人想用重金向紹貝格爾買下研製飛碟的祕密技術，加拿大也是如此，但被紹貝格爾拒絕了，他要求先簽訂一個國際協議。而施特曼認爲，無論跟誰籤合同，美國人都能得到他們想得到的一切。”
　　1952年，另一位前德國空軍上尉、航空專家斯徹裏沃也宣稱，他曾經爲一個碟形飛行器繪製過藍圖，這些研究工作是在布拉格附近展開的。據說，這個神話般的飛行器時速高得不可思議，竟然達到了3200公里、作戰半徑6400多公里。他還說，1944 年，用於實驗的模型已經完成，本來可望於1945年試飛的，但是蘇軍的挺進使這一切成爲了泡影。
　　納粹德國崩潰前夕，設計藍圖等資料散失。如果按照斯徹裏沃的說法，納粹研製的飛碟似乎由於德國的戰敗而胎死腹中，然而，一位叫喬治·克雷恩的目擊者卻又一次掀起了波瀾。
　　他聲稱曾經親眼目睹了一架奇異飛行器的試飛。他說有些研究工作被安排在佩內明德基地，那裏正是納粹研究絕密武器的頂尖航空科研機構。他還說納粹飛碟的試飛是在哈爾茨山脈地區進行的，而那裏也恰好是許多飛碟目擊者報告的目擊地點。
　　由此看來，納粹德國確實從事過碟形飛行器的研究並且似乎獲得了成功。

六 射頻扼流圈
　　Radio Frequency Choke
　　是一種大電感，由於感抗=jwL , 可見RFC 對直流短路，對高頻交流開路，
　　故用於直流通路和射頻/微波通路隔離，消除交流信號與直流源及地之間的耦合