WebTransport

1. はじめに

このセクションは規範的ではありません。

本仕様は、[WEB-TRANSPORT-HTTP3] および [WEB-TRANSPORT-HTTP2] を用いて、サーバーへのデータ送信およびサーバーからのデータ受信を行います。WebSocketsのように利用できますが、複数ストリーム対応、単方向ストリーム、順不同配信、信頼性のある・ない転送もサポートしています。

注: 本仕様で示されているAPIは、IETF WEBTRANS WGで進行中の作業に基づく暫定案です。[WEB-TRANSPORT-HTTP3] および [WEB-TRANSPORT-HTTP2] の仕様は進行中であるため、今後プロトコルやAPIが大きく変更される可能性があります。

2. 適合性

規範的でないと明記されたセクションだけでなく、著者向けガイドライン、図、例、および本仕様書内の注記も全て非規範的です。それ以外は全て規範的です。

「MUST」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「NOT RECOMMENDED」「MAY」「OPTIONAL」といったキーワードは、[RFC2119] および [RFC8174] の定義に従い、ここで示されるように全て大文字で現れる場合のみ、同様に解釈されます。

本仕様は、ここに含まれるインターフェースを実装するユーザーエージェント製品単体に適用される適合性基準を定義します。

アルゴリズムや具体的な手順として記述された適合要件は、最終結果が同等である限り、どのような方法で実装してもかまいません。（特に、本仕様で定義されているアルゴリズムは理解しやすいように意図されており、性能面を考慮しているものではありません。）

本仕様で定義されるAPIをECMAScriptを用いて実装する場合、Web IDL仕様 [WEBIDL] で定義されるECMAScriptバインディングと用語に従い、一貫した方法で実装しなければなりません。

3. プロトコルの概念

WebTransportの主要なプロトコル概念は「セッション」と「ストリーム」の2つです。各WebTransportセッションは複数のWebTransportストリームを含むことができます。

これらは、アプリケーションレベルのAPI構造であるプロトコル名と混同しないでください。

3.1. WebTransportセッション

WebTransportセッションは、HTTP/3またはHTTP/2の基盤となるコネクション上のWebTransportのセッションです。 プーリングが有効な場合、1つのコネクション上に複数のWebTransportセッションが存在することがあります。

WebTransportセッションには、[WEB-TRANSPORT-OVERVIEW]で定義された以下の機能があります：

確立するには、WebTransportセッションをoriginとprotocols配列とともに、[WEB-TRANSPORT-OVERVIEW] セクション4.1に従い、 originをシリアル化および同型エンコードし、リクエストの`Origin`ヘッダーとして使用します。 同型エンコードしたprotocolsは、クライアントがこのセッションでサーバーに優先して使ってほしいプロトコルのリストとして使用し、[WEB-TRANSPORT-OVERVIEW] セクション3.1に従います。 セッションの確立時に、クライアントは認証情報を一切提供してはなりません。 得られる基盤となるトランスポートストリームはセッションのCONNECTストリームと呼ばれます。

ドレインするには、WebTransportセッション sessionについて、[WEB-TRANSPORT-OVERVIEW] セクション4.1に従います。

WebTransportセッション sessionは、ドレイン中です。これは、CONNECTストリームがサーバーによって正常に閉じられるよう要求された場合であり、[WEB-TRANSPORT-OVERVIEW] セクション4.1に記載されています。

終了するには、オプションの整数codeおよびオプションのバイト列reasonを使い、WebTransportセッション sessionについて、[WEB-TRANSPORT-OVERVIEW] セクション4.1に従ってください。

WebTransportセッション sessionは、終了済みとなります。オプションで整数codeとバイト列reasonを持ち、CONNECTストリームがサーバーによって閉じられた時に発生します。詳細は[WEB-TRANSPORT-OVERVIEW] セクション4.1を参照してください。

3.2. WebTransportストリーム

WebTransportストリームは、WebTransportセッション上の信頼性のある順序どおりのバイトストリームの概念であり、[WEB-TRANSPORT-OVERVIEW] セクション4.3で説明されています。

WebTransportストリームは、受信単方向、 送信単方向または双方向のいずれかです。

WebTransportストリームには以下の機能があります：

WebTransportストリームは、以下のシグナルを持ちます：

4. WebTransportDatagramsWritable インターフェース

WebTransportDatagramsWritableは、WritableStream であり、 データグラムの送信のための送信ストリーミング機能を提供します。

[Exposed=(Window,Worker), SecureContext, Transferable]
interface WebTransportDatagramsWritable : WritableStream {
  attribute WebTransportSendGroup? sendGroup;
  attribute long long sendOrder;
};

4.1. 内部スロット

WebTransportDatagramsWritable オブジェクトは以下の内部スロットを持ちます。

作成するには、 WebTransportDatagramsWritable を、WebTransport transport、sendGroup、sendOrderで次のステップを実行します。

1. streamを新しいWebTransportDatagramsWritable として、以下の内容で作成：

   [[OutgoingDatagramsQueue]]

   空のキュー

   [[Transport]]

   transport

   [[SendGroup]]

   sendGroup

   [[SendOrder]]

   sendOrder

2. writeDatagramsAlgorithmをtransportとstreamでwriteDatagramsを実行するアクションとする。

3. streamをセットアップし、writeAlgorithm をwriteDatagramsAlgorithmに設定する。

4. streamを返す。

4.2. 属性

sendGroup, 型 WebTransportSendGroup, null可能

ゲッター手順：

1. thisの[[SendGroup]] を返す。

セッター手順（valueを与える）：

1. valueがnullでなく、かつ value.[[Transport]] が this.[[Transport]] でない場合、InvalidStateErrorをスローする。

2. this.[[SendGroup]] をvalueに設定する。

sendOrder, 型 long long

ゲッター手順：

1. thisの[[SendOrder]] を返す。

セッター手順（valueを与える）：

1. this.[[SendOrder]] をvalueに設定する。

4.3. 手順

ユーザーエージェントは、WebTransport オブジェクトのうち [[State]] が"connecting"または"connected"のものについて、関連するWebTransportDatagramsWritable オブジェクトの部分集合（送信順ルールにより決定）に対してsendDatagramsを実行しなければならず、アルゴリズムが進捗できる場合は合理的な範囲ですぐに実行するべきです。

送信順ルールは、送信は一般に、このトランスポート上で以前にキューされたストリームやデータグラムの送信、および今後キューされるストリームやデータグラムの送信とインターリーブされてもよいですが、送信は、同じ [[SendGroup]] かつより高い [[SendOrder]] を持つストリームやデータグラム（エラー状態でもフロー制御でブロックされているものでもない）が全て送信されるまで、優先的に待機しなければなりません。

注: トランスポートの[[State]] が"connecting"の間、データグラムの書き込みは許可されます。 データグラムは[[OutgoingDatagramsQueue]] に格納され、"connected"状態の時と同様に破棄される可能性があります。トランスポートの[[State]] が"connected"になると、キューされたデータグラムの送信が開始されます。

5. WebTransportDatagramDuplexStream インターフェース

WebTransportDatagramDuplexStreamは、汎用的なデュプレックスストリームです。

[Exposed=(Window,Worker), SecureContext]
interface WebTransportDatagramDuplexStream {
  WebTransportDatagramsWritable createWritable(
      optional WebTransportSendOptions options = {});
  readonly attribute ReadableStream readable;

  readonly attribute unsigned long maxDatagramSize;
  attribute unrestricted double? incomingMaxAge;
  attribute unrestricted double? outgoingMaxAge;
  attribute unrestricted double incomingHighWaterMark;
  attribute unrestricted double outgoingHighWaterMark;
};

5.1. 内部スロット

WebTransportDatagramDuplexStream オブジェクトは以下の内部スロットを持ちます。

ユーザーエージェントは、[[OutgoingMaxDatagramSize]] を、WebTransport オブジェクトの [[State]] が"connecting"または"connected"の場合に更新してもよいです。

作成するには、 WebTransportDatagramDuplexStream を、readableで、以下の手順を実行します。

1. streamを新しいWebTransportDatagramDuplexStream として、以下の内容で作成：

   [[Readable]]

   readable

   [[Writables]]

   空の順序付き集合。

   [[IncomingDatagramsQueue]]

   空のキュー

   [[IncomingDatagramsPullPromise]]

   null

   [[IncomingDatagramsHighWaterMark]]

   実装定義値

   [[IncomingDatagramsExpirationDuration]]

   null

   [[OutgoingDatagramsHighWaterMark]]

   実装定義値

   この実装定義値は、送信データの適切なスループットを確保しつつ、 送信データの即時性を損なわないように調整されるべきです。

   [[OutgoingDatagramsExpirationDuration]]

   null

   [[OutgoingMaxDatagramSize]]

   実装定義の整数。

2. streamを返す。

5.2. メソッド

createWritable()

WebTransportDatagramsWritableを生成します。

createWritable()メソッドが呼ばれた場合、ユーザーエージェントは以下の手順を実行しなければなりません：

1. transportをthisに関連付けられたWebTransport オブジェクトとする。

2. transport.[[State]] が"closed"または"failed"の場合は、 InvalidStateErrorをスローする。

3. sendGroupをoptionsの sendGroup とする。

4. sendOrderをoptionsの sendOrder とする。

5. WebTransportDatagramsWritable をtransport、sendGroup、sendOrderで作成した結果を返す。

5.3. 属性

readable, 型 ReadableStream、読み取り専用

ゲッター手順：

1. thisの[[Readable]] を返す。

incomingMaxAge, 型 unrestricted double、null可能

ゲッター手順：

1. thisの[[IncomingDatagramsExpirationDuration]] を返す。

セッター手順（valueを与える）：

1. valueが負またはNaNなら、RangeErrorをスローする。

2. valueが0なら、valueをnullに設定する。

3. thisの[[IncomingDatagramsExpirationDuration]] をvalueに設定する。

maxDatagramSize, 型 unsigned long、読み取り専用

WebTransportDatagramsWritableに渡せる最大データサイズ。 ゲッター手順はthisの[[OutgoingMaxDatagramSize]] を返す。

outgoingMaxAge, 型 unrestricted double、null可能

ゲッター手順：

1. thisの[[OutgoingDatagramsExpirationDuration]] を返す。

セッター手順（valueを与える）：

1. valueが負またはNaNなら、RangeErrorをスローする。

2. valueが0なら、valueをnullに設定する。

3. thisの[[OutgoingDatagramsExpirationDuration]] をvalueに設定する。

incomingHighWaterMark, 型 unrestricted double

ゲッター手順：

1. thisの[[IncomingDatagramsHighWaterMark]] を返す。

セッター手順（valueを与える）：

1. valueが負またはNaNなら、RangeErrorをスローする。

2. valueが1未満なら、valueを1に設定する。

3. thisの[[IncomingDatagramsHighWaterMark]] をvalueに設定する。

outgoingHighWaterMark, 型 unrestricted double

ゲッター手順：

1. thisの[[OutgoingDatagramsHighWaterMark]] を返す。

セッター手順（valueを与える）：

1. valueが負またはNaNなら、RangeErrorをスローする。

2. valueが1未満なら、valueを1に設定する。

3. thisの[[OutgoingDatagramsHighWaterMark]] をvalueに設定する。

5.4. 手順

pullDatagramsは、 WebTransport オブジェクトtransportについて以下の手順を実行します：

1. datagramsをtransport.[[Datagrams]] とする。

2. Assert: datagrams.[[IncomingDatagramsPullPromise]] はnullである。

3. queueをdatagrams.[[IncomingDatagramsQueue]] とする。

4. queueが空の場合：

   1. datagrams.[[IncomingDatagramsPullPromise]] に新しいpromiseを設定する。

   2. datagrams.[[IncomingDatagramsPullPromise]] を返す。

5. datagramとtimestampをqueueからデキュー した結果とする。

6. もしdatagrams.[[Readable]]の 現在のBYOBリクエストビューがnullでない場合：

   1. viewをdatagrams.[[Readable]]の 現在のBYOBリクエストビュー とする。

   2. viewのバイト長がdatagramのサイズより小さい場合、 RangeErrorでrejectされたpromiseを返す。

   3. elementSizeを型付き配列コンストラクタ表で view.[[TypedArrayName]]に指定されている要素サイズとする。viewが[[TypedArrayName]]内部スロットを持たない場合（DataViewの場合）は elementSizeを0とする。

   4. elementSizeが1でない場合、TypeErrorでrejectされたpromiseを返す。

7. datagramをバイトからプルし datagrams.[[Readable]] に格納する。

8. undefinedでresolveされたpromiseを返す。

receiveDatagrams は、 WebTransport オブジェクトtransportについて以下の手順を実行します：

1. timestampを現在のタイムスタンプとする。

2. queueをdatagrams.[[IncomingDatagramsQueue]] とする。

3. durationをdatagrams.[[IncomingDatagramsExpirationDuration]] とする。

4. durationがnullなら、durationを実装定義値に設定する。

5. sessionをtransport.[[Session]] とする。

6. sessionで利用可能な着信データグラムがある間：

   1. datagramを着信データグラムを受信の結果とする。

   2. timestampを現在のタイムスタンプとする。

   3. chunkをdatagramとtimestampのペアとする。

   4. chunkをqueueにエンキューする。

7. toBeRemovedをqueueの長さからdatagrams.[[IncomingDatagramsHighWaterMark]] を引いた値とする。

8. toBeRemovedが正ならqueueからデキュー をtoBeRemoved回（切り捨て）繰り返す。

9. queueが空でない間：

   1. bytesとtimestampをqueueの先頭要素から取得する。

   2. timestampからdurationミリ秒以上経過していれば、queueからデキューする。

   3. それ以外の場合、このループをbreakする。

10. queueが空でなく、かつdatagrams.[[IncomingDatagramsPullPromise]] がnullでない場合：

    1. bytesとtimestampをqueueからデキューした結果とする。

    2. promiseをdatagrams.[[IncomingDatagramsPullPromise]] とする。

    3. datagrams.[[IncomingDatagramsPullPromise]] をnullに設定する。

    4. ネットワークタスクをキューし transportで以下の手順を実行：

       1. chunkをUint8Array オブジェクトとしてbytesを表現したものとする。

       2. chunkを datagrams.[[Readable]] にエンキューする。

       3. promiseをundefinedでresolveする。

ユーザーエージェントは、WebTransport オブジェクトの [[State]] が"connected"のとき、アルゴリズムが進行可能な場合は合理的な範囲ですぐにreceiveDatagramsを実行するべきです。

6. WebTransport インターフェース

WebTransportは、[WEB-TRANSPORT-OVERVIEW]で定義された基盤となるトランスポート機能へのAPIを提供します。

[Exposed=(Window,Worker), SecureContext]
interface WebTransport {
  constructor(USVString url, optional WebTransportOptions options = {});

  Promise<WebTransportConnectionStats> getStats();
  [NewObject] Promise<ArrayBuffer> exportKeyingMaterial(BufferSource label, optional BufferSource context);
  readonly attribute Promise<undefined> ready;
  readonly attribute WebTransportReliabilityMode reliability;
  readonly attribute WebTransportCongestionControl congestionControl;
  [EnforceRange] attribute unsigned short? anticipatedConcurrentIncomingUnidirectionalStreams;
  [EnforceRange] attribute unsigned short? anticipatedConcurrentIncomingBidirectionalStreams;
  readonly attribute DOMString protocol;

  readonly attribute Promise<WebTransportCloseInfo> closed;
  readonly attribute Promise<undefined> draining;
  undefined close(optional WebTransportCloseInfo closeInfo = {});

  readonly attribute WebTransportDatagramDuplexStream datagrams;

  Promise<WebTransportBidirectionalStream> createBidirectionalStream(
      optional WebTransportSendStreamOptions options = {});
  /* a ReadableStream of WebTransportBidirectionalStream objects */
  readonly attribute ReadableStream incomingBidirectionalStreams;

  Promise<WebTransportSendStream> createUnidirectionalStream(
      optional WebTransportSendStreamOptions options = {});
  /* a ReadableStream of WebTransportReceiveStream objects */
  readonly attribute ReadableStream incomingUnidirectionalStreams;
  WebTransportSendGroup createSendGroup();

  static readonly attribute boolean supportsReliableOnly;
};

enum WebTransportReliabilityMode {
  "pending",
  "reliable-only",
  "supports-unreliable",
};

6.1. 内部スロット

WebTransport オブジェクトは以下の内部スロットを持ちます。

6.2. コンストラクター

6.3. 属性

ready, 型 Promise<undefined>、読み取り専用

取得時、thisの[[Ready]]を返す。

closed, 型 Promise<WebTransportCloseInfo>、読み取り専用

取得時、thisの[[Closed]]を返す。

draining, 型 Promise<undefined>、読み取り専用

取得時、thisの[[Draining]]を返す。

datagrams, 型 WebTransportDatagramDuplexStream、読み取り専用

このセッション上でデータグラムの送受信を行うための単一のデュプレックスストリーム。 datagrams属性のゲッター手順は以下の通り：

1. thisの[[Datagrams]]を返す。

incomingBidirectionalStreams, 型 ReadableStream、読み取り専用

サーバーから受信したReadableStream のWebTransportBidirectionalStreamを返す。

注: 着信ストリームにすでにデータがあるかどうかはサーバーの挙動による。

incomingBidirectionalStreams属性のゲッター手順：

1. thisの[[IncomingBidirectionalStreams]]を返す。

incomingUnidirectionalStreams, 型 ReadableStream、読み取り専用

サーバーから受信した単方向ストリーム（各WebTransportReceiveStreamで表現）を含むReadableStream。

注: 着信ストリームにすでにデータがあるかどうかはサーバーの挙動による。

incomingUnidirectionalStreamsのゲッター手順：

1. this.[[IncomingUnidirectionalStreams]]を返す。

reliability, 型 WebTransportReliabilityMode、読み取り専用

接続が非信頼性（UDP経由）転送をサポートするか、信頼性（TCPフォールバック）転送のみか。 接続確立までは"pending"を返す。 ゲッター手順はthisの[[Reliability]]を返す。

congestionControl, 型 WebTransportCongestionControl、読み取り専用

アプリケーションがコンストラクタでリクエストし、ユーザーエージェントが満たした場合のスループット最適化・低遅延最適化の輻輳制御アルゴリズムの希望。希望が満たされなかった場合は"default"となる。 ゲッター手順はthisの[[CongestionControl]]を返す。

supportsReliableOnly, 型 boolean、読み取り専用

ユーザーエージェントが排他的に信頼性のあるWebTransportセッションを コネクション上でサポートする場合はtrue、そうでなければfalseを返す。

anticipatedConcurrentIncomingUnidirectionalStreams, 型 unsigned short、null可能

アプリケーションがサーバーによる同時オープンを予想する受信単方向ストリームの数を指定できる。 nullでなければ、ユーザーエージェントは今後のラウンドトリップを減らすため、 [[AnticipatedConcurrentIncomingUnidirectionalStreams]] をサーバーとの交渉で考慮するべきである。

ゲッター手順はthisの[[AnticipatedConcurrentIncomingUnidirectionalStreams]]を返す。

セッター手順（valueを与える）は、thisの [[AnticipatedConcurrentIncomingUnidirectionalStreams]] をvalueに設定する。

anticipatedConcurrentIncomingBidirectionalStreams, 型 unsigned short、null可能

アプリケーションがサーバーによる同時オープンを予想する双方向ストリームの数を指定できる。 nullでなければ、ユーザーエージェントは今後のラウンドトリップを減らすため、 [[AnticipatedConcurrentIncomingBidirectionalStreams]] をサーバーとの交渉で考慮するべきである。

ゲッター手順はthisの[[AnticipatedConcurrentIncomingBidirectionalStreams]]を返す。

セッター手順（valueを与える）は、thisの [[AnticipatedConcurrentIncomingBidirectionalStreams]] をvalueに設定する。

注: anticipatedConcurrentIncomingUnidirectionalStreamsや anticipatedConcurrentIncomingBidirectionalStreams を設定しても、アプリケーションが予想したストリーム数が必ず受信できることは保証されません。

protocol, 型 DOMString、読み取り専用

WebTransportセッションが確立され、 protocols コンストラクタオプションで非空配列が指定された場合、サーバーが選択したアプリケーションレベルのプロトコルがあればそれを返す。なければ空文字列。 ゲッター手順はthisの[[Protocol]]を返す。

6.4. メソッド

getStats()

このWebTransportの 基盤となるコネクション の統計情報を収集し、結果を非同期で返します。

getStatsが呼ばれた場合、ユーザーエージェントは以下の手順を実行しなければなりません：

1. transportをthisとする。

2. pを新しいpromiseとする。

3. transport.[[State]] が"failed"なら、pをInvalidStateErrorでrejectし、これらの手順を中止する。

4. 以下の手順を並行して実行：

   1. transport.[[State]] が"connecting"なら、状態が変わるまで待機する。

   2. transport.[[State]] が"failed"なら、ネットワークタスクをキューし transportでpをInvalidStateErrorでrejectし、これらの手順を中止する。

   3. transport.[[State]] が"closed"なら、ネットワークタスクをキューし transportでpをコネクションの最新の統計情報でresolveし、これらの手順を中止する。 統計情報の取得タイミングは実装定義。

   4. 基盤となるコネクションから統計情報（データグラムも含む）を収集する。

   5. ネットワークタスクをキューし transportで以下の手順を実行：

      1. statsを新しい WebTransportConnectionStats オブジェクトとして収集した統計情報を格納する。

      2. pをstatsでresolveする。

5. pを返す。

exportKeyingMaterial(BufferSource label, optional BufferSource context)

このWebTransportの TLS Keying Material Exporter からTLSセッションに一意に関連付けられた基盤となるコネクションの鍵素材をエクスポートします。

exportKeyingMaterialが呼ばれた場合、ユーザーエージェントは以下の手順を実行しなければなりません：

1. transportをthisとする。

2. labelLengthをlabelのバイト長とする。

3. labelLengthが255を超える場合、RangeErrorでrejectされたpromiseを返す。

4. contextLengthを0とする。

5. contextが与えられた場合、contextLengthをcontextのバイト長とする。

6. contextLengthが255を超える場合、RangeErrorでrejectされたpromiseを返す。

7. pを新しいpromiseとする。

8. 以下の手順を並行して実行（ただしtransportの [[State]] が"closed"または"failed"になった時はネットワークタスクをキューし transportでpをInvalidStateErrorでrejectする）：

   1. keyingMaterialをTLS鍵素材のエクスポート結果とする（ [WEB-TRANSPORT-HTTP3] Section 4.7参照）、 labelLength、label、contextLength、 context（存在する場合）を使用する。

   2. ネットワークタスクをキューし transportでpをkeyingMaterialでresolveする。

9. pを返す。

createBidirectionalStream()

送信用双方向ストリームとしてWebTransportBidirectionalStream オブジェクトを生成します。ただしストリームの作成だけでは、相手側に即座に可視化されるわけではなく、データが送信されて初めて認識されます。

注: サーバーはデータ送信までストリームの存在を認識することは期待されません。

createBidirectionalStreamが呼ばれた場合、ユーザーエージェントは以下の手順を実行しなければなりません：

1. transportをthisとする。

2. transport.[[State]] が"closed"または"failed"なら、 新しいInvalidStateErrorでrejectされたpromiseを返す。

3. sendGroupをoptionsの sendGroupとする。

4. sendOrderをoptionsの sendOrderとする。

5. waitUntilAvailableをoptionsの waitUntilAvailableとする。

6. pを新しいpromiseとする。

7. 以下の手順を並行して実行（ただしtransportの [[State]] が"closed"または"failed"になった時はネットワークタスクをキューし transportでpをInvalidStateErrorでrejectする）：

   1. streamIdを transport.[[Session]] 用に有効かつ一意な新しいストリームIDとする（[QUIC] Section 19.11参照）。IDが即座に利用できない場合、waitUntilAvailableがtrueなら利用可能になるまで待つ。falseなら ネットワークタスクをキューし transportでpをQuotaExceededErrorでrejectし、これらの手順を中止する。

   2. internalStreamを双方向ストリームの作成の結果とし transport.[[Session]] とstreamIdで初期化する。

   3. ネットワークタスクをキューし transportで以下の手順を実行：

      1. transport.[[State]] が"closed"または"failed"なら、 pをInvalidStateErrorでrejectし、これらの手順を中止する。

      2. streamをWebTransportBidirectionalStreamの作成の結果とし internalStream、transport、sendGroup、sendOrderで初期化する。

      3. pをstreamでresolveする。

8. pを返す。

createUnidirectionalStream()

送信用単方向ストリームとしてWebTransportSendStream を生成します。 ただしストリームの作成だけでは、サーバーに即座に可視化されるわけではなく、データが送信されて初めて認識されます。

注: サーバーはデータ送信までストリームの存在を認識することは期待されません。

createUnidirectionalStream()が呼ばれた場合、ユーザーエージェントは以下の手順を実行しなければなりません：

1. transportをthisとする。

2. transport.[[State]] が"closed"または"failed"なら、 新しいInvalidStateErrorでrejectされたpromiseを返す。

3. sendGroupをoptionsの sendGroupとする。

4. sendOrderをoptionsの sendOrderとする。

5. waitUntilAvailableをoptionsの waitUntilAvailableとする。

6. pを新しいpromiseとする。

7. 以下の手順を並行して実行（ただしtransportの [[State]] が"closed"または"failed"になった時はネットワークタスクをキューし transportでpをInvalidStateErrorでrejectする）：

   1. streamIdを transport.[[Session]] 用に有効かつ一意な新しいストリームIDとする（[QUIC] Section 19.11参照）。IDが即座に利用できない場合、waitUntilAvailableがtrueなら利用可能になるまで待つ。falseなら ネットワークタスクをキューし transportでpをQuotaExceededErrorでrejectし、これらの手順を中止する。

   2. internalStreamを送信用単方向ストリームの作成の結果とし transport.[[Session]] とstreamIdで初期化する。

   3. ネットワークタスクをキューし transportで以下の手順を実行：

      1. transport.[[State]] が"closed"または"failed"なら、 pをInvalidStateErrorでrejectし、これらの手順を中止する。

      2. streamをWebTransportSendStreamの作成の結果とし internalStream、transport、sendGroup、sendOrderで初期化する。

      3. pをstreamでresolveする。

8. pを返す。

createSendGroup()

WebTransportSendGroup を生成します。

createSendGroup()が呼ばれた場合、ユーザーエージェントは以下の手順を実行しなければなりません：

1. transportをthisとする。

2. transport.[[State]] が"closed"または"failed"なら、 InvalidStateErrorをスローする。

3. WebTransportSendGroupの作成の結果をtransportで返す。

6.5. 手順

6.6. クライアントによって開始されていないセッション終了

6.7. コンテキストクリーンアップ手順

この仕様はコンテキストクリーンアップ手順を次の手順として定義する。WebTransport transportについて：

1. transport.[[State]] が"connected"なら：

   1. transport.[[State]] を"failed"に設定する。

   2. 並行して、transport.[[Session]]を終了する。

   3. ネットワークタスクをキューし、 transportで以下の手順を実行：

      1. errorを新しく作成したWebTransportErrorとし、 source は"session"とする。

      2. transportのクリーンアップをerrorで実行する。

2. transport.[[State]] が"connecting"なら、transport.[[State]] を "failed"に設定する。

   これはWorkerでも行う必要がある。詳細は #127 および whatwg/html#6731参照。

6.8. ガベージコレクション

WebTransport オブジェクトの[[State]] が"connecting"の場合、 [[IncomingBidirectionalStreams]]、 [[IncomingUnidirectionalStreams]]、 いずれかの WebTransportReceiveStream、 または[[Datagrams]].[[Readable]] がロックされている場合、またはready、 draining、 closed promise が監視されている場合はガベージコレクトされてはならない。

WebTransport オブジェクトの[[State]] が"connected"の場合、 [[IncomingBidirectionalStreams]]、 [[IncomingUnidirectionalStreams]]、 いずれかの WebTransportReceiveStream、 または[[Datagrams]].[[Readable]] がロックされている場合、またはdraining やclosed promiseが監視されている場合はガベージコレクトされてはならない。

WebTransport オブジェクトの[[State]] が"draining"の場合、 [[IncomingBidirectionalStreams]]、 [[IncomingUnidirectionalStreams]]、 いずれかの WebTransportReceiveStream、 または[[Datagrams]].[[Readable]] がロックされている場合、またはclosed promiseが監視されている場合はガベージコレクトされてはならない。

WebTransport オブジェクトで、確立されたWebTransportセッション があり、ネットワークへの送信待ちデータがキューされている場合（[[Datagrams]].[[OutgoingDatagramsQueue]]など）、 ガベージコレクトされてはならない。

WebTransport オブジェクトがガベージコレクトされた時、基盤となるコネクション がまだ開いている場合、ユーザーエージェントは WebTransportセッションの終了 を、Application Error Code 0とApplication Error Message ""で行う必要がある。

6.9. 設定

dictionary WebTransportHash {
  DOMString algorithm;
  BufferSource value;
};

dictionary WebTransportOptions {
  boolean allowPooling = false;
  boolean requireUnreliable = false;
  sequence<WebTransportHash> serverCertificateHashes;
  WebTransportCongestionControl congestionControl = "default";
  [EnforceRange] unsigned short? anticipatedConcurrentIncomingUnidirectionalStreams = null;
  [EnforceRange] unsigned short? anticipatedConcurrentIncomingBidirectionalStreams = null;
  sequence<DOMString> protocols = [];
};

enum WebTransportCongestionControl {
  "default",
  "throughput",
  "low-latency",
};

WebTransportOptionsは、WebTransportセッションの確立および利用方法を決定するパラメータの辞書です。

allowPooling, 型 boolean、デフォルトはfalse

trueの場合、WebTransportセッションはプール可能、すなわち 基盤となるコネクションが他のWebTransportセッションと共有可能です。

requireUnreliable, 型 boolean、デフォルトはfalse

trueの場合、HTTP/3 コネクションが不可能な場合、HTTP/2 コネクションではWebTransportセッションを確立できません。

serverCertificateHashes, 型 sequence<WebTransportHash>

このオプションは専用コネクション利用時のみサポートされます。 この機能をサポートしないトランスポートプロトコルでは、このフィールドが空でない場合、NotSupportedError例外がスローされます。

サポートされていて非空の場合、ユーザーエージェントは、証明書ハッシュ検証がserverCertificateHashes で成功し、カスタム証明書要件を満たす場合のみサーバー証明書を信頼します。未知のalgorithmを使うハッシュは無視します。 空の場合は、通常のfetch操作で使う証明書検証手順を使用します。

これはallowPoolingと併用できません。

congestionControl, 型 WebTransportCongestionControl、デフォルトは"default"

このコネクション上で送信時にスループット優先または低遅延優先の輻輳制御アルゴリズムを利用したいアプリケーションの希望を任意で指定します。これはユーザーエージェントへのヒントです。

この設定項目は、低遅延最適化の輻輳制御アルゴリズムが現時点のブラウザに実装されていないため、リスクのある機能と見なされています。

anticipatedConcurrentIncomingUnidirectionalStreams, 型 unsigned short、null可能、デフォルトはnull

サーバーが同時に作成すると予想される着信単方向ストリーム数をアプリケーションが任意で指定できます。 ユーザーエージェントは初期状態でサーバーから少なくとも100本の着信単方向ストリームを許可する必要があります。 nullでなければ、ユーザーエージェントは今後のラウンドトリップ削減のため、[[AnticipatedConcurrentIncomingUnidirectionalStreams]] をサーバーとの交渉で考慮するべきです。

anticipatedConcurrentIncomingBidirectionalStreams, 型 unsigned short、null可能、デフォルトはnull

サーバーが同時に作成すると予想される双方向ストリーム数をアプリケーションが任意で指定できます。 ユーザーエージェントは初期状態でサーバーが少なくとも100本の双方向ストリームを作成できるようにする必要があります。 nullでなければ、ユーザーエージェントはラウンドトリップ削減のため、[[AnticipatedConcurrentIncomingBidirectionalStreams]] をサーバーとの交渉で考慮するべきです。

protocols, 型 sequence<DOMString>、デフォルトは[]

アプリケーションレベルのプロトコル名の配列を任意で指定できます。サーバーが希望するアプリケーションプロトコルを選択し、クライアントに通知することは任意です。 適切なプロトコルが提供されていない場合、サーバーはリクエストを拒否することがあります。

カスタム証明書要件は以下の通り：証明書は[RFC5280]で定義されるX.509v3証明書でなければならず、Subject Public Keyの鍵は許可された公開鍵アルゴリズムのいずれかでなければならず、現在時刻は[RFC5280]のSection 4.1.2.5で定義される有効期限の範囲内でなければならず、有効期間の合計長は2週間を超えてはならない。ユーザーエージェントは追加の実装定義要件を課すことができます。

許可された公開鍵アルゴリズムのリストは実装定義ですが、相互運用性のためにNIST P-256（secp256r1）を使うECDSA（[RFC3279]、Section 2.3.5； [RFC8422]）は必須です。RSA鍵（[RFC3279]、Section 2.3.1）は含めてはなりません。

6.10. WebTransportCloseInfo辞書

WebTransportCloseInfo辞書は、WebTransport の切断時のエラーコードに関する情報を含みます。 この情報はCONNECTION_CLOSEフレームのエラーコードと理由を設定する際に使われます。

dictionary WebTransportCloseInfo {
  unsigned long closeCode = 0;
  USVString reason = "";
};

この辞書は次の属性を持ちます：

closeCode, 型 unsigned long、デフォルトは0

相手に通知されるエラーコードです。

reason, 型 USVString、デフォルトは""

WebTransport を切断する理由です。

6.11. WebTransportSendOptions辞書

WebTransportSendOptionsは、 createUnidirectionalStream、 createBidirectionalStream、 createWritable の振る舞いに影響を与える基本パラメータの辞書です。

dictionary WebTransportSendOptions {
  WebTransportSendGroup? sendGroup = null;
  long long sendOrder = 0;
};

この辞書は次の属性を持ちます：

sendGroup, 型 WebTransportSendGroup、null可能、デフォルトはnull

作成されたストリームをグループ化するための任意のWebTransportSendGroup、またはnull。

sendOrder, 型 long long、デフォルトは0

送信順序番号。指定すると作成されたストリームは厳密な順序付けに参加します。 現在厳密順序ストリームにキューされたバイトは、より小さい送信順序番号で作成された他の厳密順序ストリームにキューされたバイトよりも先に送信されます。

送信順序番号が指定されていない場合、他のストリームとの相対的な送信順は実装定義です。ただし、ユーザーエージェントは、低い順序番号で飢餓状態になっていない限り、すべてのストリーム間で帯域を公平に分配することが強く推奨されます。

注: これは送信側のデータ優先制御であり、受信順序を保証するものではありません。

6.12. WebTransportSendStreamOptions辞書

WebTransportSendStreamOptionsは、 WebTransportSendStreamの パラメータ辞書であり、 createUnidirectionalStream および createBidirectionalStream で生成されたストリームの振る舞いに影響します。

dictionary WebTransportSendStreamOptions : WebTransportSendOptions {
  boolean waitUntilAvailable = false;
};

この辞書は次の属性を持ちます：

waitUntilAvailable, 型 boolean、デフォルトはfalse

trueの場合、 createUnidirectionalStream や createBidirectionalStream の呼び出しで返されるPromiseは、 settled されるまで、基盤となるコネクションがストリーム生成に十分なフロー制御クレジットを持つか あるいはコネクションが新たな送信ストリームを生成できない状態になるまで待機します。falseの場合、呼び出し時にフロー制御ウィンドウがなければPromiseは rejectedされます。

6.13. WebTransportConnectionStats辞書

WebTransportConnectionStats辞書は、 WebTransportセッションの基盤となるコネクションに関するWebTransport固有の統計情報を含みます。

注: プールが利用される場合、同一WebTransportセッションが同じコネクション上にプールされている場合、すべて同じ情報を受け取ります。つまり、同じネットワークパーティションキーに属するプールされたセッション間で情報が公開されます。

注: 利用不可な統計項目はWebTransportConnectionStats辞書から欠落します。

dictionary WebTransportConnectionStats {
  unsigned long long bytesSent = 0;
  unsigned long long packetsSent = 0;
  unsigned long long bytesLost = 0;
  unsigned long long packetsLost = 0;
  unsigned long long bytesReceived = 0;
  unsigned long long packetsReceived = 0;
  required DOMHighResTimeStamp smoothedRtt;
  required DOMHighResTimeStamp rttVariation;
  required DOMHighResTimeStamp minRtt;
  required WebTransportDatagramStats datagrams;
  unsigned long long? estimatedSendRate = null;
  boolean atSendCapacity = false;
};

この辞書は次の属性を持ちます：

bytesSent, 型 unsigned long long、デフォルトは0

基盤となるコネクション上で送信されたバイト数（再送分も含む）。UDPやその他の外部フレーミングは含みません。

packetsSent, 型 unsigned long long、デフォルトは0

基盤となるコネクション上で送信されたパケット数（ロストと判定されたものも含む）。

bytesLost, 型 unsigned long long、デフォルトは0

基盤となるコネクション上でロストしたバイト数（単調増加ではない。ロストとされたパケットが後で受信されることもある）。UDPや外部フレーミングは含みません。

packetsLost, 型 unsigned long long、デフォルトは 0

基盤となるコネクション上でロストしたパケット数（単調増加ではない。ロストとされたパケットが後で受信されることもある）。

bytesReceived, 型 unsigned long long、デフォルトは 0

基盤となるコネクション上で受信したバイト数（ストリーム重複データも含む）。UDPや外部フレーミングは含みません。

packetsReceived, 型 unsigned long long、デフォルトは 0

基盤となるコネクション上で受信したパケット数（処理不能パケットも含む）。

smoothedRtt, 型 DOMHighResTimeStamp

コネクション上で現在観測されているスムーズなRTT（往復遅延時間）。定義は[RFC9002] Section 5.3参照。

rttVariation, 型 DOMHighResTimeStamp

コネクション上で現在観測されているRTTサンプルの平均変動。定義は[RFC9002] Section 5.3参照。

minRtt, 型 DOMHighResTimeStamp

コネクション全体で観測された最小RTT。

estimatedSendRate, 型 unsigned long long、null可能、デフォルトは null

ユーザーエージェントがキューしたデータを送信する推定速度（bps）。この値は同じWebTransportセッション内の全ストリーム・データグラムに適用され、 （congestionControlで選択された可能性のある）輻輳制御アルゴリズムにより算出されます。フレーミングオーバーヘッドは除外され、アプリケーションペイロード送信速度を示します。現在推定値がなければnullとします。前回はnullでなかった場合でもnullになることがあります。

atSendCapacity, 型 boolean、デフォルトはfalse

falseの場合、estimatedSendRate がアプリケーション制限となり、アプリケーションが輻輳制御で許容されるよりも明らかに少ないデータしか送信していないことを意味します。輻輳制御がアプリケーション制限時は、利用可能なネットワーク容量の推定値が不正確になる可能性があります。

trueの場合、アプリケーションはネットワーク容量一杯で送信しており、estimatedSendRate はアプリケーションの利用可能なネットワーク容量を反映します。

atSendCapacity がtrueの時、estimatedSendRate は上限値となります。 アプリケーション送信速度が維持される限り、estimatedSendRate はネットワーク状況に応じて適応します。ただし、estimatedSendRate はtrueでもnullになり得ます。

6.14. WebTransportDatagramStats辞書

WebTransportDatagramStats辞書は、 基盤となるコネクション上でのデータグラム送受信に関する統計情報を含みます。

dictionary WebTransportDatagramStats {
  unsigned long long droppedIncoming = 0;
  unsigned long long expiredIncoming = 0;
  unsigned long long expiredOutgoing = 0;
  unsigned long long lostOutgoing = 0;
};

この辞書は次の属性を持ちます：

droppedIncoming, 型 unsigned long long、デフォルトは0

アプリケーションがdatagramsの readable から読み取る前に、新しいデータグラムにより受信キューがオーバーフローし、破棄された着信データグラムの数。

expiredIncoming, 型 unsigned long long、デフォルトは0

incomingMaxAge より古くなり、datagramsの readable から読み取られる前に破棄された着信データグラムの数。

expiredOutgoing, 型 unsigned long long、デフォルトは0

送信待ちキューに入っていたデータグラムが、outgoingMaxAge より古くなり、送信される前に破棄された数。

lostOutgoing, 型 unsigned long long、デフォルトは0

送信されたデータグラムで、[RFC9002] Section 6.1で定義される「ロスト」と判定された数。

7. インターフェイス WebTransportSendStream

WebTransportSendStream は、WritableStream であり、送信単方向または双方向 WebTransport ストリーム の送信ストリーミング機能を提供します。

これは、WritableStream のUint8Array であり、サーバーへデータを送信するために書き込むことができます。

[Exposed=(Window,Worker), SecureContext, Transferable]
interface WebTransportSendStream : WritableStream {
  attribute WebTransportSendGroup? sendGroup;
  attribute long long sendOrder;
  Promise<WebTransportSendStreamStats> getStats();
  WebTransportWriter getWriter();
};

WebTransportSendStream は必ずcreate手続きによって作成されます。

WebTransportSendStreamの 転送ステップおよび 転送受信ステップは WritableStreamのものです。

7.1. 属性

sendGroup, 型 WebTransportSendGroup、nullable

getter手順：

1. thisの[[SendGroup]]を返す。

setter手順（valueを与えられたとき）：

1. valueがnullでなく、かつ value.[[Transport]] が this.[[Transport]] でない場合、 InvalidStateError をInvalidStateErrorとしてスローする。

2. this.[[SendGroup]] にvalueを設定する。

sendOrder, 型 long long

getter手順：

1. thisの[[SendOrder]]を返す。

setter手順（valueを与えられたとき）：

1. this.[[SendOrder]] にvalueを設定する。

7.2. メソッド

getStats()

このWebTransportSendStreamの パフォーマンスに関する統計情報を収集し、結果を非同期で報告します。

getStatsが呼び出されたとき、ユーザーエージェントは以下の手順を実行しなければなりません：

1. 新しいpromisepを作成する。

2. 以下の手順を並行して実行する：

   1. このWebTransportSendStreamに 特有の統計情報を収集する。

   2. 統計情報が準備できるまで待機する。

   3. ネットワークタスクをキューに入れる（transport）を実行し、以下の手順を行う：

      1. 収集した統計情報を表すnew WebTransportSendStreamStats オブジェクトとしてstatsを作成する。

      2. Resolve pにstatsで解決する。

3. pを返す。

getWriter()

このメソッドは、getWriter （WritableStream から継承）と同様に実装されなければならないが、 WritableStreamDefaultWriter の代わりに、 WebTransportWriterをWebTransportWriter としてthisに対して生成する必要がある。

7.3. 内部スロット

WebTransportSendStream は以下の内部スロットを持ちます。

7.4. 手続き

7.5. サーバーからのSTOP_SENDINGシグナル

7.6. WebTransportSendStreamStats辞書

WebTransportSendStreamStats辞書には、 1つのWebTransportSendStream に特有の統計情報が含まれます。

dictionary WebTransportSendStreamStats {
  unsigned long long bytesWritten = 0;
  unsigned long long bytesSent = 0;
  unsigned long long bytesAcknowledged = 0;
};

この辞書は以下の属性を持ちます：

bytesWritten, 型 unsigned long long、デフォルト値0

アプリケーションがこのWebTransportSendStream に正常に書き込んだバイト数の合計。この値は増加のみする。

bytesSent, 型 unsigned long long、デフォルト値0

このWebTransportSendStream に書き込まれたアプリケーションバイトのうち、少なくとも一度送信されたバイト数の進捗指標。この値は増加のみし、常にbytesWritten以下。

注: これは単一ストリーム上のアプリデータ送信のみの進捗であり、ネットワークオーバーヘッドは含まない。

bytesAcknowledged, 型 unsigned long long、デフォルト値0

このWebTransportSendStream に書き込まれたアプリケーションバイトのうち、QUICのACKメカニズムでサーバーに受信を認められたバイト数の進捗指標。最初の非ackバイトを除くまでの連続バイトのみカウントされる。この値は増加のみし、常にbytesSent以下。

注: HTTP/2接続時はこの値はbytesSent と一致する。

8. インターフェイス WebTransportSendGroup

WebTransportSendGroup は多数の個別（通常は厳密順序）WebTransportSendStream にまたがるデータ転送を追跡するためのオプションの管理オブジェクトです。

WebTransportSendStream は、生成時またはsendGroup属性の割り当てによって、最大1つのWebTransportSendGroup にグループ化されることができます。デフォルトでは非グループ化です。

ユーザーエージェントは、WebTransportSendGroup 間の帯域分配を平等に扱います。 各WebTransportSendGroup はsendOrder 番号評価の独立した数値空間も確立します。

[Exposed=(Window,Worker), SecureContext]
interface WebTransportSendGroup {
  Promise<WebTransportSendStreamStats> getStats();
};

WebTransportSendGroup は必ずcreate手続きによって作成されます。

8.1. メソッド

getStats()

thisのsendGroupにグループ化された全てのWebTransportSendStream の統計情報を集約し、結果を非同期で報告します。

getStatsが呼ばれたとき、ユーザーエージェントは以下の手順を実行：

1. pを新しいpromiseとする。

2. streamsをWebTransportSendStream のうち[[SendGroup]] がthisであるもの全てとする。

3. 以下の手順を並行して実行：

   1. streams内の全ストリームから統計情報を収集。

   2. ネットワークタスクをキューし、 transportで次の手順を実行：

      1. 収集した統計情報の合計値を表すnew WebTransportSendStreamStats オブジェクトstatsを作成。

      2. pをstatsで解決。

4. pを返す。

8.2. 内部スロット

WebTransportSendGroup は以下の内部スロットを持ちます。

8.3. 手続き

9. インターフェイス WebTransportReceiveStream

WebTransportReceiveStream は、ReadableStream であり、 受信単方向または双方向 WebTransport ストリーム の受信ストリーミング機能を提供します。

これは、ReadableStream のUint8Array であり、サーバーから受信したデータを読み出すことができます。 WebTransportReceiveStream はReadable byte streamであり、 そのため、利用者はBYOBリーダーやデフォルトリーダーを利用できます。

[Exposed=(Window,Worker), SecureContext, Transferable]
interface WebTransportReceiveStream : ReadableStream {
  Promise<WebTransportReceiveStreamStats> getStats();
};

WebTransportReceiveStream は必ずcreate手続きによって作成されます。

WebTransportReceiveStreamの 転送ステップおよび 転送受信ステップは ReadableStreamのものです。

9.1. メソッド

getStats()

このWebTransportReceiveStreamの パフォーマンスに関する統計情報を収集し、結果を非同期で報告します。

getStatsが呼び出されたとき、ユーザーエージェントは以下の手順を実行します：

1. 新しいpromisepを作成する。

2. 以下の手順を並行して実行する：

   1. このWebTransportReceiveStream に特有の統計情報を収集する。

   2. ネットワークタスクをキュー（transport）し、以下の手順を実行：

      1. 収集した統計情報を表すnew WebTransportReceiveStreamStats オブジェクトstatsを作成。

      2. pをstatsで解決。

3. pを返す。

9.2. 内部スロット

WebTransportReceiveStream は以下の内部スロットを持ちます。

9.3. 手続き

9.4. サーバーからのResetシグナル

9.5. WebTransportReceiveStreamStats辞書

WebTransportReceiveStreamStats辞書には、 1つのWebTransportReceiveStream に特有の統計情報が含まれます。

dictionary WebTransportReceiveStreamStats {
  unsigned long long bytesReceived = 0;
  unsigned long long bytesRead = 0;
};

この辞書は以下の属性を持ちます：

bytesReceived, 型 unsigned long long、デフォルト値0

サーバーアプリケーションがこのWebTransportReceiveStream に送信することを意図したバイトのうち、これまで受信した分の進捗指標。最初の欠損バイトを除くまでの連続バイトのみカウントされる。この値は増加のみする。

注: これは単一ストリーム上のアプリデータ受信のみの進捗であり、ネットワークオーバーヘッドは含まない。

bytesRead, 型 unsigned long long、デフォルト値0

アプリケーションがこのWebTransportReceiveStream から正常に読み取ったバイト数の合計。この値は増加のみし、常にbytesReceived以下。

10. インターフェイス WebTransportBidirectionalStream

[Exposed=(Window,Worker), SecureContext]
interface WebTransportBidirectionalStream {
  readonly attribute WebTransportReceiveStream readable;
  readonly attribute WebTransportSendStream writable;
};

10.1. 内部スロット

WebTransportBidirectionalStream は以下の内部スロットを持ちます。

10.2. 属性

readable, 型 WebTransportReceiveStream, 読み取り専用

getter手順は、thisの[[Readable]]を返すこと。

writable, 型 WebTransportSendStream, 読み取り専用

getter手順は、thisの[[Writable]]を返すこと。

10.3. 手続き

11. WebTransportWriter インターフェイス

WebTransportWriter はWritableStreamDefaultWriter のサブクラスであり、 2つのメソッドを追加します。

WebTransportWriter は必ずcreate 手続きによって作成されます。

[Exposed=*, SecureContext]
interface WebTransportWriter : WritableStreamDefaultWriter {
  Promise<undefined> atomicWrite(optional any chunk);
  undefined commit();
};

11.1. メソッド

atomicWrite(chunk)

atomicWrite メソッドは、与えられたchunkが送信時点でのフロー制御 ウィンドウ内で全て送信できない場合はrejectされます。 この動作は、フロー制御デッドロックに敏感な ニッチなトランザクション型アプリケーションに対応するためのものです（[RFC9308] Section 4.4）。

注: atomicWrite は、一部データ送信後にrejectされる場合もあります。 フロー制御に対して原子的ですが、他のエラーが発生することがあります。 atomicWrite はデータをパケット間で分割したり、他のデータとインターリーブされるのを防ぐものではありません。 フロー制御クレジット不足による失敗は送信側のみが把握できます。

注: 原子的書き込みも非原子的書き込みの後ろに並ぶとブロックされる場合があります。 atomicWriteがrejectされた場合、その時点で後ろに並んでいた全てのリクエストもrejectされます。 このときrejectされた非原子的書き込みはストリームをエラー状態にします。 したがって、アプリケーションはatomicWriteのawaitを推奨します。

atomicWrite が呼ばれた際、ユーザーエージェントは以下の手順を実行します：

1. pをwrite(chunk) （WritableStreamDefaultWriter に対してchunkを渡す）で得る。

2. pをstreamの[[AtomicWriteRequests]] に追加。

3. promiseがsettledになった際に反応する以下のステップの結果を返す：

   1. もしstreamの[[AtomicWriteRequests]] にpが含まれていれば、 pを削除する。

   2. もしpが理由rでrejectされた場合、rでrejectされたpromiseを返す。

   3. undefinedを返す。

commit()

commit メソッドは、ストリームの[[CommittedOffset]] を、そのストリームに書き込まれたバイト数（[[BytesWritten]]）に更新します。 これにより、そのバイトは書き込みが中止されてストリームがリセットされても ピアに確実に配送されます。 この仕組みは[RELIABLE-RESET]で説明されています。

注: この操作は接続障害時の配送は保証しません。 ストリームがリセットされた場合のみ配送を保証します。

commit がstreamに対して呼ばれた際、ユーザーエージェントは以下の手順を実行します：

1. transportをstreamの[[Transport]]とする。

2. streamの[[CommittedOffset]] をstreamの[[BytesWritten]] の値に設定する。

11.2. 手続き

12. WebTransportError インターフェイス

WebTransportErrorはDOMException のサブクラスであり、

• サーバーまたはネットワークからのエラー、または

• クライアントが開始した中止操作の理由を表します。

[Exposed=(Window,Worker), Serializable, SecureContext]
interface WebTransportError : DOMException {
  constructor(optional DOMString message = "", optional WebTransportErrorOptions options = {});

  readonly attribute WebTransportErrorSource source;
  readonly attribute unsigned long? streamErrorCode;
};

dictionary WebTransportErrorOptions {
  WebTransportErrorSource source = "stream";
  [Clamp] unsigned long? streamErrorCode = null;
};

enum WebTransportErrorSource {
  "stream",
  "session",
};

12.1. 内部スロット

WebTransportError は以下の内部スロットを持ちます。

12.2. コンストラクタ

12.3. 属性

source, 型 WebTransportErrorSource, 読み取り専用

getter手順は、thisの[[Source]]を返すこと。

streamErrorCode, 型 unsigned long, 読み取り専用, nullable

getter手順は、thisの[[StreamErrorCode]]を返すこと。

12.4. シリアライズ

WebTransportError オブジェクトはシリアライズ可能オブジェクトです。 そのシリアライズ手順（valueとserializedを与えて）：

1. DOMException のシリアライズ手順をvalueとserializedで実行する。

2. serialized.[[Source]]をvalue.[[Source]]に設定。

3. serialized.[[StreamErrorCode]]をvalue.[[StreamErrorCode]]に設定。

そのデシリアライズ手順（serializedとvalueを与えて）：

1. DOMException のデシリアライズ手順をserializedとvalueで実行する。

2. value.[[Source]] をserialized.[[Source]]に設定。

3. value.[[StreamErrorCode]] serialized.[[StreamErrorCode]]に設定。

13. プロトコルマッピング

この節は非規範的です。

この節では、[WEB-TRANSPORT-OVERVIEW] を用いて、本仕様で定義されるメソッドの基盤となるプロトコルの挙動を説明します。バッファリングにより、因果関係は即時でない場合があります。

下層接続がHTTP/3の場合、[WEB-TRANSPORT-HTTP3]から以下のプロトコル挙動が適用されます。

WebTransportError エラーの application streamErrorCode は、httpErrorCode に変換され、またその逆も [WEB-TRANSPORT-HTTP3] Section 4.3 に従って行われます。

注: RFC9000 Section 3.2（[QUIC]）で議論されているように、RESET_STREAM または RESET_STREAM_AT フレーム（[RELIABLE-RESET]）の受信は、必ずしもアプリケーションに通知されるとは限りません。 リセットの受信は即時通知され、ストリームデータの配信を中断し、消費されていないデータは破棄されます。 しかし、即時通知は必須ではありません。 特に、RESET_STREAM_ATフレームのReliable Sizeフィールドで示されたデータの配信を許すため、通知が遅延する可能性があります。 ストリームデータが完全に受信されているが、まだアプリケーションに読み込まれていない場合、通知が抑制されることがあります。 WebTransportは常にRESET_STREAM_ATフレームを使用し、ストリームヘッダーの確実な配送を保証します。 詳細はSection 4.1およびSection 4.2（[WEB-TRANSPORT-HTTP3]）を参照。

下層接続がHTTP/2の場合、[WEB-TRANSPORT-HTTP2]から以下のプロトコル挙動が適用されます。HTTP/3と異なり、ストリームエラーコードとHTTPエラーコードの変換は不要です。

14. プライバシーおよびセキュリティに関する考慮事項

この節は非規範的であり、新しい挙動は規定せず、他の仕様部分に既に存在する情報をまとめたものです。

14.1. 通信の機密性

ネットワークを監視できる攻撃者に対して、通信が行われている事実を隠すことはできないため、これは公開情報として扱う必要があります。

本書で説明する全てのトランスポートプロトコルはTLS [RFC8446] またはそれと同等の意味を持つプロトコルを利用し、TLSの全てのセキュリティ特性（通信の機密性と完全性含む）を提供します。WebTransport over HTTPは、外向きHTTPリクエストと同じ証明書検証メカニズムを使用するため、リモートサーバーの認証に同じ公開鍵基盤に依存します。WebTransportでは、証明書検証エラーは致命的であり、証明書検証を回避するインタースティシャル（警告画面）はありません。

14.2. 状態の永続性

WebTransport自体は新しい一意な識別子や新たな永続的状態保存方法を作成せず、既存の永続的状態をサーバーに自動的に公開することもありません。例えば、[WEB-TRANSPORT-HTTP3] や [WEB-TRANSPORT-HTTP2] では、Cookieの送信やHTTP認証、キャッシュ無効化機構はサポートされません。ただしTLSを利用するため、TLSセッションチケットなどTLSの永続的状態を継承します。これは受動的ネットワーク監視者からは見えませんが、サーバー側が同じクライアントからの複数接続を関連付けるために利用できる場合があります。

14.3. プロトコルセキュリティ

WebTransportは[WEB-TRANSPORT-OVERVIEW]で記述された一連の要件を課します。主なものは以下の通りです：

1. リモートサーバーがWebTransportプロトコルの利用を認識し、WebTransportプロトコルの利用意思があることを確認すること。[WEB-TRANSPORT-HTTP3] ではALPN [RFC7301]、 HTTP/3設定、:protocol擬似ヘッダーの組み合わせでWebTransportプロトコルを特定します。[WEB-TRANSPORT-HTTP2] ではALPN、HTTP/2設定、:protocol擬似ヘッダーの組み合わせでWebTransportプロトコルを特定します。

2. サーバーが、トランスポートセッションを開始したリソースのオリジンに基づいて接続をフィルタリングできること。セッション確立リクエストの Origin ヘッダーがこの情報を伝達します。

プロトコルセキュリティ関連の考慮事項は、Security Considerations節（[WEB-TRANSPORT-HTTP3] および [WEB-TRANSPORT-HTTP2]）で説明されています。

ネットワークAPIはローカルネットワークの利用可能なホストをスキャンする用途にも使われることが多く、フィンガープリントやその他攻撃手法に利用される可能性があります。WebTransportはWebSocketのアプローチに従います：特定の接続エラーは、エンドポイントがWebTransportエンドポイントであることが検証されるまで返されません。つまりWebアプリケーションは、存在しないエンドポイントとWebからの接続受け入れ意思のないエンドポイントとを区別できません。

14.4. 証明書ハッシュによる認証

通常、ユーザーエージェントは、URLのサーバー名に対して提供されたTLSサーバー証明書の有効性を検証することで、TLS接続の認証を行います [RFC9525]。これは、ユーザーエージェントが管理する信頼できるアンカーに証明書チェーンをつなげることで達成されます。信頼アンカーは証明書内のサーバー名認証を担当します。この仕組みをWeb PKIと呼びます。

このAPIは、Webアプリケーションが、サーバー名ではなく特定のサーバー証明書で認証されたリモートネットワークエンドポイントに接続する機能を提供します。この仕組みは、長期証明書の取得が困難なエンドポイント（例：短命な仮想マシンや公開ルート不可なホスト）への接続を可能にします。この仕組みはWeb PKIベース認証の代替となるため、両者のセキュリティ特性を比較する必要があります。

リモートサーバーは、指定された証明書の公開鍵に対応する秘密鍵を保持している場合のみ、TLSハンドシェイクに成功できます。APIは証明書のハッシュで証明書を識別します。これは使用する暗号学的ハッシュ関数がセカンドプリイメージ耐性を持つ場合のみ安全です。本書で定義される唯一の関数はSHA-256であり、APIは複数のアルゴリズム-ハッシュペア指定により新たなハッシュ関数の導入手段を提供します。

Web PKIはサーバー名の信頼チェーン構築以外にも、証明書失効処理など追加のセキュリティ機構を提供します。証明書がエフェメラルな場合はこの機構は不要ですが、その他の場合は証明書ハッシュの導入方法（例：キャッシュされたHTTPリソースの場合、証明書が侵害により交換された際はキャッシュを無効化する必要がある）を検討する必要があります。Web PKIは、既知の弱い鍵を持つ証明書の拒否など、鍵生成に関する問題への対策も提供します。本仕様では特定の指針はありませんが、ブラウザは実装依存でこれらを拒否しても構いません。

Web PKIは証明書の有効期間制限を課します。これは鍵侵害の範囲を限定し、運用者が鍵ローテーションを設計・実行する仕組みとなります。WebTransportも同様の有効期間制限（最大2週間）を課します。2週間という制限は、鍵侵害の影響最小化と、デバイス間の時計ズレやクライアントとサーバー間での証明書同期コスト低減のバランスを考慮したものです。

WebTransport APIは、アプリケーションが複数の証明書ハッシュを同時に指定できるようにし、新しい証明書がロールアウトされる期間中クライアントが複数の証明書を受け入れられるようにします。

WebRTCの類似の仕組みと異なり、WebTransportのサーバー証明書ハッシュAPIはクライアント認証手段を提供しません。クライアントがサーバー証明書や接続方法を知っているだけでは十分ではなく、必要に応じてアプリケーションがバンド内でクライアントのアイデンティティを確立する必要があります。

14.5. フィンガープリントとトラッキング

このAPIはサイトにネットワーク活動を生成し、その効果を詳細に観察する能力を提供します。このように得られた情報は識別可能である可能性があります。

同様のネットワーク機能は他のWebプラットフォームAPI（例：fetchや[webrtc]）でも提供されているため、WebTransport追加によるプライバシーへの悪影響は最小限です。本節の考慮事項は他のネットワーク機能にも等しく適用されます。

ネットワーク特性の計測にはネットワーク利用とその利用効果の計測が必要であり、どちらもこのAPIによって可能となります。WebTransportはサイトに、任意のサーバーへのネットワーク活動生成および効果の観察能力を提供します。ネットワーク経路の安定した特性や動的な利用効果の両方の観察が可能です。

ネットワーク情報は、サーバー自身のネットワークスタック、クライアントによるデータ消費・送信速度、またはAPIが提供する統計情報（§ 6.13 WebTransportConnectionStats Dictionary参照）としてサーバーに直接・間接的に提供されます。そのため、ユーザーエージェントで情報制限するだけではプライバシーリスク管理には不十分な場合があります。

14.5.1. 静的観測

サイトはユーザーエージェントと選択したサーバー間の利用可能なネットワーク容量やRTT（往復遅延時間）を観測できます。これらの情報は他のトラッキング要素と組み合わせると識別性を持つ場合があります。RTTは複数地点から複数回測定することでユーザーエージェントの物理的な位置情報の一部を明らかにできる場合もあります。

ネットワークは共有されているものの、利用は断続的なことが多いため、サイトは競合や負荷の少ない経路の容量やRTTを観測できる場合があります。これらの特性は多くの人にとって安定しており、ネットワークの位置が変わらず、ボトルネック（容量決定要素）がユーザーエージェントに近い場合は特に安定します。

14.5.2. 共有ネットワーク

競合するリンクでは、サイトにクロスサイト認識 の機会が生まれ、これが非公認のトラッキング（[UNSANCTIONED-TRACKING]）に利用される恐れがあります。 ネットワーク容量は有限で共有資源のため、ユーザーエージェントが複数サイトに同時アクセスする場合、各サイトに提示されるアイデンティティの関連付けが明らかになる場合があります。

一つのサイトでネットワーク機能を使うと、他サイトで利用できる容量が減少し、ネットワークAPIを使って観測できます。ネットワーク利用やメトリクスは動的に変化し、変化はリアルタイムで観測可能です。これにより、異なるサイト上の活動が同一ユーザーによるものであるという確信度を高めることができます。

ユーザーエージェントは、アクティブでない・フォーカスされていないサイトに対して、フィードバック機構（統計情報、§ 6.13 WebTransportConnectionStats Dictionary）へのアクセスを制限・劣化させることができます。ただし、これだけではサーバーがネットワークの変化を観測することを防ぎきれません。

14.5.3. セッションのプール

共有ネットワークのシナリオと同様、セッションが単一の接続上でプールされる場合、あるセッションの情報は他のセッションの活動によって影響を受けます。別のセッションがどの程度データを送信しているかなどの情報が推論される可能性があります。

共有接続の利用は、サーバー側がセッションを関連付けることを可能にします。network partition keyを使用すると、プール利用が無効化され、共有セッションが不要なクロスサイト認識を可能にする状況を防ぐことができます。

15. 例

15.1. データグラムバッファの送信

この節は非規範的です。

データグラムのバッファ送信は、datagramsの createWritable メソッドおよびその結果のストリームのwriterを利用して実現できます。下記例では、トランスポートが送信可能な場合のみデータグラムを送信します。

async function sendDatagrams(url, datagrams) {
  const wt = new WebTransport(url);
  const writable = wt.datagrams.createWritable();
  const writer = writable.getWriter();
  for (const bytes of datagrams) {
    await writer.ready;
    writer.write(bytes).catch(() => {});
  }
  await writer.close();
}

15.2. 一定レートでデータグラム送信

この節は非規範的です。

トランスポートが送信可能かどうかに関わらず一定レートでデータグラムを送信したい場合は、datagramsの createWritable メソッドと、その結果のストリームのwriterをready属性を待たずに使えばよいです。

// 100msごとにデータグラム送信
async function sendFixedRate(url, createDatagram, ms = 100) {
  const wt = new WebTransport(url);
  const writable = wt.datagrams.createWritable();
  const writer = writable.getWriter();
  const bytes = createDatagram();
  setInterval(() => writer.write(bytes).catch(() => {}), ms);
}

15.3. データグラム受信

この節は非規範的です。

データグラムはtransport.datagrams.readable 属性から読み出すことで受信できます。null値はパケット処理が遅すぎることを示す場合があります。

async function receiveDatagrams(url) {
  const wt = new WebTransport(url);
  for await (const datagram of wt.datagrams.readable) {
    // datagramを処理
  }
}

15.4. BYOBリーダーによるデータグラム受信

この節は非規範的です。

datagrams はReadable byte streamなので、BYOBリーダーを取得でき、バッファ割り当てをより精密に制御しコピーを避けることができます。この例では64kBメモリバッファにデータグラムを読み取ります。

const wt = new WebTransport(url);

for await (const datagram of wt.datagrams.readable) {
  const reader = datagram.getReader({ mode: "byob" });

  let array_buffer = new ArrayBuffer(65536);
  const buffer = await readInto(array_buffer);
}

async function readInto(buffer) {
  let offset = 0;

  while (offset < buffer.byteLength) {
    const {value: view, done} = await reader.read(
        new Uint8Array(buffer, offset, buffer.byteLength - offset));
    buffer = view.buffer;
    if (done) {
      break;
    }
    offset += view.byteLength;
  }

  return buffer;
}

15.5. ストリーム送信

この節は非規範的です。

一方向ストリームでデータを送信するには、createUnidirectionalStream 関数およびその結果のストリームのwriterを利用します。

書き込みchunkの境界は受信側で保証されません。バイトがワイヤ上で合流する可能性があるため、アプリケーションは独自フレーミングを推奨します。

async function sendData(url, ...data) {
  const wt = new WebTransport(url);
  const writable = await wt.createUnidirectionalStream();
  const writer = writable.getWriter();
  for (const bytes of data) {
    await writer.ready;
    writer.write(bytes).catch(() => {});
  }
  await writer.close();
}

エンコーディングは、ReadableStreamからpipeすることで実現できます。 例えばTextEncoderStream を用います。

async function sendText(url, readableStreamOfTextData) {
  const wt = new WebTransport(url);
  const writable = await wt.createUnidirectionalStream();
  await readableStreamOfTextData
    .pipeThrough(new TextEncoderStream("utf-8"))
    .pipeTo(writable);
}

15.6. 着信ストリームの受信

この節は非規範的です。

着信ストリームの読み出しは、incomingUnidirectionalStreams 属性を反復し、各WebTransportReceiveStream のチャンクを反復処理することで実現できます。

チャンク化はユーザーエージェントによって決定され、送信者ではありません。

async function receiveData(url, processTheData) {
  const wt = new WebTransport(url);
  for await (const readable of wt.incomingUnidirectionalStreams) {
    // 各ストリームを個別に消費し、ストリームごとのエラーを報告
    ((async () => {
      try {
        for await (const bytes of readable) {
          processTheData(bytes);
        }
      } catch (e) {
        console.error(e);
      }
    })());
  }
}

デコードは新しいWritableStreamにpipeすることで実現できます。例えば TextDecoderStream を使います。 この例ではテキスト出力が混在しないよう、1ストリームずつ読み取ります。

async function receiveText(url, createWritableStreamForTextData) {
  const wt = new WebTransport(url);
  for await (const readable of wt.incomingUnidirectionalStreams) {
    // 順次消費して出力を混在させず、ストリームごとのエラーを報告
    try {
      await readable
       .pipeThrough(new TextDecoderStream("utf-8"))
       .pipeTo(createWritableStreamForTextData());
    } catch (e) {
      console.error(e);
    }
  }
}

15.7. BYOBリーダーでストリーム受信

この節は非規範的です。

WebTransportReceiveStream はReadable byte streamなので、BYOBリーダーを取得でき、バッファ割り当てをより精密に制御しコピーを避けることができます。この例ではWebTransportReceiveStreamから最初の1024バイトを単一バッファに読み取ります。

const wt = new WebTransport(url);

const reader = wt.incomingUnidirectionalStreams.getReader();
const { value: recv_stream, done } = await reader.read();
const byob_reader = recv_stream.getReader({ mode: "byob" });

let array_buffer = new ArrayBuffer(1024);
const buffer = await readInto(array_buffer);

async function readInto(buffer) {
  let offset = 0;

  while (offset < buffer.byteLength) {
    const {value: view, done} = await reader.read(
        new Uint8Array(buffer, offset, buffer.byteLength - offset));
    buffer = view.buffer;
    if (done) {
      break;
    }
    offset += view.byteLength;
  }

  return buffer;
}

15.8. ストリームでトランザクションチャンク送信

この節は非規範的です。

一方向ストリームで、フロー制御でブロックせずに全体送信できる場合のみトランザクションデータを送信したい場合は、 getWriter 関数およびそのwriterを利用します。

async function sendTransactionalData(wt, bytes) {
  const writable = await wt.createUnidirectionalStream();
  const writer = writable.getWriter();
  await writer.ready;
  try {
    await writer.atomicWrite(bytes);
  } catch (e) {
    if (e.name != "AbortError") throw e;
    // フロー制御でブロックを避けるためreject
    // 非atomicな書き込みがpendingでなければwritableはエラー化されない
  } finally {
    writer.releaseLock();
  }
}

15.9. サーバー証明書ハッシュ利用

この節は非規範的です。

WebTransportセッションは、クライアント側で行われるデフォルトの信頼評価を、サーバーに提供された証明書のハッシュによるチェックで上書きできます。下記例ではhashValueは下層接続が有効とみなすべきサーバー証明書のSHA-256ハッシュを含むBufferSourceです。

const wt = new WebTransport(url, {
  serverCertificateHashes: [
    {
      algorithm: "sha-256",
      value: hashValue,
    }
  ]
});
await wt.ready;

15.10. 完全な例

この節は非規範的です。

この例はclosed/ready promiseの利用、クライアント・サーバー双方での一方向・双方向ストリームの開始、データグラムの送受信方法を示します。

wt.datagrams.writable ||= wt.datagrams.createWritable();

// ページ上のイベントログにエントリを追加し、指定CSSクラスを適用可能
// CSSクラスを任意指定

let wt, streamNumber, datagramWriter;

connect.onclick = async () => {
  try {
    const url = document.getElementById('url').value;

    wt = new WebTransport(url);
    wt.datagrams.writable ||= wt.datagrams.createWritable();
    addToEventLog('接続を開始しています...');
    await wt.ready;
    addToEventLog(`${(wt.reliability == "reliable-only")? "TCP" : "UDP"} ` +
                  `接続完了.`);
    wt.closed
      .then(() => addToEventLog('接続が正常に閉じられました。'))
      .catch(() => addToEventLog('接続が異常終了しました。', 'error'));

    streamNumber = 1;
    datagramWriter = wt.datagrams.writable.getWriter();

    readDatagrams();
    acceptUnidirectionalStreams();
    document.forms.sending.elements.send.disabled = false;
    document.getElementById('connect').disabled = true;
  } catch (e) {
    addToEventLog(`接続失敗: ${e}`, 'error');
  }
}

sendData.onclick = async () => {
  const form = document.forms.sending.elements;
  const data = sending.data.value;
  const bytes = new TextEncoder('utf-8').encode(data);
  try {
    switch (form.sendtype.value) {
      case 'datagram': {
        await datagramWriter.ready;
        datagramWriter.write(bytes).catch(() => {});
        addToEventLog(`データグラム送信: ${data}`);
        break;
      }
      case 'unidi': {
        const writable = await wt.createUnidirectionalStream();
        const writer = writable.getWriter();
        writer.write(bytes).catch(() => {});
        await writer.close();
        addToEventLog(`一方向ストリームでデータ送信: ${data}`);
        break;
      }
      case 'bidi': {
        const duplexStream = await wt.createBidirectionalStream();
        const n = streamNumber++;
        readFromIncomingStream(duplexStream.readable, n);

        const writer = duplexStream.writable.getWriter();
        writer.write(bytes).catch(() => {});
        await writer.close();
        addToEventLog(`双方向ストリーム #${n} でデータ送信: ${data}`);
        break;
      }
    }
  } catch (e) {
    addToEventLog(`送信中のエラー: ${e}`, 'error');
  }
}

// EOF到達までデータグラムをイベントログに読み出し
async function readDatagrams() {
  try {
    const decoder = new TextDecoderStream('utf-8');

    for await (const data of wt.datagrams.readable.pipeThrough(decoder)) {
      addToEventLog(`データグラム受信: ${data}`);
    }
    addToEventLog('データグラム読み取り終了！');
  } catch (e) {
    addToEventLog(`データグラム読取中のエラー: ${e}`, 'error');
  }
}

async function acceptUnidirectionalStreams() {
  try {
    for await (const readable of wt.incomingUnidirectionalStreams) {
      const number = streamNumber++;
      addToEventLog(`新しい着信一方向ストリーム #${number}`);
      readFromIncomingStream(readable, number);
    }
    addToEventLog('着信一方向ストリーム受付終了！');
  } catch (e) {
    addToEventLog(`ストリーム受付中エラー ${e}`, 'error');
  }
}

async function readFromIncomingStream(readable, number) {
  try {
    const decoder = new TextDecoderStream('utf-8');
    for await (const data of readable.pipeThrough(decoder)) {
      addToEventLog(`ストリーム #${number} でデータ受信: ${data}`);
    }
    addToEventLog(`ストリーム #${number} 閉じました`);
  } catch (e) {
    addToEventLog(`ストリーム #${number} 読取中のエラー: ${e}`, 'error');
    addToEventLog(`    ${e.message}`);
  }
}

function addToEventLog(text, severity = 'info') {
  const log = document.getElementById('event-log');
  const previous = log.lastElementChild;
  const entry = document.createElement('li');
  entry.innerText = text;
  entry.className = `log-${severity}`;
  log.appendChild(entry);

  // ログの直前のエントリが可視なら、新しい要素までスクロール
  if (previous &&
      previous.getBoundingClientRect().top < log.getBoundingClientRect().bottom) {
    entry.scrollIntoView();
  }
}

16. 謝辞

WebTransport インターフェイスは、W3C ORTC CGで最初に記述された QuicTransport インターフェイスに基づいており、本仕様に合わせて適合・拡張されています。