要約

  • 9月19日付のPCAP草案第09版は、従来形式をHistoricのRFCとして記録し、application/pcapの登録を求める。まだRFCでも登録済みのメディアタイプでもない。
  • 9月23日、担当Area Directorは審査への回答が見当たらないとして状態を「Revised I-D Needed」に戻した。審査では既存のapplication/vnd.tcpdump.pcapとの関係と、The Tcpdump Groupを変更管理者とする理由を尋ねている。
  • 書式の記述、メディアタイプの管理、LinkType番号の割り当ては別々の手続きだ。

既存登録を抜きにして新しい名前だけを語ると、判断を誤る。IANAには2011年登録のapplication/vnd.tcpdump.pcapがあり、著者兼変更管理者はGuy Harrisだ。一方、OPSAWGの草案は標準ツリーのapplication/pcapを提案し、その変更管理者をThe Tcpdump Groupと記す。古い登録への参照はあるものの、新旧の名前が併存するのか、一方が他方に代わるのかは明記されていない。審査者が確認を求めたのは、この説明の欠落である。

8月の審査は、旧版にあったナノ秒タイムスタンプ用マジックナンバーの誤記も指摘した。9月版のバイト列は修正されている。したがって、23日の状態変更を「修正が却下された」と読むのは正しくない。公開履歴が示すのは、審査全体への回答が確認できず、改訂を要する状態へ戻ったことだ。最終承認やIANAの登録は確認できない。

Historicという区分にも射程がある。PCAP v2はファイル内で一種類のLINKTYPEを使い、ファイルを単純につなぐのに向かない。拡張性を狙うpcapngも別の作業部会草案として進む。しかしPCAP草案は、従来形式のファイルにも新しいリンク層タイプを含められると説明する。さらにLinkTypeの一覧をIANAへ移す案は別草案だ。三つを一括りに「移行済み」と扱うことはできない。

保存や交換を担う側に必要なのは、入力として受け取る名称、出力時に付ける名称、それぞれの登録版と変更管理者、そしてLinkTypeを解釈する一覧の版を結び付けた記録だ。Historicの表示はファイルの来歴や収集の適正さを証明しない。二つの名称の関係を明示すれば、従来ファイルの互換性を守りながら変更責任も追える。

出典