要約

  • 2026 年 10 月 28 日付の mailmaint 作業部会草案第 03 版は、個人データの容器に POSIX pax を選んだ。一つの論理的な書き出しを複数のアーカイブに分け、巨大なフォルダーも複数巻にまたがらせられる。
  • 取り込み側は同じフォルダー uid と整合するメタデータを使って分割部分を統合する。危険なパスや特殊なエントリーを拒否し、格納された所有者、モード、拡張属性、ACL を新しいファイルに適用してはならない。

同じ「受信箱」が二つになったら移行ではない

大きなメールボックスを二巻に分ける理由は分かりやすい。ダウンロードが途中で失敗しても、全量を最初から送り直さずに済む。しかし受信側が各巻のフォルダー名だけを見れば、「受信箱」を二つ作ってしまう。片方だけを採用すれば、もう片方のメールが見えなくなる。どちらも書き出しの成功通知と両立してしまう事故だ。

草案は名前ではなく識別子を結合点にする。各巻には独立して読める archive.json が必要で、part と final が巻の位置を表す。同じフォルダーを複数巻に置く場合、各 folder.json はその巻に入る項目だけを列挙し、他のメタデータは一致させる。削除済み項目の一覧も複製する。共通の uid を持つ断片は一つのフォルダーに統合する義務がある。利用者に必要なのはファイルを二つ受け取った証拠ではなく、受信箱が一つに戻った結果だ。

第 03 版は POSIX pax 形式も明記した。従来の tar を拡張し、国際化されたパス名や追加のサイズ情報を扱える。格納できるのは通常ファイルとディレクトリーだけで、シンボリックリンクやデバイス項目は認めない。パスは UTF-8 の相対名とし、. や .. の区切りを含めない。アーカイブ内部で別名でも、取り出す先が大文字と小文字を区別しなかったり Unicode を正規化したりすれば同じファイル名に化ける。書き出す側は衝突を避け、受け入れる側は黙って上書きするより重複を拒否すべきだという。

この制約は、異なる運用環境を渡る時に初めて意味を持つ。送信元のディスクで共存できた二つの名前が、移行先では共存できないことがある。可搬性をうたうなら、その差を利用者の紛失として隠してはならない。

旧サービスの共有設定は命令書にならない

草案の第 8.3 節は、受信側がファイルを書き込む前に絶対パス、親ディレクトリーへの移動、通常ファイル・ディレクトリー以外の項目を拒否するよう求める。さらに、アーカイブ内のモードビット、所有者、拡張属性、ACL を適用せず、移行先自身の標準設定でファイルを作るよう命じる。持ち込まれた荷物に、受け入れ施設の鍵を設定させないための線引きだ。

アプリケーションの共有情報も自動的な権限ではない。予定には参加者が記され、オブジェクトには shareWith や役割の情報が含まれうる。元サービスのアクセス制御が確実に移るとは限らず、アップロードされたデータは改変できる。したがって移行先は、その役割情報をどの程度信用し、どのアカウントにどんな権利を与えるかを自分で判断しなければならない。旧サービスの記録を保存することと、新サービスで同じ人に閲覧を許すことは、別の操作だ。

一方向の同期にも同様の判断がある。JSContact、JSTask、JSCalendar の対象オブジェクトは uid と updated を持つ。同じ uid の既存項目が十分似ているなら、単なる再取り込みで更新時刻を書き換えるべきではない。毎回「新しい変更」を作れば、連絡先や予定の重複が増える。ただし何を「十分似ている」とみなすかは実装に委ねられる。共有書式は、同じ判断をすべての事業者に強制する魔法ではない。

圧縮は未圧縮、gzip、Zstandard から選べる。取り込み側は未圧縮と gzip に対応しなければならず、Zstandard への対応も推奨される。圧縮された小さなファイルが展開後に大量のデータや項目を生む可能性があるため、草案は総展開量、項目数、項目ごとの大きさへの注意も挙げる。アーカイブには本人だけでなく、通信相手や招待された人の情報まで集まる。出口を広げる設計は、持ち出しの認可と受け入れ時の処理にも仕事を増やす。

旧版には、この pax 容器と分割フォルダーの規則がまだ確定していなかった。Datatracker上では現在も作業部会の Internet-Draft であり、発行済み RFC や実運用の調査結果ではない。アーカイブを要求・転送するための通信手順は別の仕様の仕事として残る。

出典