Résumé

  • Le projet permet à un client LoST de suivre des ChangeSets, de repérer les enregistrements civiques susceptibles de changer et de valider à l’avance leur remplacement pour un instant asOf.
  • La réponse future exprime la connaissance présente du serveur : elle est NO-CACHE, peut évoluer avant l’échéance et ne dispense jamais d’une résolution LoST contemporaine à l’usage du service.
  • L’avis, la continuité du flux, la préparation, l’activation, la résolution actuelle, la transmission de la localisation, la réception par le PSAP et l’issue opérationnelle sont des preuves différentes.

Une frontière administrative change sans déplacer la maison

Une commune annexe un quartier à minuit. La veille, l’adresse d’un bâtiment peut être correctement validée sans nom de commune dans le champ A3 ; le lendemain, le même bâtiment doit porter une nouvelle valeur. La géométrie n’a pas bougé. Ce sont la description civique et son autorité temporelle qui changent.

Le projet actuel donne au serveur LoST et à ses clients une façon de préparer ce passage. RFC 5222 savait déjà valider les éléments d’une adresse et associer une localisation et un service à une URI. RFC 5139 fournit le vocabulaire civique. L’extension ajoute un flux de changements planifiés, un objet ChangeSet et la possibilité de demander ce qui serait valide à une date future.

Un client interroge PlannedChangePoll, conserve le dernier identifiant reçu, récupère le contenu par GetChangeSet, compare les localisations partielles à ses propres lignes puis prépare les remplacements. L’heure changeSetEffective coordonne l’activation. revalidateAfter peut indiquer quand contrôler de nouveau une validation courante.

Le mécanisme réduit le travail à l’aveugle. Il ne transforme pas la préparation en exécution.

asOf est une projection datée, pas un acte irrévocable

Le texte encadre très précisément la réponse future. Le serveur répond avec ce qu’il sait, au moment de la requête, des changements qui devraient être en vigueur à l’instant demandé. Une information nouvelle peut arriver. Deux requêtes portant sur le même asOf peuvent donc diverger. La réponse doit imposer expires="NO-CACHE", et le client ne doit pas supposer que la correspondance survivra jusqu’à la date prévue.

Lorsqu’il faut effectivement joindre le service, une requête LoST contemporaine reste nécessaire. Cette phrase sépare trois réalités : le plan publié, l’état activé et la route utilisée.

Même NO-EXPIRATION reste modeste. Il signifie que le serveur ne connaît actuellement aucun changement planifié justifiant une échéance de revalidation. Il ne garantit ni stabilité perpétuelle ni absence de correction imprévue. Le projet maintient donc la revalidation périodique en complément du flux.

La chaîne décrite par RFC 6443 explique l’enjeu. Un terminal obtient une localisation, LoST calcule une destination, la signalisation transporte localisation et route, puis des fonctions de routage conduisent l’appel vers un centre de réception des appels d’urgence. RFC 6881 demande en outre une tentative d’actualisation de la localisation et du mapping au moment de l’appel, avec une procédure de repli sur une valeur en cache si l’actualisation n’arrive pas assez vite. La projection de la veille n’atteste aucune de ces opérations.

L’identifiant de flux ne tranche pas un désaccord d’autorité

Le ChangeSet ID sert de mémoire entre un serveur et un client. Sa chaîne de caractères ne doit pas nécessairement exposer son ordre ; le serveur sait quels ensembles viennent après. Si le client perd l’identifiant, il redemande tout ce que le serveur conserve encore.

L’avis du Security Directorate demande alors où se trouve la portée de cet identifiant. Deux serveurs peuvent-ils produire la même valeur ? Le client doit-il garder une file distincte par serveur ? Que faire si deux autorités ne décrivent pas le même état pour la même date ? L’avis relève aussi un écart apparent entre la prose, qui exige l’ancien identifiant lors des interrogations suivantes, et l’OpenAPI, qui ne semble pas déclarer ce paramètre.

Ce sont des questions de responsabilité, pas de syntaxe décorative. Un curseur prouve au mieux la position du client dans le flux conservé par un serveur déterminé. Sans portée, provenance et réconciliation, il ne prouve ni l’accord des autorités, ni l’absence de trou, ni l’application locale du changement.

L’avis opérationnel formule une difficulté comparable pour les schémas. Le projet laisse Relax NG, issu de RFC 5222, comme référence autoritative, tout en proposant un XML Schema plus accessible mais non autoritatif et destiné aux extensions. Une validation réussie contre l’outil pratique ne peut valoir conformité à l’outil autoritatif sans démonstration d’équivalence.

La bascule doit produire ses propres preuves

Un dossier exploitable commence par l’avis : serveur émetteur, identifiant, heure d’effet, localisations partielles et lignes locales correspondantes. Il continue avec la continuité du flux : curseur précédent, ordre renvoyé, durée de conservation et éventuels trous. La validation future conserve l’heure de requête, asOf, l’entrée exacte, la réponse et l’interdiction de cache.

La préparation locale enregistre les nouvelles lignes, les conflits, la validation humaine ou automatique et la tâche programmée. À l’heure d’effet, une preuve différente doit constater le retrait des anciennes lignes, l’activation des nouvelles, les échecs et la capacité de retour arrière.

Puis la chaîne de service repart de l’état présent : localisation effectivement obtenue, mapping LoST actuel, URI du PSAP, objet de localisation transmis, trajet de signalisation, réception, établissement de l’appel et réponse opérationnelle. La continuité du processus ne donne à aucun composant le droit de parler pour le suivant.

Cette discipline rejoint une règle élémentaire : le document décrit, le code exécute et chaque opérateur ne peut attester que la surface qu’il contrôle. Mélanger ces plans produit une autorité symbolique — « le changement était validé » — là où les dirigeants ont besoin d’une réalité exécutable — « la bonne route a fonctionné ».

Le document n’est pas encore une norme approuvée

À l’heure de clôture de la recherche, l’ordre du jour de l’IESG plaçait la révision 18 au téléchat du 24 septembre. Datatracker indiquait IESG Evaluation, trois positions DISCUSS, des voix encore nécessaires et un examen IANA non résolu sur l’enregistrement XML. Les avis sécurité et opérations signalaient des problèmes. Il s’agit d’un Internet-Draft actif, non d’un RFC approuvé, d’un déploiement ou d’un résultat d’interopérabilité.

L’analyse ne prédit pas le scrutin. Elle préserve une question qui demeurera après toute révision : quel fait chaque reçu établit-il, qui possède la transition suivante et quelle voie de retour subsiste si la réalité refuse le calendrier ?

Sources

Documents primaires : Internet-Draft actuel, ordre du jour IESG, revue Security Directorate, revue Operations Directorate, RFC 5222, RFC 5139, RFC 6443 et RFC 6881.