編譯自： https://opensource.com/article/18/7/requests-for-comments-to-know
以及 3 個有趣的 RFC。
閱讀源碼是開源軟件的重要組成部分。這意味著用戶可以查看代碼並瞭解做了什麼。
但“閱讀源碼”並不僅適用於代碼。理解代碼實現的標準同樣重要。這些標準編寫在由 互聯網工程任務組 (Internet Engineering Task Force)（IETF）發佈的稱為“ 意見徵集(Requests for Comment)”（RFC）的文檔中。多年來已經發布了數以千計的 RFC，因此我們收集了一些我們的貢獻者認為必讀的內容。
6 個必讀的 RFC
RFC 2119 - 在 RFC 中用於指示需求級別的關鍵字
這是一個快速閱讀，但它對了解其它 RFC 非常重要。 RFC 2119 定義了後續 RFC 中使用的需求級別。 “MAY” 究竟意味著什麼？如果標準說 “SHOULD”，你真的必須這樣做嗎？通過為需求提供明確定義的分類，RFC 2119 有助於避免歧義。
RFC 3339 - 互聯網上的日期和時間：時間戳
時間是全世界程序員的禍根。 RFC 3339 定義瞭如何格式化時間戳。基於 ISO 8601 標準，3339 為我們提供了一種表達時間的常用方法。例如，像星期幾這樣的冗餘信息不應該包含在存儲的時間戳中，因為它很容易計算。
RFC 1918 - 私有互聯網的地址分配
有屬於每個人的互聯網，也有隻屬於你的互聯網。私有網絡一直在使用， RFC 1918 定義了這些網絡。當然，你可以在路由器上設置在內部使用公網地址，但這是一個壞主意。或者，你可以將未使用的公共 IP 地址視為內部網絡。在任何一種情況下都表明你從未閱讀過 RFC 1918。
RFC 1912 - 常見的 DNS 操作和配置錯誤
一切都是 #@%@ 的 DNS 問題，對吧？ RFC 1912 列出了管理員在試圖保持互聯網運行時所犯的錯誤。雖然它是在 1996 年發佈的，但 DNS（以及人們犯的錯誤）並沒有真正改變這麼多。為了理解我們為什麼首先需要 DNS，如今我們再來看看 RFC 289 - 我們希望正式的主機列表是什麼樣子的 就知道了。
RFC 2822 — 互聯網郵件格式
想想你知道什麼是有效的電子郵件地址麼？如果你知道有多少個站點不接受我郵件地址中 “+” 的話，你就知道你知道不知道了。 RFC 2822 定義了有效的電子郵件地址。它還詳細介紹了電子郵件的其餘部分。
RFC 7231 - 超文本傳輸協議（HTTP/1.1）：語義和內容
想想看，幾乎我們在網上做的一切都依賴於 HTTP。 RFC 7231 是該協議的最新更新。它有超過 100 頁，定義了方法、請求頭和狀態代碼。
3 個應該閱讀的 RFC
好吧，並非每個 RFC 都是嚴肅的。
RFC 1149 - 在禽類載體上傳輸 IP 數據報的標準
網絡以多種不同方式傳遞數據包。 RFC 1149 描述了鴿子載體的使用。當我距離州際高速公路一英里以外時，它們的可靠性不會低於我的移動提供商。
RFC 2324 — 超文本咖啡壺控制協議（HTCPCP/1.0）
咖啡對於完成工作非常重要，當然，我們需要一個用於管理咖啡壺的程序化界面。 RFC 2324 定義了一個用於與咖啡壺交互的協議，並添加了 HTTP 418（“我是一個茶壺”）。
RFC 69 — M.I.T.的分發列表更改
RFC 69 是否是第一個誤導取消訂閱請求的發佈示例？
你必須閱讀的 RFC 是什麼（無論它們是否嚴肅）？在評論中分享你的列表。
via: https://opensource.com/article/18/7/requests-for-comments-to-know
作者： Ben Cotton 選題： lujun9972 譯者： geekpi 校對： wxy
本文由 LCTT 原創編譯， Linux中國 榮譽推出
閱讀更多 Linux中國 的文章
