[译] 如何阅读 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，我知道还有更多东西能够写，我也知道确定会有一些人对我所写的这些东西议论，但这只是我我的的心得而已，但愿它对大家有用。