Résumé

  • RFC 3073 a enregistré application/font-tdpfr et publié des métadonnées d’identification, tout en renvoyant à Bitstream pour les détails techniques complets de Portable Font Resource.
  • Le registre pouvait rendre un nom commun. Il ne prouvait ni la garde de la spécification, ni la présence d’un code compatible, ni la fidélité du rendu chez le destinataire.

En mars 2001, John Collins, de Bitstream, a publié RFC 3073 afin d’enregistrer un sous-type MIME pour Portable Font Resource. La fiche était précise : aucun paramètre requis, aucun paramètre facultatif, un transfert binaire ou en base64, la signature hexadécimale 50 46 52 30, l’extension de fichier PFR et un usage prévu comme courant. Un expéditeur pouvait annoncer un type, et le destinataire pouvait reconnaître le même jeton sans inventer une appellation locale.

Mais la fiche n’était pas le format entier. RFC 3073 résumait PFR comme un ensemble compact de formes de glyphes associées à des codes de caractères, indépendant de la plateforme et de la résolution, redimensionnable et capable d’inclure des images matricielles. Pour les fonctions et les détails techniques complets, le texte dirigeait le lecteur vers la spécification PFR originale. Celle-ci était définie par Bitstream, disponible sur demande auprès de l’entreprise et signalée à une adresse web de Bitstream. Collins figurait à la fois comme contact et comme auteur ou responsable des modifications.

Cette séparation était explicite. La couche publique contenait le nom, la fiche d’enregistrement et quelques propriétés utiles à l’identification. La couche descriptive complète restait ailleurs. Le document rappelait même que le type avait auparavant porté le nom application/vnd.truedoc. Son nouvel enregistrement faisait suite, selon RFC 3073, à son adoption par DAVIC, DVB et DTG. Passer d’un nom à facette de fournisseur à application/font-tdpfr élargissait la coordination symbolique; cela ne déposait pas toutes les règles du format dans le RFC et n’installait aucun moteur de rendu.

Un type de média sert d’abord de signal d’aiguillage. Le logiciel lit l’en-tête, choisit éventuellement un gestionnaire puis lui remet les octets. Chacune de ces étapes fournit une preuve différente. Reconnaître le nom montre que la chaîne a été comparée. Trouver un gestionnaire montre qu’une configuration relie ce nom à un programme. Accepter le fichier montre ce que le parseur a décidé. Afficher une forme montre qu’une sortie a été produite. Aucune de ces observations ne garantit à elle seule la même révision de spécification, les mêmes métriques, la même association entre code et glyphe ou le même résultat visuel que chez l’émetteur.

Les considérations de sécurité doivent elles aussi rester dans leur périmètre. RFC 3073 disait que les champs alors définis étaient descriptifs et n’induisaient pas d’action particulière de l’application destinataire. Il envisageait qu’une structure extensible puisse un jour recevoir des champs commandant une action, avec des risques supplémentaires, tout en précisant que de telles instructions n’étaient pas prises en charge et contrediraient l’esprit de PFR. C’était une propriété de conception annoncée, pas un audit de sûreté mémoire de tous les lecteurs, une authentification du fichier ou une autorisation d’agir sur le contenu affiché.

La mention « Interoperability considerations: none » ne constitue pas davantage un rapport d’essai. Elle ne s’accompagnait ni d’un corpus de conformité, ni de comparaisons indépendantes, ni de mesures de rendu. La liste de Netscape Communicator, Bitstream WebFont Maker et Hexmac Typograph montrait des applications déclarées, pas la réussite de tout échange possible entre elles. L’affirmation historique défendable est donc limitée : un nom partagé et des métadonnées publiques ont été enregistrés dans un contexte où plusieurs produits et organismes de normalisation étaient cités comme utilisateurs.

Les règles ont évolué plus tard sans supprimer la différence entre le registre et l’exécution. RFC 6838 a formalisé les arbres de noms, les voies d’examen, les exigences de publication et la responsabilité des modifications. RFC 8081 a ensuite créé le type de premier niveau font et enregistré notamment font/ttf, font/otf, font/sfnt, font/woff et font/woff2. Le registre IANA actuel marque les anciens noms application/font-sfnt et application/font-woff comme dépréciés, mais continue d’inscrire application/font-tdpfr avec RFC 3073 sans cette annotation. Cette ligne prouve l’état du registre, non une migration, un déploiement ou une interopérabilité actuelle.

RFC 2045 rappelait déjà la nature du compromis MIME : donner une grammaire commune aux corps de message, y compris quand le destinataire ne possède pas l’outil nécessaire. RFC 2048 organisait l’enregistrement afin que les nouveaux noms soient documentés et examinables. Cette infrastructure réduisait l’ambiguïté de l’étiquette. Elle ne transformait pas automatiquement la coordination du nom en garde du format, en disponibilité du code ou en continuité de maintenance.

Running-Code Primacy offre ici une grille d’analyse postérieure : vérifier séparément le nom enregistré, la version de spécification accessible, le décodeur installé, son état de maintenance, le fichier reçu et la sortie observée. Reality Layers invite à ne pas confondre le prestige symbolique d’un nom public avec l’autorité exécutable au point où le rendu doit avoir lieu. Ces perspectives ne sont pas attribuées à Collins, à Bitstream, à l’IANA ou à l’IETF; elles servent à empêcher qu’une preuve se substitue aux autres.

Il ne s’agit pas de soutenir qu’un format maintenu hors de l’IETF ne devrait jamais avoir de type public. L’échange en a souvent besoin. Il ne s’agit pas non plus de dire que la spécification PFR était secrète : RFC 3073 indiquait qu’elle pouvait être demandée et donnait une adresse web. La limite est plus exacte. La visibilité du nom, la disponibilité de la fiche, la garde du document complet, l’existence d’une implémentation et la fidélité du résultat sont cinq conditions distinctes.

RFC 3073 a donc produit une véritable infrastructure : un identifiant stable, consultable et commun. Il n’a pas fusionné le registre, la spécification et le moteur de rendu. Le registre pouvait dire quel contenu le fichier prétendait être et où sa documentation était annoncée. Seules la spécification, l’implémentation et l’observation du résultat pouvaient dire ce que le destinataire savait réellement en faire.

Sources