前言

在技術界和標準化組織中，準確和清晰的溝通至關重要。定義和理解標準和協議時，必須非常明確關於哪些部分是強制性的，哪些是建議的，以及哪些是選擇性的。RFC2119 就是為此目的而生的一份文件。通過在整個互聯網社群中建立共同的語言和解釋，它使溝通變得更精確，並有助於確保標準的一致實施和互操作性。

RFC2119 是一份由 IETF（互聯網工程任務組）發佈的標準文件，用於定義在許多 IETF 文件中使用的特定關鍵字的準確含義。下面是這份文件的翻譯和解釋。

狀態
此文件規定了互聯網社群的當前最佳實踐，並請求討論和建議改進。此通知的分發不受限制。

摘要
在許多標準文件中，使用了一些詞彙來表示規範中的要求。這些詞彙通常會大寫。本文件定義了這些詞彙在 IETF 文件中應有的解釋。遵循這些指導方針的作者應在文件開頭附近包括以下語句：

arduino
Copy code
本文件中的 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、 "MAY" 和 "OPTIONAL" 按照 RFC 2119 的描述解釋。
注意，這些詞的力量會因所用文件的要求等級而有所改變。

MUST: 此詞彙或 "REQUIRED" 或 "SHALL" 表示規範的絕對要求。

MUST NOT: 此詞組或 "SHALL NOT" 表示規範的絕對禁止。

SHOULD: 此詞或形容詞 "RECOMMENDED" 表示在某些特定情況下可能存在忽略某一項目的有效理由，但在選擇不同方向之前必須充分理解並仔細衡量其全部含義。

SHOULD NOT: 此詞組或 "NOT RECOMMENDED" 表示在某些特定情況下，特定行為可能是可接受甚至有用的，但在實施任何用此標籤描述的行為之前，應充分理解其全部含義並仔細衡量情況。

MAY: 此詞或形容詞 "OPTIONAL" 表示項目完全是可選的。一個供應商可能選擇包括該項目，而另一個供應商可能選擇省略相同項目。不包括特定選項的實現必須能與包括該選項的另一實現互操作，雖然功能可能有所減少。

這些命令詞的使用指引

本通知中定義的命令類型必須謹慎並節制地使用。特別是，只有在實際需要互操作或限制可能造成損害的行為（例如，限制重傳）時，才能使用它們。

安全考慮

這些術語經常用於指定具有安全含義的行為。不實施 MUST 或 SHOULD，或做某些規範說 MUST NOT 或 SHOULD NOT 做的事情可能會對安全產生非常微妙的影響。文件作者應花時間闡述不遵循建議或要求的安全影響，因為大多數實施者可能不具有產生規範的經驗和討論的好處。

致謝

這些術語的定義是從多個 RFC 中抽取的定義的混合體。此外，還整合了包括 Robert Ullmann、Thomas Narten、Neal McBurnett 和 Robert Elz 在內的多人的建議。

簡而言之，RFC 2119 提供了一套清晰、一致的術語，用於描述協議和其他標準文檔中的要求等級。這有助於確保協議的開發人員和使用者對文檔的理解和解釋保持一致。

總結

RFC 2119 透過確定特定的關鍵字並定義其在標準和協議文檔中的精確含義，為工程師、開發人員和標準組織提供了共同的語言。這消除了模糊性和不確定性，並有助於確保在實施和解釋標準時的一致性。其結果是更健壯的技術解決方案和更可靠的互操作性，從而增強了整個互聯網社群的效率和效能。這正是使 RFC 2119 成為如此重要文件的原因。其深遠的影響和跨越多個領域的應用使其成為標準化工作的基石。

RFC2119

幹話王部落格

OpenTelemetry 入門指南：建立全面可觀測性架構