Resumo

  • A revisão 03 do PDPArchive adota POSIX pax como contêiner, admite gzip ou Zstandard e explica a divisão de uma exportação lógica em vários arquivos.
  • O importador deve rejeitar caminhos absolutos, segmentos .. e tipos especiais antes de gravar arquivos. Também deve usar suas próprias configurações de permissão e propriedade, sem aplicar os atributos trazidos pelo pacote.

Uma caixa de mudança não recebe chave de administrador

O grupo de trabalho de manutenção de correio da IETF procura um formato comum para mover mensagens, calendários, contatos e outros dados pessoais. A versão 02 já detalhava muito do conteúdo. A atualização especifica o invólucro: pax, da família tar, capaz de transportar metadados estendidos de nomes e tamanhos. Exportadores devem usá-lo e incluir apenas arquivos comuns ou diretórios. No Datatracker, o documento continua sendo rascunho de grupo de trabalho; não há RFC aprovado nem medição de uma migração real.

O nome de um item vira o endereço de gravação no destino. O texto exige UTF-8, caminhos relativos, ausência de segmentos . e .. e nomes únicos dentro de cada parte. O receptor tem de verificar cada entrada antes de escrever, recusando caminhos absolutos, saltos para diretórios superiores e qualquer tipo que não seja arquivo comum ou pasta. A fronteira também vale para metadados de segurança: bits de modo, proprietário, atributos estendidos e listas ACL do arquivo exportado não podem ser aplicados. O novo serviço cria arquivos com seus próprios padrões. Transportar o dado não é nomear o dono do disco alheio.

Um choque de nomes pode passar despercebido na caixa e acontecer na bancada. Inbox e INBOX são nomes diferentes num arquivo, mas podem colidir num sistema que ignora maiúsculas. Formas Unicode distintas também podem convergir após normalização. O rascunho manda o exportador tentar evitar isso e recomenda ao importador rejeitar nomes duplicados em vez de perder um item silenciosamente. Para o usuário, uma importação que anuncia sucesso mas apaga uma pasta é uma saída apenas decorativa.

Uma exportação grande pode vir repartida. Cada parte precisa ser legível por si e trazer archive.json, com part e final distinguindo o conjunto. Se uma pasta cruzar duas partes, seu UID e demais metadados permanecem coerentes, e a lista removed se repete em cada cópia. O importador deve fundir essas partes numa pasta, não produzir duas. É o identificador estável que une a coleção; o nome aparente da caixa não basta.

O pacote pode chegar sem compressão, em gzip ou Zstandard. Os dois primeiros casos são obrigatórios para o importador; Zstandard é recomendado. O documento orienta a considerar tamanho total expandido, número de entradas e tamanho individual, sem impor teto numérico. Também avisa que papéis e compartilhamentos carregados no upload podem ter sido alterados. O receptor precisa decidir se essas alegações de acesso merecem confiança.

A próxima evidência útil será a decisão do grupo de trabalho e um teste entre exportadores e importadores que mostre o tratamento de partes, caminhos e permissões. Por enquanto, a revisão escreve as obrigações propostas com precisão suficiente para serem cobradas.

Fontes: revisão 03; revisão 02; estado IETF; RFC 1952; RFC 8878.