---
tags: 技術文章, RFC
GA: UA-79596126-4
title: 如何閱讀 RFC 文件
---
###### 作者: 大叔
###### 撰寫日期：2020/05/08
{%hackmd BJrTq20hE %}

# 如何閱讀 RFC 文件
可參考這篇文章 [How to Read an RFC](https://www.mnot.net/blog/2018/07/31/read_rfc)。

首先要先知道什麼是 RFC 文件，RFC (Request for Comments: 請求意見稿) 是由網際網路工程任務組 (IETF) 發布的一系列備忘錄。檔案收集了有關網際網路相關資訊，以及UNIX和網際網路社群的軟體檔案，以編號排定。只要是與通訊協議相關的工程師應該都無法避免閱讀 RFC 文件，但這些文件並不是這麼容易閱讀，這篇文章主要敘述如何快速上手閱讀 RFC。

### 找尋 RFC 文件
想要找 RFC 文件，可以從一些網站上尋找，像是 [RFC Editor](https://www.rfc-editor.org/) 、 [IETF Tools](https://tools.ietf.org/) 等。另一種方式是使用 [EveryRFC](https://rfc.fyi/) ，可以使用關鍵字與標籤分類來查詢 RFC 。

### RFC Banner
每個 RFC 文件上頭都有一塊橫幅，類似於下方這樣：

Internet Engineering Task Force (IETF)                  R. Fielding, Ed.
Request for Comments: 7230                                         Adobe
Obsoletes: 2145, 2616                                    J. Reschke, Ed.
Updates: 2817, 2818                                           greenbytes
Category: Standards Track                                      June 2014
ISSN: 2070-1721

首先先看第一行，寫著 Internet Engineering Task Force (IETF) ，這代表這個 RFC 文件是由 IETF 所發布的，也有其他的發布管道，但是只有 IETF 的發布管道才表示 IETF 對該協議的規範進行了審核並達成共識。然而年代久遠的 RFC ( ```RFC 5705``` 之前 ) 上頭寫著 Network Working Group，這些文件需要更進一步去看 IETF 有沒有認可這份文件，可以從 ```Status of this Memo``` 這個部份來判定。

接著往下看會看到 Request for Comments ，也就是這份 RFC 文件的編號。如果這一欄寫者 Internet-Draft 的話，則表示這份文件並不是一個 RFC 文件，只是個提議而已，並不意味已經被 IETF 採用。

Category 指的是這份文件的分類，可分為 ```Standard Track``` 、 ```Informational``` 、 ```Experimental``` 、 ```Best Current Practice``` 等。要注意的地方是 ```Informational``` 與 ```Experimental``` 並不屬於標準。

最後在最右邊的是文件的作者，與學術文章不同，這邊並不是列出對這份文件貢獻人員，而是撰寫這份 RFC 文件的人。貢獻人員會放到文件最後 Acknowledgets 章節這邊。

RFC 是一種存檔系列的文件，確定了就不能更動，那怕只是一個字，像是 ```RFC 7158``` 與 ```RFC 7159``` 由於年份搞錯而在發布一篇。要如何知道當前 RFC 文件是否為最新版可以從 Obsoletes 與 Updates 得知。 Obsoletes 代表這份文件取代了哪些文件，應該要使用當前文件而不是那些被取代的文件。 Updates 列出了哪些文件被更新成這份文件，主要的意思是當你在閱讀這份 RFC 文件時也應該閱讀那些文件。由於 RFC 文件只會紀錄當前文件更新或淘汰了哪些文件，並不會記錄這份文件"被"哪些文件更新或淘汰，這時可以用一些工具像是 [IETF Tools](https://tools.ietf.org/) 會在頂部幫你標註連結那些文件。

即使最新的文件也可能會有錯誤，而 [IETF Tools](https://tools.ietf.org/) 在頂部的右側可以看到 ```Errata Exist``` ，上頭有 ```Errata``` 的連結可以看到相關訊息。```Errata``` 是關於這份文件的糾正與澄清，但還不到可以重新發布一個新的 RFC 文件的程度，但還是有一定的影響，值得去看。

### 解讀 RFC
幾乎所有的 RFC 文件都有一個樣板

舊版：
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119].

新版：
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.

舊版的定義在 ```RFC 2119```，而新版的定義在 ```RFC 8174```，而新舊版的定義只差在 ```NOT RECOMMENDED``` ，也就是 ```RFC 2119``` 有定義到 ```NOT RECOMMENDED``` 但並沒有寫到樣板中。這些關鍵字主要是在幫助理解 RFC 文件，那些事是"必須"的那些是"建議要做"的，詳情如下：

* ```MUST```：此關鍵字的等級最高，代表這一定需要，也可以使用 ```REQUIRED``` 、 ```SHALL```，等級與 "MUST" 一樣。

* ```MUST NOT```：此關鍵字與 ```MUST``` 等級相同，但意思與 ```MUST``` 相反，也可使用 ```SHALL NOT``` 代替。

* ```SHOULD```：此關鍵字等級低於 ```MUST``` ，代表希望這樣做，但不強制，可以用 ```RECOMMENDED``` 代替。

* ```SHOULD NOT```：此關鍵字與 ```SHOULD``` 同等，意思與 ```SHOULD``` 相反，可用 ```NOT RECOMMENDED``` 代替。

* ```MAY```：強制力最低，主要代表這是可選擇的項目，有沒有支援都無關，可用 ```OPTIONAL``` 替代。

### 安全議題
自從 ```RFC 3552``` 發布後， RFC 的樣板出現了 "Security Considerations" 的章節。之後的 RFC 文件幾乎都有探討關於安全的議題，審核過程中也不允許任何一份文件標註說該協議不須考慮安全性方面的問題。所以建議要閱讀這個章節，不然在實現或部屬這個通訊協議時有可能會翻車。