はじめに
『DApps開発入門』という本や色々記事を書いているかるでねです。
今回は、技術仕様書で使われる「MUST」、「SHOULD」などの強調語の意味を明確に定義しているRFC2119についてまとめていきます！
以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。
他にも様々なEIP・BIP・SLIP・CAIP・ENSIP・RFCについてまとめています。
概要
RFC2119は、IETF（Internet Engineering Task Force）において標準文書を記述する時に使用される「要求レベルを表すキーワード」の意味とその使用方法を定義したドキュメントです。 この文書により、技術仕様における意図の明確な伝達が可能になります。
目的と背景
インターネット技術の標準化に関わる文書では、仕様に対する要件を明確に伝えるために「MUST」や「SHOULD」といった強い語調の単語が頻繁に使われます。
しかし、これらの語が人によって異なる強さで解釈されると、相互運用性や安全性に影響が出るおそれがあります。
RFC2119はこの問題を解消するために、そうした語の意味を明確に定義し、文書の冒頭でその使い方を明示することを推奨しています。 例えば以下のような文を仕様の前提に記載します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.各キーワードの意味
MUST / REQUIRED / SHALL
これは絶対的な要件を意味します。 ある仕様項目に対して「`MUST」と記載されている場合、それを満たさなければ仕様に準拠しているとは言えません。
MUST NOT / SHALL NOT
これは絶対的な禁止事項を意味します。 このルールに反する行動をしてはいけません。
SHOULD / RECOMMENDED
これは強い推奨を意味します。 基本的には従うべきですが、正当な理由がある場合に限って例外が認められます。 ただし、その例外の影響を十分に理解した上で判断する必要があります。
SHOULD NOT / NOT RECOMMENDED
これは基本的に避けるべきだが、特別な場合には許容されるという意味です。 使用する場合は、リスクや影響をよく検討することが求められます。
MAY / OPTIONAL
これは完全な任意項目を意味します。 導入してもしなくてもよく、選択は実装者に委ねられています。 ただし、相互運用性を保つために、実装が異なる場合でも通信可能であることが前提です。
注意点
RFC2119のキーワードは、相互運用性の維持や安全性の確保のために慎重に使う必要があります。
単に好みや実装スタイルを強制するために「MUST」などを使うべきではありません。
例えば「データはJSON形式で保存するべき」という内容を「MUST」としてしまうと、他のフォーマット（XMLなど）を使いたい開発者の選択肢を不必要に制限してしまいます。
RFC2119では、このような誤用を避けるよう注意しています。
セキュリティ
これらのキーワードの使い方はセキュリティ上の意味合いを持つことも多く、特に「MUST」や「MUST NOT」の遵守が脆弱性の有無に直結する場合もあります。
したがって、文書の作成者は、その推奨や要件に従わなかった場合のリスクについてもきちんと明記することが望まれます。
最後に
今回は「技術仕様書で使われる「MUST」、「SHOULD」などの強調語の意味を明確に定義しているRFC2119」についてまとめてきました！
いかがだったでしょうか？
質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！
他の媒体でも情報発信しているのでぜひ他も見ていってください！
