Résumé

  • La révision 03 du projet mailmaint, datée du 28 octobre, fixe le conteneur au format POSIX pax et autorise plusieurs archives pour un même export. Un grand dossier peut être réparti entre plusieurs parties.
  • L’importateur doit réunir ces morceaux à partir du même identifiant de dossier et de métadonnées cohérentes. Il doit rejeter les chemins dangereux et les entrées spéciales; il ne doit pas appliquer les propriétaires, modes, attributs étendus ou listes de contrôle d’accès contenus dans l’archive.

Deux fichiers, une seule boîte aux lettres

Le scénario le plus instructif n’a rien de spectaculaire. Une personne quitte un fournisseur de messagerie avec une boîte volumineuse. Le téléchargement est découpé pour que l’échec d’une partie n’oblige pas à recommencer l’ensemble. La première partie contient les messages anciens; la seconde porte les messages récents. Les deux décrivent le même dossier. Un importateur naïf les traite comme deux dossiers distincts. Il peut annoncer « importation terminée » tout en laissant au client une boîte scindée, des recherches incomplètes et des règles de classement ambiguës.

Le nouveau texte ne laisse pas cette identité au hasard du nom affiché. Chaque partie doit pouvoir être lue seule et contenir son propre archive.json, dont les champs part et final indiquent la place dans l’ensemble. Si un dossier apparaît dans plusieurs parties, chaque copie de folder.json énumère seulement les éléments de sa partie, mais les autres champs restent identiques. Le uid du dossier est commun. L’importateur doit fusionner le contenu, pas créer des doublons. La liste des éléments supprimés doit aussi être répétée. Il s’agit de préserver un état logique au-delà des limites d’un fichier de téléchargement.

La révision 03 choisit le format pax, extension de tar capable de porter des chemins internationalisés et des tailles supplémentaires. Le producteur ne peut inclure que des fichiers ordinaires et des répertoires. Il ne peut glisser ni lien symbolique, ni périphérique, ni autre type spécial dans ce conteneur. Les noms doivent être des chemins relatifs en UTF-8, sans segment . ou ... Le texte connaît même le piège des systèmes de fichiers qui ne distinguent pas majuscules et minuscules, ou qui normalisent Unicode. Deux noms différents dans l’archive peuvent finir au même endroit sur le disque. L’exportateur doit tenter d’éviter cette collision; l’importateur devrait la rejeter plutôt que sacrifier silencieusement un élément.

La permission n’est pas une pièce jointe

Le changement de fournisseur pose une autre question: qui obtient accès aux données reconstituées? Une invitation de calendrier peut nommer plusieurs personnes. Un dossier exporté peut porter des rôles ou un champ shareWith. Rien de cela ne confère automatiquement un droit dans le service destinataire. Le projet dit que les contrôles d’accès de la source ne voyagent pas nécessairement avec les données; les indications importées peuvent avoir été altérées. Le nouveau service doit juger leur fiabilité dans son propre modèle d’autorisation.

La règle sur le système de fichiers est plus tranchée. Avant toute écriture, l’importateur doit contrôler les noms et écarter les chemins absolus, les remontées vers le dossier parent et les types d’entrée autres que fichiers ou répertoires. Il ne doit reprendre ni bits de mode, ni propriétaire, ni attributs étendus, ni ACL du paquet. Les fichiers prennent les paramètres locaux du destinataire. Le format facilite le transport de l’objet; il refuse de laisser l’expéditeur commander les permissions de la machine d’accueil.

La synchronisation reste limitée. Pour les contacts, tâches et objets de calendrier visés, l’export doit conserver uid et updated; l’importateur cherche le même identifiant et évite de modifier une entrée suffisamment semblable juste pour changer son horodatage. C’est un progrès contre les doublons, mais l’appréciation de « suffisamment semblable » appartient toujours au programme d’arrivée. La spécification décrit une propagation à sens unique, sans régler tous les conflits possibles entre deux comptes actifs.

Le fichier peut être livré brut, compressé avec gzip ou avec Zstandard. L’importateur doit accepter le brut et gzip; Zstandard est recommandé. Plus l’archive concentre de messages, de rendez-vous et de pièces jointes, plus elle concentre aussi des données sur des correspondants qui n’ont pas demandé ce transfert. Le texte avertit que la décompression, le nombre d’entrées et leur taille peuvent épuiser les ressources de l’importateur. Un service sérieux doit pouvoir ouvrir la valise sans lui donner les clés de toute la gare.

La version précédente n’avait pas fixé ces règles de conteneur et de division des dossiers. La fiche IETF désigne encore un Internet-Draft du groupe mailmaint, pas une norme publiée ni une migration observée. Les protocoles qui permettraient de demander et de transmettre l’archive restent hors de ce texte. Un format précis ne force aucun service à produire un export complet au bon moment.

Sources