Résumé

  • RFC 9569 nomme chaque instantané ou mise à jour incrémentale d’une ressource ALTO et les organise dans un graphe de versions. Le serveur doit maintenir une chaîne continue, un point de reprise complet et un historique qui n’évolue que vers l’avant.
  • Ces garanties portent sur la reconstruction du contenu déclaré. Elles ne datent pas la mesure amont, ne prouvent pas l’ordre d’application chez le client et ne relient pas l’information à une route réellement choisie ou à un gain mesuré.

410 Gone est peut-être le code le plus honnête de RFC 9569. Il dit au client que l’arête demandée précède désormais le début du graphe conservé. Le serveur a compacté son histoire ; le client doit demander un nouveau chemin.

Ce code ne prétend pas que l’information encore disponible est récente. Il ne prétend pas davantage que l’ancienne information est devenue fausse. Il situe seulement une demande dans l’histoire que le serveur accepte encore de publier. C’est une borne précise, et c’est justement pourquoi il faut résister à l’envie de lui faire dire plus.

RFC 9569 est une norme IETF de septembre 2024. Sa fiche RFC Editor, sa page Datatracker, son historique et la recherche d’errata établissent son statut documentaire. Aucun de ces éléments ne prouve qu’un déploiement donné observe correctement le réseau.

Publier une transition plutôt qu’un flux opaque

Le protocole ALTO de RFC 7285 permet à une application de demander des ressources d’information réseau. RFC 8895 ajoute des mises à jour incrémentales poussées au moyen de Server-Sent Events. TIPS complète ces deux mécanismes en donnant une adresse HTTP à chaque instantané et à chaque différence. Un client choisit les éléments qu’il tire et peut les transporter en parallèle, sans blocage, notamment avec HTTP/2 ou HTTP/3.

Le TIPS view contient un graphe orienté sans cycle. Ses nœuds représentent les versions historiques déclarées par le serveur. Ses arêtes contiennent soit un remplacement complet, soit une transformation partielle fondée sur JSON Patch ou JSON Merge Patch. La version 0 représente l’état vide. Les transitions entre versions consécutives sont obligatoires ; des raccourcis peuvent relier des versions plus éloignées.

Le contenu d’un nœud doit être indépendant du chemin suivi. Un instantané direct, une série d’écarts ou un raccourci doivent conduire au même résultat. Cette propriété permet de contrôler la cohérence interne du graphe. Elle ne compare jamais ce résultat aux protocoles de routage, aux règles de provisionnement ou aux mesures dynamiques qui ont alimenté la ressource ALTO.

Trois invariants, une portée limitée

La continuité impose toutes les versions entières entre le début et la fin, ainsi que chaque arête consécutive. La faisabilité impose un instantané complet au début de la fenêtre. Le déplacement « vers la droite seulement » autorise la fenêtre à avancer, jamais à revenir en arrière.

Ces invariants garantissent qu’un client peut reconstruire un état encore offert. Ils ne garantissent ni l’heure de l’observation, ni l’exhaustivité de ses sources, ni sa pertinence au moment de la décision. Un graphe impeccable peut transporter fidèlement une vision périmée.

Le schéma d’URI rend chaque arête prévisible : le client connaît les numéros de départ et d’arrivée et peut même interroger à l’avance la transition suivante. Si le view n’existe plus, 404 Not Found peut être renvoyé ; si la séquence demandée dépasse la fenêtre de long polling, 425 Too Early peut apparaître. Chaque réponse documente le service de transport, pas l’état externe du réseau.

La « recommandation d’arête » mérite la même discipline. Le serveur peut choisir le chemin qui minimise le nombre de messages ou le volume cumulé. Il recommande une manière de reconstruire sa ressource ; il ne recommande pas une route de production.

Le client fabrique la cohérence finale

Les mises à jour parallèles et reçues dans le désordre augmentent le débit. Elles obligent toutefois le client à respecter les dépendances. Une version de carte de coûts peut dépendre d’une version précise de carte réseau. Avoir reçu les deux fichiers ne signifie pas avoir assemblé la bonne paire. Si le client manque de mémoire pour mettre les écarts en attente, RFC 9569 lui recommande de redemander un instantané complet.

Le déploiement du serveur compte lui aussi. Si l’état d’un view réside sur un seul backend et qu’un répartiteur de niveau 4 envoie la requête suivante à un autre backend, le traitement peut être erroné. Le texte envisage un état partagé ou un routage de niveau 7 fondé sur le chemin du view. Un succès HTTP isolé ne prouve donc pas l’unité de l’autorité d’état.

La norme a également abandonné une ancienne tentative de déduire la présence du client d’une connexion HTTP persistante. Avec un mandataire, la connexion client-mandataire et la connexion mandataire-serveur sont distinctes. La seconde peut survivre sans prouver la première. RFC 9205 expose les bonnes pratiques de protocoles fondés sur HTTP ; RFC 9113 définit HTTP/2. Le transport reste un transport.

Le registre ALTO de l’IANA confirme les types de médias TIPS. Il ne mesure ni déploiement ni adoption.

Pour affirmer un effet d’optimisation, il faut joindre l’observation amont horodatée, le calcul de la ressource, les identifiants de version, les condensats des arêtes, la version de base du client, le résultat de chaque patch, les dépendances appliquées, la consultation par l’application, l’action retenue, le trajet réellement observé et la comparaison de performance. Le graphe n’est qu’un segment de cette chaîne.

L’essai de Heng Lu sur les couches du réel empêche la cohérence interne d’usurper la vérité externe. Running-Code Primacy replace l’autorité dans le comportement observable. Le texte sur la raison d’être de BTW Media impose enfin une règle éditoriale : dire exactement quelle transition est prouvée, puis signaler les jonctions absentes.

Sources