Resumen

  • La revisión 03 del borrador elige POSIX pax para empaquetar datos personales, permite comprimir con gzip o Zstandard y regula la división de un archivo lógico en varias partes.
  • El importador debe rechazar rutas absolutas, segmentos .. y tipos de entrada especiales antes de escribir en disco. También debe ignorar propietario, bits de modo, atributos extendidos y ACL transportados en el paquete.

El dato cruza la puerta; la autoridad del fichero, no

El grupo de mantenimiento del correo de la IETF trabaja en un formato común de salida y entrada para mensajes, agendas, contactos y otros datos personales. La versión anterior describía buena parte del contenido. La nueva define el embalaje: pax, de la familia tar, con metadatos ampliados para nombres y tamaños. El exportador tiene que usar ese contenedor y limitar sus entradas a ficheros ordinarios y directorios. Datatracker lo mantiene como borrador de un grupo de trabajo; no hay todavía RFC aprobado ni prueba de que una migración concreta haya seguido estas reglas.

Una ruta de archivo no es una simple etiqueta. Indica dónde podría escribir el receptor. El texto exige nombres UTF-8 y relativos, sin segmentos . o .. y únicos dentro de cada parte. Antes de tocar el sistema de archivos, el importador debe descartar rutas absolutas, subidas al directorio padre y entradas que no sean fichero o carpeta. La prohibición continúa después de extraer el contenido: el nuevo servicio no puede aplicar permisos, dueño, atributos extendidos ni listas de control de acceso enviados por el anterior. Usará sus propios valores por defecto. El derecho de sacar datos no entrega al proveedor saliente el mando del disco ajeno.

Incluso una caja bien formada puede perder piezas por un choque de nombres. Inbox e INBOX son distintos en el paquete, pero pueden apuntar al mismo sitio en un sistema que ignora mayúsculas. Diferentes formas Unicode también pueden normalizarse al mismo nombre. El borrador pide al exportador que intente evitar esas colisiones y aconseja al importador rechazar nombres duplicados antes que sobrescribir algo en silencio. Para la persona que se marcha, una importación que parece exitosa y pierde una carpeta es una portabilidad de escaparate.

El borrador permite varios paquetes para un único export. Cada parte debe poder leerse por separado y llevar su archive.json, con part y final como diferencias previstas. Una carpeta enorme repartida entre cajas conserva su UID y metadatos coherentes; la lista removed aparece en cada copia. El importador debe unirlas en una carpeta, no duplicarla. La identidad estable del directorio pesa más que el nombre que ve un operario en la tapa.

Se admiten paquetes sin comprimir, gzip y Zstandard. El receptor debe aceptar los dos primeros y debería aceptar Zstandard. El texto recomienda vigilar tamaño expandido, número de entradas y tamaño de cada una, sin fijar una cifra universal. Además recuerda que los roles y permisos incluidos en una subida pueden haberse alterado: el nuevo servicio tendrá que decidir qué afirmaciones de acceso acepta.

La próxima noticia será una decisión de estandarización o un ensayo de interoperabilidad que muestre cómo se comportan receptores reales ante rutas, partes y permisos. Por ahora, la revisión convierte la frontera de confianza en una lista concreta de obligaciones propuestas.

Fuentes: versión 03; versión 02; estado IETF; RFC 1952; RFC 8878.