Résumé

  • En 2003, RFC 3553 a créé urn:ietf:params afin de nommer durablement des paramètres de protocole enregistrés sans transformer l'URL courante du dépôt IANA en identité.
  • Le texte ne définissait ni résolution ni validation. Il interdisait surtout d'enfermer dans un nom permanent une valeur dont le sens change : le nom pouvait désigner la case stable, pas son contenu du jour.

Un dépôt doit parfois déménager. Le serveur change, l'arborescence de fichiers est réorganisée, la représentation HTML devient XML, puis une autre interface la remplace. Si un schéma de protocole utilise l'adresse courante comme identité d'un paramètre, chaque opération de maintenance devient une migration sémantique. Le lien ne dit plus seulement où regarder ; il devient ce que l'objet est censé être.

RFC 3553, publié en juin 2003 comme BCP 73, a séparé ces fonctions. RFC 2648 avait déjà réservé l'espace URN ietf aux ressources de l'IETF. Le nouveau segment params devait fournir un mécanisme commun pour les éléments enregistrés que les standards voulaient citer sous forme d'URI. Le problème venait d'identifiants improvisés qui pouvaient désigner le même paramètre avec des chaînes différentes.

La solution ne fut pas un annuaire universel. Le texte dit explicitement qu'aucun mécanisme de résolution n'est défini. Il dit aussi qu'il n'existe aucun mécanisme de validation. Un nom global peut donc rester global sans être directement ouvrable dans un navigateur. Il peut être syntaxiquement correct sans être enregistré, enregistré sans être reconnu par un logiciel, et reconnu sans que l'opération de protocole réussisse.

La règle de persistance va plus loin que l'unicité. Une fois attribué, un nom ne doit pas être réattribué à un autre usage. Surtout, les règles internes doivent empêcher que le sens d'une valeur nommée se transforme avec le temps. Lorsqu'un paramètre varie, on peut nommer la case ou le concept qui contient la valeur. On ne doit pas mettre la valeur actuelle dans l'identifiant, sauf si cette valeur est elle-même permanente et unique, comme un numéro de version stable.

Cette distinction protège le registre contre sa propre mobilité. Le modèle d'enregistrement demande d'indiquer un dépôt autoritatif, mais RFC 3553 présente ce champ comme l'emplacement actuel, susceptible de changer avec les fichiers et les serveurs. Il s'agit d'un indice opérationnel, non d'une liaison éternelle à un nom de fichier. La continuité repose sur l'attribution et le sens, pas sur le maintien d'une machine.

L'espace est décrit comme principalement opaque. Les deux-points introduisent une hiérarchie limitée, mais ils ne suffisent pas à révéler une chaîne de délégation. urn:ietf:params:xml acquiert son régime par RFC 3688 et par le registre XML. urn:ietf:params:oauth dépend de RFC 6755 et de son registre. Découper la chaîne ne remplace pas la lecture du document qui attribue l'autorité et définit l'index.

Le registre gelé pour cette enquête porte la date de mise à jour du 2 février 2026. Il contient sept sous-espaces de second niveau sous ietf et 23 identifiants enregistrés sous params, parmi lesquels xml, oauth, netconf, scim, acme, jmap, whip et unit. Ce constat prouve la continuité administrative du mécanisme. Il ne mesure ni l'adoption, ni la conformité, ni la sécurité des produits.

RFC 6924 a ensuite créé une vue d'ensemble des sous-espaces ietf et remplacé l'ancien libellé de procédure par « IETF Review ». RFC 8141 a remplacé RFC 2141 pour la syntaxe générale des URN. Ces évolutions montrent précisément pourquoi l'identité ne pouvait pas être confondue avec son conteneur documentaire. Les procédures et les formats changent ; une attribution stable doit continuer à désigner le même concept.

Pour un audit, il faut donc conserver plusieurs reçus. La chaîne exacte reçue est un reçu lexical. La ligne IANA et la spécification citée établissent l'attribution. La copie datée du registre indique l'état consulté. La version du logiciel établit ce qui pouvait être reconnu. Les journaux et mesures de protocole montrent enfin ce qui s'est produit. Aucun de ces reçus n'autorise à inventer le suivant.

La fonction du registre est décisive mais étroite : éviter les collisions, conserver le sens et publier le dossier. Elle ne donne pas à l'opérateur du registre la propriété de l'exécution. C'est dans le code en fonctionnement que la reconnaissance devient comportement. RFC 3553 a rendu cette vérification possible en fournissant un point de référence stable, sans prétendre être le résultat.

Sources