要約

  • IETF 84のAVTCOREとMMUSICの議事録は、拡張子なしの公開リンクから取得できなかった一方、rsyncで同期した会議資料には対応するファイルが存在した。
  • IETFスタッフは、サーバーが試す拡張子をPDF、HTMなど実データにある形式へ広げた。9月6日の限定的な確認では、両方の元のURLがHTTP 200を返した。
  • ファイルがどこかにあること、公開経路で届くこと、意図したオブジェクトが返ること、宣言済みの版とバイトが一致することは、それぞれ別の状態である。
  • 会議、セッション、資料種別、安定識別子、具体的パス、形式、サイズ、ハッシュ、版、訂正・後継関係、最終確認時刻を結ぶ機械可読マニフェストを公開すべきだ。
  • このマニフェストは議事録を置き換えず、内容の正しさも認定しない。リンク解決という運用上の選択を検証可能にするだけである。

「ない」のではなく、「たどれない」

8月29日、Jörg OttはIETF 84の会議資料からAVTCOREとMMUSICの議事録へ進めないと報告した。無作為に選んだ他のグループは開けたという。彼の最初の報告には、自動リンク検査の提案と、条件の悪い遠隔地のモバイル接続で調べている際にCloudflare 1015を受けたという記録もある。

ここで確かめられたのは、ある利用者にとって公開経路が機能しなかったことだ。削除や改ざんの証拠ではない。Carsten Bormannは別の面を調べ、68GBあるというrsync同期済みの会議資料の中に両グループのファイルを見つけた。この観察は一つのスナップショットに限られ、全歴史資料の完全性やバイト列の継続性までは保証しない。それでも今回の二件では、保存の有無とウェブ到達性が異なる問いだと分かる。

Ottは続報で、問題をPDFとHTMの拡張子の違いに結び付けた。9月2日、IETFスタッフが仕組みを説明した。古い会議ページは拡張子を付けずに議事録を指していたが、ウェブサーバーが候補として試す拡張子は限られていた。そこで、データ中に実在する .pdf、.htm などを含めるよう候補集合を拡張した。報告された二件と、ほかに見つかった複数の例は開けるはずだとした。

同じ返信は、レート制限を通常の閲覧では到達しにくい高い値に設定していると説明し、再発時にはCloudflare Ray IDの提示を求めた。これはOttが経験した1015を否定しないし、会議資料全体の障害を示すものでもない。解決規則の不一致とアクセス制限は別の分類に置く必要がある。

正常応答にも同一性の曖昧さは残る

9月6日に低頻度で確認すると、拡張子なしのAVTCORE議事録URLは242,140バイトのPDFを返し、Last-Modified は2012年だった。観測したSHA-256は 937e224285a7eae6bf1cbeb9106e5eb0bf4df7b34bf02a10587f6da9ef4e49e1 である。MMUSIC議事録URLはHTMLを返し、こちらも2012年の更新時刻とSHA-256 88a6f5fd2d5459bfa1c66dc7d24b54e441a4e05507e009adf99409486c19a214 が得られた。

これは9月6日の観測値であって、永続的な正本宣言ではない。avtcore.html と mmusic.html を直接指定したURLも正常応答したが、内容は議事録ではなくグループ概要であり、バイト列も更新時刻も異なった。論理名に .html を補えばよいという推測は、実在する別オブジェクトへ利用者を誘導し得る。

IETF 84の会議資料索引は、人が過去の会合をたどるための入口だ。過去の不統一な命名を吸収する拡張子フォールバックは、その目的にかなう。しかし、正常応答は次の四点を一度に証明しない。

  1. 保存：そのセッションに対応する資料がストレージやミラーに存在する。
  2. 到達：公開リクエストから現在何らかの応答を取得できる。
  3. 同一性：返ったものがグループ概要などではなく、宣言された議事録である。
  4. 完全性：返ったバイトが、ある時点で宣言された版と一致する。

今回の変更が直接改善したのは到達性だ。同期コピーは二つのファイルの存在を裏付けた。メディア形式、長さ、ハッシュは同一性と完全性を調べる手掛かりになる。それらがそろっても、議事録が会合を完全かつ正確に表すか、手続上承認されたかまでは決められない。

提出済みと公開済みの間にも状態がある

RFC 2418は、各ワーキンググループ会合について報告すること、議長が議事録作成を確実にすることを求め、公開メーリングリストのアーカイブを作業記録の一部として扱う。重要な決定とその履歴も要約して保存すべきだとしている。議事録への経路は、単なるサイト保守ではなく、手続の記憶へのアクセスである。

現在の会議資料に関する議長向け案内も議事録提出を必須とし、受理形式、提出期限、訂正期間を説明する。8月13日に送られたIETF 126の事務局リマインダーは、14日の締切前に議事録が未提出だったセッションを列挙し、9月8日の訂正期限を示した。これは途中時点の一覧であり、最終的な欠落を証明しない。未提出、受領済み、公開済み、訂正済み、旧版化、現在到達可能という状態が別々であることを示す。

人向けリンクと機械向けの厳密さを両立させる

最小限の完全性マニフェストには、会議番号、グループまたはセッション、資料種別、安定した論理識別子を載せる。その識別子を、具体的なオブジェクトパス、MIMEタイプ、バイト長、暗号学的ハッシュに結び付ける。さらに受領・公開日時、版、現行・訂正・旧版の状態、後継版への参照、最後に公開リンクを確認した時刻、到達方法を変えた修正や移行の履歴を記録する。

訂正時には新しい版と明示的な後継関係を追記する。古いハッシュが黙って新しいバイトを意味するようにしてはいけない。人向けの古いリンクは現行版へ案内し続けてもよい。厳密な引用が必要な利用者には各版の固定した識別情報が残る。

公開する来歴は必要最小限とし、私信、個人のネットワーク情報、認証情報や防御設定は含めない。この目録は新たな議事録ではなく、正確性や権威を判定する装置でもない。運用上の主張を検証できる形に限定する。

その上で、公開監査は負荷を避けて間隔を空けて行い、失敗を「資料不在」「オブジェクトはあるがリンク未解決」「誤った候補」「形式不一致」「アクセス制限」「ハッシュ不一致」「旧版」「不明」に分ける。緑の判定は、記録した時点で宣言オブジェクトを取得し、形式、長さ、ハッシュが一致した、という範囲だけを意味する。

出典

  1. Jörg OttによるIETF 84議事録の問題報告
  2. Carsten Bormannによるrsyncコピーの確認
  3. PDF・HTM拡張子についての続報
  4. IETFスタッフによる説明と修正
  5. IETF 126議事録の提出リマインダー
  6. IETFの会議資料ガイド
  7. RFC 2418
  8. IETF 84会議資料
  9. AVTCORE議事録URL
  10. MMUSIC議事録URL
  11. Lu Hengによるランニングコード優先論