[譯] 如何閱讀 RFC 文件

程式設計師 · 發表 2018-11-19 14:42:57

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

原文：ofollow,noindex">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 fewother things.

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

從什麼地方開始

The canonical place to find RFCs is theRFC Editor Web Site. However, as we’ll see below, some key information is missing there, so most people usetools.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 isEveryRFC, 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 anew 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 theHTTP 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: 7230Adobe
Obsoletes: 2145, 2616J. Reschke, Ed.
Updates: 2817, 2818greenbytes
Category: Standards TrackJune 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, theindependent 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 theRFC 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, andanyone 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 所採用。

Categoryis 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 arenot standards, even if there’s IETF consensus to publish.

Category（目錄）分為“Standard Track”（標準）、“Informational”（資訊性的）、“Experimental”（實驗性的）、“Best Current Practice”（當前最佳實踐）。它們之間的區別有時候比較模糊，但可以確信的是，如果是由 IETF 製作的，肯定經過了大量的稽核。不過要注意，Informational 和 Experiment 並不屬於標準，即便是經過 IETF 批准釋出的。

Finally, theauthors 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 thediff 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 attools.ietf.org, which puts this information in abanner 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, 7235DRAFT STANDARD
Updated by: 2817, 5785, 6266, 6585Errata 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(存在勘誤)”的字樣，在其上面則是關於勘誤資訊的連結。

Errataare 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 theerrata 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 aredefined to be separated by CRLF, but if you skip downhere, 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 upIANA registries to manage their extension points; these, not the specifications, are the sources of truth. For example, the canonical list of HTTP methods is inthis 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.
複製程式碼

TheseRFC2119 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’sConformance and Error Handling section).

如果不是這樣描述的的話，最好是檢視一下規範中關於錯誤處理的更寬泛的建議（例如，HTTP 規範的“Conformance and Error Handling 行為規範及異常處理”一節）

Also, keep in mind thetarget 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 hasproxies, 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 中是這樣描述它的：

SHOULDThis 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 theoverview 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 未認證）。

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

SHOULD 也並不表示如果伺服器不喜歡就可以隨意忽視規則的要求。

Sometimes, wesee 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 requirementsat 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 sinceRFC3552, 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.