MS_ShallShouldMay - NetDevInfraWGinOSSConsortium/NetDevInfraWiki GitHub Wiki

技術文書中での Shall / Should / May

概要

キーワードとして解釈し、自然言語の意味で解釈しない。

補足(なぜ重要か): RFC や W3C 仕様を読む際、
これらは大文字で書かれたときだけ規範的なキーワードとして働く。
「should は "べき" だから努力目標」といった
日常語の感覚で読むと、準拠判定を誤る

例えば OAuth 2.0 で
「認可サーバーは PKCE を MUST サポートする」と書かれていれば
実装しなければ準拠を名乗れないが、
SHOULD なら「実装しない合理的理由があるなら許される」となる。
この差が、相互接続性テストや監査で効いてくる。

詳細

MUST

MUSTREQUIREDSHALL という言葉は、
定義が仕様の「絶対的要件」であることを意味する。

MUST NOT

MUST NOTSHALL NOT は、
定義が仕様の「絶対的禁止」であることを意味する。

SHOULD

SHOULD や形容詞 RECOMMENDED は、「推奨」なので
特定の状況で特定の項目を無視する有効な理由が存在する可能性があることを
意味するが、別のコースを選択する前に十分な意味を理解して
慎重に検討する必要がある。

SHOULD NOT

SHOULD NOT、または NOT RECOMMENDED は、「非推奨」なので
特定の動作が許容可能であるか有用である場合に
特に有効な理由が存在する可能性があり、
このラベルで説明されている動作を実装する前に、
十分な含意を理解し、ケースを慎重に検討する必要がある。

MAY

MAYOPTIONAL は、項目が本当に「オプション」であることを意味する。

一覧

キーワード 同義語 意味
MUST REQUIRED / SHALL 絶対的要件
MUST NOT SHALL NOT 絶対的禁止
SHOULD RECOMMENDED 推奨(外すなら理由が要る)
SHOULD NOT NOT RECOMMENDED 非推奨(採るなら理由が要る)
MAY OPTIONAL 任意

補足(RFC 8174 による明確化): RFC 2119 は
RFC 8174(2017年)で更新されており、

これらのキーワードは、大文字で書かれている場合にのみ
本文書で定義された特別な意味を持つ。

と明記された。つまり小文字の must / should
通常の英語として読む。
仕様を書く側になった場合も、この区別を守る必要がある。

補足(MAY の落とし穴): 「本当にオプション」であることの帰結として、

  • 実装する側: 実装しなくても準拠である。
  • 相手にする側: 相手が実装していないことを前提に作る必要がある

つまり MAY の機能に依存した設計をすると、
相互接続で破綻する。RFC 2119 の原文も

同じ項目を省略する別の実装と相互運用できなければならない
(ただし、機能は低下する)

と注意している。
「オプションだから実装しなくていい」ではなく、
オプションだから、あることを前提にしてはいけない」と
読むのが実務的である。

参考


Tags: 移行, IT国際標準, プログラミング, その他、開発の色々

⚠️ **GitHub.com Fallback** ⚠️