Résumé

  • Dans RFC 3402, le résultat non terminal d’une règle devenait la clé de la base suivante, mais la règle suivante s’appliquait encore à l’exacte chaîne unique de l’application reçue au départ.
  • Ce partage des rôles empêchait la délégation de devenir une succession de transformations incontrôlables : le chemin pouvait changer d’autorité sans changer silencieusement de sujet.

Le mot « réécriture » invite à une fausse image. On imagine volontiers un texte que chaque règle modifie avant de le transmettre à la suivante. Une telle chaîne possède une propriété séduisante : chaque étape semble simple. Mais elle perd peu à peu la capacité de répondre à une question fondamentale. La dernière règle travaille-t-elle encore sur l’objet initial, ou seulement sur l’accident produit par toutes les règles précédentes ?

RFC 3402 a choisi une autre architecture. Publié en octobre 2002 sur la voie de normalisation, ce deuxième volet du Dynamic Delegation Discovery System décrivait un algorithme de liaison tardive. L’application remettait une chaîne unique, l’Application Unique String ou AUS. Le système consultait ensuite des règles obtenues dynamiquement jusqu’à ce qu’une règle terminale fournisse le type de résultat prévu par l’application.

Le principe essentiel tenait en une séparation. Le résultat d’une règle non terminale servait de clé pour interroger une nouvelle base. Il ne remplaçait jamais l’AUS. À l’étape suivante, l’expression de substitution était de nouveau évaluée sur la chaîne originale. Le document l’imposait avec un « MUST NOT » et répétait l’interdiction dans les exigences auxquelles toute spécification d’application devait satisfaire.

La première transition n’était pas récupérée au hasard dans une base. Une First Well Known Rule, définie par l’application, transformait l’AUS en première clé valable. Elle ancrait ainsi le parcours dans un contrat connu. Sans elle, un client aurait pu choisir une base parce qu’elle acceptait la forme de l’entrée, puis présenter cette commodité comme une délégation autorisée.

Chaque consultation renvoyait un ensemble ordonné de règles. Le client essayait leurs expressions sur l’AUS d’origine jusqu’à obtenir un résultat non vide. Les champs Services, Flags et Priority donnaient ensuite un sens opérationnel à cette correspondance : service utilisable, caractère terminal ou non terminal, préférence entre solutions par ailleurs équivalentes.

Le rejet d’un service n’effaçait pas l’ensemble déjà consulté. Si la règle correspondait lexicalement mais proposait un service que le client ne pouvait accepter, celui-ci reprenait dans la même liste, juste après la règle rejetée. Cette reprise est un détail décisif pour la preuve. Elle permet de conserver la position, l’ordre et le motif du refus au lieu de fabriquer après coup un chemin plus propre que celui réellement parcouru.

Lorsqu’une règle acceptable n’était pas terminale, sa substitution produisait uniquement la prochaine clé. Le client devait vérifier que cette clé respectait le format imposé par la base avant de l’utiliser. Une expression régulière mal conçue pouvait en effet fabriquer une clé illégale. Même dans ce cas, la faute ne donnait aucun droit de promouvoir la clé au rang de nouvelle identité.

RFC 3402 comparait la méthode interdite aux chaînes de réécriture de type sendmail, qualifiées de fragiles et sujettes aux erreurs. Dans un modèle cumulatif, une sortie inattendue modifie le matériau de toutes les étapes suivantes. Dans DDDS, on peut au contraire rejouer chaque règle avec la même AUS et examiner séparément le résultat intermédiaire comme clé, le choix du service ou la sortie terminale.

Il existait une frontière explicite pour passer à un autre système. Un drapeau pouvait suspendre l’application DDDS courante et transférer le traitement à une autre application ou à une procédure propre à un protocole. Le drapeau p de RFC 3404 illustrait ce cas. Mais ce passage déclarait un changement de contexte ; il n’autorisait pas les anciennes règles à poursuivre leur travail sur un sujet substitué en secret.

La règle terminale rendait une sortie conforme au contrat de l’application avec ses Flags et Services. Le mot « terminal » ne signifiait donc pas « vrai dans le monde ». Il signifiait que l’algorithme avait atteint une forme de résultat attendue. La disponibilité du service, la légitimité de l’autorité qui avait publié la règle et l’acceptation finale par un consommateur restaient des faits distincts.

La portée de Priority était elle aussi limitée. Ce champ exprimait une préférence entre règles équivalentes, éventuellement pour une solution meilleure, plus rapide ou moins coûteuse. Le texte précisait qu’il ne s’agissait pas d’un mécanisme de répartition de charge. Confondre préférence et pondération de trafic attribuerait au protocole un comportement qu’il n’avait pas défini.

La fraîcheur empêchait les optimisations de reconstruire une histoire fictive. Un client pouvait mémoriser des clés ou des règles déjà utilisées, mais devait respecter leur expiration. Si une règle antérieure avait expiré, l’application recommençait à la première étape. Elle ne pouvait assembler une première moitié périmée et une seconde moitié récente tout en prétendant posséder une chaîne continue.

L’algorithme n’était utilisable qu’avec deux autres contrats. La spécification d’application définissait l’AUS, la première règle, les bases permises, les jeux de caractères et le résultat attendu. La spécification de base définissait stockage, consultation, formats des clés et des règles, insertion et prévention des collisions. RFC 3401 avertissait qu’isoler un seul document de la série menait aux malentendus et aux défauts d’interopérabilité.

Cette architecture reconnaissait également ses limites. DDDS pouvait tirer une décision de l’AUS et des règles. Il ne savait pas décider seul de faits extérieurs tels que l’heure, un paiement, un droit ou une transaction. Ces conditions devaient rester visibles ailleurs, au lieu d’être cachées dans une sortie qui donnerait à la chaîne une apparence d’autorité excessive.

La sécurité dépendait donc du couple application-base. RFC 3403 décrivait la base DNS et les enregistrements NAPTR ; RFC 3404, l’application de résolution d’URI ; RFC 2916, une première forme d’ENUM. Ces textes montraient différents usages du même algorithme. Aucun ne prouvait qu’un client DDDS quelconque prenait en charge toutes les applications.

Le registre IANA des services ENUM montre aujourd’hui la coordination d’identifiants dans une application ultérieure. Une inscription ne prouve ni exécution par un résolveur, ni fraîcheur, ni autorité, ni succès du service terminal. Le RFC Editor recense une seule correction éditoriale vérifiée pour RFC 3402, l’erratum 7049 : la référence à la discussion du drapeau p dans RFC 3404 doit viser la section 4.3, et non 4.4. L’invariant algorithmique ne change pas.

Une preuve d’exécution sérieuse doit donc garder l’AUS exacte, la version de l’application, la première règle, le type de base, toutes les clés successives, chaque ensemble ordonné, l’identité et l’expiration de chaque règle, le résultat de la substitution, les refus de service et leurs positions de reprise, la décision de priorité, le drapeau terminal, la validation de sortie et l’action du consommateur.

Le principe de spécification initiale minimale de Lu Heng éclaire cette sobriété : normaliser le seuil commun nécessaire aux implémentations indépendantes, sans prétendre uniformiser le sens de toutes les applications. La primauté du code en fonctionnement impose ensuite de produire le reçu concret. Il faut pouvoir rejouer une AUS sur les règles réellement reçues et démontrer qu’aucune clé intermédiaire n’a pris la place du sujet.

RFC 3402 racontait ainsi une histoire de continuité plus qu’une histoire de remplacement. La délégation pouvait envoyer la recherche ailleurs, parfois plusieurs fois. Mais chaque autorité rencontrée devait continuer à parler du même objet initial. Le parcours changeait ; son sujet demeurait.

Sources