最近讀 RFC 文檔的過程中，發(fā)現(xiàn)在過去十幾年里，每年都有嘗試翻譯 RFC 的小伙伴，但是大家沒有統(tǒng)一的規(guī)范，譯文的組織也非常松散，翻譯的水平參差不齊。

為了能夠使大家的工作成果得到維護，并提供對譯文不斷迭代的可能，我最近建了一個 Github 倉庫和一個網(wǎng)站；另外，我還翻譯了幾篇比較基礎的 RFC，對于 RFC 文檔的準確理解和翻譯都很重要。希望通過做一點微小的貢獻，達到“前人栽樹，后人乘涼”的目的。

網(wǎng)站的視覺效果應該會好些，使用了等寬字體，并且有中英對照；但畢竟是第一次進行網(wǎng)站開發(fā)，且使用的是最低配的服務器，響應時間、頁面布局會有很多問題。

https://github.com/dianbo-rfc/dianbo-rfc

https://dianbo-rfc.cn/progress

下面是譯文：

Internet Architecture Board (IAB) H. Flanagan Request for Comments: 7322 S. Ginoza Obsoletes: 2223 RFC Editor Category: Informational September 2014 ISSN: 2070-1721RFC 樣式指南摘要此文檔描述了: 目前在 RFC 系列文檔中所使用的, 基本的、獨有的樣式約定和編輯方針。此文檔包含了 RFC Editor 的基本要求, 且提供了關于 RFC 的樣式及結構的指南。其它的一些指南可以在一網(wǎng)站上獲取, 這些指南是實驗性質的,并準備將其納入到未來的 'RFC 樣式指南' 中。此文檔廢除了 RFC2223,"Instructions to RFC Authors"。Status of This MemoThis document is not an Internet Standards Track specification; it ispublished for informational purposes.This document is a product of the Internet Architecture Board (IAB)and represents information that the IAB has deemed valuable toprovide for permanent record. It represents the consensus of theInternet Architecture Board (IAB). Documents approved forpublication by the IAB are not a candidate for any level of InternetStandard; see Section 2 of RFC 5741.Information about the current status of this document, any errata,and how to provide feedback on it may be obtained athttp://www.rfc-editor.org/info/rfc7322.Copyright NoticeCopyright (c) 2014 IETF Trust and the persons identified as thedocument authors. All rights reserved.This document is subject to BCP 78 and the IETF Trust's LegalProvisions Relating to IETF Documents(http://trustee.ietf.org/license-info) in effect on the date ofpublication of this document. Please review these documentscarefully, as they describe your rights and restrictions with respectto this document.Flanagan & Ginoza Informational [Page 1]RFC 7322 RFC Style Guide September 2014目錄1. 導言 ............................................................32. RFC Editor 的理念 ...............................................43. RFC 樣式約定 ....................................................53.1. 語言 .......................................................53.2. 標點符號 ...................................................53.3. DNS 名稱和 URI .............................................63.4. 大寫形式 ...................................................63.5. 引用 .......................................................63.6. 縮寫規(guī)則 ...................................................74. RFC 的結構 ......................................................84.1. 首頁頁頭 ...................................................94.1.1. 作者/編輯者 .........................................94.1.2. 組織 ................................................94.1.3. "ISSN: 2070-1721" ..................................104.1.4. 更新和廢除 .........................................104.2. 全文標題 ..................................................104.3. "摘要" 章節(jié) ...............................................114.4. RFC Editor or Stream Notes Section ........................114.5. "此備忘錄的狀態(tài)" 章節(jié) .....................................114.6. 版權, 許可證, 及知識產(chǎn)權樣板章節(jié) ..........................114.7. "目錄" 章節(jié) ...............................................114.8. 備忘錄正文 ...............................................124.8.1. "導言" 章節(jié) ........................................124.8.2. "文檔要求的用語" 章節(jié) ..............................124.8.3. "IANA 注意事項" 章節(jié) ...............................134.8.4. "國際化注意事項" 章節(jié) ..............................134.8.5. "安全注意事項" 章節(jié) ................................134.8.6. "參考文獻" 章節(jié) ....................................144.8.6.1. RFC 中的 URI ..............................154.8.6.2. 引用 RFC ..................................154.8.6.3. 引用 STD 和 BCP ...........................164.8.6.4. 引用互聯(lián)網(wǎng)草案 ............................174.8.6.5. 引用勘誤 ..................................184.8.6.6. 引用其它標準開發(fā)組織 ......................184.9. "附錄" 章節(jié) ...............................................194.10. "致謝" 章節(jié) ..............................................194.11. "貢獻者" 章節(jié) ............................................194.12. "作者地址" 章節(jié) ..........................................205. 安全注意事項 ...................................................206. 參考文獻 .......................................................206.1. 前提類參考文獻 ............................................206.2. 信息類參考文獻 ............................................20Flanagan & Ginoza Informational [Page 2]RFC 7322 RFC Style Guide September 2014附錄 A. Related Procedures ........................................23A.1. Dispute Resolution .........................................23A.2. Returning an I-D to the Document Stream ....................23A.3. Revising This Document and Associated Web Pages ............23IAB Members at the Time of Approval ...............................24致謝 ..............................................................24貢獻者 ............................................................24作者地址 ..........................................................241. 導言RFC 發(fā)布流程的最終目標是: 產(chǎn)生可讀的、清晰的、一致的、且合理統(tǒng)一的文檔。20 世紀 70 年代, 最早的 RFC 編輯者, Jon Postel, 建立了基本的 RFC格式約定。此文檔描述了: 目前在 RFC 系列文檔 [RFC4844] 中所使用的, 基本的、獨有的樣式約定和編輯方針。其目的是作為一個穩(wěn)定的、不常更新的指南, 以供作者、編輯者、和評審員參考。RFC Editor 還維護了樣式指南 (Style Guide) 的網(wǎng)頁部分 (見附錄第 A.3節(jié)), 其中描述了出現(xiàn)的問題, 并指出了 RFC Editor 打算如何處理這些問題。當出現(xiàn)新的樣式相關的問題時, RFC Editor 首先會在樣式指南的網(wǎng)頁部分中[STYLE-WEB] 處理這些問題。當這些主題得到修訂后, 可能會成為 RFC 樣式指南的一部分。技術出版界對語法、標點符號、大寫字母、及句子的長度、復雜度、并行度等都有公認的規(guī)則。RFC Editor 大體上遵循了在 "芝加哥樣式手冊" (ChicagoManual of Style, CMOS) [CMOS] 中所定義的這些公認的規(guī)則, 除了一些重要的例外情況: 為了避免復雜的技術文章中的歧義性、為了處理普通文本與計算機語言的混用、或為了保留歷史遺留的格式規(guī)則。此文檔展示了那些被 RFCEditor 所應用或推薦的例外情況。所有的 RFC 都是以互聯(lián)網(wǎng)草案 (Internet-Drafts, 又稱 I-Ds) 開始的, 而一個編寫良好、結構合理的互聯(lián)網(wǎng)草案 [ID-GUIDE] 為一個優(yōu)秀的 RFC 提供了堅實的基礎。RFC Editor 接受來自一些特定的發(fā)布流 (stream) 的互聯(lián)網(wǎng)草案,來進行發(fā)布 [RFC4844], 并在編輯流程中應用 RFC 系列文檔 (RFC Series) 的規(guī)則和指南。Flanagan & Ginoza Informational [Page 3]RFC 7322 RFC Style Guide September 20142. RFC Editor 的理念理解 RFC Editor 在發(fā)布流程中的目標, 可能會對作者有所幫助, 即:- 根據(jù) RFC 的樣式和格式準備文檔。- 使文檔盡可能清晰、一致、且可讀。- 更正較嚴重的文本內容/表述清晰相關的問題; 標記任何不清楚的段落以供作者審閱。- 解決不一致問題 (例如, 同一術語采用了多種不同的表述形式、同一文本出現(xiàn)多次、或大小寫不一致)。我們力求在以下范圍內保持一致性:a. 文檔自身的范圍內,b. 一 "簇" 文檔的范圍內 [CLUSTER],c. 與同一主題相關的一系列 RFC 文檔的范圍內。RFC Editor 的編輯流程并不是對文檔進行額外的技術性審閱。當 RFC Editor為了清晰性與可讀性而建議更改措辭時, 這一修改是否會對技術含義產(chǎn)生影響,是由作者、工作組、或發(fā)布流審批機構來決定。如果原始的措辭可以更加準確地描述文檔中的技術內容, 則其優(yōu)先于文檔的編輯約定。對文檔的編輯活動有時會造成作者和編輯者之間的緊張關系。RFC Editor 試圖將文檔發(fā)布過程中的這一沖突最小化, 同時力求產(chǎn)生大量優(yōu)秀的系列文檔。RFCEditor 將這種基本的緊張關系稱為 "編輯平衡" ("editorial balance"), 而保持這種平衡是 RFC Editor 所持續(xù)關注的問題。這里有一個凌駕于語法約定的基本要求, 即: 不要改變文本的本來含義。如果 RFC Editor 不冒著改變文本含義的高風險, 就無法編輯文檔, 則該文檔應當退還給發(fā)布流審批機構進行再審。更多信息見附錄第 A.2 節(jié)。Flanagan & Ginoza Informational [Page 4]RFC 7322 RFC Style Guide September 20143. RFC 樣式約定此樣式指南 (Style Guide) 沒有使用 RFC 2119 [BCP14] 中定義的術語。此文檔中, 對 "must" 和 "should" 的小寫形式的使用 (譯者, 譯文中未加方括號【】進行強調的 "必須" 和 "應該" 等詞), 表示 RFC Editor 將會自動地對文檔進行修改, 以遵循此樣式指南; 與之相對, 如果沒有應用此修改, 則將受到質疑。小寫形式的 "must" (譯者, 譯文中未加方括號【】的 "必須"), 表示將會自動地應用這些修改, 而非由作者決定。小寫形式的 "should" (譯者, 譯文中未加方括號【】的 "應該"), 表示是 RFC Editor 所建議的用法, 但遵循該建議并不是必須的; RFC Editor 可能會詢問是否要應用該條指南。3.1. 語言RFC 的發(fā)布語言為英語。單詞拼寫可能是美式的、或英式的, 只要其在單個文件內部保持一致即可。如果在一個文件內部、或一 "簇" 文件內部同時使用了英式拼寫和美式拼寫, 則文本將會被修改為與美式拼寫相一致。3.2. 標點符號* 不允許對文本加粗 (或添加下劃線)。* 如果一個句子以句點結束, 且其后緊跟另一個句子, 則句點后必須有兩個空格。* 在一序列中的最后一項前添加逗號, 例如:"TCP service is reliable, ordered, and full duplex"* 當引述純單詞的文本時, 標點符號放在引號外部, 例如:Search for the string "Error Found".當引述一般的文本時, 例如來自另一個 RFC 的一般文本, 標點符號可以被包含到引號內部, 例如:RFC 4844 indicates that "RFCs are available free of charge toanyone via the Internet."當文本采用塊引述的形式時, 不需要使用引號。Flanagan & Ginoza Informational [Page 5]RFC 7322 RFC Style Guide September 20143.3. DNS 名稱和 URI在 RFC 中用作一般示例的 DNS 名稱 (無論其是否在 URI 中), 都應當使用在"Reserved Top Level DNS Names" [BCP32] 所定義的特定示例, 以避免意外的沖突。強烈建議在 URI 周圍使用尖括號 [STD66], 例如:<http://example.com/>3.4. 大寫形式* 大寫形式必須在文本內保持一致, 且在理想情況下, 應與相關的 RFC 保持一致。請參考在線表格 [TERMS], 了解關于 RFC 中術語的一致性使用的決定。* 根據(jù) CMOS (Chicago Manual of Style) 中的準則, 在 RFC 的主標題和章節(jié)標題中的主要單詞應當被大寫 (這有時被稱為 "title case")。通常, 標題中的所有單詞都應被大寫, 但其中的冠詞、介詞、和連詞除外。(譯者,這里的大寫是指首字母大寫)。* 句子形式的章節(jié)標題, 將遵循典型的句首單詞首字母大寫的形式。* 圖片的標題可以采用句子或標題的大寫形式。3.5. 引用* 參考文獻和引用必須要匹配。因此, 對于每一個引用都必須有相應的參考文獻, 反之亦然。* 引用必須被包裹在方括號中 (例如 "[CITE1]")。* 在引用/參考文獻的標簽中禁止包含空格。示例: "[RFC2119]" rather than "[RFC 2119]"但是, 正確的 RFC 文本命名中包含有一個空格。示例: "See RFC 2119 [BCP14] for more information."* 位于備忘錄 (譯者, 實際上就是指文檔) 正文中的、 指向其它 RFC 的交叉引用 (Cross-references), 應當使用章節(jié)號, 而非頁號; 因為頁號可能會因格式或設備的不同而改變。Flanagan & Ginoza Informational [Page 6]RFC 7322 RFC Style Guide September 20143.6. 縮寫規(guī)則當縮寫出現(xiàn)在標題中、或在文檔中第一次使用時, 縮寫應當被展開。文本的縮寫形式應該用括號包裹, 并跟在其完整展開形式的后面。存在例外, 即一縮寫非常常見, 以至于 RFC 讀者可以立即認出該縮寫; 例如 (但不限于) TCP, IPSNMP, 和 HTTP。在線的縮寫列表 [ABBR] 提供了相關指南。存在一些少見的樣例, RFC Editor 會在權衡了模糊性和復雜性后, 作出最終的判斷。注意: 在線的縮寫列表并非是事無巨細的、完全明確的。它僅僅是出現(xiàn)在RFC 中的縮寫的列表, 有時反映了與作者、工作組主席 (Working GroupChairs)、和/或區(qū)域主管 (AD, Area Director) 的討論結果。注意, 有一些縮寫具有多個展開形式。此外, 該列表還包含一些看起來像縮寫的術語,但實際上它們是事物的固定名稱, 因此不能夠也不應當被展開。這些術語被記作 "No Expansion"。Flanagan & Ginoza Informational [Page 7]RFC 7322 RFC Style Guide September 20144. RFC 的結構一個已發(fā)布的 RFC 將主要包含以下列表中的元素。如上所述, 其中的一些章節(jié)是必需的。在文檔的編輯流程中, 如有必要, RFC Editor 將會提供那些用 "*"標出的章節(jié)。在各個章節(jié)中, 只能包含子章節(jié)。關于這些文檔元素的規(guī)則, 將在下面詳細介紹。First-page header 首頁頁頭 * [Required]Title 標題 [Required]Abstract 摘要 [Required]RFC Editor or Stream Note * [Upon request]Status of This Memo 此備忘錄的狀態(tài) * [Required]Copyright Notice 版權聲明 * [Required]Table of Contents 目錄 * [Required]Body of the Memo 備忘錄正文 [Required]1. Introduction 導言 [Required]2. Requirements Language (RFC 2119)3. ... ...MAIN BODY OF THE TEXT 文本的主體6. ... ...7. IANA Considerations IANA 注意事項 [Required in I-D]8. Internationalization Considerations9. Security Considerations 安全注意事項 [Required]10. References 參考文獻10.1. Normative References 前提類參考文獻10.2. Informative References 信息類參考文獻Appendix A. 附錄 A.Appendix B. 附錄 B.Acknowledgements 致謝Contributors 貢獻者Author's Address 作者地址 [Required]強烈建議: 在備忘錄的正文 (body of the memo) 中, 使用上面所示的順序。對于那些未采用該順序的例外情況, 可能會受到問詢。在備忘錄的正文外, 上面所示的順序是必須的。上面所示的章節(jié)編號僅用于說明目的; 它們并不與實際的 RFC 中所需的編號相對應。不應對備忘錄正文 (body of the memo) 前面的元素進行編號。通常, 在備忘錄正文中的, 章節(jié)使用數(shù)字進行編號, 附錄使用字母進行標記。出現(xiàn)在附錄后面的章節(jié), 不應當被編號或標記 (例, 上面所示的 "Contributors")。Flanagan & Ginoza Informational [Page 8]RFC 7322 RFC Style Guide September 20144.1. 首頁頁頭 (First-Page Header)頁頭 (Headers) 將遵循在 "RFC Streams, Headers, and Boilerplates"[RFC5741] 及其后續(xù)文檔中所描述的格式。此外, 將會應用下述的約定。4.1.1. 作者/編輯者由發(fā)布流來確定: 在 RFC 中, 哪些人應當被列為作者或編輯者。作者的姓名應出現(xiàn)在頁頭的第一行。允許在姓名中添加額外的姓氏的縮寫或大寫。一旦作者選擇了姓名的顯示方式, 他們應當在其所有的文檔中使用一致的顯示方式。在首頁中, 作者或編輯者的總數(shù)通常限制在五個, 包括個人及其所屬機構。如果要求列出五名以上的作者, 則發(fā)布流審批機構需要考慮: 這些人中是否有一到兩人對此文檔負有主要責任, 并將其他人列在貢獻者 (Contributors) 或致謝 (Acknowledgements) 章節(jié)中。出現(xiàn)在文檔頁頭中、及作者地址 (Authors'Addresses) 章節(jié)中的作者和編輯者, 必須有著直接關聯(lián)。這些人要負責: 在AUTH48 流程中, 在文檔上簽字; 以及回應各類詢問, 例如勘誤。4.1.2. 組織作者所屬的組織應在作者姓名的下一行指出。對于多名作者的情形, 每名作者的姓名出現(xiàn)在單獨一行中, 并后跟作者所屬的組織。當有多名作者從屬于同一組織時, 可以將組織名稱 "提取" 出來, 并跟隨在這些作者姓名行的后面, 僅顯示一次。但是, 當這種 "提取" 會改變作者姓名的順序, 且這種順序的改變是不可接受的時候, "提取" 行為是不合適的。如果一名作者因為某些原因, 不能或不愿提供所屬機構時, 可以使用 "獨立的"("Independent")、"個人貢獻者" ("Individual Contributor")、"已退休"("Retired")、或其他合適的術語, 來描述作者從屬情況。或者, 當沒有提供任何從屬信息時, 可以在文檔頁頭中包含一空行。Flanagan & Ginoza Informational [Page 9]RFC 7322 RFC Style Guide September 20144.1.3. "ISSN: 2070-1721"RFC 系列文檔已經(jīng)被賦予了一個國際標準期刊編號 (International StandardSerial Number), 為 2070-1721 [ISO3297]。該編號將會被包含在 RFC Editor中。4.1.4. 更新 (Updates) 和廢除 (Obsoletes)當一個 RFC 要廢除或更新之前的一個或多個已發(fā)布的 RFC 時, 應當在文檔的頁頭中包含如下信息。例如:"Updates: nnnn" or "Updates: nnnn, ..., nnnn""Obsoletes: nnnn" or "Obsoletes: nnnn, ... , nnnn"如果當前文檔更新或廢除了多個文檔, 則文檔編號將按照升序列出。4.2. 全文標題 (Full Title)標題必須位于頁頭的下方, 居中對齊, 并前后各添加一空行。為 RFC 選擇一個好的標題是一個挑戰(zhàn)。一個好的標題應當能夠中肯地表明文檔涉及的領域及其目的, 且不會過于籠統(tǒng)、或過于具體和冗長。標題中的縮寫, 若是第一次遇到, 一般必須要被展開 (關于縮寫的額外指南見第 3.6 節(jié))。通常, 很有幫助的做法是: 在縮寫的展開形式的后面, 跟隨被括號包裹的該縮寫。如下面的例子所示:Encoding Rules for theCommon Routing Encapsulation Extension Protocol (CREEP)RFC Editor 建議: 一個用于描述某個特定的公司私有協(xié)議的文檔, 應當采用形如 "Foo's ... Protocol" (其中 Foo 是公司名稱) 的標題, 以使其明確區(qū)別于其它更加普遍適用的協(xié)議。Flanagan & Ginoza Informational [Page 10]RFC 7322 RFC Style Guide September 20144.3. "摘要" (Abstract) 章節(jié)每個 RFC 必須具有一個摘要, 來對整個文檔的目的和內容進行簡明和全面的概述, 以便技術相關的讀者能夠對該文檔的功能有個大致的概覽。撰寫一篇有用的摘要一般需要深思熟慮。通常, 摘要應當以類似 "This memo..." 或 "This document ..." 這樣的短語作為開頭。一篇令人滿意摘要經(jīng)常是根據(jù)導言 (Introduction) 章節(jié)的部分材料來構建的, 但是一篇有效的摘要應當比導言更加簡短、粗略、且可能范圍更廣。允許簡單地復制粘貼導言的前幾個段落, 但是這可能使摘要變得既不完整又多余。注意: 摘要不能代替導言;RFC 應當是字包含的, 就像沒有摘要一樣。同樣, 摘要本身應當是完整的。摘要將會單獨出現(xiàn)在 RFC 的發(fā)布公告及在線索引中。因此, 摘要中禁止包含引用。4.4. RFC Editor or Stream Notes SectionA stream-approving body may approve the inclusion of an editorialnote to explain anything unusual about the process that led to thedocument's publication or to note a correction. In this case, astream note section will contain such a note.Additionally, an RFC Editor Note section may contain a note insertedby the RFC Editor to highlight special circumstances surroundingan RFC.4.5. "此備忘錄的狀態(tài)" 章節(jié)RFC Editor 將會提供合適的 "此備忘錄的狀態(tài)" ("Status of This Memo") 信息, 其定義在 RFC 5741 [RFC5741] 與 "IAB 發(fā)布流中的 RFC 格式" ("Formatfor RFCs in the IAB Stream") [IAB-FORM] 中。4.6. 版權, 許可證, 及知識產(chǎn)權樣板章節(jié)完整的版權和許可證的聲明, 可以從 IETF Trust Legal Provisions 文檔頁面[IETF-TRUST] 獲取。4.7. "目錄" 章節(jié)所有的 RFC 都需要有目錄 (TOC, Table of Contents)。目錄必須位于版權聲明之后、導言之前。Flanagan & Ginoza Informational [Page 11]RFC 7322 RFC Style Guide September 20144.8. 備忘錄正文跟隨在目錄后的是備忘錄的正文。每個 RFC 必須包含一個導言 (Introduction) 章節(jié), 以解釋該 RFC 的動機,以及 (如果合適) 描述文檔的適用性, 例如: 它是否能說明了某個協(xié)議、提供了關于某些問題的討論、僅是對互聯(lián)網(wǎng)社區(qū)的興趣、又或者提供了某些活動的狀態(tài)報告。備忘錄的正文和摘要 (Abstract) 都必須是獨立的、可分離的。這可能會導致在摘要和導言間出現(xiàn)一些重復文本; 這是可以接受的。4.8.1. "導言" (Introduction) 章節(jié)導言章節(jié)應當總是目錄后的第一個章節(jié) (MIB 模塊文檔除外)。雖然建議使用"導言" ("Introduction") 一詞, 但是作者可能選擇其它標題, 例如 "概述"("Overview") 或 "背景" ("Background")。這些替代方式是可接受的。對于 MIB 模塊文檔, 通常的做法見 "The Internet-Standard ManagementFramework" [MIB-BOILER], 即文本作為第 1 節(jié)出現(xiàn)。4.8.2. "文檔要求的用語" 章節(jié)一些文檔使用了特定的大寫單詞 ("MUST"、"SHOULD" 等, 譯文中為【必須】、【應當】等), 來指出對某一技術特性的明確的要求級別。RFC 2119 [BCP14]定義了: 當這些大寫單詞出現(xiàn)在 IETF 文檔中時的默認解釋。如果使用此解釋,則必須引用 RFC 2119 (如 RFC 2119 中指定的那樣), 并將其作為前提類參考文獻。否則, 必須在文檔中說明用詞的正確釋義。這一章節(jié)必須作為備忘錄正文的一部分出現(xiàn) (如此文檔中定義的那樣)。它必須作為導言章節(jié)的一部分、或作為導言的后續(xù)章節(jié)。這些單詞被認為是文檔的技術內容的一部分, 這些單詞的使用通常以技術特性的互操作性作為考量, 旨在為實現(xiàn)者提供關于一些具體的技術特性的指導。在RFC 2119 中, 有說:在此備忘錄中定義的這些祈使詞, 必須被小心地、保守地使用。特別的, 這些祈使詞的使用【必須】是出于互操作性的實際需要、或是為了限制可能導致潛在危害的行為 (例如, 限制重傳)。例如, 它們不得被用于: 將特定方法強加給實現(xiàn)者, 而該方法是互操作性所不需要的。Flanagan & Ginoza Informational [Page 12]RFC 7322 RFC Style Guide September 20144.8.3. "IANA 注意事項" (IANA Considerations) 章節(jié)關于如何注冊與 IANA 相關的值, 或如何創(chuàng)建新的由 IANA 管理的注冊表, 見"Guidelines for Writing an IANA Considerations Section in RFCs"[BCP26]。在完成 IANA 分配后, RFC Editor 將會相應地對文本進行更新。建議作者清楚地標出應當更新哪些文本, 以反映新分配的值。例如, 推薦在 "IANA 注意事項" 章節(jié)、及備忘錄正文中, 使用 "TBD1", "TBD2" 等。如果作者已經(jīng)提供了由 IANA 分配的值, 則 RFC Editor 將會驗證: 作者插入到文檔中的值是否與在 IANA 站點上實際注冊的值匹配。當書寫給定的值時,建議使用一致的十進制或十六進制形式。如果有任何與 IANA 相關的信息不明確, 則 RFC Editor 會同 IANA 一起向作者發(fā)出問詢, 以確保該分配流程及分配的值被正確插入到文檔中。如果一個 "IANA 注意事項" 章節(jié)表示其沒有關于 IANA 的注意事項, 則 RFCEditor 將會刪除該章節(jié) (盡管, 在 RFC 發(fā)布前的互聯(lián)網(wǎng)草案 Internet-Draft階段確實需要這一章節(jié))。4.8.4. "國際化注意事項" (Internationalization Considerations) 章節(jié)所有處理國際化問題的 RFC 都應當包含這一章節(jié)來描述這些問題; 更多信息見"IETF Policy on Character Sets and Languages" [BCP18] 中的第 6 節(jié)。4.8.5. "安全注意事項" (Security Considerations) 章節(jié)所有的 RFC 都應當包含這一章節(jié), 來討論與該規(guī)范相關的安全注意事項。更多信息見 "Guidelines for Writing RFC Text on Security Considerations"[BCP72]。注意, 存在其它的樣文, 用于那些包含有 MIB 和 YANG 模塊的 RFC。詳細信息, 見 "Security Guidelines for IETF MIB Modules" [MIB-SEC] 和 "yangmodule security considerations" [YANG-SEC]。Flanagan & Ginoza Informational [Page 13]RFC 7322 RFC Style Guide September 20144.8.6. "參考文獻" (References) 章節(jié)參考文獻列表僅僅用于記錄參考項。不允許加入介紹性文本。RFC 樣式允許使用任何種類的引用樣式, 只要它們的使用在同一文檔中保持一致。但是, 在此 RFC 系列文檔的范圍內, 有一些已被描述過的引用樣式的使用是必要的。具體示例參見此文檔。RFC Editor 會確保: 引用其它 RFC 的參考文獻, 會引用相關主題的最新版的RFC (除非提供了不這樣做的理由)。當引用一個被廢除的文檔時, 通常也會引用其最新版本的文檔。如果一 RFC 被分配了一個 STD [RFC1311]、BCP [RFC1818]、或 FYI [FYI90]子系列編號 (sub-series number), 則參考文獻在引用它時, 必須包含該文檔的子系列編號。注意, FYI 系列的文檔已由 RFC 6360 終止。那些含有 FYI 子系列編號發(fā)布的、或依舊在維護 FYI 編號的 RFC, 必須在其參考文獻中包含該子系列編號。參考文獻列表必須要指明: 每一個參考文獻是前提類的 (normative) 還是信息類的 (informative), 其中前提類的參考文獻對實現(xiàn)或理解 RFC 的內容至關重要, 而信息類的參考文獻則提供了附加信息。關于前提類和信息類參考文獻的更多信息, 可以在 IESG 的聲明 "Normative and Informative References"[REFS] 中找到。當同時存在前提類和信息類的參考文獻時, 參考文獻章節(jié)應當被劃分為兩個子章節(jié):s. References s. 參考文獻s.1. Normative References s.1. 前提類參考文獻xxx xxx... ...xxx xxxs.2. Informative References s.2. 信息類參考文獻xxx xxx... ...xxx xxxFlanagan & Ginoza Informational [Page 14]RFC 7322 RFC Style Guide September 2014參考文獻通常按照引用標簽的字母數(shù)字的順序顯示。當只有前提類或信息類其中一種參考文獻時, 不需要劃分子章節(jié); 其頂級章節(jié)標題為 "前提類參考文獻"("Normative References") 或 "信息類參考文獻" ("InformativeReferences")。如果前提類參考文獻引用了互聯(lián)網(wǎng)草案, 則將會造成該 RFC 的發(fā)布被暫停, 直到被引用的草案也準備好發(fā)布為止; 然后, RFC Editor 將會更新相應條目, 以引用要發(fā)布的 RFC, 并同時發(fā)布兩個文檔。4.8.6.1. RFC 中的 URI允許在參考文獻中使用 URI, 只要該 URI 是非常穩(wěn)定的 (例, 不太可能更改,且預期持續(xù)可用), 且可以直接引用。在 RFC 編輯流程中, 將會驗證 URI 的有效性。如果對某網(wǎng)頁的引用, 有一可用的、且含有日期的 URI (包含有該頁面的時間戳), 則應當使用這種 URI。注意, URI 不應是為引用條目所提供的唯一信息。4.8.6.2. 引用 RFC要引用 RFC, 需要使用下面給出的格式。注意, 當對多名作者排序時: 列表中,列出的最后一名作者的姓名格式, 不同于所有在他前面列出的其他作者。對于一名作者或編輯者:[RFCXXXX] Last name, First initial., Ed. (if applicable),"RFC Title", Sub-series number (if applicable),RFC number, Date of publication,<http://www.rfc-editor.org/info/rfc#>.示例:[RFC3080] Rose, M., "The Blocks Extensible ExchangeProtocol Core", RFC 3080, March 2001,<http://www.rfc-editor.org/info/rfc3080>.Flanagan & Ginoza Informational [Page 15]RFC 7322 RFC Style Guide September 2014對于兩名作者或編輯者:[RFCXXXX] Last name, First initial., Ed. (if applicable)and First initial. Last name, Ed. (if applicable),"RFC Title", Sub-series number (if applicable),RFC number, Date of publication,<http://www.rfc-editor.org/info/rfc#>.示例:[RFC6323] Renker, G. and G. Fairhurst, "Sender RTTEstimate Option for the Datagram CongestionControl Protocol (DCCP)", RFC 6323, July 2011,<http://www.rfc-editor.org/info/rfc6323>.對于三名或更多的作者或編輯者:[RFCXXXX] Last name, First initial., Ed. (if applicable),Last name, First initial., Ed. (if applicable),and First initial. Last name, Ed. (if applicable),"RFC Title", Sub-series number (if applicable),RFC number, Date of publication,<http://www.rfc-editor.org/info/rfc#>.示例:[RFC6429] Bashyam, M., Jethanandani, M., and A. Ramaiah,"TCP Sender Clarification for PersistCondition", RFC 6429, December 2011,<http://www.rfc-editor.org/info/rfc6429>.4.8.6.3. 引用 STD 和 BCP互聯(lián)網(wǎng)標準 (Internet Standards, STDs) 和當前最佳實踐 (Best CurrentPractices, BCPs) 可能由一個或多個 RFC 組成。當引用包含多個 RFC 的 STD或 BCP 時, 該引用條目應當包括: 組成該子系列 (STD 或 BCP) 的所有 RFC。作者應當在文本中指出具體的 RFC 編號 (非引用形式), 并引用相應的子系列編號。推薦在參考文獻章節(jié)的引用中包含指向相應 STD 或 BCP 信息頁的 URI(見 [RFC5741] 中的第 3.2.3 節(jié))。文本中的引用應如下所示。See RFC 1034 [STD13].Flanagan & Ginoza Informational [Page 16]RFC 7322 RFC Style Guide September 2014對于包含有一個 RFC 的 STD 或 BCP:[STDXXX] Last name, First initial., Ed. (if applicable),"RFC Title", Sub-series number, RFC number, Date ofpublication, <http://www.rfc-editor.org/info/std#>.示例:[STD72] Gellens, R. and J. Klensin, "Message Submissionfor Mail", STD 72, RFC 6409, November 2011,<http://www.rfc-editor.org/info/std72>.對于包含有兩個或更多 RFC 的 STD 或 BCP:[STDXXX] Last name, First initial., Ed. (if applicable),"RFC Title", Sub-series number, RFC number, Date ofpublication.Last name, First initial., Ed. (if applicable)and First initial. Last name, Ed. (if applicable),"RFC Title", Sub-series number, RFC number, Date ofpublication.<http://www.rfc-editor.org/info/std#>示例:[STD13] Mockapetris, P., "Domain names - concepts andfacilities", STD 13, RFC 1034, November 1987.Mockapetris, P., "Domain names - implementation andspecification", STD 13, RFC 1035, November 1987.<http://www.rfc-editor.org/info/std13>4.8.6.4. 引用互聯(lián)網(wǎng)草案 (Internet-Drafts)對互聯(lián)網(wǎng)草案 (Internet-Draft) 的引用只能作為信息類參考文獻出現(xiàn)。鑒于可能會在短時間內對一個 I-D 進行多次修訂, 對其的引用必須包括: 發(fā)布日期(月和年)、完整的互聯(lián)網(wǎng)草案文件名 (包括版本號)、及短語 "Work inProgress"。作者可以引用一個 I-D 的多個版本。如果被引用的 I-D 后來作為RFC 被發(fā)布, 則該 RFC 也必須被列出。Flanagan & Ginoza Informational [Page 17]RFC 7322 RFC Style Guide September 2014[SYMBOLIC-TAG] Last name, First initial., Ed. (if applicable)and First initial. Last name, Ed. (ifapplicable), "I-D Title", Work in Progress,draft-string-NN, Month Year.示例:[RFC-STYLE] Flanagan, H. and S. Ginoza, "RFC Style Guide",Work in Progress, draft-flanagan-style-01,June 2013.4.8.6.5. 引用勘誤 (Errata)當需要引用一個勘誤報告時, 要求使用下面的格式:[ErrNumber] RFC Errata, Erratum ID number, RFC number.[Err1912] RFC Errata, Erratum ID 1912, RFC 2978.4.8.6.6. 引用其它標準開發(fā)組織當引用來自其它標準開發(fā)組織 (Standards Development Organization, SDO)的文檔或標準時, 在參考文獻的作者列表處, 應當使用下面的格式:[SYMBOLIC-TAG]Last name, First initial. and First initial. Last name,"Document Title", Document reference number, Date ofpublication, <URI if available>.[W3C.REC-xml11]Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E.,Yergeau, F., and J. Cowan, "Extensible Markup Language(XML) 1.1 (Second Edition)", W3C RecommendationREC-xml11-20060816, August 2006,<http://www.w3.org/TR/2006/REC-xml11-20060816>.注意, 列表中的作者的順序, 應與真實文檔中顯示的順序相同, 并使用與 SDO相同的縮寫形式。Flanagan & Ginoza Informational [Page 18]RFC 7322 RFC Style Guide September 2014或者, 當沒有作者列表時, 推薦使用下面的格式:[SYMBOLIC-TAG] Organization, "Document Title", Documentreference number, Date of publication,<URI if available>.示例:[IEEE802.1Q] IEEE, "Local and Metropolitan AreaNetworks -- Media Access Control (MAC)Bridges and Virtual Bridged Local AreaNetworks", IEEE Std 802.1Q-2011, August 2011,<http://standards.ieee.org/findstds/standard/802.1Q-2011.html>.4.9. "附錄" (Appendices) 章節(jié)RFC Editor 建議將 "參考文獻" 章節(jié)放在 "附錄" 章節(jié)之前。"附錄" 章節(jié)應當被標記為 "Appendix A. Title"、"A.1. Title"、"Appendix B. Title"等形式。4.10. "致謝" (Acknowledgements) 章節(jié)此可選章節(jié)可以用來代替、或補充 "貢獻者" (Contributors) 章節(jié)。作者經(jīng)常使用它來: 公開感謝那些對文檔提供反饋的人員、及注明在文本中所借鑒過的任何文檔。4.11. "貢獻者" (Contributors) 章節(jié)此可選章節(jié)用于感謝那些對文檔作出重要貢獻的人員。與 "作者地址" (Author's Address) 章節(jié)類似, RFC Editor 不會決定誰應當被列為 RFC 的貢獻者。誰應當被列為貢獻者, 是由發(fā)布流決定的。"貢獻者" 章節(jié)可以包含關于特定的貢獻內容的簡短陳述 ("Sam contributedSection 3")、及可以包含所列出的貢獻者的所屬機構。根據(jù)作者的判斷, "貢獻者" 章節(jié)中也可以包含貢獻者的通訊地址; 因為在將來獲取 RFC 相關的信息時, 他們的學識可能會很有用。任何通訊信息的格式應當與 "作者地址" 章節(jié)的信息格式類似。Flanagan & Ginoza Informational [Page 19]RFC 7322 RFC Style Guide September 20144.12. "作者地址" ("Author's Address" 或 "Authors' Addresses") 章節(jié)此必須章節(jié)給出了在首頁頁頭中列出的作者的通訊信息。通訊信息中包括一個必須的長期有效的電子郵件地址, 及可選的郵政地址和/或電話號碼。如果包括了一個郵政地址, 地址中應當包含國家名稱, 該名稱采用由 ISO 3166 Maintenance Agency [ISO_OBP] 所列出的英文縮寫。此章節(jié)的目的是: (1) 明確定義作者身份 (例如, the John Smith who works for FooBarSystems); (2) 為將來有疑問或意見的讀者提供通訊信息。偽裝郵件地址的做法 (即, 更改電子郵件地址以降低機器人和網(wǎng)絡爬蟲程序的可讀性, 從而避免垃圾郵件) 在歸檔的文檔系列中是不合適的。提供作者的通訊信息, 為的是讀者能夠方便地聯(lián)系到作者, 并提出疑問和/或意見。在 RFC中不允許偽裝郵件地址。5. 安全注意事項此文檔沒有關于安全的注意事項。6. 參考文獻6.1. 前提類參考文獻[STYLE-WEB]RFC Editor, "Web Portion of the Style Guide",<http://www.rfc-editor.org/rfc-style-guide/part2.html>.6.2. 信息類參考文獻[ABBR] RFC Editor Abbreviations List,<http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt>.[BCP14] Bradner, S., "Key words for use in RFCs to IndicateRequirement Levels", BCP 14, RFC 2119, March 1997,<http://www.rfc-editor.org/info/bcp14>.[BCP18] Alvestrand, H., "IETF Policy on Character Sets andLanguages", BCP 18, RFC 2277, January 1998,<http://www.rfc-editor.org/info/bcp18>.Flanagan & Ginoza Informational [Page 20]RFC 7322 RFC Style Guide September 2014[BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing anIANA Considerations Section in RFCs", BCP 26, RFC 5226,May 2008, <http://www.rfc-editor.org/info/bcp26>.[BCP32] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNSNames", BCP 32, RFC 2606, June 1999,<http://www.rfc-editor.org/info/bcp32>.[BCP72] Rescorla, E. and B. Korver, "Guidelines for Writing RFCText on Security Considerations", BCP 72, RFC 3552,July 2003, <http://www.rfc-editor.org/info/bcp72>.[CLUSTER] RFC Editor, "Clusters in the RFC Editor Queue",<http://www.rfc-editor.org/cluster_def.html>.[CMOS] Chicago Manual of Style, 16th ed. Chicago: University ofChicago Press, 2010.[FYI90] Malkin, G. and J. Reynolds, "FYI on FYI: Introduction tothe FYI Notes", FYI Notes, RFC 1150, March 1990.Housley, R., "Conclusion of FYI RFC Sub-Series", RFC 6360,August 2011.[IAB-FORM] IAB, "Format for RFCs in the IAB Stream",<http://www.rfc-editor.org/rfc-style-guide/iab-format.txt>.[ID-GUIDE] IETF, "Guidelines to Authors of Internet Drafts",<http://www.ietf.org/ietf-ftp/1id-guidelines.txt>.[IETF-TRUST]IETF Trust, "Trust Legal Provisions (TLP)",<http://trustee.ietf.org/license-info/>.[ISO_OBP] ISO, "Online Browsing Platform (OBP)",<https://www.iso.org/obp/ui/>.[ISO3297] Technical Committee ISO/TC 46, Information anddocumentation, Subcommittee SC 9, Identification anddescription, "Information and documentation -International standard serial number (ISSN)",September 2007.[MIB-BOILER]IETF OPS Area, "Boilerplate for IETF MIB Documents",<http://www.ops.ietf.org/mib-boilerplate.html>.Flanagan & Ginoza Informational [Page 21]RFC 7322 RFC Style Guide September 2014[MIB-SEC] IETF OPS Area, "Security Guidelines for IETF MIB Modules",<http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security>.[REFS] IESG, "IESG Statement: Normative and InformativeReferences", <http://www.ietf.org/iesg/statement/normative-informative.html>.[RFC1311] Postel, J., "Introduction to the STD Notes", RFC 1311,March 1992, <http://www.rfc-editor.org/info/rfc1311>.[RFC1818] Postel, J., Li, T., and Y. Rekhter, "Best CurrentPractices", RFC 1818, August 1995,<http://www.rfc-editor.org/info/rfc1818>.[RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors",RFC 2223, October 1997, <http://www.rfc-editor.org/info/rfc2223>.[RFC2223bis]Reynolds, J., Ed. and B. Braden, Ed. "Instructions toRequest for Comments (RFC) Authors", Work in Progress,draft-rfc-editor-rfc2223bis-08, August 2004.[RFC4844] Daigle, L., Ed., and Internet Architecture Board, "The RFCSeries and RFC Editor", RFC 4844, July 2007,<http://www.rfc-editor.org/info/rfc4844>.[RFC5741] Daigle, L., Ed., Kolkman, O., Ed., and IAB, "RFC Streams,Headers, and Boilerplates", RFC 5741, December 2009,<http://www.rfc-editor.org/info/rfc5741>.[RFC6635] Kolkman, O., Ed., Halpern, J., Ed., and IAB, "RFC EditorModel (Version 2)", RFC 6635, June 2012,<http://www.rfc-editor.org/info/rfc6635>.[STD66] Berners-Lee, T., Fielding, R., and L. Masinter, "UniformResource Identifier (URI): Generic Syntax", STD 66,RFC 3986, January 2005, <http://www.rfc-editor.org/info/std66>.[TERMS] RFC Editor, "Terms List",<http://www.rfc-editor.org/styleguide.html>.[YANG-SEC] IETF OPS Area, "yang module security considerations",<http://trac.tools.ietf.org/area/ops/trac/wiki/yang-security-guidelines>.Flanagan & Ginoza Informational [Page 22]RFC 7322 RFC Style Guide September 2014附錄 A. Related ProceduresThe following procedures are related to the application and updatingof the RFC Style Guide.A.1. Dispute ResolutionThere are competing rationales for some of the rules described inthis Guide, and the RFC Editor has selected the ones that work bestfor the Series. However, at times, an author may have a disagreementwith the RFC Production Center (RPC) over the application of StyleGuide conventions. In such cases, the authors should discuss theirconcerns with the RPC. If no agreement can be reached between theRPC and the authors, the RFC Series Editor will, with input from theappropriate stream-approving body, make a final determination. Iffurther resolution is required, the dispute resolution process asdescribed in the RFC Editor Model [RFC6635] will be followed.A.2. Returning an I-D to the Document StreamFor a given document, if the RFC Editor determines that it cannot beedited without serious risk of altering the meaning of the technicalcontent or if the RFC Editor does not have the resources to providethe level of editing it needs, it may be sent back to the stream-approving body with a request to improve the clarity, consistency,and/or readability of the document. This is not to be considered adispute with the author.A.3. Revising This Document and Associated Web PagesThe RFC Series is continually evolving as a document series. Thisdocument focuses on the fundamental and stable requirements that mustbe met by an RFC. From time to time, the RFC Editor may offer lessformal recommendations that authors may apply at their discretion;these recommendations may be found on the RFC Editor website"Guidelines for RFC Style" [STYLE-WEB].When a new recommendation is made regarding the overall structure andformatting of RFCs, it will be published on that page and acceptedfor a period of time before the RFC Editor determines whether itshould become part of the fundamental requirements in the RFC StyleGuide or remain as a less formal recommendation. That period of timewill vary, in part depending on the frequency with which authorsencounter and apply the guidance.Flanagan & Ginoza Informational [Page 23]RFC 7322 RFC Style Guide September 2014IAB Members at the Time of ApprovalJari Arkko (IETF Chair)Mary BarnesMarc BlanchetJoel HalpernTed HardieJoe HildebrandRuss HousleyEliot LearXing LiErik NordmarkAndrew SullivanDave ThalerBrian Trammell致謝This document refers heavily to RFC 2223 [RFC2223] and[RFC2223bis]; as such, we are grateful to the authors of thosedocuments for putting their time and effort into the RFC Series.Robert T. BradenUSC Information Sciences InstituteJoyce ReynoldsJon Postel貢獻者Alice RussoRFC Production Center作者地址Heather FlanaganRFC Series EditorEMail: rse@rfc-editor.orgSandy GinozaRFC Production CenterEMail: rfc-editor@rfc-editor.orgFlanagan & Ginoza Informational [Page 24]

總結

以上是生活随笔為你收集整理的翻译 RFC 7322: RFC 样式指南的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。