Resumen

  • RFC 2083 convirtió cada letra del tipo PNG de cuatro bytes en una propiedad: crítico o auxiliar, público o privado, reservado o vigente, inseguro o seguro para copiar.
  • El cuarto bit gobernaba al editor, no certificaba el contenido. Tras cambiar datos críticos, un chunk auxiliar desconocido e inseguro debía descartarse; uno seguro podía conservarse.
  • La supervivencia del chunk y un CRC correcto probaban custodia limitada de bytes, no singularidad del nombre privado, vigencia semántica, autoría, permiso, privacidad ni exactitud de la imagen.

Un editor abre una imagen, cambia la paleta y vuelve a codificar IDAT. Entre los chunks conocidos aparece uno que no sabe interpretar. Puede leer su longitud, saltar sus datos y validar el CRC, pero no sabe si guarda un histograma, una calibración, una nota de derechos o un estado propietario del flujo de trabajo. Debe decidir sin fingir conocimiento.

RFC 2083 resolvió esa incertidumbre mediante una gramática pequeña. Los cuatro bytes del tipo solo usan letras ASCII, pero el programa debe tratarlos como valores binarios. El dato operativo es el bit 5 de cada byte, no la idea lingüística de mayúscula o minúscula.

El nombre del chunk contenía cuatro contratos

La primera letra separa chunks críticos y auxiliares. Una mayúscula indica que el contenido puede ser necesario para interpretar la imagen: ante un tipo crítico desconocido, el decodificador debe reconocer que no puede seguir con seguridad. Una minúscula permite ignorar el tipo auxiliar desconocido y mostrar la imagen. Auxiliar no significa irrelevante. Una coordenada, una atribución o una calibración puede ser esencial para una decisión humana sin ser necesaria para extraer píxeles.

La segunda letra divide los nombres públicos y privados. Es una comodidad administrativa, no una orden funcional para el decodificador. Evita que una futura asignación pública invada el espacio privado, pero no evita que dos empresas usen el mismo nombre privado con significados incompatibles. Por eso el RFC recomendó incluir identificación adicional dentro de los datos privados.

La tercera letra estaba reservada. La versión 1.0 exigía mayúscula, aunque pedía que los decodificadores antiguos no fallaran solo por encontrar minúscula: una versión futura podía definirla.

La cuarta letra asigna el tratamiento editorial. Minúscula significa seguro para copiar; mayúscula, inseguro. bLOb, el ejemplo del RFC, representa un chunk auxiliar, público, con el bit reservado en cero y seguro para copiar. TEXT y Text no son dos estilos del mismo nombre, sino códigos binarios diferentes.

Seguro para copiar no era seguro para creer

Un chunk auxiliar desconocido marcado como seguro puede atravesar una edición aunque cambien datos críticos. Si está marcado como inseguro y el editor añade, elimina, modifica o reordena chunks críticos, debe excluirlo. Si solo toca chunks auxiliares, puede conservarlo.

La extensión declaraba así su dependencia sin exigir que cada editor entendiera su formato. El autor del chunk elegía la clase; el editor conocía el alcance de su modificación. La regla también limitaba el diseño: un chunk auxiliar podía depender de datos críticos, pero no debía depender de otro auxiliar. Una dependencia respecto de todo el archivo no cabía en un solo bit.

La actual Tercera Edición de PNG del W3C mantiene esta frontera y añade precisión de orden. Un editor no puede mover un chunk desconocido e inseguro respecto de los críticos. Incluso uno seguro no puede cruzar libremente la frontera de IDAT. “Copiar” nunca significó “reubicar sin condiciones”.

El CRC respondía por daños, no por significado

El CRC cubre el tipo y los datos de cada chunk. Detecta corrupción accidental en ese ámbito. RFC 2083 incluso propuso que un chunk privado almacenara el CRC de PLTE para detectar cambios en la paleta de la que dependía.

El resultado no autentica a un autor ni resuelve una colisión de nombres privados. Tampoco prueba que una descripción continúe siendo válida después de cambiar la imagen. Si un programa modifica datos y recalcula el CRC, solo demuestra que el nuevo conjunto es coherente con la regla de suma.

La diferencia importa porque una imagen puede verse limpia y seguir conservando información. La Tercera Edición advierte que algunos programas ocultaron píxeles mediante transparencia o cambiaron dimensiones sin eliminar datos recuperables, y que eXIf puede llevar GPS. La apariencia no prueba borrado. El bit safe-to-copy tampoco es una etiqueta de privacidad: únicamente declara dependencia respecto de los datos críticos.

Compatibilidad por función, no por un número global

RFC 2083 eliminó deliberadamente un número de versión general. Un valor alto habría hecho que lectores antiguos rechazaran archivos que no usaban ninguna función crítica desconocida. También habría sido inútil para extensiones privadas.

La compatibilidad se decidía chunk por chunk. Una función auxiliar desconocida podía ignorarse; una función crítica desconocida detenía el procesamiento. El documento del W3C sobre extensiones PNG sigue publicando chunks adicionales fuera del núcleo. Registro, reconocimiento e interpretación siguen siendo estados distintos.

La idea posterior de Lu Heng sobre especificación inicial mínima y decisión futura localizada sirve como lente retrospectiva: una gramática común estrecha permitió decisiones locales verificables sobre funciones futuras. No es una afirmación de influencia histórica sobre el RFC de 1997.

Su distinción entre capas de realidad y poder simbólico también aclara la prueba. El bit, la clase de edición y la acción de copiar o eliminar son ejecutables. “Oficial”, “verdadero”, “autorizado” o “seguro” son afirmaciones adicionales.

Una auditoría debe conservar hash de entrada, inventario ordenado de chunks, bytes de tipo, interpretación de los cuatro bits, resultados CRC, conjunto de tipos conocidos por el editor, cambios críticos y auxiliares, decisión para cada desconocido y hash de salida. Cuando un metadato sostiene una afirmación pública, hacen falta además su esquema, responsable, procedencia y una razón para seguir aplicándolo.

La cuarta letra no certificaba el metadato. Decía quién debía asumir la decisión de conservarlo.

Fuentes