要約

  • RFC 8174では、宣言されたBCP 14の慣例の下で、列挙された語がすべて大文字になっている場合だけ特別な定義が働く。小文字のmustやshouldは通常の英語として扱われる。
  • しかし、これは「大文字だけが規範的」という規則ではない。同RFCはキーワードのない規範文もあると明記し、RFC 2119は語の強さが文書の要求レベルによって変わると述べる。
  • 信頼できる適合性の記録には、文書の版と状態、宣言、全文、主体、条件、例外、試験、観測結果が必要であり、大文字の件数だけでは足りない。

最も取り出しやすい証拠は最も薄かった

RFC中のMUSTを検索し、試験項目へ変換することは簡単だ。色付きの一覧は決定的に見える。しかし、その語が引用にあるのか、例示なのか、文書自身の命令なのかを検索式はまだ知らない。

要求文だったとしても、対象となる実装、動作を起こす条件、参照先の定義、文書の状態が欠ければ試験入力すら決められない。これらは後から付ける説明ではなく、義務の構成要素である。

RFC 8174は一つの曖昧さだけを確実に除いた。その慎重さによって、機械が安全に発見できる範囲も見えるようになった。

「しばしば大文字」が二つの文法を残した

Scott BradnerのRFC 2119は要求レベルの共通語彙を作った。MUSTは仕様の絶対要件、MUST NOTは絶対禁止である。SHOULDは正当な理由があり影響を理解した場合にだけ逸脱を認める。MAYは本当に任意だが、選択が異なる実装どうしの相互運用を求める。

元の文章は、これらの語が「しばしば」大文字になると書いた。小文字のmustは、組版が崩れた定義語なのか、普通の英単語なのか。著者と査読者とツールが同じ一文に別の文法を当てる余地があった。

Leibaの更新は分岐を閉じた。特別な意味はすべて大文字の形にだけ適用され、小文字なら通常の英語の意味になる。さらに、文書内の定型文がその慣例を明示する。

小文字でも規範文は規範文であり得る

この整理を「大文字は規範、小文字は説明」と読み替えると、RFC 8174の半分を失う。同文書は、キーワードの使用は必須ではなく、キーワードを使わない規範文も多いと明言している。

したがって判断は二段階になる。ある語がBCP 14の定義を呼び出しているか。そして、その文章がどの権限で、誰に、どの範囲の規範を与えるかである。

一つの正規表現で両方を答えると、普通の文章で書かれた規範を落とし、引用内の大文字を義務へ昇格させる。自動化は速くなるが、間違いの所在が隠れる。

語は文書から力を借りる

RFC 2119自身が、語の効力はそれが現れる文書の要求レベルにより修正されると注意している。大文字はInternet-Draftを標準にせず、Informational RFCを相互運用命令にせず、社内メモをIETFの合意にしない。

権限は分担されている。著者が文章を選び、ワーキンググループとストリーム承認者が手続きと状態を与え、RFC Editorが承認済みの意味を保ち、実装者がコードへ写し、試験者が動作を観測する。

大文字は引き渡しを読みやすくするが、どの担当者にも代われない。BCP 14の定型文は装飾ではなく、語彙の来歴を示す記録である。

SHOULDは弱い命令ではなく例外の設計である

MUST、SHOULD、MAYを強弱の目盛りに並べると、それぞれの制御構造を見失う。MUSTは選択を閉じる。SHOULDは理由と影響評価を伴う逸脱口を残す。MAYは選択を開き、その両方を周囲が扱えるようにする。

現在のIETF著者向け案内はSHOULDを特に難しい語として扱う。なぜMUSTではないのか、逸脱したとき何が起きるのかを明確にすべきだという。適合表で単に「任意」とするのは、実装判断に必要な部分を消すことになる。

使える要求には主体、動作、前提、例外、相互運用上の結果がある。強調された語はその場所を示すだけだ。

スタイルガイドは意図的な小文字を使う

RFC 7322はRFC 2119の用語を使わないと宣言し、その後で小文字のmustとshouldに独自の編集上の意味を与える。一方はRFC Editorが自動的に行う変更、他方は適用しない場合に確認される推奨である。

これはBCP 14の例外ではない。どの文法を使うかを明示した例だ。読者は小文字を誤植だと推測しなくてよい。

同じガイドは、RFC 2119の解釈を使うなら引用し規範参照にし、使わないなら正しい解釈を文書内で定めるよう求める。見慣れた字面は宣言の代わりにならない。

構造化タグも語句の外側までは決めない

RFCXMLには任意の<bcp14>要素があり、MUSTやSHOULD NOTという実際の語句を囲める。著者ツールや表示系には有用だが、公式説明は要求文全体を囲まないよう指示している。

この境界が示すのは、機械可読な対象が義務全体より小さいということだ。主体、動作、条件、例外、参照先は通常の文書構造に残る。

タグは候補を見つける高品質な手掛かりになる。そこから直接テストを作れば、マークアップが保持していない判断まで保持したことにしてしまう。

大文字は語彙の受領証であって委任状ではない

Barry Leibaが行ったのは、大文字を強くすることではない。BCP 14の特別な意味がいつ発動するかを検証可能にしたことだ。

その先の権限は合意、ストリーム、文書状態から来る。範囲は文と参照から来る。適合性は実装と試験結果から来る。字形だけでこの連鎖を復元することはできない。

良い自動化は語を見つけた後、文書を捨てない。誰が拘束され、どの版に基づき、どんな例外があり、何を観測するのかを続けて問う。大文字がその問いへ導けば、役割を果たしている。

情報源