Résumé

  • Le RFC 2083 attribuait une propriété à chaque lettre d’un type de chunk PNG : critique/auxiliaire, public/privé, réservé/actuel et dangereux/sûr à recopier.
  • Le quatrième bit réglait le travail de l’éditeur. Après modification des données critiques, un chunk auxiliaire inconnu marqué dangereux ne devait pas survivre ; un chunk marqué sûr pouvait être conservé.
  • Cette conservation et un CRC correct attestaient une garde limitée des octets, non l’unicité du nom privé, l’actualité du sens, l’auteur, l’autorisation, la confidentialité ou la véracité de l’image.

Prenons un éditeur qui recadre et recolore une image. Il reconnaît IHDR, IDAT et IEND, mais découvre entre eux un type qu’il ne connaît pas. Il peut lire sa longueur, passer ses données et vérifier son CRC. Rien de cela ne lui révèle si le bloc décrit une calibration, un histogramme, un état de production ou une affirmation devenue fausse après la retouche.

Le problème utile n’était donc pas de fabriquer une compréhension universelle. Il fallait donner à un ancien programme une décision correcte quand une extension future restait opaque. Le RFC 2083 a placé cette décision dans quatre bits lisibles comme quatre lettres.

Un nom qui était déjà une politique

Chaque chunk contient longueur, type sur quatre octets, données et CRC. Les octets du type appartiennent aux plages ASCII des lettres, mais le logiciel doit les comparer comme des valeurs binaires fixes. Il ne doit pas appliquer les règles de casse d’une langue. Le bit pertinent est le bit 5, valeur 32, dans chaque octet.

La première lettre exprime la criticité. Une majuscule signale un chunk critique : si le type est inconnu, le décodeur ne peut pas affirmer qu’il sait produire une représentation raisonnable. Une minuscule signale un chunk auxiliaire, que le décodeur peut ignorer tout en affichant l’image. « Auxiliaire » ne signifie ni insignifiant ni fiable. Un droit, une calibration ou une localisation peut être décisif pour un utilisateur sans être nécessaire au décodage des pixels.

La deuxième lettre sépare les noms publics et privés. Ce bit n’ordonne aucune opération au décodeur ; il organise les espaces de noms. Il protège les futures attributions publiques contre les noms privés, mais n’empêche pas deux acteurs privés de choisir le même code pour deux sémantiques incompatibles. Le RFC recommande donc d’ajouter une identification dans les données du chunk privé.

La troisième lettre est réservée. La version 1.0 exigeait une majuscule, tout en demandant aux anciens décodeurs de ne pas rejeter automatiquement une minuscule : une version future pourrait lui donner un sens.

La quatrième lettre concerne l’édition. Une minuscule signifie « sûr à recopier » ; une majuscule signifie le contraire. Le nom hypothétique bLOb encode ainsi un chunk auxiliaire, public, conforme au bit réservé et sûr à recopier. TEXT et Text restent deux codes binaires distincts, pas une même étiquette décorée différemment.

« Sûr » décrivait une dépendance, pas une vérité

Un éditeur peut recopier un chunk auxiliaire inconnu marqué sûr malgré des modifications importantes. Si ce chunk est marqué dangereux et que l’éditeur ajoute, supprime, modifie ou réordonne un chunk critique, il doit l’omettre. S’il ne touche qu’à des chunks auxiliaires, il peut encore le conserver.

La règle partageait la responsabilité. L’auteur de l’extension déclarait si ses données dépendaient de l’image critique. L’éditeur savait ce qu’il avait changé. Aucun des deux n’avait besoin d’un registre consulté en temps réel. Mais la grammaire excluait certaines dépendances : un chunk auxiliaire pouvait dépendre des données critiques, pas d’un autre chunk auxiliaire ; une dépendance à tout le flux ne tenait pas dans ce bit.

La troisième édition de PNG du W3C maintient cette architecture et précise l’ordre. Un chunk inconnu dangereux ne peut pas être déplacé par rapport aux chunks critiques. Même un chunk sûr ne peut pas franchir la frontière avant/après IDAT. La sécurité de copie ne donne donc pas une liberté de déplacement universelle.

Le CRC fermait la question des octets, pas celle du sens

Le CRC de chaque chunk couvre son type et ses données. Il aide à détecter une corruption accidentelle. Le RFC envisage même qu’un chunk privé conserve le CRC de PLTE pour savoir si la palette dont il dépend a changé.

Un résultat égal ne désigne pourtant ni l’auteur ni l’usage légitime. Il ne révèle pas une collision de noms privés. Il ne dit pas qu’une calibration décrit encore les pixels retouchés. Et recalculer le CRC après une modification montre seulement que le nouvel ensemble d’octets est cohérent avec l’algorithme.

La question devient visible avec la vie privée. La troisième édition rappelle que certains outils ont masqué des pixels par transparence ou changé les dimensions sans supprimer les données récupérables, et que eXIf peut contenir une position GPS. Une prévisualisation propre ne prouve pas l’effacement. Mais le bit safe-to-copy n’est pas davantage une classification de confidentialité : il ne parle que de dépendance à l’égard des données critiques.

Pas de numéro global, mais un contrat par fonction

Le RFC 2083 a volontairement omis tout numéro de version global dans le fichier. Un numéro trop élevé aurait poussé un ancien lecteur à refuser une image qu’il pouvait réellement traiter. Il n’aurait pas non plus décrit correctement une extension privée.

Les chunks offraient une compatibilité plus fine. Une fonction auxiliaire inconnue pouvait être ignorée ; une fonction critique inconnue imposait l’arrêt. Le fichier était jugé par les fonctions présentes, non par un badge unique. Le document actuel sur les extensions PNG du W3C continue de publier des chunks supplémentaires séparément. Être enregistré, être reconnu et être compris restent trois faits.

La comparaison rétrospective avec la spécification initiale minimale et la décision future localisée de Lu Heng est éclairante : une petite grammaire commune rend possible une validation locale sans prétendre centraliser tout changement futur. Ce texte de 2026 n’est évidemment pas une source historique du RFC de 1997.

La distinction des couches de réalité ajoute la discipline probatoire. Le bit, la classe de modification et la décision copier/supprimer sont exécutables. Les mots « officiel », « exact », « autorisé » ou « digne de confiance » sont des affirmations supplémentaires.

Un reçu de transformation doit donc conserver le hash du flux entrant, l’inventaire ordonné des chunks, les quatre bits de chaque type inconnu, les résultats CRC, les types compris par l’outil, les modifications critiques et auxiliaires, chaque décision de conservation et le hash final. Quand une métadonnée soutient une publication, il faut encore sa provenance, son propriétaire de schéma et la preuve qu’elle reste applicable.

La quatrième lettre ne certifiait pas le contenu. Elle attribuait la charge de la décision.

Sources