Zusammenfassung

  • Mark Nottingham schlug „HTTP/3“ vor, damit das Mapping von HTTP-Semantik über QUIC als HTTP-Protokoll erkennbar blieb und nicht mit dem QUIC-Transport selbst verschmolz.
  • Der Namensvorschlag war mit einem Zuständigkeitsvorschlag verbunden: Nach der Veröffentlichung sollten die HTTP-Gruppe HTTP/3 und QPACK pflegen. Spätere IETF-Charter halten diese Aufteilung fest.
  • Die Grenze machte Verantwortlichkeiten sichtbarer. Sie garantierte weder kompatiblen Code noch den Einsatz des Protokolls und machte Nottingham nicht zum alleinigen Entscheider.

Ende 2018 bezeichnete „QUIC“ mitunter zwei verschiedene Dinge: das Transportprotokoll und das HTTP-Mapping, das auf diesem Transport laufen sollte. Wer die Arbeit nicht eng verfolgte, konnte beides leicht für ein einziges Vorhaben halten. Das war mehr als eine kommunikative Ungenauigkeit. Wenn Transport und Anwendungsprotokoll nicht auseinanderzuhalten waren, blieb auch unklar, welche Arbeitsgruppe später über Änderungen entscheiden sollte.

Am 28. Oktober schrieb Mark Nottingham an die QUIC-Arbeitsgruppe. Er schlug vor, das HTTP-Dokument „HTTP/3“ zu nennen und h3 als endgültige ALPN-Kennung zu verwenden. Der Name sollte zeigen, dass HTTP-Semantik an ein anderes Protokoll auf der Leitung gebunden wird, ähnlich wie bei HTTP/2, und dass diese Abbildung von QUIC als Transport zu unterscheiden ist. Seine ursprüngliche Mail hält die Begründung fest.

Nottingham verband den Namen mit einem zweiten Vorschlag: Nach der Veröffentlichung sollten HTTP/3 und QPACK von der HTTP-Arbeitsgruppe gepflegt werden. Ein Dokument in der Gruppe zu verfassen, die den Transport entwickelt, heißt nicht, dass diese Gruppe jede spätere Entscheidung über das Anwendungsprotokoll übernehmen muss. Die QUIC-Gruppe konnte das erste Mapping liefern; die HTTP-Gruppe sollte anschließend die für HTTP relevanten Erweiterungen und Wartungsfragen verantworten. Der Name erklärte, was beschrieben wurde. Die Übergabe sollte klären, wer als Nächstes zuständig wäre.

Im Raum wurden Zustimmung und Entscheidungsrecht getrennt

Bei IETF 103 diskutierte die QUIC-Gruppe den Namen. Das Protokoll zeigt unterschiedliche Einschätzungen: Manche verstanden HTTP/3 als Nachfolger von HTTP/2, andere befürchteten, der Name könne einen Fork nahelegen. Nottingham erinnerte daran, dass HTTP/2 HTTP/1.1 weder abgeschafft noch ersetzt hatte. Entscheidend sei vielmehr die Trennung von Semantik und Protokoll auf der Leitung.

Das Protokoll hält kein formelles Votum fest. Es vermerkt ein informelles „Humming“: ungefähr 70 zu 30 für die Umbenennung und nahezu einhellige Unterstützung dafür, HTTPbis entscheiden zu lassen. Der zweite Punkt erklärt die Zuständigkeitsgrenze besser. Die Arbeit war in der QUIC-Gruppe entstanden, aber über den Namen einer HTTP-Version sollte die HTTP-Community befinden. Nottingham sagte ausdrücklich, dass die Benennung von HTTP in der HTTP-Community bleiben müsse.

Seine Mail vom Oktober trug den Zusatz „Chair hat“. Er wollte der Namensfrage in Bangkok nur begrenzt Zeit geben und ein endloses Wunschkonzert vermeiden. Entwickler und Nutzer brauchten eine verständliche Beschreibung, zugleich musste die Gruppe ihre technische Arbeit fortsetzen. Ein Vorsitzender kann eine Frage eingrenzen und die Tagesordnung steuern. Das ersetzt jedoch keinen Konsens.

Der Name ist nur dann präzise, wenn die Schichten sichtbar bleiben

Die veröffentlichte Spezifikation bewahrt diese Unterscheidung. RFC 9114 beschreibt HTTP/3 als Mapping von HTTP-Semantik über QUIC. RFC 9110 legt die HTTP-Semantik fest; RFC 9000 definiert den QUIC-Transport. HTTP/3 nutzt QUICs zuverlässige, geordnete Übertragung je Stream und dessen Sicherheitseigenschaften, behält aber die Bedeutung der HTTP-Nachrichten und ihre Anwendungsfunktion. Der Name bezeichnet die Abbildung, nicht die Verschmelzung beider Schichten.

Auch das ALPN-Token h3 ist nicht bloß eine zweite Schreibweise für HTTP/3. Es ist die Kennung, die Endpunkte bei der Aushandlung auf der Leitung verwenden. „HTTP/3“ hilft, Spezifikation und Arbeit einzuordnen; h3 hilft zwei Endpunkten, ein Protokoll auszuwählen. Nottingham schrieb, der Name werde erst mit der Veröffentlichung formalisiert und auf der Leitung verwendet. Bis dahin konnte die Gruppe den Vorschlag noch ändern, bevor die Kennung Kompatibilitätserwartungen prägte.

Die Wartungsübergabe wurde ebenfalls in Governance-Dokumenten verankert. Die HTTPbis-Charter von 2018 sah vor, dass HTTPbis nach der Veröffentlichung durch QUIC HTTP/3 pflegt und bei Bedarf Erweiterungen entwickelt, darunter QPACK. Die aktuelle HTTP-Charter führt HTTP/3 und QPACK als Kernbestandteile von HTTP. Die aktuelle QUIC-Charter hält fest, dass QUIC die Abbildung und QPACK hervorgebracht hat, beide Spezifikationen nun aber in der HTTP-Gruppe gepflegt werden.

Die Grenze ist keine Mauer. Die QUIC-Gruppe führt weiterhin Arbeit an qlog-Ereignissen für HTTP/3. Dort treffen Beobachtbarkeit des Transports und der Anwendung aufeinander. Präziser ist daher die Aufteilung nach Hauptzuständigkeit: HTTP pflegt das HTTP-Mapping und seine Erweiterungen; QUIC bearbeitet weiterhin transportbezogene Mechanismen. Weil beide Schichten in laufenden Systemen zusammentreffen, bleibt Zusammenarbeit notwendig.

Veröffentlichung ersetzt keinen Betrieb

Der Name HTTP/3 bringt einen Client nicht dazu, das Protokoll anzubieten, verpflichtet einen Server nicht zur Annahme und beweist nicht, dass ein Netzwerkpfad es störungsfrei überträgt. RFC und ALPN-Kennung schaffen eine gemeinsame Referenz. Implementierungen müssen weiterhin verhandeln, interoperieren, Rückfälle behandeln und über den Einsatz entscheiden. Der Name verringert Verwechslungen, misst aber weder Verbreitung noch Leistung.

Damit ist auch die Reichweite des Vorschlags klar. Eine gemeinsame Spezifikation kann festlegen, was HTTP-Nachrichten bedeuten und wie sie über QUIC abgebildet werden. Die Transportspezifikation kann Zustellung, Überlaststeuerung und Transportsicherheit definieren. Charters können die fortlaufende Pflege zuordnen. Betreiber und Implementierer entscheiden danach, ob und wie sie diese Spezifikationen nutzen. Jeder Nachweis beantwortet eine andere Frage.

Nottinghams Beitrag bestand nicht darin, HTTP/3 allein zu benennen oder seine Wartung persönlich zu übertragen. Er verknüpfte den öffentlichen Namen mit einer künftigen Zuständigkeit und vertrat, dass die HTTP-Community über den Namen entscheiden sollte. Protokolle und Charters zeigen, wie die Gruppen damit umgingen. Bei einer neuen Spezifikation lohnt sich deshalb die Frage: Können Leser erkennen, was gemeinsam bleibt, was sich ändert, wer jeden Teil pflegt und was Implementierungen noch belegen müssen?

Quellen