共计 6229 个字符，预计需要花费 16 分钟才能阅读完成。
如何浏览 RFC
无论好坏，Requests for Comments (RFCs) 是互联网上许多协定内容的具体阐明(specify)。这些文件被开发者视为圣典，他们剖析这些文件的深层含意，然而又因为无奈了解这些内容而把这些文件漠视掉或者漠视局部内容（irrelevant）, 这会给人带来挫败感，更重要的是可能会造成软硬件之间的信息替换和导致平安问题。然而如果你对它们的构建和公布过程有一些理解，就会对这些内容有一个更深的理解。
上面是我依据从 HTTP 以及其余一些事件中得出的教训。
Where to start? – 从什么中央查找咱们须要的 RFC
RFC Editor Web Site 是查找 RFCs 文档比拟权威的中央。然而，正如咱们在上面所看到的那样这个网站短少一些要害信息，所以大多数人应用 tools.inetf.org。
你能够用浏览器搜寻你想查看的 RFC 文档, 但因为 RFCs 数量泛滥,(目前有近 9000 个), 所以说找到本人所需的 RFC 是比拟艰难的。高效期间, 你能够在 RFC Editor Web Site 网站上进行搜寻。
另一个网站是 rfc.fyi, 这个网站容许你按“题目”和“关键词”搜寻，能够点击界面上的一些“标签”快速访问一些内容。
RFC Editor Web Site 正在开发一种体验更好并带有自定义选项的新 RFC 格局, 以此改善之前
纯文本的 RFC 难以浏览的问题, 同时, 如果你想取得更多可用的 RFCs，你能够应用第第三方资源库来查问; 例如，greenbytes 保留了一个 WebDAV 相干的 RFCs 列表,HTTP 工作组也保留了一些与 HTTP 相干的内容。
What kind of RFC is it? RFC 的类型是什么
所有 RFC 文档顶部都有一个横幅，看起来像上面这样
下面第一行, 写着 “Internet Engineering Task Force (IETF)”。这表明该文档通过了 IETF 审查并对该协定内容达成了共识; 只管 IETF 并不广为人知, 但还有其余办法能够公布 RFC，而不须要 IETF 的共识；例如，独立集体或者其余个人(independent stream)。
事实上，有许多 “集体或者个人(streams)” 能够公布文件。只有“IETF”示意整个 IETF 曾经审查了该协定并发表了对该协定标准达成共识。(原文:Only the IETF stream indicates that the entire IETF has reviewed and has declared consensus on a protocol’s specification.)
较早的文件（大概在 RFC5705 之前）第一行写着 “Network Working Group”，所以你必须多开掘一些信息来查看它们是否通过 IETF 的审查并达成共识；首先看一下 “Status of this Memo” 局部，以及 RFC Editor Web Site 这个网站。（Memo：备忘录）
第二行是 “Request for Comments” 的“编号”。如果它写的是 “Internet-Draft”，它就不是 RFC；它只是一个互联网草案，任何人都能够写草案，该草案最初不肯定会被 IETF 驳回。
Category 这行有 4 个可选值:“Standards Track”,“Informational”,“Experimental”,“Best Current Practice”. 四者之间的区别有时是含糊的, 但如果它是由 IETF 公布(见第一行内容), 它就通过了正当的审查。然而请留神即便由 IETF 公布的, “Informational” 和 “Experimental” 并不是规范。
最初, 该文件的作者被列在题目的右侧。与学术界其余文档中作者含意不同的是: 这里的 “作者”是指“谁写了这个文件” 如果你看到附加的 “Ed.”，这表明他们是编辑了该文件, 该文件是事后存在的（比方当 RFC 被批改时), 通常在靠近整个文件底部的 ” 致谢 ” 局部会有谁为该文件做出奉献的全面的清单。
Is it current? 是否以后
RFCs 是一系列的存档文件(曾经归档)；它们一个字符都不能扭转（RFC7158 和 RFC7159 之间的差别, 这是一个极其的例子, 他们把年份搞错了）
文档顶部的横幅蕴含的一些元数据帮忙咱们分别该文档是不是咱们所需的。
Obsoletes: 列出了本文档齐全取代的 RFCs；也就是说你应该应用以后该文档，而不是那些个被淘汰的文档。请留神当一个较新的协定呈现时，一个旧版本的协定不肯定会被淘汰；例如，HTTP/ 2 并没有淘汰 HTTP/1.1，因为旧协定依然是非法的（而且是必要的); 然而 RFC7230 的确淘汰了 RFC2616，因为当初 RFC7230 是该协定的参考。
Updates: 该行列出了该文件对“哪些其余的 RFCs”进行了重大扭转；换句话说，如果你正在浏览那些被更新的文件, 那么你可能也应该浏览该文件。
可怜的是，ASCII 格局的 RFC（例如，在 RFC Editor Web Site 这个网站 RFC）并没有通知你哪些文件更新或淘汰了你目前正在看的文件。这就是为什么大多数人应用 tools.inetf.org 上的 RFC 库，它把这些信息放在一个像上面这样的横幅上
下面横幅中每个数字都是一个链接，所以你能够很容易地找到数字所链接的文件。
即便是最新的 RFC 也常常有问题。在下面的横幅上, 你还会看到左边有一个：”Errata Exist(勘误表)”, 下面还有一个勘误的链接。
勘误表是不值得公布新的 RFC 状况下对文件的更正和廓清。有时它们会对 RFC 的施行产生实质性的影响（例如, 如果标准中的一个谬误导致了重大的误会), 所以它们是值得去看的。
例如，这里是 RFC7230 的勘误表。当浏览勘误表时，请记住它们的状态; 许多被回绝是因为有人误读了标准。
Understanding context
开发者依照 RFC 中的标准, 并实现了一些内容, 但却做了与作者用意相同的事件，这比你设想的更常见。
这是因为要把标准写得在有选择地浏览时不会被误会是十分艰难的（任何圣经都是如此）
因而，不仅要浏览间接相干的文本，还要（至多）浏览它所援用的任何内容，无论是在同一个标准中还是在另一个标准中; 在紧要关头，如果你不能浏览整个文件，浏览任何可能相干的局部会有很大的帮忙。
例如，HTTP 音讯头被定义为由 CRLF 分隔，但如果你跳到这里，当你看到 “ 接收者能够将单个 LF 辨认为行结束符，并疏忽后面的 CR”。你感觉对吗？
同样重要的是许多协定设立了 IANA 注册处来治理他们的扩大点；这些不是标准，是真谛的起源。例如，HTTP 办法的标准列表就在这个注册表中，而不是在任何 HTTP 标准中。
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.
Interpreting requirements
在凑近文档顶部的局部, 简直所有的 RFC 都有相似这样的内容
这些 RFC2119 关键字有助于定义互操作性，但它们有时也会使开发者感到困惑。很常见的状况是看到一个标准说:
这个 requirement 被放在 “Foo Message” 这个协定上，如果你要发送一个 Foo Message, 很显著它不须要蕴含一个 Bar Header；如果你蕴含了 Bar Header 它就不是一个符合要求的音讯。
然而, 收件人的行为就不那么分明了; 如果你看到一个带有 Bar Header 的 Foo Message，你会怎么做？
只管标准中没有说要怎么做，但一些开发者会回绝蕴含有 Bar Header 的 Foo Message。另一些人依然会剥去 Bar Header 并解决该 Foo Message 或疏忽它 – 即便标准明确指出所有头都须要解决。
所有这些事件都会 – 无心中 – 导致 互操作性 问题。正确的做法是遵循失常的 Header 解决，除非有相同的具体要求。
这是因为在个别状况下, 标准的编写是为了公开地规定行为; 换句话说, 所有没有明确禁止的行为都是容许的。因而, 在标准中读到 太多 的内容会无心中造成挫伤 (Reading too much into specifications can unintentionally cause harm): 也就是不要对标准过分的解读, 因为你会引入新的行为, 而其他人将不得不绕过这些行为。
在一个现实的世界里，标准将以 解决信息的人的行为 来定义，就像这样:
如果没有这一点，最好在标准的其余中央寻找对于错误处理的一般性倡议(例如:HTTP 的一致性和错误处理局部)
另外, 请记住 requirements 的指标(the target of requirements)；大多数标准都有一套术语, 它们用来辨别协定中的不同角色。
例如: HTTP 有代理，这是一种 proxies，它同时实现了客户端和服务器（但不是 User-Agent 或 an origin server）; 须要留神针对所有这些角色的需要(pay attention to requirements targeted at all of those roles)。
同样,HTTP 在一些要求中辨别了 “generating” 音讯和 仅仅 ”forwarding” 音讯, 这取决于具体的状况。留神这种特定的术语能够让你省去很多猜想的麻烦。
SHOULD
Should 是一个不置可否的术语,RFC2119 中的形容如下:
在实践中作者常常应用 Should 和 Should not 来示意:” 咱们心愿你这样做, 但咱们晓得咱们不可能总是要求你这样做 ”。
例如:overview of HTTP methods 咱们能够看到:
这些 “SHOULDs” 不是 “MUSTs”，因为服务器可能正当的采取一些口头: 如果申请来自一个被认为是攻击者的客户端可能会放弃该连贯, 如果须要 HTTP 认证, 它可能会返回 401(Not Authenticated)代替 405
有时咱们会看到这种模式的 Should:
留神下面的 “unless” 指定了一种 Should” 容许的状况。
Reading examples
另一个十分常见的陷阱是搬运文档的中的示例(examples), 然而示例通常很少受到作者的关注, 因为它们须要随着协定的每次更改而更新。
因而示例 (examples) 通常是标准中最不牢靠的局部, 只管作者在发表之前应该会再次查看示例但谬误总会呈现。
此外即便是一个完满的示例也不可能笼罩到该协定的方方面面; 为了简洁这些示例会被简化。
你应该破费更多的工夫去浏览真正的文本内容而不是这些示例。
On ABNF
BNF:(Backus-Naur Form)是由 John Backus 和 Peter Naur 首先引入的用来形容计算机语言语法的符号集,RFC2234 定义了扩大的 ABNF, 在 Internet 的定义中 ABNF 被宽泛应用。
Augmented BNF is often used to define protocol artefacts. For example:
Once you get used to it, ABNF offers an easy-to-understand sketch of what protocol elements should look like.
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.
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.
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.
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(互操作性).
Security considerations
从 RFC3552 以来 RFC 就包含了 “Security Considerations” 局部。
个别 RFC 在公布时都含一个 “Security Considerations” 的重要局部; 审查过程不容许该草案中没有“Security considerations” 局部。无论你是协定的起草者或者使用者都要浏览并确保你了解了“Security considerations”; 如果你不这样做你很可能会遇到麻烦。
如果遇到一些须要探讨的问题能够查看该文档的参考文献(如果有的话), 也能够尝试查找其余的对于该问题的一些条目。
Finding out more
如果在 RFCs 文档中你还没有找到问题的答案, 或者你不太明确 RFCs 文档所表白的真正含意, 那么你能够先找到与你的问题关系最为亲密的”相干工作组“(relevant Working Group) 并在其邮件列表中提出本人的疑难。如果没有工作组波及到你提的这个问题, 请尝试在 “ 相应畛域 ”(appropriate area) 的邮件列表中发问。
然而你最应该做的是与理解该问题的人进行探讨而不是提交勘误。
许多工作组当初都应用 Github 来治理他们的标准, 如果你对一个 “active specification” 有疑难，就去提交你的问题。如果它曾经是一个 RFC, 通常最好应用邮件列表进行沟通, 除非你发现要求应用其余的沟通形式。
我敢肯定还有更多的对于如何浏览 RFCs 的文章, 而且有些人会质疑我写的内容, 但这是我的认识并心愿对你有用。
这篇文章最后呈现在 mnot 的博客上并经许可后转载于此。
本篇文章转载于 www.ietf.org ; 感激作者的付出。
Ready Enjoy It
