Résumé

  • Dans la RFC 3650, l’espace mondial des Handles est fédéré : une autorité unique et un nom local unique forment un Handle unique dans le système, tandis que les espaces locaux peuvent conserver leurs noms et leurs associations de valeurs.
  • Le Global Handle Registry fournit principalement les informations de service nécessaires pour trouver le service Handle compétent ; les Local Handle Services assurent normalement la résolution des Handles relevant de leurs autorités.

Un nom mondial n’impliquait pas une base mondiale unique

La question historique posée par la RFC 3650 dépasse la forme d’un identifiant persistant. Comment des espaces de nommage et d’administration distincts pouvaient-ils partager un cadre commun sans remettre chaque donnée à un opérateur central ? La réponse repose sur la séparation entre nom, autorité et découverte du service.

Un Handle associe une autorité de nommage — son préfixe — à un nom local, ou suffixe. L’autorité est unique dans le système Handle ; le nom local doit être unique sous cette autorité. Leur combinaison rend le Handle unique dans le système. Un espace local existant pouvait le rejoindre en obtenant une autorité unique, sans abandonner ses noms ni ses associations de valeurs. « Mondial » décrivait donc le contexte partagé d’unicité, pas une base de données sous administration unique. RFC 3650

L’architecture distribuait ensuite les services. Le Global Handle Registry (GHR) se trouvait à la racine, au-dessus des Local Handle Services (LHS). Le Handle d’une autorité contenait des informations de service — sites et interfaces des serveurs — permettant au client de joindre le service « d’origine » compétent. Le client interrogeait d’abord le GHR pour obtenir ces informations, puis contactait le service responsable du Handle demandé. Le registre servait de carte des responsabilités de service ; il n’était pas nécessairement le dépôt de toutes les valeurs locales. RFC 3650 · RFC 3651

« Local » désignait ici une responsabilité de nommage et d’administration, pas une proximité géographique. Un LHS pouvait avoir plusieurs sites répartis sur Internet, avec plusieurs serveurs par site. La réplication faisait partie des possibilités décrites ; elle ne constitue pas une mesure de disponibilité d’un déploiement particulier.

Une hiérarchie d’enregistrement n’est pas une chaîne de commandement

Les autorités pouvaient former un arbre. Un parent devait être enregistré avant de déclarer un enfant, mais la RFC précise que cet ordre ne crée pas à lui seul de relation administrative : les espaces parent et enfant peuvent relever de services différents et ne partager aucun privilège. L’arbre ne dit donc pas qui peut modifier les Handles de l’enfant, arbitrer un conflit ou assurer la continuité du service. RFC 3650

Le GHR n’est toutefois pas un simple annuaire incapable de gérer des Handles individuels. La RFC 3650 indique qu’il peut gérer tout espace Handle ; la RFC 3651 prévoit aussi qu’il puisse gérer, résoudre ou administrer certains Handles qui ne sont pas des autorités de nommage. La distinction utile est plus précise : son rôle distinctif est la gestion des autorités et de leurs informations de service, tandis que les services locaux prennent normalement en charge les espaces qui leur sont confiés. RFC 3651

La valeur associée à un Handle peut changer sans que l’identifiant change. Cela permet de mettre à jour une localisation ou une autre information liée à la ressource. Mais la syntaxe ne garantit pas la pérennité : la RFC 3650 la fait dépendre du soin administratif. Un identifiant stable ne contraint aucune institution à maintenir ses données, son résolveur ou sa destination. RFC 3650

Des systèmes voisins, pas des systèmes interchangeables

La RFC situe Handle parmi les services de nommage existants sans les confondre. DNS organise les noms et leur résolution selon sa propre délégation de zones. Les URN visent des noms de ressources indépendants de leur emplacement, tandis que leur découverte et leur résolution relèvent d’autres mécanismes. Un Handle peut servir des applications ayant besoin d’identifiants persistants ou de résolution ; il n’est pas automatiquement un URN, et une réponse Handle ne prouve pas qu’une ressource est accessible. RFC 1034 · RFC 1737 · RFC 2276 · RFC 3406 · RFC 8141

Le statut de publication compte également. La RFC 3650 est informative, pas une norme Internet. La note de l’IESG précise que les discussions à l’IETF et à l’IRTF n’avaient pas abouti à un consensus de l’IETF sur le système décrit ni sur sa place dans l’architecture des identifiants de l’IETF. Ce constat n’est ni une approbation ni un rejet : il distingue une proposition architecturale publiée d’un consensus institutionnel. RFC 3650

La contribution historique réside dans cette répartition : un registre racine indiquait quel service répondait de chaque autorité, tandis que des services administrés séparément pouvaient héberger et résoudre leurs espaces locaux. La promesse dépendait toujours des données, des opérateurs et des chemins de service qui maintenaient la carte à jour. La RFC décrit comment assembler ces frontières ; elle ne prouve ni résolution universelle, ni permanence, ni adoption à grande échelle, ni accès réussi à une ressource donnée.

Sources : RFC 3650 ; RFC 3651 ; RFC 3652 ; RFC 1737 ; RFC 2276 ; RFC 3406 ; RFC 8141 ; RFC 3986 ; RFC 1034.