Summary

  • Revision 03 of the Personal Data Portability Archive draft chooses POSIX pax for the container, permits gzip or Zstandard compression and explains how one logical export can occupy several files.
  • It requires an importer to reject unsafe archive entry paths and special entry types before filesystem writes, and to create files under its own defaults rather than applying permissions, ownership, extended attributes or ACLs supplied by the archive.

A moving box is not a set of instructions

The Mail Maintenance working group is trying to give personal mail, contacts, calendars and related data a common travel format. The previous draft described the material inside the box. The 28 October revision specifies the box itself: a POSIX pax archive, a tar-family format that can carry extended path and size metadata. Exporters must use pax and put only regular files or directories into it. The working-group draft is still listed by Datatracker as an Internet-Draft, not an approved RFC or a record of a deployed migration.

Once a file can be imported, its name becomes a decision about where the receiving service will write. The draft requires UTF-8 relative names without . or .. path segments and with no duplicate names inside a single archive file. It tells importers to validate before writing, rejecting absolute paths, parent-directory jumps and entries that are neither regular files nor directories. It also forbids importers from applying the archive's mode bits, ownership, extended attributes or access-control lists. The recipient's own defaults govern the files it creates. A portability format carries someone's information; it does not get to appoint the new server's file owner.

The mundane collision is just as revealing. An archive can contain two names that look different in bytes but collapse on a case-insensitive or Unicode-normalizing filesystem. The draft tells exporters to try to keep names distinct across those transformations and recommends that importers reject duplicate named items rather than silently lose one. A folder labelled Inbox and one labelled INBOX can be two entries in a package and one place on the receiving disk. The format has to confront both views.

The box may arrive in several pieces. Each part must be independently readable and contain its own archive.json, with the part and final fields distinguishing the pieces. If a large folder is split, its metadata uses the same UID and consistent fields across parts; the removed list is repeated. The importer must merge those pieces into one folder, not create twins. That is a custody decision as much as a storage trick: the stable folder UID, rather than the label on a carton, says which pieces belong together.

Compression sharpens the receiving duty. The draft permits an uncompressed archive, gzip or Zstandard. Importers must accept the first two and should accept Zstandard. It advises the receiver to consider total expanded size, entry count and per-entry size; it sets no universal numeric ceiling. Its security section separately warns that role or sharing information inside an uploaded archive may be tampered with. A new service has to decide which imported access assertions it trusts, not merely whether the file opens.

The standardization question is now concrete. Can a user leave with mail and calendars in a common package while the recipient keeps control of its paths, permissions and access decisions? Revision 03 gives implementers a set of checks. A published standard and evidence from interoperable importers are still missing; those facts would show whether the boundary survives outside the draft.

Sources: revision 03; revision 02; IETF status; gzip, RFC 1952; Zstandard, RFC 8878.