Résumé

  • RFC 3937 a enregistré urn:iptc avec trois branches gouvernées par l’IPTC : normes approuvées, projets de normes et documents de travail.
  • L’IPTC promettait persistance et accessibilité, mais le résolveur URL restait à développer et aucun mécanisme autonome de validation n’était alors défini.

Un mot stable pour une cible mouvante

Le détail le plus révélateur de RFC 3937 tient en sept lettres : current. Dans les branches consacrées aux normes, l’IPTC pouvait publier un URN contenant une version explicite, ou employer current pour désigner la version alors en vigueur. Le second nom pouvait traverser les années sans changer de chaîne de caractères tout en pointant successivement vers plusieurs éditions. Il était persistant comme alias, non comme photographie du passé.

Cette ambiguïté n’était pas une erreur de syntaxe. Elle répondait à deux besoins légitimes. Le lecteur qui voulait toujours la dernière norme pouvait préférer current. Le chercheur, l’auditeur ou le logiciel qui devait reproduire une décision ancienne avait besoin d’un numéro de version. Confondre les deux revenait à attribuer au nom une propriété — l’immuabilité — que son opérateur n’avait jamais promise.

Le dossier du RFC Editor qualifie le texte d’Informational, et son registre d’errata permet de vérifier les corrections publiées. Le registre IANA des espaces de noms URN associe aujourd’hui iptc à RFC 3937. Ensemble, ces pièces prouvent l’existence du NID et la référence normative de son enregistrement. Elles ne prouvent ni l’attribution de chaque identifiant descendant, ni la disponibilité continue des ressources.

L’enregistrement n’était pas le service

L’histoire des URN avait déjà séparé plusieurs couches. RFC 1737 énonçait les exigences fonctionnelles d’un nom persistant. RFC 2141 en fixait la syntaxe. RFC 2276 traitait l’architecture de résolution, tandis que RFC 3401 décrivait le Dynamic Delegation Discovery System utilisable par certaines applications de résolution. Enfin, RFC 3406 définissait la procédure suivie pour enregistrer un espace formel. Un nom conforme pouvait donc être enregistré sans que le chemin opérationnel vers sa ressource soit encore déployé.

RFC 3937 réservait trois branches. std concernait les ressources d’une norme approuvée ; std-draft, celles d’un projet avant approbation ; workdoc, les documents liés aux travaux de l’IPTC sans appartenir directement à une norme. Le directeur général de l’IPTC devait préserver l’unicité et seules l’organisation ou ses autorités pouvaient attribuer un nom. IANA enregistrait la racine iptc, non chaque chaîne située en dessous. La forme correcte d’un urn:iptc:... ne constituait donc pas une preuve d’attribution.

RFC 3085 avait auparavant créé un espace URN pour NewsML. Le nouveau dispositif couvrait davantage de ressources : DTD, schémas XML, espaces de noms, feuilles de style, PDF, documents bureautiques et autres productions utiles à l’industrie de l’information. Cette extension ne démontrait ni une migration complète des anciens noms NewsML ni la disparition des identifiants antérieurs.

Une promesse institutionnelle avant sa mécanique

Le texte disait que l’IPTC s’engageait à maintenir l’accessibilité et la persistance de toutes les ressources identifiées. Mais il annonçait aussi, au futur, que l’organisation développerait un mécanisme approprié pour associer les URN attribués à des URL. À la rubrique validation, il ne spécifiait aucun dispositif distinct : le futur résolveur devait aussi permettre de savoir si un URN était valide.

Cette chronologie borne précisément ce que l’on peut affirmer. En octobre 2004, l’autorité d’attribution et la politique de nommage existaient dans le document. Le document ne prouve pas qu’un résolveur public fonctionnait déjà. Un URN valide pouvait rester temporairement sans résolution ; un résolveur pouvait renvoyer une URL morte ; une URL active pouvait servir la mauvaise édition ; une chaîne bien formée pouvait ne jamais avoir été attribuée.

Les exemples de RFC 3937 — DTD NewsML, schéma XML NITF en projet, espace de noms SportsML, guides et document de travail — étaient déclarés représentatifs et pouvaient ne correspondre à aucune ressource réelle. Ils enseignaient la grammaire, pas l’état du registre. À l’inverse, la spécification ultérieure IPTC Core XMP Schema porte bien un URN explicite de la famille urn:iptc:std:... : elle prouve un usage concret ultérieur, mais ni un inventaire exhaustif ni une résolution ininterrompue depuis 2004. La page IPTC sur un espace de noms externe offre aujourd’hui une représentation Web ; sa disponibilité actuelle ne peut être transformée en preuve rétroactive.

RFC 8141 a plus tard actualisé la syntaxe et la sémantique générales des URN. Il éclaire le cadre moderne sans documenter l’état du service IPTC au moment de l’enregistrement. La méthode proposée par Heng Lu — distinguer la spécification initiale minimale de l’adoption ultérieure et donner la priorité aux preuves de code en fonctionnement — interdit précisément de fusionner publication, attribution, déploiement et usage.

La leçon n’est donc pas que l’URN aurait échoué. Elle est plus exigeante : une chaîne ne porte pas seule sa permanence. Celle-ci dépend du registre d’attribution, du résolveur et de ses correspondances, des dépôts de versions, des serveurs qui livrent les fichiers et du choix du lecteur entre édition fixe et alias current.