Résumé

  • RFC 3367 définissait un noyau interopérable pour interroger des services de noms communs, découvrir leurs capacités, recevoir résultats, états et renvois, et conserver la provenance du service et du jeu de données.
  • La découverte et le choix du fournisseur, l’enregistrement, la propriété et l’unicité des noms restaient volontairement hors champ. La syntaxe pouvait être commune sans rendre commun celui qui détenait l’autorité de répondre.

À la fin des années 1990, le champ d’adresse d’un navigateur recevait déjà bien davantage que des URL. Des personnes y tapaient le nom d’une entreprise, un titre de livre ou une expression ordinaire. Les portails et les navigateurs savaient transformer ce geste en navigation ou en recherche, mais leurs services spécialisés ne partageaient pas nécessairement une interface de requête.

Le Common Name Resolution Protocol répondait à ce problème d’intégration. Publié en 2002 sur la voie des normes, RFC 3367 décrivait des requêtes et réponses XML pour associer des expressions humaines à des ressources Internet. Il ne proposait ni un DNS parallèle ni un annuaire universel.

Le « nom commun » du texte était une expression sans structure syntaxique imposée. Il pouvait désigner une société, une personne, une œuvre ou un lieu. Contrairement à un URI, il ne portait pas une grammaire d’identification. Contrairement à un URN, son association à une ressource n’avait à être ni unique ni persistante.

Plusieurs services étaient attendus. Le même nom pouvait exister dans chacun d’eux, relié à des données différentes. CNRP commençait après le choix d’un service : le client demandait une description de ses capacités, apprenait son schéma, envoyait une requête et recevait des descripteurs de ressources, des états ou des renvois.

Cette mécanique rendait possible une intégration propre. Un service décrivait ses serveurs et ses jeux de données. Un intermédiaire pouvait interroger plusieurs fournisseurs puis joindre leurs réponses tout en indiquant l’origine de chaque résultat. La provenance n’était donc pas un commentaire facultatif ; elle permettait de ne pas confondre l’agrégation avec une source unique.

Le noyau obligatoire restait limité : nom commun, identifiant local au service, URI de ressource et description. Langue, géographie, catégorie et autres propriétés pouvaient affiner la demande. Mais RFC 3367 les traitait comme des indications de meilleur effort. Un fournisseur pouvait les prendre en compte autrement qu’un autre, voire en ignorer certaines, et cette différence constituait un élément de son offre.

La requête ne fonctionnait donc pas comme une clause SQL exigeant que chaque résultat respecte chaque condition. Elle demandait les éléments jugés les plus proches des critères. Le protocole normalisait la forme de l’échange et des états de succès partiel, sans uniformiser la couverture, le classement ou toutes les taxonomies.

RFC 2972 avait tracé la limite politique avec franchise. Découverte et sélection des fournisseurs, administration des services, enregistrement, propriété et création de noms uniques ne faisaient pas partie du premier périmètre. La norme pouvait relier un client à un fournisseur déjà choisi ; elle ne décidait pas lequel consulter.

C’est pourtant dans ce choix que se trouvait l’autorité. Un navigateur configuré pour un répertoire commercial et un autre utilisant un service régional pouvaient transmettre exactement la même expression et recevoir deux associations conformes. CNRP savait indiquer les jeux de données d’origine. Il ne désignait pas une réponse mondiale gagnante.

Les espaces de noms publics rendaient cette pluralité inévitable. RFC 2972 citait les noms de personnes, de lieux ou d’œuvres, dont l’attribution n’est contrôlée par aucune autorité unique. Il envisageait des classifications différentes et reconnaissait que des mots-clés libres ne garantissaient pas une interopérabilité totale entre services.

RFC 3368 rendait la limite visible avec le schéma d’URI go:. Une forme nommait un serveur précis. Une autre exprimait une requête sans serveur, destinée aux services déjà configurés dans le client. La chaîne transportait la question ; la configuration locale fournissait les institutions capables de répondre.

Le démarrage du transport était plus déterministe. Les clients et serveurs génériques devaient accepter HTTP sur le port 1096 pour le premier contact. Un service pouvait ensuite annoncer d’autres transports. Cette règle disait comment joindre un service connu, pas comment le découvrir ni pourquoi lui faire confiance.

Les renvois prolongeaient le graphe. Un fournisseur pouvait livrer quelques résultats et indiquer qu’un autre service en possédait peut-être davantage. Le client devait suivre les couples service-jeu de données et détecter les boucles. Un serveur de renvoi indisponible pouvait produire un succès partiel : réponse exploitable, mais couverture incomplète.

La sécurité revenait au même point. RFC 3367 recommandait l’authentification du transport et permettait de signer un objet Service. Pourtant, vérifier cette signature exigeait une clé publique faisant autorité. Le moyen d’obtenir cette clé restait hors champ, car il dépendait précisément de la découverte du service.

La cryptographie pouvait protéger une déclaration une fois le point de confiance choisi. Elle ne choisissait pas ce point. Validité cryptographique et autorité institutionnelle se rejoignaient sans devenir la même chose.

Aujourd’hui, le registre IANA classe go comme schéma permanent et cite RFC 3368 ; RFC 3367 garde le statut Proposed Standard. Ces faits attestent une garde normative. Ils ne comptent ni navigateurs compatibles, ni serveurs actifs, ni trafic, ni utilisateurs. Les promesses d’intégration de RFC 2972 ne constituent pas davantage une mesure d’adoption.

Les RFC 2396 puis 3986 encadrent la syntaxe générale des URI ; RFC 2276 et RFC 2483 examinent la résolution autour des URN ; RFC 3401 présente une autre famille de découverte par délégation. Elles situent CNRP dans une période d’exploration intense, mais ne prouvent pas qu’un mécanisme a remplacé l’autre dans les systèmes en fonctionnement.

Deux textes de Lu Heng servent ici de grille déclarée. « Minimum Initial Specification » éclaire le choix d’un petit noyau commun suivi de décisions locales. CNRP standardisait l’échange sans standardiser l’autorité. « On Reality Layers » oblige à séparer conformité du protocole, identité du service, provenance du jeu, association renvoyée, ressource accessible et intention de l’utilisateur.

Le dessin assumait donc des réponses plurielles. Il rendait la provenance visible, signalait les résultats partiels et imposait une détection des boucles. Mais cette honnêteté ne supprimait pas le pouvoir de distribution : celui qui configurait la liste de services déterminait les jeux de données pouvant entrer dans la réponse.

RFC 3367 fixe ainsi une frontière historique nette. Internet pouvait partager une façon de poser la question sans partager une seule institution chargée d’y répondre. Le protocole s’arrêtait à cette frontière et laissait assez de traces pour qu’un client attentif sache qu’elle existait.

Sources