Document WebTransport protocol offer formatting

mondain · mondain · commit 95b912d2b533 · 2026-05-20T07:31:55.000-07:00
diff --git a/docs/publisher-api.es.md b/docs/publisher-api.es.md
@@ -159,7 +159,7 @@ De forma predeterminada, la API aplica el ALPN adecuado para el transporte:
 - Raw QUIC + draft-18: `moqt-18`
 - WebTransport: `h3`
 
-Para WebTransport, la API envía la oferta del protocolo de aplicación MoQ separada del ALPN de QUIC: draft-16 ofrece `moqt-16`, draft-18 ofrece `moqt-18`, y draft-14 mantiene el comportamiento heredado sin subprotocolo.
+Para WebTransport, la API envía la oferta del protocolo de aplicación MoQ separada del ALPN de QUIC mediante `WT-Available-Protocols`: draft-16 ofrece `"moqt-16"`, draft-17 ofrece `"moqt-17"`, draft-18 ofrece `"moqt-18"`, y draft-14 mantiene el comportamiento heredado sin subprotocolo. Las comillas forman parte de la sintaxis HTTP Structured Fields; el ALPN de Raw QUIC conserva el token sin comillas.
 
 Si su aplicación ya configuró el ALPN del endpoint y quiere conservarlo:
 
diff --git a/docs/publisher-api.fr.md b/docs/publisher-api.fr.md
@@ -159,7 +159,7 @@ Par défaut, l'API applique l'ALPN adapté au transport :
 - Raw QUIC + draft-18 : `moqt-18`
 - WebTransport : `h3`
 
-Pour WebTransport, l'API envoie l'offre de protocole applicatif MoQ séparément de l'ALPN QUIC : draft-16 propose `moqt-16`, draft-18 propose `moqt-18`, et draft-14 conserve l'ancien comportement sans sous-protocole.
+Pour WebTransport, l'API envoie l'offre de protocole applicatif MoQ séparément de l'ALPN QUIC via `WT-Available-Protocols` : draft-16 propose `"moqt-16"`, draft-17 propose `"moqt-17"`, draft-18 propose `"moqt-18"`, et draft-14 conserve l'ancien comportement sans sous-protocole. Les guillemets font partie de la syntaxe HTTP Structured Fields ; l'ALPN Raw QUIC reste le jeton sans guillemets.
 
 Si votre application a déjà défini l'ALPN de l'endpoint et veut le conserver :
 
diff --git a/docs/publisher-api.it.md b/docs/publisher-api.it.md
@@ -159,7 +159,7 @@ Per impostazione predefinita, l'API applica l'ALPN appropriato al trasporto:
 - Raw QUIC + draft-18: `moqt-18`
 - WebTransport: `h3`
 
-Per WebTransport, l'API invia l'offerta del protocollo applicativo MoQ separatamente dall'ALPN QUIC: draft-16 offre `moqt-16`, draft-18 offre `moqt-18` e draft-14 mantiene il comportamento legacy senza sottoprotocollo.
+Per WebTransport, l'API invia l'offerta del protocollo applicativo MoQ separatamente dall'ALPN QUIC tramite `WT-Available-Protocols`: draft-16 offre `"moqt-16"`, draft-17 offre `"moqt-17"`, draft-18 offre `"moqt-18"` e draft-14 mantiene il comportamento legacy senza sottoprotocollo. Le virgolette fanno parte della sintassi HTTP Structured Fields; l'ALPN Raw QUIC resta il token senza virgolette.
 
 Se la vostra applicazione ha già impostato l'ALPN dell'endpoint e vuole mantenerlo:
 
diff --git a/docs/publisher-api.ja.md b/docs/publisher-api.ja.md
@@ -159,7 +159,7 @@ if (!status.ok) {
 - Raw QUIC + draft-18: `moqt-18`
 - WebTransport: `h3`
 
-WebTransport では、API は MoQ アプリケーションプロトコルの offer を QUIC ALPN とは別に送信します。draft-16 は `moqt-16`、draft-18 は `moqt-18` を offer し、draft-14 は従来のサブプロトコルなしの動作を維持します。
+WebTransport では、API は `WT-Available-Protocols` を使い、MoQ アプリケーションプロトコルの offer を QUIC ALPN とは別に送信します。draft-16 は `"moqt-16"`、draft-17 は `"moqt-17"`、draft-18 は `"moqt-18"` を offer し、draft-14 は従来のサブプロトコルなしの動作を維持します。引用符は HTTP Structured Fields 構文の一部です。Raw QUIC ALPN は引用符なしの token のままです。
 
 アプリケーションがすでに endpoint の ALPN を設定しており、それを維持したい場合:
 
diff --git a/docs/publisher-api.md b/docs/publisher-api.md
@@ -160,8 +160,10 @@ By default, the API applies transport-appropriate ALPN:
 - WebTransport: `h3`
 
 For WebTransport, the API sends the MoQ application protocol offer separately
-from QUIC ALPN: draft-16 offers `moqt-16`, draft-18 offers `moqt-18`, and
-draft-14 keeps the legacy no-subprotocol behavior.
+from QUIC ALPN through `WT-Available-Protocols`: draft-16 offers `"moqt-16"`,
+draft-17 offers `"moqt-17"`, draft-18 offers `"moqt-18"`, and draft-14 keeps
+the legacy no-subprotocol behavior.  The quotes are part of the HTTP
+Structured Fields syntax; Raw QUIC ALPN remains the unquoted token.
 
 If your application already set endpoint ALPN and wants to keep it:
 
diff --git a/docs/publisher-api.pt.md b/docs/publisher-api.pt.md
@@ -159,7 +159,7 @@ Por padrão, a API aplica o ALPN apropriado ao transporte:
 - Raw QUIC + draft-18: `moqt-18`
 - WebTransport: `h3`
 
-Para WebTransport, a API envia a oferta do protocolo de aplicação MoQ separadamente do ALPN de QUIC: draft-16 oferece `moqt-16`, draft-18 oferece `moqt-18`, e draft-14 mantém o comportamento legado sem subprotocolo.
+Para WebTransport, a API envia a oferta do protocolo de aplicação MoQ separadamente do ALPN de QUIC por `WT-Available-Protocols`: draft-16 oferece `"moqt-16"`, draft-17 oferece `"moqt-17"`, draft-18 oferece `"moqt-18"`, e draft-14 mantém o comportamento legado sem subprotocolo. As aspas fazem parte da sintaxe HTTP Structured Fields; o ALPN de Raw QUIC continua sendo o token sem aspas.
 
 Se sua aplicação já configurou o ALPN do endpoint e deseja mantê-lo:
 
diff --git a/docs/publisher-api.zh.md b/docs/publisher-api.zh.md
@@ -159,7 +159,7 @@ if (!status.ok) {
 - Raw QUIC + draft-18：`moqt-18`
 - WebTransport：`h3`
 
-对于 WebTransport，API 会将 MoQ 应用协议 offer 与 QUIC ALPN 分开发送：draft-16 offer `moqt-16`，draft-18 offer `moqt-18`，draft-14 保留旧的无子协议行为。
+对于 WebTransport，API 会通过 `WT-Available-Protocols` 将 MoQ 应用协议 offer 与 QUIC ALPN 分开发送：draft-16 offer `"moqt-16"`，draft-17 offer `"moqt-17"`，draft-18 offer `"moqt-18"`，draft-14 保留旧的无子协议行为。引号是 HTTP Structured Fields 语法的一部分；Raw QUIC ALPN 仍使用不带引号的 token。
 
 如果应用已经设置了 endpoint ALPN，并且希望保留它：
 
diff --git a/docs/webtransport-compliance.md b/docs/webtransport-compliance.md
@@ -55,15 +55,18 @@ It is carried in:
 - `WT-Protocol`
 
 These are Structured Fields strings on the CONNECT exchange.  The
-WebTransport draft allows a server to omit `WT-Protocol`, but if it sends one
-it must choose a value from the client's offer.  MoQ Transport draft-18 still
-expects clients to include MOQT protocol identifiers in `WT-Available-Protocols`.
+`WT-Available-Protocols` header value is therefore a structured string list:
+send `"moqt-16"`, not bare `moqt-16`.  The WebTransport draft allows a server
+to omit `WT-Protocol`, but if it sends one it must choose a value from the
+client's offer.  MoQ Transport draft-18 still expects clients to include MOQT
+protocol identifiers in `WT-Available-Protocols`.
 
 Current offers in this repo:
 
 - draft 14: offer no WebTransport subprotocol for legacy compatibility
-- draft 16: offer `moqt-16` only
-- draft 18: offer `moqt-18` only
+- draft 16: offer `"moqt-16"` only in `WT-Available-Protocols`
+- draft 17: offer `"moqt-17"` only in `WT-Available-Protocols`
+- draft 18: offer `"moqt-18"` only in `WT-Available-Protocols`
 
 Red5's current picoquic/h3zero server path no longer exposes
 `WT-Available-Protocols` to the application on CONNECT accept.  Red5 therefore
@@ -134,8 +137,9 @@ Areas that should be treated as suspect until proven:
 Before changing wire behavior, verify each of these:
 
 1. CONNECT succeeded and the WebTransport protocol offer matches the intended draft:
-   draft-14 offers no WebTransport subprotocol, draft-16 offers `moqt-16`,
-   and draft-18 offers `moqt-18`.  If the relay omits `WT-Protocol`, verify
+   draft-14 offers no WebTransport subprotocol, draft-16 offers `"moqt-16"`,
+   draft-17 offers `"moqt-17"`, and draft-18 offers `"moqt-18"` as structured
+   `WT-Available-Protocols` strings.  If the relay omits `WT-Protocol`, verify
    the negotiated MoQ setup version before treating the session as draft-specific.
 2. The first client MoQ bytes are sent only on a WT application stream, not the CONNECT stream.
 3. The WT application stream gets exactly one WT preamble.
