こんにちは。
株式会社ウィルドの豊田です。
いよいよ新年度がスタートしましたね。
昨年度は採用活動に注力しましたが、なかなか結果に繋げられず辛い思いをしました。
今年度は良い一年になることを願って、頑張っていきます！
さて、今回のブログはRFC2119（ちょっとだけRFC8174）を、英語力ゼロの私が読んで自分なりに解釈してみたよ。という内容でお届けしたいと思います。
RFC2119って？
RFC2119は、1997年に「Key words for use in RFCs to Indicate Requirement Levels」（RFCで使用される要求レベルを示すキーワード）というタイトルで発行されたRFCで、IETF（当時のNetwork Working Group）が発行しています。
この文書では、技術仕様やプロトコルの標準化に関する文書（主にRFC）で使用される、要件レベルを示すキーワードの定義と使用方法が説明されています。
元々はRFC（IETF）での利用を目的としたものでしたが、現在では様々な団体の仕様策定文章の中で利用されています。エンジニアの方々なら比較的目にする機会が多いのではないでしょうか。
※ちなみに、機能の「仕様策定者」と「利用者」の観点で捉え方が変わるため、今回は「仕様策定者」の観点で解釈しています。
1. MUST
まず、”MUST” 。英単語の意味そのままって感じです。
絶対に守るべき条件であることを意味します。
特にこの項目については書くこともないですね。
同じ意味で、”REQUIRED”, “SHALL”も利用される場合があります。
2. MUST NOT
次に “MUST NOT”。これは “MUST” の逆ですね。
絶対に行ってはならない禁止事項であることを意味します。
こちらも “MUST” 同様、シンプルにそのままの意味です。
同じ意味で、”SHALL NOT”も利用することができます。
3. SHOULD
次は “SHOULD” ですね。
“MUST” ほどの強制力は無いものの、遵守することを強く推奨する仕様であることを意味します。
守らなくても一応動くように作ってある機能につけるキーワードですかね。
開発側は、この仕様を守らなかった場合に発生するリスクをきちんと説明し、利用者側に正しく判断してもらうための十分な情報を提供しなければいけません。
同じ意味を持つキーワードとして “RECOMMENDED” があります。
4. SHOULD NOT
こちらは “SHOULD” の逆の意味ですね。
禁止…とまではいかないものの、明確な理由がない限り利用を避けるべき仕様であることを意味します。
SHOULD同様、仕様策定者は、避けるべき仕様である理由をきちんと説明しなければなりません。
同じ意味を持つキーワードとして “NOT RECOMMENDED” があります。
5. MAY
最後は “MAY” です。
これは、利用してもしなくても、どちらでも良い仕様につけられるキーワードです。
仕様策定者に対する注意事項として「利用者がどちらの選択をしたとしても、問題なく動作するように作り込まなければならない。」みたいなことが書かれていました。
同じ意味を持つキーワードとして “OPTIONAL” があります。
6. Guidance in the use of these Imperatives
一応、キーワードの定義としては “MAY” までなのですが、RFCには続きがあるので、一応サクッと読んでみます。
Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability.
このメモに定義されているタイプのキーワードは、注意深く、控えめに使用されなければならない。特に、相互運用のために実際に必要な場合、または害を及ぼす可能性のある動作を制限する場合（例えば、再送信の制限）にのみ使用しなければならない（MUST）。例えば、相互運用のために必要でない特定の方法を実装者に押し付けるために使用してはならない。
（Translated by DeepL翻訳ツール）
（ここでいう「実装者」は利用者のことです）
ここまでのキーワードの利用に関する注意事項のようです。
本来SHOULDなのに、MUSTであるかのように書いちゃダメ（嘘をついて実装方法を押し付けちゃダメ）ですよ。って感じですかね。
この文章の中で既に「MUST」が使われているあたり、個人的には洒落がきいてるなーと思います。
7. Security Considerations
最後です。
These terms are frequently used to specify behavior with security implications. The effects on security of not implementing a MUST or SHOULD, or doing something the specification says MUST NOT or SHOULD NOT be done may be very subtle. Document authors should take the time to elaborate the security implications of not following recommendations or requirements as most implementors will not have had the benefit of the experience and discussion that produced the specification.
これらの用語は、セキュリティに影響を与える動作を指定するために頻繁に使用されます。 MUSTやSHOULDを実装しない、あるいは仕様でMUST NOTやSHOULD NOTとされていることを行うことによるセキュリティへの影響は、非常に微妙なものである場合がある。文書作成者は、推奨事項や要求事項に従わない場合のセキュリティへの影響について、時間をかけて詳しく説明する必要がある。なぜなら、ほとんどの実装者は、その仕様を作成した経験や議論の恩恵を受けていないからである。
（Translated by DeepL翻訳ツール）
（ここでいう「実装者」は利用者のことです）
日本語がちょっと？？な部分もありますが、基本的に「”SHOULD” や “SHOULD NOT” などの定義を守らずに実装した場合、セキュリティ面でのリスクは、それほど無いケースが多い」（本当に？）ので、そのあたりの内容は、仕様策定者（ドキュメント著者）側が丁寧に説明すべき。ということみたいです。
ちなみに
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.
確かにSemVerやInfra Standardのページにも、このコメントが組み込まれていました。
キーワードのバリエーション
“MUST”のエイリアスとして”REQUIRED”や”SHALL”が定義されているように、キーワードにはバリエーションが定義されていることがわかります。
ただ、実際のところは “MUST” , “MUST NOT” , “SHOULD”, “MAY” の4つくらいで十分で、実際にそれだけに限定しているドキュメントもあるようです。（WHATWGの”Infra Standard“）
ドキュメント毎の説明をちゃんと読まないといけませんね。
大文字とか小文字とか
RFC2119では、キーワードを “MUST” や “SHOULD”、”MAY”など大文字で書いていますが、RFC内で「大文字で記述すべし」とは定義していなかったりします。
実はその後2017年に発行されたRFC8174で「大文字の時だけRFC2119のキーワードとしての意味を持つ」と明確に定義してたりするんですが、RFC2119ほど広く受け入れられなかったようです。
（「RFC8174が定義以前の多くの文章（大文字も小文字も混在して使われていた頃）の習慣を維持したい」という動機らしい？諸説アリ）
実際、多くの団体から参照されているWHATWGの”Infra Standard“においては、RFC8174の定義に故意に違反している旨が明記されています。
そのあたり、ChatGPTさんはどのような見解なのか聞いてみました。（有料ユーザーになったので、4.0をただ使いたかっただけ）
なるほど。英語の文章として読みづらくなることを嫌ったということなんですね。
まとめ
今回はRFC2119の内容を斜め読みしつつ、他のドキュメントへの影響についても見てみました。
各団体の考えは様々ですが、その人たちが標準化してくれた仕様のおかげで、今のITの世界があると考えると、とても興味深い世界ですね。
※冒頭のRFCの画像は e-words.jp のサイトから拝借しました m(_ _)m
