Résumé

  • RFC 3981 a rendu le cœur IRIS volontairement insuffisant : les schémas propres aux registres devaient définir requêtes, résultats et classes d’entités, et la couche de transport devait fournir authentification et sessions.
  • Un format commun permettait un lookup cohérent, mais ni une recherche universelle ni une interprétation conviviale. Capacité, autorisation, renvoi et résultat final demeuraient des preuves distinctes.

La phrase la plus révélatrice de RFC 3981 ressemble d’abord à un aveu de faiblesse. Le schéma de base, expliquait le texte, ne définissait qu’un type de requête, deux types de résultats autonomes et aucune structure de registre; pris seul, il avait donc une utilité limitée. Or cette limite était précisément le dessin d’IRIS. Le protocole voulait normaliser la façon dont des univers différents se rencontrent, pas décider qu’un nom de domaine, une ressource d’adressage et tout autre objet de registre obéissent à la même grammaire métier.

RFC 3981, publié en janvier 2005, décrit le cœur XML de l’Internet Registry Information Service. Sa fiche, ses errata et son historique Datatracker établissent son statut Standards Track et sa mise à jour ultérieure par RFC 4992. Ces archives prouvent une filiation normative, non un taux de déploiement.

L’architecture séparait trois responsabilités. La couche propre au registre définissait ses requêtes, résultats et classes d’entités. Le niveau commun IRIS fournissait ensembles de recherche, ensembles de résultats, références et identification des types. La couche transport prenait en charge authentification, messages, connexions, sessions et URI de transport. Partager le niveau médian ne donnait à celui-ci aucune autorité sur les deux autres.

Chaque type était identifié par un URN servant aussi d’espace de noms XML et de référence de schéma. Un serveur pouvait offrir plusieurs instances. Mais le cœur ne connaissait ni registre concret ni structure universelle. RFC 3982 et sa fiche ajoutaient le modèle des registres de domaines; RFC 4698 ajoutait celui des registres d’adresses. Ces textes spécialisés n’étaient pas des rustines : ils étaient l’endroit prévu pour la sémantique.

La distinction lookup/recherche rendait le choix visible. Un lookup portait une valeur discrète vers un seul index. L’opération commune lookupEntity indiquait type de registre, classe et nom d’entité. Valeur partielle, plusieurs index ou plusieurs interrogations sur un index constituaient une recherche. Il n’existait pas de recherche standard commune à tous les types IRIS. Chaque schéma devait déclarer celles que ses données et son exploitation pouvaient réellement supporter.

L’annexe nommait alors « le leurre du client universel ». Un client générique pouvait retrouver une donnée et l’afficher rudimentairement. Pour chercher avec pertinence ou présenter le résultat de façon intelligible, il lui fallait connaître le domaine. Ajouter une langue de requête commune ne supprimait pas ce besoin : le client devait toujours traduire l’intention de l’utilisateur, mais désormais à travers le plus petit dénominateur commun.

Le coût concernait aussi le serveur public. Une syntaxe capable de combiner des valeurs partielles sur plusieurs index pouvait servir l’expert comme l’utilisateur abusif. L’opérateur limiterait alors les requêtes coûteuses afin de préserver le service, et l’universalité annoncée disparaîtrait. RFC 3707 et sa fiche avaient déjà formulé les exigences CRISP sur recherche, distribution, versionnement et abus. Cela cadre le jugement de conception; cela ne mesure ni fréquence d’attaque ni coût d’implémentation.

Même les renvois ne portaient pas une promesse unique. Une référence d’entité exprimait une connaissance précise d’une entité. Une continuation de recherche indiquait seulement qu’une autre autorité pouvait fournir ce qui était cherché — ou autre chose, ou rien. Le client ne devait suivre chaque renvoi qu’une fois afin d’éviter une boucle. Recevoir une continuation ne démontrait donc ni accessibilité, ni autorité finale, ni résultat.

Les erreurs séparaient d’autres états : nom syntaxiquement invalide, recherche dépourvue de sens, requête non prise en charge, limite de ressources, nom absent et permission refusée. Un document XML valide pouvait parfaitement transporter une demande incorrecte, impossible, trop coûteuse ou non autorisée.

La modularité du transport obéissait à la même règle. RFC 3983 et sa fiche définissaient la liaison BEEP. RFC 4992, avec sa fiche, ses errata et son dossier Datatracker, mit ensuite RFC 3981 à jour par un transport TCP découpant et pipelineant le XML. Changer la mise en trame ou l’authentification ne changeait pas le sens d’une recherche de registre.

Le registre IANA des schémas URI conserve iris et ses variantes de transport; le registre XML de l’IETF conserve l’espace iris1. Ce sont des preuves d’enregistrement, pas celles d’un serveur vivant, d’une requête réussie ou d’une adoption générale.

L’apport historique de RFC 3981 tient ainsi à sa retenue. Elle standardisait les jointures entre plusieurs domaines sans prétendre que leurs contenus formaient un seul arbre. La syntaxe pouvait voyager; la compréhension restait locale.

Sources