要約

  • PDPArchiveの第03版は、容器をPOSIX paxと定め、gzipまたはZstandardによる圧縮と、ひとつの論理的な書き出しを複数ファイルに分ける方法を示した。
  • 取込側は書き込み前に絶対パスや..を含む経路、特殊な種類の項目を拒否し、アーカイブ中の所有者・モードビット・拡張属性・ACLを新しいファイルに適用してはならない。

引っ越し箱に新居の鍵は入れない

IETFのmailmaint作業部会は、メール、連絡先、予定表などを共通の形で輸出入できるようにしようとしている。一つ前の版は中身の形式を詳しく扱った。新しい版は入れ物を決める。paxはtar系の形式で、拡張されたパス名やサイズを扱える。書き出し側はpaxを使い、通常のファイルかディレクトリーだけを収める。これはIETFの記録では作業部会のInternet-Draftであり、実運用の移行報告ではない。

ファイル名は、受け手の機械でどこへ書くかを左右する。草案はUTF-8の相対パスを要求し、.や..の経路要素、ひとつのアーカイブ内の重複名を認めない。取込側も書き込む前に絶対パス、親ディレクトリーへの移動、通常ファイルとディレクトリー以外を拒否する。さらに所有者、権限ビット、拡張属性、アクセス制御リストは持ち込まず、受け手自身の初期設定でファイルを作る。旧サービスが内容を送れても、新サービスのファイルの持ち主までは決められない。

名前の衝突は見た目より厄介だ。箱の中ではInboxとINBOXが別でも、大文字小文字を区別しない保存先では同じ場所になる。Unicodeの正規化でも別表記が重なる。草案は書き出し側に衝突しにくい名前を求め、取込側には重複名を黙って上書きするのではなく拒否するよう勧める。移行が成功したように見えて片方のフォルダーが消えるなら、利用者にとって持ち出しは未完成だ。

大きなフォルダーは複数の箱に分けられる。各部品は単独で読める必要があり、archive.jsonを持つ。全体の記述はpartとfinal以外そろえる。分割された同じフォルダーはUIDとメタデータを共有し、削除項目のremoved一覧を各部に載せる。取込側はこれらを一つに結合しなければならない。箱の表面の名前より、フォルダーのUIDが帰属の手掛かりになる。

圧縮しない形とgzipは取込側が受け入れる必要があり、Zstandardは受け入れを推奨する。草案は展開後の総量、項目数、一項目の大きさを考慮するよう促すが、一律の数値上限は置かない。取り込まれた役割や共有権限の情報は改変され得るとも指摘する。ファイルを読めることと、その中の権限の主張を信じることは別の判断だ。

次に必要なのは作業部会の正式な決定と、別々の輸出入実装で同じ結果が得られるかという試験である。第03版は、その試験で問うべき境界を明瞭にした。

出典：第03版、第02版、IETFの状態、RFC 1952、RFC 8878。