Résumé

  • Le projet ECRIT définit un flux ordonné de changements planifiés, une validation LoST avec asOf et un conseil revalidateAfter. Un client peut ainsi repérer les enregistrements susceptibles de changer et préparer leur remplacement.
  • Deux requêtes visant la même date future peuvent produire des réponses différentes lorsqu’elles sont émises à des moments distincts. La réponse décrit les connaissances présentes du serveur, non une garantie sur l’état futur.
  • Un reçu à deux étapes devrait conserver séparément la préparation et l’observation du basculement. Cette forme de preuve est une proposition éditoriale de Daniel Kade, et non une exigence de l’IETF.

Une même porte, une autre adresse administrative

Une limite municipale peut entrer en vigueur à minuit sans déplacer une maison d’un centimètre. Pourtant, l’adresse civique utilisée par des systèmes de localisation peut devoir acquérir un nouveau nom de commune. Le projet Validation of Locations Around a Planned Change part de ce cas, puis mentionne les changements de nom ou de numérotation d’une rue. Sa révision 18 est un Internet-Draft actif : elle reste un travail en cours, pas un RFC ni la preuve d’un déploiement.

RFC 5222 définit LoST, protocole qui associe une localisation et un identifiant de service à des URI de service. Il permet aussi de demander la validation des éléments d’une adresse civique. Le format de ces éléments vient notamment de RFC 5139.

Avant l’extension proposée, un client LoST tel qu’un serveur d’information de localisation doit revalider périodiquement ses enregistrements pour découvrir les évolutions. La cadence peut être trop lente au moment du changement et trop coûteuse le reste du temps. Le projet cherche donc à annoncer un ensemble de lieux pouvant être touchés et à permettre une vérification anticipée.

La difficulté institutionnelle se loge dans le mot « anticipée ». Une vérification effectuée lundi pour vendredi reste une observation du lundi. Même si le paramètre de la requête porte la date du vendredi, le serveur ne peut répondre qu’avec les informations dont il dispose au moment où il répond.

Trois horloges ne forment pas un seul verdict

Le premier temps est celui du flux de changements. Une interface REST/JSON distincte permet de connaître la version, de sonder le serveur et de récupérer un ChangeSet. Chaque ensemble possède un identifiant ordonné, une date d’effet et des localisations partielles. Le client mémorise le dernier identifiant reçu et demande les suivants.

Le deuxième temps est celui de asOf. Dans une requête findService, le client peut demander comment une localisation serait validée à une date et une heure données. Pour une réponse qui ne vise pas l’instant présent, le serveur doit renvoyer la valeur asOf, tandis que les correspondances portent l’indication NO-CACHE.

Le troisième temps concerne la revérification. revalidateAfter suggère le moment après lequel le client peut souhaiter interroger de nouveau le serveur. La valeur NO-EXPIRATION affirme seulement que le serveur ne connaît actuellement aucun changement planifié qui modifierait le résultat. Elle ne garantit pas l’absence d’une information nouvelle.

Ces mécanismes distribuent l’autorité au lieu de la concentrer. Le flux décrit ce que le serveur connaît après une position donnée. asOf donne une projection datée. revalidateAfter conseille un rythme. Le client reste responsable de la sélection de ses propres lignes, de la mise en service du nouvel état et du retour arrière éventuel.

Un tableau de bord qui fusionne tout en « changement validé » efface ces responsabilités. Il donne au producteur du ChangeSet un pouvoir fictif sur la base locale et transforme une prévision révisable en certification d’exécution.

La localisation partielle sélectionne, elle ne condamne pas

Énumérer chaque adresse complète rendrait les annonces lourdes et fragiles. Le projet utilise donc une localisation partielle : une suite de couples associant espace de noms, nom d’élément et valeur. Un enregistrement local peut être concerné lorsque tous les couples fournis correspondent. Les champs absents ne servent pas à la comparaison.

Un ChangeSet peut ainsi désigner une subdivision administrative entière sans nommer chaque rue, ou une rue sans lister tous ses numéros. Le mécanisme délimite une population de travail. Il ne dit pas que chaque membre de cette population devra nécessairement changer.

La nuance « peut être concerné » doit survivre dans les systèmes internes. Il faut conserver la règle de comparaison, l’instantané de la base, le nombre de candidats, les exclusions et les exceptions humaines. Un chiffre global ne permet pas de savoir si une mise à jour du schéma, une valeur corrigée ou un filtre défectueux a élargi ou réduit la sélection.

Cette économie de la couche commune rejoint la doctrine de spécification initiale minimale de Lu Heng. Le protocole fournit les éléments déterministes nécessaires à l’interopérabilité. La décision future demeure chez les participants qui exploitent le code. Refuser cette séparation revient à demander au format d’échange de gouverner des bases qu’il ne voit pas.

Le futur doit rester corrigeable

Le projet est explicite : deux requêtes envoyées à des dates différentes avec la même valeur asOf future peuvent recevoir des résultats différents. Une modification planifiée ou imprévue peut être apprise entre-temps. Le serveur ne garantit donc pas le résultat d’une prochaine requête sur le même lieu.

Cette instabilité encadrée est une qualité. Une annexion peut être reportée, une numérotation rectifiée ou un jeu de données livré tardivement. Figer la première projection protégerait un ticket de changement au détriment de la réalité.

L’instruction NO-CACHE matérialise la limite. Le texte précise également qu’un client qui doit contacter un service reste censé utiliser LoST au moment du besoin. La validation future sert à préparer une base ; elle ne remplace pas la résolution contemporaine du service.

Le mandat du groupe ECRIT concerne notamment l’usage de la localisation et des informations de routage afin de permettre une communication avec le centre d’intervention pertinent. Il exige une architecture utilisable entre plusieurs régions et juridictions, sans autorité centrale unique. La prudence est donc double : une adresse validée ne prouve pas la réussite d’une communication d’urgence, et l’état prévu par un serveur ne prouve pas son adoption par tous les clients indépendants.

La règle éditoriale de Lu Heng — produire la réalité, non le plaidoyer — conduit à nommer exactement l’observation : telle requête, telle réponse, à tel instant, pour telle date visée. L’expression « basculement achevé » exige une autre preuve.

Une suite ordonnée peut néanmoins avoir un trou

Le client doit normalement sonder le serveur toutes les quelques minutes et conserver le dernier identifiant de ChangeSet. Si le serveur ne renvoie rien, cela signifie que cet identifiant est le plus récent qu’il connaît. Cela ne prouve ni le traitement des ensembles antérieurs ni l’absence d’un changement imprévu.

Un nouveau client, ou un client ayant perdu sa position, peut sonder sans identifiant. Il reçoit alors tous les ChangeSets que le serveur conserve encore. Or le projet n’impose pas une rétention perpétuelle : il propose, à titre d’exemple, douze mois dans une zone peu changeante et trois mois dans une zone très active.

La perte de position crée donc un nouvel état opérationnel : continuité inconnue. Le client doit établir un socle courant, enregistrer le trou et ouvrir une nouvelle époque de suivi. Prendre le plus ancien ensemble encore disponible pour le début de l’histoire fabriquerait une continuité qui n’a pas été observée.

Le Policy Mirror de Lu Heng distingue le registre de la souveraineté. Ici, la liste ordonnée mérite confiance dans sa portée : elle atteste la séquence conservée par ce serveur. Elle ne doit pas être transformée en témoin de toutes les décisions civiques ou de toutes les activations locales.

Un reçu en deux étapes

La première partie, consacrée à la préparation, devrait relier l’identité du serveur, la version de l’interface, l’heure du sondage, l’ancien identifiant et les nouveaux identifiants reçus. Elle ajouterait la date d’effet, la localisation partielle, l’instantané local, la règle de sélection, les candidats et les exceptions. Enfin, elle conserverait la requête de validation, asOf, la réponse, revalidateAfter, l’état de cache et la révision du document source.

La seconde partie commencerait au basculement. Elle enregistrerait l’heure réellement reconnue, le retrait des anciens enregistrements, l’activation des nouveaux, une validation contemporaine, les différences avec la projection, les échecs, les reports, le retour arrière et l’autorité locale qui a clos l’opération.

« Reçu en deux étapes » est une proposition de cet article. Le projet IETF ne l’impose pas. La vue complète peut rester protégée, car les bases de localisation sont sensibles. Une vue publique peut présenter des volumes, des plages temporelles, les références de ChangeSet et les exceptions non résolues. Une empreinte peut lier les deux vues sans certifier la justesse de leur contenu.

Le principe important consiste à ne jamais remplacer la préparation par l’observation. Si le résultat du vendredi diffère de celui du lundi, les deux ont une valeur. Le premier explique la décision raisonnable avec les connaissances disponibles. Le second montre l’état que le client a réellement rencontré.

Conseiller une cadence, c’est répartir un coût

Le projet décrit le choix de l’intervalle comme un équilibre entre fraîcheur, charge du serveur, stabilité des données et politique locale. Il évoque six mois ou davantage dans certaines zones stables, et 20 à 30 jours dans des zones à croissance rapide. Ces nombres illustrent un raisonnement ; ils ne constituent pas un niveau de service universel.

Le serveur connaît sa charge et ses données. Le client connaît son inventaire, sa tolérance au retard et les conséquences d’une information périmée. revalidateAfter transmet un conseil sans absorber la décision du client. Toute dérogation devrait néanmoins avoir un propriétaire et un motif.

Une cadence trop longue laisse survivre des données invalides. Une cadence trop courte peut gêner le traitement LoST, comme le rappelle la section de sécurité du projet à propos des sondages excessifs. Disponibilité et actualité partagent la même capacité. Les gouverner exige donc de conserver le conseil reçu, le choix local et les mesures de charge qui ont fondé ce choix.

Ce qui peut être affirmé

Le reçu de préparation peut établir qu’un client a reçu un ensemble précis, l’a comparé à un instantané défini et a obtenu une réponse future à un instant précis. Le reçu de basculement peut établir ce que ce client a activé et le résultat de sa nouvelle validation.

Même réunis, ils ne prouvent pas que tous les serveurs possédaient les mêmes données, que l’acte juridique sous-jacent était valide, que la correspondance de service n’a plus changé ou qu’une communication a atteint un intervenant. Ces affirmations ont besoin d’autres témoins.

L’autorité civique modifie la limite. Le serveur LoST représente les données qu’il détient. Le client transforme certains enregistrements locaux. Une requête actuelle trouve un service. Le système de communication tente un acheminement. Une gouvernance honnête conserve ces verbes séparés, puis documente leurs jonctions au lieu de les résumer par une seule couleur.

Sources