要約

  • RFC 9682はRFC 8610の収集ABNFを置き換える。旧来の適合ファイルが新文法に収まることと、新構文を旧処理系が受理することは違う。RFC 9682
  • 採用判断には、モデルの入力バイト列、実際のパーサ、生成物、配備先、電文の判定を結ぶ記録が要る。解析成功やコンパイル成功を、後工程の受領証明に流用しない。

公開された規則と、導入された能力

標準が公開されても、それだけで現場のパーサが更新されるわけではない。RFCを参照する設計書が承認された日に、ビルド環境や配備先まで切り替わったとは限らない。問うべきは更新の告知が届いたかではなく、誰が何を受け取り、どの能力を確かめたかである。

ABNFは構文を記述する記法であり、CDDLはCBORやJSONのデータ構造を表す言語だ。CDDLソースを解析する処理と、そのモデルに従って電文を検証する処理では、入力も判定対象も違う。RFC 5234、RFC 8610 §1

2024年11月公開のRFC 9682は、規範的な付録Aの収集ABNFで、RFC 8610付録Bの収集ABNFを置換した。RFC 8610全体を廃止したのではない。文字の許容範囲（6278）、文字列エスケープ（6527）、出版時に失われたバックスラッシュ（6526）、バイト文字列の扱い（6543）、タグ・単純値の数値解釈（6575）に関わるErrataに対処した。RFC 9682 §§1–3

加わった \u{hex} はUnicodeスカラー値を16進表記する構文だ。後方互換性を、古いプロセッサへの対応機能の自動追加と読んではいけない。新しい記法を使う仕様は、既存実装の更新を必要とし得る。また、古い道具が一度通したという事実だけで、旧仕様への適合が証明されるわけでもない。RFC 9682 §2

最初の受領記録には、原稿と読み手を残す

最初の引き渡しは、標準本文から実装側の採用判断への引き渡しである。参照する規定、許容する構文、対象環境を明らかにする。次が、モデルからパーサへの引き渡しだ。ここではファイル名や版ラベルではなく、実際に渡した正確なバイト列を保存し、ハッシュで照合できるようにしたい。ただしハッシュだけでは、誰が承認し、どこで使うことを認めたかは分からない。

読み手についても、製品名だけでなく、実際に起動したパーサの版、実行条件、使う構文の受理能力を記録する。版番号は追跡の索引であって、能力確認の代用品ではない。入力の識別子と解析結果を結び、失敗なら診断を、成功なら文字列がどの値として解釈されたかを残す。以上は、工程間の確認を可能にする運用設計の提案だ。

たとえば "⌘" と "\u{2318}" は、対応する処理系では同じテキスト値を表せる。しかし、ソースのバイト列は異なる。等価なデコード値だからといって、同じ原稿を受理したことにはならない。書き換えを挟むなら、変換前後とパーサへの実入力を分けて保存する必要がある。RFC 9682 §2.2

CDDLはUTF-8を使い、その処理にUnicode正規化を含めない。見た目を整えた表示を、原本の代わりにしてはいけない。RFC 8610 §3.1 またCBORはテキスト文字列とバイト文字列を区別し、テキストの文字をエスケープせずUTF-8で符号化する。CDDLの新エスケープが、そのままCBOR電文上の新構文になるわけではない。RFC 8949 §3.1

解析の成功を、生成物の証明にしない

生成バリデータを使う構成を考えよう。解析成功は、制約を解釈するスキーマコンパイルの成功ではない。その先のバリデータ生成も、独立した結果として記録する。工程ごとに入力、処理器と設定、結果、生成物の識別子を結ぶ。コンパイルが完了したことと、意図した制約が生成物に正しく実装されたことは、別に確かめるべきだ。

自動的なデータ検証はCDDLの用途の一つである。RFC 8610 §4.2 だからこそ、生成されたコードには、受理すべき電文と拒否すべき電文を与え、期待した判定との対応を調べたい。試験対象はモデルだけでなく、その生成物でなければならない。

再構築も同じ考え方で扱う。同じ入力と固定した条件から生成物を再現できるかを調べ、差分が出れば説明を求める。ただし、再現性は意味上の正しさではない。同じ誤りを再生成する可能性までは排除しないし、限られた試験で未試験の入力まで等価だと証明できるわけでもない。

最後の受取人は、動いているプロセス

次の引き渡し先は、バリデータを使う配備済みコンシューマである。生成物の保存記録、配布イメージの内容、稼働プロセスが実際にロードしたものを照合する。生成コードだけを使う構成なら、コンシューマ自身がCDDLを読むとは限らない。そこで問うのはパーサの設置状況ではなく、どの解析・生成履歴を持つ成果物が動いているかだ。

さらに実行時メッセージのバイト列、送受信側の版と条件、検証結果、アプリケーションの処理結果を結ぶ。RFC 8949は、CBORの構文に合う「well-formed」、CBORの意味的制約も満たす「valid」、アプリケーションの追加要求に合う「expected」を区別している。モデルの解析成功は、この電文側のどの判定も代行しない。RFC 8949 §1.2

相互運用性の観測も、こうした履歴とは別の記録だ。通信が成立しても、言えるのは試した組合せと条件の範囲までである。仕様上受理されるはずの電文が拒否されれば、上流の成功だけで十分だという見込みを反証し得る。それだけでパーサが原因だと断定せず、どの引き渡しまで整合しているかを戻って調べる。

RFC 9682も、更新済みと未更新の道具が混在する際の解釈の混乱に注意を促し、モデルの出所と適用可能性を確かめ、ソースコードと同様に扱うよう勧める。これは特定製品の脆弱性や事故を示す報告ではない。RFC 9682 §4