[譯] 如何閱讀 RFC 文檔

原文：How to Read an RFC
做者：Mark Nottingham 發表時間：31 July 2018
譯者：西樓聽雨 發表時間： 2018/11/19 (轉載請註明出處)

For better or worse, Requests for Comments (RFCs) are how we specify many protocols on the Internet. These documents are alternatively treated as holy texts by developers who parse them for hidden meanings, then shunned as irrelevant because they can’t be understood. This often leads to frustration and – more significantly – interoperability and security issues.

不論好壞，互聯網上的許多協議都是經過 Requests for Comments (RFC) 來規範的。開發人員在分析這些文本的含義時會把其當作像聖經同樣，而後就會刻意迴避，由於他們沒法理解這些文本。這樣經常就會產生挫敗感，更嚴重的是會出現交流障礙和安全性問題。

However, with some insight into how they’re constructed and published, it’s a bit easier to understand what you’re looking at. Here’s my take, informed from my experiences with HTTP and a few other things.

雖然如此，若是對他們的構建和發佈方式進行必定了解的話，其實要理解你所看到的東西也是比較容易的。下面就是個人心得，主要來自我在 HTTP 和其餘一些東西上的經驗。

從什麼地方開始

The canonical place to find RFCs is the RFC Editor Web Site. However, as we’ll see below, some key information is missing there, so most people use tools.ietf.org.

找尋 RFC 規範，權威的渠道就是 RFC Editor 網站。但就像下面咱們會將看到的那樣，這個網站缺失了一些信息，因此大多數人會選擇使用 tools.ietf.org。

Even finding the right RFC can be difficult since there are so many (currently, nearly 9,000!). Obviously you can find them with general Web search engines, and the RFC Editor has an excellent search facility on their site.

由於 RFC 文檔量多（目前接近9000！），因此要找到所需的 RFC 是比較困難的。不過你固然能夠經過網絡搜索引擎來找尋，以及 RFC Editor 網站的搜索設施來找尋。

Another option is EveryRFC, which I put together to allow searching RFCs by their titles and keywords, and exploration by tags.

另一種途徑是 EveryRFC 網站，這個網站容許你經過 RFC 的標題和關鍵字來查找，以及經過標籤分類來導航。

It’s no secret that plain text RFCs are difficult to read bordering on ugly, but things are about to improve; the RFC Editor is wrapping up a new RFC format, with much more pleasing presentation and the option for customisation. In the meantime, if you want more usable RFCs, you can use third-party repositories for selected ones; for example, greenbytes keeps a list of WebDAV-related RFCs, and the HTTP Working Group maintains a selection of those related to HTTP.

你們都知道閱讀近乎醜陋的純文本 RFC 是比較困難，不過幸虧事情正在好轉——RFC Editor 網站正在用一種新的 RFC 格式來進行包裝，這種新的格式的展現方式更加使人舒服，並提供了自定義的選項。另外，若是你想找到更有用的 RFC ，可使用第三方的倉庫；例如，greenbytes 上就保有一份 WebDAV 相關的 RFC 列表，HTTP Working Group 也維護了一份 HTTP 相關的文檔。

RFC 的類型是什麼？

All RFCs have a banner at the top that looks something like this:

全部 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
複製代碼

At the top left, this one says 「Internet Engineering Task Force (IETF)」. That indicates that this is a product of the IETF; although it’s not widely known, there are other ways to publish an RFC that don’t require IETF consensus; for example, the independent stream.

最頂部的左側，寫着「Internet Engineering Task Force (IETF) 」，意思是說這是 IETF (因特網工程任務組) 組織的做品。雖然不廣爲人知，但其實除此以外還有其餘的方式能夠發佈一份 RFC，例如，獨立發佈流。

In fact, there are a number of 「streams」 that a document can be published on. Only the IETF stream indicates that the entire IETF has reviewed and has declared consensus on a protocol’s specification.

其實還有許多的「發佈流」。只有 IETF 的發佈流才表示 IETF 組織對該協議的規範進行了審覈並達成了共識。

Older documents (before about RFC5705) say 「Network Working Group」 there, so you have to dig a bit more to find out whether they represent IETF consensus; look at the 「Status of this Memo」 section for a start, as well as the RFC Editor site.

年代較遠的文檔（RFC5705以前的那些）寫着的是「Network Working Group」，因此你須要更一步發掘看看是否他們表明了 IETF 的共識；關於這一點，咱們能夠把「Status of this Memo」做爲切入點，還有 RFC Editor 網站。

Under that is the 「Request for Comments」 number. If it says 「Internet-Draft」 instead, it’s not an RFC; it’s just a proposal, and anyone can write one. Just because something is an Internet-Draft doesn’t mean it’ll ever be adopted by the IETF.

再接着往下則是「Request for Comments」編號。若是這一欄寫着「Internet-Draft」，則表示這個文檔並非一個 RFC 文檔，它只是一份提議而已，任何人均可以寫一份，由於 Internet-Draft 並不意味着它已經被 IETF 所採用。

Category is one of 「Standards Track」, 「Informational」, 「Experimental」, or 「Best Current Practice」. The distinctions between these are sometimes fuzzy, but if it’s produced by the IETF (see above), it’s had a reasonable amount of review. However, note that Informational and Experimental are not standards, even if there’s IETF consensus to publish.

Category（目錄）分爲「Standard Track」（標準）、「Informational」（信息性的）、「Experimental」（實驗性的）、「Best Current Practice」（當前最佳實踐）。它們之間的區別有時候比較模糊，但能夠確信的是，若是是由 IETF 製做的，確定通過了大量的審覈。不過要注意，Informational 和 Experiment 並不屬於標準，即使是通過 IETF 批准發佈的。

Finally, the authors of the document are listed on the right side of the header. Unlike in academia, this is not a comprehensive list of who contributed to the document; often, that’s done near the bottom in an 「Acknowledgments」 section. In RFCs, this is literally 「who wrote the document.」 Often, you’ll see 「Ed.」 appended, which indicates that they were acting as an editor, often because the text was pre-existing (like when an RFC is revised).

最後，列在「橫幅」右邊的是這個文檔的做者。和學術文章不同，這個列表列出的並非對這份文檔作出了貢獻的人員列表，在 RFC 中，這塊信息位於文檔尾部的「Acknowledgets (鳴謝)」一節；在 RFC 中，表示的只是「文檔是誰寫的」。

如何肯定是否爲最新版本？

RFCs are an archival series of documents; they can’t change, even by one character (see the diff between RFC7158 and RFC7159 for an example of this taken to the extreme; they got the year wrong ;).

RFC 是一種存檔性質的系列文檔，肯定了就不能變更，哪怕只是一個字符（見RFC7158 和 RFC7159 以前的比較這個極端的例子——他們把年份搞錯了）。

As a result, it’s important to know that you’re looking at the right document. The header contains a couple of bits of metadata that help here:

因此，知道你如今正在查看的是否找對了是很是重要的。這一點從文檔的頂部所包含的一些元信息中能夠得到一些幫助：

• Obsoletes: lists the RFCs that this document completely replaces; i.e., you should be using this document, not that one. Note that an old version of a protocol isn’t necessarily obsoleted when a newer one comes out; for example, HTTP/2 doesn’t obsolete HTTP/1.1, because it’s still legitimate (and necessary) to implement the older protocol. However, RFC7230 did obsolete RFC2616, because it’s the reference for that protocol.

  列出了被這個文檔所完全取代的 RFC 。它說的是，你應該使用當前的這個文檔，而不是這些。注意：老版本的協議不必定就會被新版本的取代；例如，HTTP/2 並無淘汰 HTTP/1.1，由於它仍然是合法的（且是必要的），不過 RFC7230 淘汰了 RFC2616，由於他是那個協議的一個引用。

• Updates：lists the RFCs that this document makes substantive changes to; in other words, if you’re reading that other document, you should probably read this one too.

  列出了被這個文檔實質性更新到的 RFC。意思就是說，若是你閱讀這些文檔，那麼同時也應該閱讀這個。

Unfortunately, the ASCII text RFCs (e.g., at the RFC Editor site) don’t tell you what documents update or obsolete the document you’re currently looking at. This is why most people use the RFC repository at tools.ietf.org, which puts this information in a banner like this:

不過遺憾的時，RFC 的純文本展現版本（如 RFC Editor 網站上的文檔）不會給出哪些文檔對你正在閱讀的這個文檔形成了更新或者淘汰。這也是爲何許多人寧願使用 tools.ietf.org 網站上的 RFC 文檔庫，由於它會在文檔頂部給出這塊信息，就像這樣：

[Docs] [txt|pdf] [draft-ietf-http...] [Tracker] [Diff1] [Diff2] [Errata]

Obsoleted by: 7230, 7231, 7232, 7233, 7234, 7235          DRAFT STANDARD
Updated by: 2817, 5785, 6266, 6585                          Errata Exist
複製代碼

Each of the numbers on the tools page is a link, so you can easily find the current document.

上面這些數字都是一個連接，因此你能夠輕易找到目前最新的文檔。

Even the most current RFC often has issues. In the tools banner, you’ll also see a warning on the right that 「Errata Exist」 along with a link to Errata above it.

即使是最新的 RFC 文檔也常存在錯漏，因此在這個工具欄的右側你還能夠看到一個「Errata Exsit (存在勘誤)」的字樣，在其上面則是關於勘誤信息的連接。

Errata are corrections and clarifications to the document that aren’t worthy of publishing a new RFC. Sometimes they can have a substantial impact on how the RFC is implemented (for example, if a bug in the spec led to a significant misinterpretation), so they’re worth going through.

Errata 是一些關於這個文檔的糾正和澄清，但還沒到值得從新發佈一個新的 RFC 的程度。不過有個時候他們會對 RFC 規範的實現形成必定影響（例如，這個規範中存在一個 bug，就會產生嚴重的誤解），因此這仍是值得一覽的。

For example, here are the errata for RFC7230. When reading errata, keep their status in mind; many are rejected because someone just misread the spec.

舉個例子，這是 RFC7230 的勘誤列表。在閱讀時要留意他們的狀態，許多的沒被採納的實際上是由於人們的誤解。

理解上下文

It’s more common than you might think for a developer to look at a statement in an RFC, implement what they see, and do the opposite of what the authors intended.

開發人員在查看了 RFC 中的某條語句後，在實現他們所看到的時，違背規範做者的用意的狀況，會比你想象的還要廣泛。

This is because it’s extremely difficult to write a specification in a manner that can’t be misinterpreted when reading it selectively (as is the case with any holy text).

這是由於要寫出一份在選擇性閱讀的狀況下不會產生誤解的規範是極端困難的（就像任何聖經中的語句同樣）。

As a result, it’s necessary to read not only the directly relevant text but also (at a minimum) anything that it references, whether that’s in the same spec or a different one. In a pinch, reading any potentially related sections will help immensely, if you can’t read the whole document.

所以，不僅是要閱讀直接相關的那些文本，還要閱讀它所引用的文本，無論引用的是規範以內的，仍是其餘規範的。在比較趕的狀況下，若是不能把整個文檔讀一遍，那麼把那些可能相關的段落都閱讀一遍會有極大的幫助。

For example, HTTP message headers are defined to be separated by CRLF, but if you skip down here, you’ll see that 「a recipient MAY recognize a single LF as a line terminator and ignore any preceding CR.」 Obvious, right?

例如，HTTP 的消息頭定義中使用的是以 CRLF 進行分割，但若是往下看到這的話，你會看到「a recipient MAY recognize a single LF as a line terminator and ignore any preceding CR.（接收方能夠用單個 LF 字符做爲行結束符並忽略緊接在它以前的 CR）」這樣一句話，顯然這也是對的？

It’s also important to keep in mind that many protocols set up IANA registries to manage their extension points; these, not the specifications, are the sources of truth. For example, the canonical list of HTTP methods is in this registry, not any of the HTTP specifications.

另一個也比較重要的點是，許多協議都設有 IANA 註冊表用於管理他們自己的可擴展點，這些纔是實際的事實，而不是規範文檔。例如，HTTP 方法列表的權威位於這個註冊表中，而不是什麼 HTTP 規範。

解讀規則文本

Almost all RFCs have boilerplate that looks something like this near the top:

幾乎全部 RFC 文檔的頂部附近都有一段像下面這樣的模板式文本：

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.
複製代碼

These RFC2119 keywords help define interoperability, but they also sometimes confuse developers. It’s very common to see a specification say something like:

RFC2119 定義的這些關鍵字有助於交流，但有時候也會給開發人員帶來困惑。常常會在規範中看到下面這樣的話：

The Foo message MUST NOT contain a Bar header.
Foo 消息**必定**不能包含 Bar 消息頭。
複製代碼

This requirement is placed upon a protocol artefact, the」 Foo message」. If you’re sending one, it’s pretty clear it needs to not contain a Bar header; if you include one, it won’t be a conformant message.

這個要求描述的是協議中的一條消息，即「Foo 消息」。若是你發要出這樣一條消息，它說的很明確，不須要包含 Bar 消息頭；若是你包含了，那就不是一條符合規範的消息。

However, the behaviour of the recipient is much less clear; if you see a Foo message with a Bar header, what do you do?

不過，對於消息的接收方來講，它就沒有明確說明；假如你收到了一條帶有 Bar 消息頭的 Foo 消息，你該怎麼作呢？

Some developers will reject a message that contains it, even though the specification says nothing about doing so. Others will still process the message, but strip the Bar header, or ignore it – even when the spec explicitly says that all headers need to be processed.

某些開發人員會選擇拒絕這樣一條消息——雖然規範文檔中沒有對該採起什麼動做有明確規定；另一些開發人員則會選擇繼續處理這條消息，但會先把 Bar 消息頭剔除掉，或者忽視掉——即使規範文檔明確說明了全部的消息頭都須要進行處理。

All of these things can – unintentionally – cause interoperability issues. The correct thing to do is to follow normal processing for the header unless there’s a specific requirement to the contrary.

以上所述的這些就可能形成預料以外的消息交流問題。正確的作法應該是遵循正常的消息頭處理規則，除非規範中有特別說明。

That’s because in general, specifications are written so that behaviours are overtly specified; in other words, everything that is not explicitly disallowed is allowed. Therefore, reading too much into specifications can unintentionally cause harm, since you’ll be introducing new behaviours that others will have to work around.

這是由於，規範定義的比較寬泛的話，行爲就會比較寬泛；言外之意就是說，全部沒有明確說明不容許作的事情都是容許的。所以，越是對規範解讀的過多就越可能發生意外的影響，由於這樣你會傾向於引入更多的行爲，而這樣其餘人就須要想辦法避開這些行爲。

In an ideal world, the specification would be defined in terms of the behaviours of those who handle the message, like this:

理想而狀況是，規範爲文檔在作定義時都是以處理這些消息的人的行爲角度來的，就像這樣：

Senders of the Foo message MUST NOT include a Bar header. Recipients
of a Foo message that includes a Bar header MUST ignore the Bar header,
but MUST NOT remove it.
Foo 消息的發送者**必定**不能包含 Bar 消息頭；接收到一條包含 Bar 消息頭的 Foo 消息的接受者**必定**要忽略掉 Bar 消息頭，但**必定**不能剔除它。
複製代碼

Absent that, it’s best to look for more general advice about error handling elsewhere in the specification (e.g., HTTP’s Conformance and Error Handling section).

若是不是這樣描述的的話，最好是查看一下規範中關於錯誤處理的更寬泛的建議（例如，HTTP 規範的「Conformance and Error Handling 行爲規範及異常處理」一節）

Also, keep in mind the target of requirements; most specifications have a highly developed set of terms that they use to distinguish between different roles in the protocol.

另外，始終要記住規則所規定的要求；許多規範都有一套精心製做的術語，這些術語能夠很好地界定協議中不一樣角色的職責。

For example, HTTP has proxies, which are a kind of intermediary, which implement both a client and a server (but not a User-Agent or an origin server); they need to pay attention to requirements targeted at all of those roles.

例如 HTTP 的代理，這是一種中間層，既充當客戶端又充當服務端（但並不真的是一個 User-Agent (用戶代理) 和源頭服務器），須要關注全部這兩種角色的規則要求。

Likewise, HTTP distinguishes between 「generating」 a message and merely 「forwarding」 it in some requirements, depending on the specific situation. Paying attention to this kind of specific terminology can save you a lot of guesswork.

一樣，HTTP 協議是一些規則中視狀況使用「generating (生成)」 一條消息或者「forwarding (轉發)」消息，對它們作出清晰的界定。對這類特定的術語多關注點能夠節省你許多的猜想時間。

SHOULD

Yep, SHOULD deserves its own section. This wishy-washy term plagues many RFCs, despite efforts to eradicate it. RFC2119 describes it as:

對的，SHOULD 值得用一個章節來寫。這個「不清不楚」的詞給許多 RFC 文檔帶來了「瘟疫」——儘管有嘗試根除它。RFC2119 中是這樣描述它的：

SHOULD  This word, or the adjective "RECOMMENDED", mean that there
        may exist valid reasons in particular circumstances to ignore a
        particular item, but the full implications must be understood and
        carefully weighed before choosing a different course.
複製代碼

In practice, authors often use SHOULD and SHOULD NOT to mean 「We’d like you to do this, but we know we can’t always require it.」

實際狀況是，做者們偏心使用 SHOULD 和 SHOULD NOT 的來表述「咱們但願你這樣作，但咱們知道咱們不能總要求你這樣作」這樣的意思。

For example, in the overview of HTTP methods, we see:

例如，在 HTTP 請求方法概覽一節中咱們能夠看到：

When a request method is received that is unrecognized or not
implemented by an origin server, the origin server SHOULD respond
with the 501 (Not Implemented) status code. When a request method
is received that is known by an origin server but not allowed for
the target resource, the origin server SHOULD respond with the 405
(Method Not Allowed) status code.
當服務器接收到一條沒法識別或者未實現支持的請求方法時，服務器**應該**用 501 (Not Implementd 未實現) 狀態碼予以迴應。當服務器接收到一條的請求方法，但其請求的目標資源不被容許訪問時，服務器**應該**用 405 (Method Not Allowed 方法不被容許) 狀態碼予以迴應。
複製代碼

These SHOULDs are not MUSTs because the server might reasonably decide to take another action; if the request is from a client that is believed to be an attacker, it might drop the connection, or if HTTP authentication is required for the resource, it might enforce that with a 401 (Not Authenticated) before getting to the 405.

這段文本中的這些 SHOULD 並非 MUST，由於服務器某些狀況下有合理緣由採起其餘動做，例如，若是某條請求能夠被確信是來自某個攻擊者時，服務器可能會丟棄這條通信鏈接；又或者，若是所請求的資源須要有認證，那麼服務器可能會在到達 405 以前就強制迴應 401 (Not Authenticated 未認證）。

SHOULD doesn’t mean that the server is free to ignore a requirement because it doesn’t feel like honouring it.

SHOULD 也並不表示若是服務器不喜歡就能夠隨意忽視規則的要求。

Sometimes, we see a SHOULD that follows this form:

有時候，咱們能夠看到這樣使用 SHOULD 的文本形式：

A sender that generates a message containing a payload body SHOULD
generate a Content-Type header field in that message unless the
intended media type of the enclosed representation is unknown to
the sender.
發送者在生成一條含有消息體的消息時，**應該**同時生成一個 Content-Type 頭字段，除非發送者沒法得知所發送的消息部分所屬的總體消息的媒體類型。
複製代碼

Notice the 「unless」 – it’s specifying the 「particular circumstances」 that the SHOULD allows. Arguably this could be specified as a MUST, since the unless clause would still apply, but this style of specification is somewhat common.

留意上面提到的「unless (除非)」一詞——它指出了 SHOULD 所容許的特定條件。在這裏，其實也可使用 MUST 來表述，由於還有 unless 限制條件，但使用 SHUOLD 的會稍微通用點。

閱讀示例

Another very common pitfall is to skim the specification for examples, and implement what they do.

在翻閱規範文檔中示例以及示例所要實現的東西時，有一個坑須要注意。

Unfortunately, examples typically get the least amount of attention from authors, since they need to be updated with each change to the protocol.

由於有一個很差的事實就是，示例一般是做者給予關注度最小的，由於它們須要與協議的每次變更保持同步。

As a result, they’re very often the least reliable parts of the spec. Yes, the authors should absolutely double-check the examples before publication, but errors do slip through.

這樣的結果就是，它們成爲了規範中最不可靠的部分。對，規範的做者是應該在發佈前對示例進行復核，但這並不表明不會存在漏洞。

Also, even a perfect example might not be intended to illustrate the aspect of the protocol you’re looking for; they’re often truncated for brevity, or shown after an decoding step takes place.

另外，即使某個示例比較完美，它所要展現的關於協議的某個方面也可能並非你所要尋找的；這些示例一般爲了簡潔都會都被精簡過，或者是展現的只是解碼步驟以後的。

Even though it takes more time, it’s better to read the actual text; examples are not the specification.

因此，即使會耗費更多時間，也必定要看看文字部分——示例並非規範。

On ABNF

Augmented BNF is often used to define protocol artefacts. For example:

協議中的內容一般使用的是加強的 BNF 範式來表示。例如：

FooHeader = 1#foo
foo       = 1*9DIGIT [ ";" "bar" ]
複製代碼

Once you get used to it, ABNF offers an easy-to-understand sketch of what protocol elements should look like.

一旦你習慣了 ABNF，你會很容易理解協議中元素的應該會是什麼樣子。

However, ABNF is 「aspirational」 - it identifies an ideal form for a message, and those messages that you generate really need to match it. It doesn’t specify what to do with received messages that fail to match it. In fact, many specifications fail to say what the relationship of ABNF is to processing requirements at all.

ABNF 爲消息提供了一種理想的表達形式，你生成一條消息時須要知足它的規則，但他並無指定當收到一條不知足規則的消息時如何處理的過程。其實，許多規範都沒能說清 ABNF 的角色實際上是描述規則要求的處理過程的。

Most protocols will fail badly if you try to enforce their ABNF strictly, but sometimes it matters. In the example above, whitespace isn’t allowed around the semicolon, but you can bet that some people will put it there, and some implementations will accept it.

若是你嚴格執行 ABNF 的規則，許多協議會達不到要求，但有時候這樣反而是好事。在上面的這個例子中，空白字符是不容許出如今分號先後的，但你能夠確信有些人就是會在這裏放置空白字符，而有些規則的實現方也會接受這種狀況。

So, make sure you read the text around the ABNF for additional requirements or context, and realise that absent a direct requirement, you may have to adjust parsing to be more accepting of input than the ABNF implies.

因此，考慮到上下文及額外的規則要求，必定要看看 ABNF 先後的文本，並造成一種意識——你可能得在解析消息時放鬆 ABNF 的要求。

Some specifications are starting to acknowledge the aspirational nature of ABNF and specifying explicit parsing algorithms that incorporate error handling. When specified, these should be followed exactly, to ensure interoperability.

有些規範文檔會更大強度地採起 ABNF 的強大性，並顯式地指明解析的算法和發生錯誤時的處理。當出現這樣的狀況，你應該嚴格遵照，以確保交流性。

安全問題

Ever since RFC3552, the RFC boilerplate has included a 「Security Considerations」 section.

自 RFC3552 發佈以後，RFC 的模板就開始出現「安全考慮（Security Considerations）」章節。

As a result, it’s rare for an RFC to be published without a substantial section on security; the review process does not allow a draft to just say 「There are no security considerations for this protocol」.

結果就是，以後的 RFC 不多出現沒有關於安全的章節的；在審覈的過程當中也不會容許一個草案文件直接說「該協議不須要考慮安全性方面的問題」

So, it pays to read and make sure you understand the Security Considerations section, whether you’re implementing or deploying the protocol; if you don’t, it’s very likely that something will bite you down the road.

因此，你須要付出精力閱讀一下「Security Considerations」一節——無論是在實現仍是部署這個協議；若是你不這樣作，極可能你會所以而「翻車」。

Following its references (if any) is also a good idea. If there aren’t any, try looking up some of the terms used to get an appreciation of the issues being discussed.

跟隨它裏面的引用（若是有的話）也是一個好習慣。If there aren’t any, try looking up some of the terms used to get an appreciation of the issues being discussed.

更多信息

If an RFC doesn’t answer your question, or you’re not sure about the intent of its text, the best thing to do is to find the most relevant Working Group and ask a question on their mailing list. If there isn’t an active working group covering the topic in question, try the mailing list for the appropriate area.

若是 RFC 沒能解答你的問題，或者你不肯定它的文本所要表達的意思就是你所理解的，那麼最好的方法就是找到相關的工做組，而後在他們的郵件列表中進行提問。若是沒有關於這個問題所屬話題的活躍工做組，能夠嘗試到對應領域的郵件列表提問。

Filing an errata is usually not the first step you should take – talk to someone first.

咱們不該該一開始就提交一條勘誤——應該先跟其餘人進行交流。

Many Working Groups are now using Github for managing their specifications; if you have a question about an active specification, go ahead and file an issue. If it’s already an RFC, it’s usually best to use the mailing list unless you find directions to the contrary.

許多工做組如今都選擇使用 GIthub 來管理他們的規範了；若是你有任何問題，能夠提交一條問題反饋。若是規範已經成爲 RFC 了，那麼最好就是到該 RFC 的郵件列表中來反饋。

I’m sure there’s more to write about how to read RFCs, and some will dispute what I’ve written here, but this is how I think about them. I hope it was useful.

關於如何閱讀 RFC，我知道還有更多東西能夠寫，我也知道確定會有一些人對我所寫的這些東西議論，但這只是我我的的心得而已，但願它對大家有用。