要約

  • RFC 2234 は、各インターネット仕様書に個別に載っていた ABNF の定義を独立文書にまとめた。
  • 共通の文法言語は規則の参照や合成を容易にするが、異なる実装が同じ解釈をする証明にはならない。

仕様書はプロトコルのメッセージ形式を定めると同時に、その規則を記述する記法も説明していた。RFC 2234 が振り返るところでは、ARPANET 初期には仕様書ごとに ABNF の定義が含まれていた。電子メール仕様の RFC 733、続く RFC 822 は、やがて ABNF の一般的な参照先となる。とはいえ、特定プロトコルの文書内に文法言語の説明が埋め込まれていると、文法そのものを調べたい読者には回り道になる。

1997年11月に発行された RFC 2234 は、その定義を切り出し、必要に応じて他の仕様書から参照できるようにした。意味するのは、インターネットが単一のパーサーを採用したことではない。規則名、終端記号、反復、選択肢、数値範囲、グループ化について、共通の説明を参照できるようにしたことだ。ABNF は受理される文字列の構文を表す。ネットワーク上の実装が実際に何を受け入れるかの証拠ではない。

ここでは層を分けて考える必要がある。ABNF は構文を記述し、プロトコル仕様がメッセージを定める規則を選び、伝送環境が終端値の外部表現を決め、パーサーがそれらを実装する。RFC 2234 は、同じ文法でも外部エンコーディングが異なりうると述べ、その詳細を ABNF の範囲外に置く。だから文法記法は複数のプロトコルで再利用できても、回線上のバイトの意味をすべて自動的に決めるわけではない。

規則は断片から組み立てることもできる。=/ 演算子は、別の箇所で定義済みの規則に選択肢を追加する。RFC 2234 は、共通の親規則群から派生する独立仕様で役立つ場合があると説明している。これは文書を合成する仕組みであって、実行時にパーサーが拡張を自動発見する指示ではない。どの文書が規則を構成し、その適用範囲がどこまでかは、仕様書が示す必要がある。

これは控えめなインターネット協調の形だ。規則を書く語彙を共通化し、プロトコル固有の規則は分け、エンコーディングの選択を見えるようにする。RFC 2234 は、名前を付けるだけで意見の相違をなくしたのではない。どの層で意見が分かれているのかを示しやすくした。その後 RFC 4234、RFC 5234 と改訂が続いたことも、共有言語が更新可能であることを示す。RFC 7405 は後年 UTF-8 関連の構文を扱ったが、その変更を1997年の文書に遡って読み込むべきではない。

したがって ABNF の歴史は、文章を数学に置き換えた物語ではない。文章はプロトコルの目的や背景を説明し、文法は形式を簡潔に示す。重要だったのは、文法言語自体の定義を、それを使う各プロトコル仕様書の中に毎回置かずに済むようにしたことだ。再利用の参照先は明示できるようになった一方、実装についての主張には、引き続き実装そのものの証拠が要る。

出典：RFC 2234、Datatracker の RFC 2234 記録、RFC 2234 の履歴、RFC Editor の RFC 2234 情報、RFC 733、RFC 822、RFC 4234、RFC Editor の RFC 4234 情報、RFC 5234、RFC Editor の RFC 5234 情報、RFC 7405、RFC 2119、Lu Heng「実装コードの優先」、Lu Heng「最小初期仕様」、Lu Heng「現実の層」。