Résumé

  • La RFC 3043 proposait urn:pin, un espace de noms persistant pour désigner personnes et organisations d’une application à l’autre.
  • Les identifiants étaient opaques hors du résolveur interne de Network Solutions, dont les résolveurs étaient présentés comme faisant autorité. Une syntaxe mondiale ne rendait pas le pouvoir de résolution également portable.

Le problème ne consistait pas seulement à attribuer une étiquette durable à une personne. Il fallait qu’une référence survive aux changements d’adresse électronique, de nom, d’employeur ou de fournisseur, voire aux systèmes qui l’avaient créée. Dans la RFC 3043, publiée en janvier 2001, Network Solutions présentait ce besoin comme un enjeu pour les annuaires et le commerce électronique : distinguer deux fiches malgré des données descriptives similaires et continuer à désigner la même personne ou organisation au fil du temps.

La proposition était le Personal Internet Name (PIN), encodé comme nom uniforme de ressource dans l’espace pin. Les exemples de la RFC sont des jetons compacts, tels que urn:pin:bs4321234, plutôt que des noms révélant un patronyme ou une raison sociale. La partie spécifique au nom (NSS) devait former un espace plat de caractères alphanumériques. Surtout, le document indiquait que sa structure interne était inconnaissable hors du résolveur de Network Solutions et ne devait jamais être déduite ni présumée. L’opacité fixait une limite de conception ; elle n’invitait pas à décoder le jeton.

Cette séparation apportait un bénéfice réel. Une application pouvait transporter une référence stable sans intégrer une adresse électronique susceptible de changer ni dépendre de la clé locale d’un annuaire. Selon le modèle décrit, les identifiants n’étaient pas réattribués et leur association avec la personne ou l’organisation était dite permanente malgré un changement de nom, une restructuration, un décès ou une dissolution. La RFC invoquait aussi un mécanisme normalisé de résolution des URN, censé permettre à d’autres applications de référencer et résoudre les PIN de façon ouverte et non propriétaire.

Mais le formulaire d’enregistrement traçait une autre frontière : qui pouvait établir la signification du PIN. Network Solutions attribuait les identifiants au moyen d’un système d’inscription propriétaire et affirmait en garantir l’unicité. L’algorithme alors employé avançait à partir du dernier numéro attribué, d’un incrément positif ; le document envisageait un changement ultérieur. Pour la résolution, il désignait les propres résolveurs URN de Network Solutions. Il avertissait qu’un résolveur tiers risquait de se tromper et ne serait pas considéré comme faisant autorité.

C’est le paradoxe de la portabilité. Le jeton pouvait circuler dans une application extérieure à l’annuaire d’origine ; pourtant, une application tierce ne pouvait ni reconstituer indépendamment sa structure ni revendiquer un lien faisant autorité en se contentant de l’analyser. La portabilité de la référence et celle de l’autorité sont deux propriétés distinctes. Le format franchissait plus facilement les frontières organisationnelles que le pouvoir de certifier la personne ou l’organisation désignée.

Ce cas n’est pas propre à pin. Un espace de noms peut rendre des références globalement distinctes tout en subordonnant l’attribution, la correction, la résolution et les litiges à un dépositaire. Le compromis peut se défendre : l’opacité protège la flexibilité interne, un attributaire unique coordonne l’unicité et un résolveur désigné fournit un point d’autorité clair. Mais il concentre aussi le risque de continuité. Si les identifiants doivent survivre au service ou à l’organisation qui les résout, le système doit préciser la succession du résolveur, l’export des données, le traitement des identités contestées et la vérification en cas d’indisponibilité. La RFC décrit attribution et résolution ; elle n’établit pas que ces mécanismes de continuité existaient.

Il faut aussi distinguer le statut du document. Le Datatracker de l’IETF classe aujourd’hui la RFC 3043 comme RFC informative de la filière Legacy, sans statut formel dans le processus de normalisation de l’IETF. Par ailleurs, le registre IANA des espaces de noms URN inscrit toujours pin dans son tableau des espaces formels, avec la RFC 3043 en référence. Ces deux registres répondent à des questions différentes : le statut du RFC dans la filière de normalisation n’est pas identique à la présence de l’espace dans le registre IANA. Aucun des deux ne prouve, à lui seul, qu’un service fonctionne encore ni qu’il est utilisé aujourd’hui.

La leçon historique n’est pas que tout résolveur central est mauvais. Un identifiant stable répond à un premier problème : les références qui cassent lorsque la description ou l’emplacement changent. Il n’en résout pas automatiquement un autre : la dépendance envers l’institution qui attribue l’identifiant ou en confirme la résolution. La RFC 3043 rendait cette séparation visible dans son propre formulaire. Un nom persistant peut voyager plus loin que son ancre de confiance.

Un système qui promet à la fois durée et ouverture doit donc préciser non seulement la formation des noms, mais aussi qui peut vérifier leur lien, comment l’autorité peut être transférée et ce qui subsiste lorsque le résolveur d’origine n’est plus là.