要約

  • RFC 9512 は、交換とコンテンツネゴシエーションのために application/yaml と +yaml を YAML 表現の識別子として登録している。
  • その識別は、完全なストリームの受理、パーサの安全な設定、意味の妥当性、権限、実際の効果を証明しない。

荷札に「冷蔵」と書かれていても、荷物が検品済みか、誰が受領してよいか、どの棚に置くかは別に決めなければならない。Content-Type も同じである。これは処理の入口で役立つ標識であり、標識そのものが運用上の決裁になるわけではない。それにもかかわらず、自動化が密になるほど、形式を読めたという事実が、内容を信頼して実行できるという結論へ静かに膨らみやすい。

RFC 9512 が定めるのは、その膨張を防ぐのにちょうどよい狭さである。application/yaml と構造化構文接尾辞 +yaml は、YAML で直列化された表現を識別するための共通語である。送信者と受信者が形式を取り違えずに済む。しかし RFC は、当該文書がどの受信者にも安全だとは言わないし、そこに書かれた要求を実行する権限を送信者に与えない。

バージョンの扱いだけでも、形式と方針は分かれている。登録はバージョン非依存であり、YAML 文書はディレクティブでバージョンを示せるが、媒体型が受信側の採用バージョンを選ぶことはない。何を許容するかはサービス自身が決める。+yaml を用いる特殊な型も、YAML 系であることは示せるが、フラグメント識別子の意味はその型自身が定義しなければならない。親族関係はわかっても、個別契約まで決まるわけではない。

ストリームはこの差を実務に引き戻す。YAML はゼロ個以上の文書を含むことができる。RFC 9512 は、一文書を期待するアプリケーションが複数を受け取った場合、残りを黙って捨てずにエラーとすべきだとする。重要なのは、複数文書が悪いという一般論ではない。どこまでを入力として審査したのかを明確にすることだ。先頭だけで変更を始め、末尾を判断の外に置くなら、アプリケーションは未記録の範囲決定をしている。

安全性の節も受信側の責任を具体的に残している。タグは一部の実装で任意コード実行につながり得るため、RFC は既定で無効にすることを勧める。表現グラフは循環し得るし、構築時に指数的に膨らむこともある。したがって検証と再帰・資源の上限が必要になる。増分解析では、後からエラーが出る前に部分結果が返ることがあるので、処理を始める前にストリーム内の全文書を検査すべきだと RFC は述べる。これらは YAML 全体への判決ではない。実装の姿勢をローカルに持たなければならない理由である。

証跡を扱う組織にとっては、再符号化の注意も重い。空白やアンカーが変われば署名検証に影響し得る。YAML から JSON への変換はコメント、ディレクティブ、エイリアスノードを失うことがあり、複数文書、非 UTF-8、文字列でないキー、循環、.inf、.nan、タグは相互運用を難しくし得る。見た目が似た構造になったからといって、署名対象と同一の証拠であるとは限らない。受信バイト列、解釈された構造、検証、承認、観測結果を分けて残す必要がある。

責任ある流れは、標識を通行証にしない。まず表現を識別する。次に受理するバージョンとパーサ設定で完全なストリームを検査する。その後にスキーマとローカルな意味を評価し、別の権限主体が効果を認める。最後に、実際に何が変わったかを観測する。この順番なら自動化は速いまま、各判断の持ち主が消えない。

Heng Lu の最小の共通仕様と局所的な将来判断という考え方は、ここで実用的である。共通にすべきなのは表現を識別する事実まででよい。損失や変更を引き受ける判断まで、標準名に預ける理由はない。動くコードは重要だが、解析に成功したというログは、実施の許可や実施済みの証明とは別の記録である。

出典