Zusammenfassung

  • Die neue Charta der WebTransport Working Group gilt vom 1. September 2026 bis 31. August 2028. In der Historie wird potenzielle neue Arbeit an Peer-to-Peer-Interaktionen genannt.
  • P2P steht im Arbeitsrahmen als Gegenstand einer erwogenen Inkubation. Unter den normativen Liefergegenständen steht nur WebTransport; dessen erste Version bleibt auf Client-Server-Verbindungen begrenzt.
  • Issue 590 bündelt lokale Netze, Server hinter NAT sowie mDNS, ICE, NAT-PMP, UPnP und P2P-QUIC als Fragen oder Möglichkeiten. Eine Auswahl ist nicht dokumentiert.
  • Ein später, ausdrücklich nicht blockierender Sicherheitshinweis verlangte eine frühe Prüfung. Die Antwort sagte frühe Prüfung und einen möglichen TPAC-Breakout zu, entschied aber keine Technik.
  • Der W3C Process trennt Arbeitsrahmen und Liefergegenstände. Welcher Verfahrensweg später gilt, hängt vom konkreten Entwurf und seinem Verhältnis zum bestehenden WebTransport-Liefergegenstand ab.
  • Ein öffentlicher Zustandsbeleg sollte zeigen, ob P2P in die nächste Version eingeht, ein eigener Liefergegenstand wird, anderswo landet, nicht normativ bleibt oder endet.

Arbeitsauftrag und Produktstatus sind zweierlei

Der neue Satz ist sorgfältig abgestuft. Die Working Group „erwägt“, Mechanismen für Peer-to-Peer-Fähigkeiten zu „inkubieren“. Damit darf sie Anwendungsfälle schärfen, Entwürfe vergleichen und Experimente verwerfen. Der Satz verspricht weder eine Browser-zu-Browser-API noch ein Verfahren für NAT-Traversal.

Die normative Tabelle setzt einen zweiten Grenzstein. Sie führt allein WebTransport auf, beschrieben als ECMAScript-APIs für Datenverkehr zwischen Browser und Server. Die erste Version dieses Liefergegenstands ist ausdrücklich auf Client-Server-Verbindungen beschränkt. Auch die Charta-Historie spricht nur von potenzieller neuer P2P-Arbeit.

So entsteht eine klare Folge von Zuständen. Der Rahmen bestimmt, womit sich die Gruppe befassen darf. Ein Liefergegenstand benennt ein institutionell zugeordnetes Standardsprodukt. Working Draft, Candidate Recommendation und Recommendation beschreiben später den Dokumentstatus. Interoperable Implementierungen und Einsatz belegen wieder etwas anderes.

Wer alle Stufen in „W3C hat P2P für WebTransport freigegeben“ zusammenzieht, verleiht einer Untersuchung vorzeitig Autorität. Zugleich nimmt er Experimenten die Möglichkeit, ergebnisoffen zu bleiben.

Unter P2P liegen mehrere Topologien

WebTransport Issue 590 enthält keinen fertigen Vorschlag. Manche Anfragen betreffen einen Client und Server im selben lokalen Netz, wo mDNS zur Entdeckung dienen könnte. Andere betreffen einen Server hinter NAT und nennen ICE, NAT-PMP oder UPnP. Hinzu kommen IETF-Diskussionen über NAT-Traversal und P2P-QUIC ohne ICE.

Diese Fälle unterscheiden sich in ihrer Vertrauens- und Angriffsfläche. Lokale Diensterkennung kann Geräte und Anwesenheitsmuster offenbaren. Eine Öffnung durch einen Heimrouter verändert, wer eine Verbindung anstoßen kann. Direkte Browserkommunikation wirft andere Fragen zu Einwilligung, Identität und Missbrauch auf. Ein Server hinter NAT ist nicht automatisch eine Browser-zu-Browser-API.

Die Issue fragt deshalb nach dem richtigen Ansatz. Sie ist offen und enthält weder Gruppenbeschluss noch ausgewählte Technik oder normativen Text. Eine Liste möglicher Verfahren ist kein Produktplan.

Als Vergleich dient die TAG-Prüfung einer anderen Local Peer-to-Peer API. Dieses Vorhaben wurde im WICG inkubiert; der Standardisierungsort war zunächst unbekannt oder möglicherweise bei der Second Screen Working Group. Ein TAG-Kommentar verlangte ein konkretes Bedrohungsmodell zu Funktionsmissbrauch, Entdeckung, Geräte-Fingerprinting, Nutzerprofilen und UPnP-ähnlichen Risiken.

Der Sicherheitskommentar zur WebTransport-Charta betonte ausdrücklich, dass es nicht derselbe Vorschlag ist. Die Fragen sind übertragbare Warnsignale, die Ergebnisse aber keine erledigte WebTransport-Prüfung.

Eine Prüfungszusage ist noch kein Beschluss

Am 29. Juli, als die Charta bereits in der Advisory-Committee-Prüfung war, erschien ein verspäteter und ausdrücklich nicht blockierender Sicherheitskommentar. Er verband den neuen Rahmen mit Issue 590 und fragte nach mindestens einer Prüfung auf hoher Ebene. Die öffentliche Antwort vom 24. August sagte für jede neue Fähigkeit eine frühe Prüfung zu und stellte einen Breakout bei TPAC in Aussicht.

Frühe Prüfung ist sinnvoll, weil sich ein Entwurf vor Verfestigung günstiger korrigieren lässt. Die geprüften Quellen belegen jedoch weder die Durchführung des Breakouts noch ein akzeptiertes Bedrohungsmodell, technischen Konsens oder die Aufnahme von P2P in eine Spezifikation.

Strategy Issue 537 wurde am 1. September als completed geschlossen. Der Schlusskommentar erklärte die Charta für angekündigt und verwies auf ein nur für Mitglieder zugängliches Archiv. Öffentlich nachprüfbar sind nun die endgültige Charta und die Gruppenseite: Laufzeit vom 1. September 2026 bis zum 31. August 2028.

Aus einer kurzzeitig gesetzten Zähletikette und Sekundenabständen vor der Schließung lassen sich weder Stimmen noch Einwände ableiten. Die belegbare Aussage bleibt eng: Der Untersuchungsraum wurde genehmigt, ein P2P-Entwurf nicht.

Der Februar-Termin hat noch keinen P2P-Inhalt

Für Februar 2027 ist ein First Public Working Draft der nächsten WebTransport-Version vorgesehen. Die Charta weist P2P diesem Dokument nicht zu. Die nächste Version kann andere Neuerungen enthalten. P2P könnte einen eigenen Recommendation-Track-Liefergegenstand erhalten, nur nicht normative Anwendungsfälle liefern, in einer anderen Gruppe weiterlaufen oder eingestellt werden.

Der W3C Process macht diese Einordnung verfahrensrelevant. Eine Charta muss den Arbeitsrahmen und die Art der Liefergegenstände getrennt aufführen. Ein neuer Recommendation-Track-Liefergegenstand außerhalb des Rahmens eines bestehenden Liefergegenstands ist eine major change. Umbenennung oder Neuordnung bereits im Rahmen liegender Liefergegenstände kann minor sein.

Darum lässt sich heute weder eine neue Charta zwingend verlangen noch jeder spätere P2P-Text vorab genehmigen. Maßgeblich wird sein, was konkret vorgeschlagen wird und ob es dem bestehenden WebTransport-Liefergegenstand zugeordnet werden kann.

Den Übergang selbst quittieren

Zur Inkubations-Issue gehört ein kleiner öffentlicher Zustandsbeleg. Er sollte Problem und Arbeitsrepository, den Verantwortlichen für die nächste Einordnung, Sicherheits-, Datenschutz- und Architekturprüfungen, IETF-Abhängigkeiten, den statusändernden Beschluss sowie das übernehmende Dokument oder Gremium nennen.

Damit wären fünf Ausgänge unterscheidbar: Aufnahme in die nächste WebTransport-Version; eigener normativer Liefergegenstand; Übertragung oder Teilung; ausschließlich experimentelles oder erläuterndes Ergebnis; Vertagung oder Schließung.

Heute muss kein Ausgang gewählt werden. Der Beleg soll verhindern, dass später ein Editor-Commit, eine Sitzung oder ein Prototyp unbemerkt zum vermeintlichen Autoritätsakt wird.

Lu Hengs Running-Code Primacy liefert dafür eine begrenzte, hilfreiche Ordnung. Eine Charta erlaubt Arbeit. Laufender Code prüft eine technische Hypothese. Eine öffentliche Spezifikation dokumentiert institutionelle Festlegungen. Interoperabilität und Einsatz zeigen Adoption. Keine Ebene darf für die anderen sprechen.

P2P gehört nun zum legitimen Suchraum der WebTransport Working Group. Es ist noch kein eigener normativer Output. Die nächste Governance-Probe besteht darin, den genauen öffentlichen Akt sichtbar zu machen, der diesen Status eines Tages ändert.

Quellen

  1. W3C — WebTransport Working Group Charter 2026
  2. W3C — WebTransport Working Group
  3. W3C — WebTransport-Charta-Historie
  4. W3C Strategy Issue 537 — WebTransport Group Charter
  5. Verspätete, nicht blockierende Sicherheitsbitte um P2P-Prüfung
  6. Öffentliche Zusage früher Prüfung mit erwartetem TPAC-Breakout
  7. WebTransport Issue 590 — Server hinter NAT oder im lokalen Netz
  8. W3C TAG Design Review 932 — Local Peer-to-Peer API
  9. TAG-Sicherheitskommentar zum getrennten Vorschlag
  10. W3C Process Document, Ausgabe vom 18. August 2025
  11. W3C — öffentliche Mitteilung zur Advisory-Committee-Prüfung
  12. W3C — WebTransport Candidate Recommendation Snapshot
  13. Charta-Commit, der den P2P-Rahmen einführte
  14. Lu Heng — Running-Code Primacy