RFC 2119 / 8174: 要求レベルのキーワード

このRFCが決めたこと

横にスクロール

RFC 2119（1997年、Scott Bradner）は、プロトコルを定義するのではなく、プロトコル仕様を書くための語彙を定義した異色のRFCです。わずか数ページで、要求の強さを表す一群のキーワード——MUST、SHOULD、MAY とその否定形・同義語——の意味を1つに固定しました。狙いは単純で、仕様書から「〜すべきである」「〜が望ましい」といった曖昧な自然言語の揺れを排除し、実装者がどこが必須でどこが裁量かを誤解なく読み取れるようにすることです。

これが効くのは相互運用性の世界だからです。別々の組織が同じ仕様だけを頼りに実装し、それらが初対面で正しく通信できなければなりません。「推奨」を必須と読むか任意と読むかで実装が食い違えば、接続は壊れます。RFC 2119 は、その解釈のブレをキーワードの定義という一点に閉じ込めました。以後、ネットワークやWeb、セキュリティの主要仕様は、冒頭で「本書のキーワードは RFC 2119 の定義に従う」と宣言するのが定番になっています。

3段階の要求レベルを精読する

キーワードは実質3つの強度に集約されます。同義語が複数あるのは英文法上の言い回しを許すためで、意味は同じです。

読解上の要は SHOULD と MAY の非対称性です。MAY の機能を「実装しない」ことは完全に自由ですが、逆にある実装が MAY の機能を省いても、それと通信する相手はその機能に依存してはいけない——RFC 2119 はこの相互の含意まで明記しています。つまり MAY は「送る側の自由」であると同時に「受ける側は無くても動け」という制約でもあります。

RFC 8174 の補足（大文字のときだけ規範）

RFC 2119 には長年ひとつの曖昧さが残っていました。地の文で自然に使われる小文字の "must" や "should" まで規範的キーワードと解釈すべきか、という点です。仕様の散文には「この値は正の整数であるべき（should）」のような日常語としての should が混ざり、どこからが強制力を持つのか判然としませんでした。

2017年の RFC 8174 がこれを一文で解決します。規範的な意味を持つのは、キーワードが大文字で書かれているときだけ、と定めたのです。以後の仕様は「大文字の MUST/SHOULD/MAY のみが RFC 2119 の意味を持ち、小文字は通常の英単語である」という定型文（boilerplate）を冒頭に置きます。

つまずきやすい点

第一に、キーワードは要件の強さであって、優先度や実装難度ではないという点です。MUST が難しく MAY が簡単とは限りません。第二に、SHOULD の逸脱は「許されている」のではなく「正当化を要求されている」ことです。ログや設計文書に理由を残せない逸脱は、事実上の非準拠と変わりません。第三に、否定形の読み違いです。MUST NOT は「してはならない絶対禁止」で、SHOULD NOT より一段強い。うっかり SHOULD NOT を MUST NOT と同じ強さで実装すると、本来許容される例外ケースを弾いてしまいます。

最後に、これは仕様を書くときの規律でもあります。自分が設計文書やAPIの取り決めを書くなら、要件を大文字キーワードで表現するだけで、読み手の解釈ブレが激減します。曖昧な「〜が望ましい」を一掃できるのは、既製の語彙を借りる最大の利点です。

まとめ

RFC 2119 は、インターネット標準の読み書きを支える最小の共通語です。MUST・SHOULD・MAY の3段階と、RFC 8174 の「大文字のみ規範」という補足を押さえれば、分厚い仕様書からでも必須要件と裁量の境界を素早く抽出できます。他のRFCを読む前に、まずこの語彙を頭に入れておくのが近道です。関連する主要RFCはRFC精読の各記事でも同じ枠組みで読み解いています。