Zusammenfassung

  • RFC 9569 ordnet ALTO-Snapshots und inkrementelle Änderungen als benannte Kanten zwischen fortlaufenden Ressourcenversionen. Ein Start-Snapshot und Regeln für die Vorwärtskompaktierung halten die veröffentlichte Historie rekonstruierbar.
  • Rekonstruierbarkeit betrifft die Darstellung des Servers. Sie belegt weder den Zeitpunkt der zugrunde liegenden Netzbeobachtung noch die konsistente Verarbeitung beim Client, die tatsächliche Anwendungsentscheidung oder ein besseres Verkehrsergebnis.

Ein Update-Graph kann jede vorgeschriebene Kante enthalten und trotzdem der Gegenwart hinterherlaufen. Das ist kein Fehler in der Graphentheorie, sondern eine Verwechslung von zwei Uhren: der Versionsuhr des Servers und der Uhr der beobachteten Welt.

RFC 9569 regelt die erste Uhr. Der RFC-Editor-Eintrag, der IETF-Datatracker, die Dokumenthistorie und die Errata-Suche belegen Herkunft und Status des Standards. Sie belegen keine laufende ALTO-Installation und keine Netzbeobachtung.

Aus Änderungen werden adressierbare Belege

Das ALTO-Basisprotokoll aus RFC 7285 liefert vollständige Netzinformationsressourcen. RFC 8895 ergänzt gepushte inkrementelle Aktualisierungen über Server-Sent Events. TIPS bietet ein Pull-Modell, in dem jeder Snapshot und jede Änderung eine eigene HTTP-Ressource ist. Clients können mehrere Kanten parallel und außerhalb der Reihenfolge abrufen, insbesondere über HTTP/2 oder HTTP/3; HTTP/1.1 bleibt möglich.

Eine TIPS view enthält einen gerichteten azyklischen Update-Graphen. Knoten sind historische, vom Server vergebene Versionen. Kanten berechnen aus Version i die Version j. Version 0 ist als leerer Ausgangszustand reserviert; eine Kante von 0 ist ein vollständiger Snapshot. Andere Kanten können JSON Patch oder JSON Merge Patch enthalten. Übergänge zwischen Nachbarversionen sind zwingend, Abkürzungen optional.

Alle Wege zu einem Knoten müssen denselben Inhalt ergeben. Diese Pfadunabhängigkeit prüft die interne Transformationslogik. Sie prüft nicht, ob Routingprotokolle, Bereitstellungsregeln, dynamische Messwerte und externe Quellen den wirklichen Netzzustand vollständig oder rechtzeitig beschrieben haben.

Die Regeln bewahren Erreichbarkeit, nicht Wahrheit

Kontinuität verlangt alle ganzzahligen Versionen und Nachbarkanten zwischen start-seq und end-seq. Machbarkeit verlangt einen Snapshot für die aktuelle Startversion. Die Regel „nur nach rechts“ erlaubt beiden Grenzen, mit der Zeit voranzurücken, aber nicht zurückzugehen.

Damit bleibt jeder angebotene Zustand erreichbar. Der Standard fügt dieser Aussage weder einen Messzeitpunkt noch eine externe Wahrheitsprüfung hinzu. Auch ein formal perfekter Graph kann eine veraltete Eingabe präzise weitertragen.

Wird eine alte Kante bei der Kompaktierung entfernt, kann der Client 410 Gone erhalten und eine neue Einstiegsempfehlung anfordern. Ein fehlender oder geschlossener View kann 404 Not Found liefern, eine zu weit vorausgreifende Anfrage 425 Too Early. Solche Antworten erklären den Zustand des Veröffentlichungsdienstes. Sie bewerten nicht, ob der zuletzt angewandte Netzzustand noch brauchbar ist.

Die empfohlene Kante ist ebenfalls eng definiert. Der Server darf nach Nachrichtenanzahl, Datenmenge oder einem anderen Implementierungskostenmaß wählen. Diese Empfehlung betrifft den günstigsten Weg durch den Update-Graphen, nicht den besten Weg für Nutzverkehr.

Parallelität verlagert die Konsistenzarbeit

Paralleler, ungeordneter Empfang beschleunigt die Übertragung, beseitigt aber keine Abhängigkeiten. Eine Cost Map kann nur zu einer bestimmten Network-Map-Version passen. Zwei erfolgreich geladene Objekte sind noch kein konsistentes Paar. Der Client muss Updates passend puffern und anwenden; fehlen Ressourcen, empfiehlt RFC 9569 einen vollständigen Snapshot.

Auch die Backend-Architektur ist Teil des Belegs. Liegt der Zustand eines Views nur auf einem Server, kann Layer-4-Lastverteilung eine spätere Anfrage an das falsche Backend schicken. Der RFC nennt gemeinsam gespeicherten Zustand oder Layer-7-Verteilung nach dem View-Pfad. Ein einzelnes 200 OK beweist deshalb keine durchgehend einheitliche Zustandsquelle.

Eine frühere Entwurfsfassung wollte zudem aus einer dauerhaften HTTP-Verbindung die Erreichbarkeit des Clients ableiten. Der endgültige Text verwirft das: Ein Proxy trennt Client-Proxy- und Proxy-Server-Verbindung. Die serverseitige Verbindung kann bestehen, obwohl der eigentliche Client nicht mehr lebt. RFC 9205 beschreibt die Disziplin für HTTP-basierte Protokolle; RFC 9113 spezifiziert HTTP/2. Transportzustand bleibt von Anwendungszustand getrennt.

Das IANA-Register für ALTO führt die TIPS-Medientypen. Registrierung ist Koordinations-, nicht Betriebsnachweis.

Wer eine Optimierung behauptet, braucht eine längere Kette: Quelle und Zeit der Netzbeobachtung, ALTO-Berechnung und Versionstag, View und Kanten-Hashes, Basisversion und Patch-Ergebnis des Clients, Abhängigkeitsversionen, Nutzung durch die Anwendung, gewählte Aktion, tatsächlich beobachteter Pfad und Leistungswert gegenüber einer benannten Vergleichsbasis. TIPS stärkt die Mitte dieser Kette, nicht deren Anfang oder Ende.

Heng Lus Text über Realitätsebenen verhindert, dass Graphenkonsistenz die Messwahrheit vereinnahmt. Running-Code Primacy verlangt beobachtetes Verhalten statt symbolischer Gewissheit. Warum BTW Media existiert liefert die redaktionelle Grenze: Den belegten Übergang berichten und den Erfolg erst dann, wenn auch seine Übergänge belegt sind.

Quellen