Zusammenfassung

  • Die MOQ-Arbeitsgruppe hat am 1. Oktober Entwurf 22 vorgelegt. Bei Parameter 0x21 (LOCATION_FILTER) steht hinter der Kennung nicht mehr das Length-Feld von Fassung 21, sondern ein Location Filter Type. Die Werte 0x00 bis 0x05 wählen die zulässige Form; jeder andere Wert ist eine PROTOCOL_VIOLATION.
  • Das Änderungsprotokoll führt diesen Schritt als Eingriff in Sitzungs- und Steuerungsebene. Eine neue Darstellung pausierter Abonnements ist dagegen als redaktionelle Klarstellung verzeichnet. Der Text ist weiterhin ein Internet-Draft, keine verabschiedete RFC und kein Befund über einen realen Ausfall.

Beim Abonnieren eines laufenden Tracks ist „ab dem nächsten Objekt“ eine andere Anweisung als „ab dem Anfang dieser Gruppe“. Dass ein QUIC-Kanal offen bleibt, beweist nicht, dass ein Relay diese Auswahl an beiden Enden gleich interpretiert. Wer ein Release abnimmt, muss deshalb mehr prüfen als den Handshake. Die neue Fassung macht einen bislang impliziten Bestandteil dieser Prüfung ausdrücklich sichtbar.

In Entwurf 21 begann LOCATION_FILTER mit dem Parametertyp 0x21 und danach einem variablen Integer namens Length. Seine Bytezahl entschied, ob null bis vier weitere variable Integer folgten. Null Byte bedeuteten keinen Filter. Zwei Felder mit dem Wert null bezeichneten als Sonderfall das nächste Objekt. Für relative Starts und absolute Bereiche ergab sich die Form ebenfalls aus Zahl und Inhalt der Felder.

Fassung 22 lässt 0x21 bestehen, ersetzt aber die zweite Zahl durch einen Diskriminator. 0x00 steht für keinen Filter, 0x01 für einen relativen Start, 0x02 für einen absoluten Start, 0x03 für einen Bereich bis zu einem Gruppenende, 0x04 für einen vollständigen absoluten Bereich und 0x05 für das nächste Objekt. Nur die jeweils vorgesehenen Felder folgen. Der alte Sonderfall aus zwei Nullen ist für die letzte Form nicht mehr nötig. Ein unbekannter Typ ist kein frei interpretierbarer Zusatz, sondern ein Protokollverstoß. Die sechs Werte sind Formen der Positionsangabe, nicht Kategorien von Medien oder Zugriffsrechten.

Die Reichweite der Änderung ergibt sich aus den Nachrichten, die diesen Parameter tragen dürfen: FETCH, SUBSCRIBE, PUBLISH, ein REQUEST_UPDATE für Abonnements und PUBLISH_STATE_NOTIFY. Ein Relay kann also sowohl eine Anfrage lesen als auch einen wirksamen Filter zurückmelden oder nach oben weiterreichen. Daraus folgt eine Testaufgabe für Betreiber; aus dem Entwurf folgt nicht, dass eine bestimmte Installation bereits falsch gearbeitet hat.

Das Protokoll sieht eine Versionsaushandlung vor: per ALPN bei QUIC und über den entsprechenden Mechanismus bei WebTransport. Vorläufige Kennungen unterscheiden Entwurfsstände. Darum wäre die Behauptung falsch, konforme Implementierungen von 21 und 22 müssten automatisch dieselben Bytes widersprüchlich deuten. Die konkrete Frage lautet vielmehr, welcher Stand auf jeder Verbindung ausgehandelt und welcher Parser für den Filter tatsächlich eingesetzt wurde. Erst der Vergleich mit den ausgelieferten Objekten zeigt, ob die Auswahl erhalten blieb.

Die Abgrenzung zu anderen Änderungen ist wichtig. Anhang A.1 nennt den neuen Filtertyp als Änderung an der Steuerung. Umstellungen bei FETCH, Antwortenamen und der Beschreibung pausierter Abonnements stehen unter den redaktionellen Punkten. Sie können die Umsetzung erleichtern, sollten aber nicht als neu geschaffene Pause-Funktion verkauft werden. Der eigenständige Nachrichtenwert dieser Fassung liegt in der geänderten Codierung des Auswahlbefehls.

Quellen