Résumé

  • RFC 3017 décrivait un carnet XML capable de choisir un POP et de fournir au client numéros, scripts, DNS, proxies, passerelle et transformations du nom d’utilisateur ; ce n’était donc pas un simple répertoire à consulter.
  • Les compteurs croissants du carnet et de l’entrée aidaient à repérer une différence dans un périmètre connu. Ils ne remplaçaient pas le protocole de mise à jour, l’authentification de l’émetteur, la validation du résultat ni l’observation de la connexion.

Le problème apparaissait souvent trop tard : après l’arrivée. Le carnet s’ouvrait correctement, le XML était valide et le nombre inscrit en tête dépassait celui de la copie précédente. Pourtant le modem appelait un numéro retiré.

Dans ce cas, « version 73 » ne mentait pas forcément. Le nombre pouvait appartenir à une autre édition. RFC 3017 prévoyait que le consortium d’itinérance adapte ses carnets à différents groupes et que l’utilisateur en extraie encore des sous-ensembles. Le nom du carnet était une chaîne arbitraire. Sans émetteur, public, profil et base, comparer deux entiers ne suffisait pas.

Publié en décembre 2000, RFC 3017 portait un titre modeste : XML DTD for Roaming Access Phone Book. Son contenu l’était moins. L’objet pouvait indiquer une adresse téléphonique, les médias et tunnels disponibles, les débits annoncés, le script de numérotation, le prix, les serveurs DNS et de messagerie, les proxies, la passerelle, l’assistance et les chaînes à ajouter au nom d’utilisateur.

Le carnet proposait un menu. Le logiciel pouvait transformer ce menu en action.

Une compilation réunissait des déclarations distinctes

Les fournisseurs alimentaient le consortium avec leurs informations de POP. Le consortium réunissait les contributions et diffusait une version unifiée. Ce montage répondait à un besoin réel : un voyageur ne pouvait pas maintenir manuellement les numéros et paramètres de chaque opérateur.

Mais l’unification ne supprimait pas la provenance. Une entrée restait une déclaration du fournisseur, passée par une compilation et éventuellement par un filtrage destiné à un public. Un sous-ensemble national pouvait être exact tout en ne constituant pas la même lignée que le carnet mondial. Une absence pouvait signifier retrait, filtrage ou omission.

RFC 2194 avait observé cette mécanique dans des services antérieurs. Dans l’exemple GRIC, les membres transmettaient leurs données au secrétariat ; celui-ci compilait manuellement les numéros puis distribuait les mises à jour par FTP, par le web et par un client. Les données couvraient aussi les proxies, la configuration du composeur et les serveurs. Cette histoire n’établit pas l’adoption de RFC 3017. Elle montre le problème que le format cherchait à rendre portable.

Le compteur promettait une différence, pas une transition sûre

phoneBook@version devait augmenter à chaque modification. Un serveur pouvait comparer la valeur du client à sa valeur courante et renvoyer, par exemple, une URL contenant des différences.

Le texte ne définissait pourtant ni ces différences, ni leur transport. Il excluait explicitement tout protocole de transfert ou de mise à jour. Aucune règle n’y imposait une transaction atomique, un accusé de réception, une restauration, une relation cryptographique avec la base ou une représentation de suppression.

RFC 2477 avait placé ces obligations ailleurs. Un protocole de mise à jour devait permettre au client d’authentifier le serveur, de passer de n’importe quelle ancienne version à la dernière, de vérifier l’intégrité avant application, de vérifier le carnet produit, de rester léger et de respecter langue et jeu de caractères.

Cette liste montre ce que le nombre ne prouvait pas. Il ne prouvait pas que le bon serveur avait répondu. Il ne prouvait pas que le fichier avait été reçu en entier. Il ne prouvait pas que le résultat correspondait au digest attendu. Il ne prouvait pas que le client l’avait activé.

Le entryVersion de chaque POP avait la même limite. Il pouvait aider une opération de fusion, mais le POP n’avait pas d’attribut XML ID, contrairement aux blocs setup, support et provider. Une fusion devait encore déterminer si un changement d’adresse décrivait le même objet, un remplacement ou une deuxième entrée. La disparition d’un POP ne portait pas en elle sa cause.

Un compteur est utile lorsque l’identité et la transition existent autour de lui. Il ne les crée pas.

Le DTD savait lire la forme, pas tester le service

La plupart des valeurs étaient du #PCDATA. Des notations indiquaient une intention — FQDN, adresse IP, image encodée — mais ne rendaient pas la donnée vraie. Une adresse pouvait respecter la syntaxe et ne plus répondre. Un débit maximal pouvait être une capacité théorique. Un prix pouvait être ancien. Un serveur DNS pouvait exister tout en refusant le client.

Cette limite devenait opérationnelle parce que le carnet pouvait conduire le composeur. Le script déterminait comment joindre le POP. Les préfixes et suffixes pouvaient modifier automatiquement l’identifiant de base. Le bloc de configuration pouvait choisir DNS, courrier, proxy et passerelle.

Une erreur n’était donc pas confinée à l’affichage. Elle pouvait modifier la destination appelée, l’identité présentée et la route suivie par les applications.

L’extensibilité ne supprimait pas cette question. RFC 3017 permettait l’enregistrement de nouvelles valeurs et de nouveaux éléments optionnels. Maintenir la validité des anciens documents protégeait la compatibilité documentaire ; cela ne démontrait pas qu’un ancien client comprenait la sémantique d’une nouvelle extension. Il fallait connaître la version du parseur et l’ensemble réellement pris en charge.

La signature arrêtait la substitution, pas le temps

La sécurité de distribution restait hors du DTD. Le RFC exigeait une authentification fiable de l’émetteur et la préservation de l’intégrité, en citant une signature PGP comme possibilité.

Une signature vérifiée pouvait protéger les octets et l’identité de signature selon la politique de confiance. Elle ne garantissait pas que le POP fonctionnait encore au moment du voyage. Elle ne démontrait pas que l’édition signée visait ce client, ni que le client avait appliqué la bonne base.

Après le choix et la numérotation venait encore l’authentification. RFC 2486 utilisait le Network Access Identifier pendant l’échange PPP et pour orienter la demande vers le domaine d’origine. Un lien physique pouvait donc réussir tandis que l’identité échouait. L’authentification pouvait réussir tandis que l’adresse, le tunnel, le DNS ou le proxy échouait.

Chaque succès appartenait à une étape précise. Le signer ne recevait pas le reçu de la connexion ; le composeur ne recevait pas celui de l’application.

Deux sources pouvaient proposer le même paramètre

RFC 3017 reconnaissait que certaines valeurs de setup pouvaient également venir de DHCP. Si le carnet indiquait un DNS et DHCP un autre, le DTD ne pouvait pas décider lequel devait gagner. La décision appartenait au client, à la politique de l’opérateur et au contexte de connexion.

L’enquête devait donc partir de la configuration active, pas seulement du document téléchargé. Il fallait conserver l’émetteur, le nom et le profil du carnet, son digest, sa version, le POP retenu, entryVersion, la validation de signature, le parseur, les extensions, la base de mise à jour et le résultat du commit. Puis distinguer appel, lien, PPP, NAI, authentification, adresse, tunnel, DNS, proxy et trafic applicatif.

Alors seulement une équipe pouvait séparer carnet périmé, fusion incorrecte, numéro indisponible, identité rejetée et service défaillant.

La normalisation avait gardé une frontière saine

RFC 3017 n’avait pas promis d’exécuter tout le système. Il définissait une structure commune et laissait le protocole de transition à un autre travail. Cette limite était une force. Le danger naissait si l’implémentation transformait un artefact borné en vérité universelle.

Running-Code Primacy, chez Lu Heng, invite à confronter la configuration publiée au système qui fonctionne réellement. Reality Layers sépare forme valide, émetteur authentifié, état installé et accès réussi. Minimum Initial Specification montre pourquoi la couche commune peut rester étroite, tout en exigeant que compatibilité, validation locale et transition trouvent une place explicite.

Ces textes servent ici de grilles d’analyse, sans attribuer à Lu Heng un rôle dans RFC 3017.

Le carnet rendait l’itinérance possible à une époque où l’accès commençait souvent par un numéro local. Mais son compteur n’était jamais le dernier témoin.

Il disait que le livre avait bougé. Seule la connexion pouvait dire si le réseau était encore là.

Sources