HTTP/3 越しの WebTransport

1.1. 各種用語

この文書~内の~keyword "MUST" … 【以下、この段落の内容は`~IETF日本語訳~共通~page＠~IETFcommon#requirements-notation$に移譲。】 ◎ The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

この文書は、 `OVERVIEW$r `規約と定義＠~WT-OVERVIEW#conventions-and-definitions§ にて定義された各種用語に従う。 この文書は、 `~WebTransport~server$と`~HTTP3~server$を判別することに注意。 ~HTTP3~serverが，`~HTTP3接続$を終了する~serverである。 ~WebTransport~serverは、 `~WebTransport~session$を受容する応用であり， ~HTTP3~serverを介して~accessされ得るものである。 ◎ This document follows terminology defined in Section 1.2 of [OVERVIEW]. Note that this document distinguishes between a WebTransport server and an HTTP/3 server. An HTTP/3 server is the server that terminates HTTP/3 connections; a WebTransport server is an application that accepts WebTransport sessions, which can be accessed via an HTTP/3 server.＼

【 単に［ ~server／~client ］と記される箇所も多々あるが、 多くは［ `~WebTransport~server$／`~WebTransport~client$ ］を意味するであろう。 】

`応用~client@ とは、［ 利用者／開発者 ］が供した — 信用-済みでないことが多い — ~codeであって， `応用~server$と通信するために`~WebTransport~client$により提供された~interfaceを用立てるものである。 `応用~server@ とは、 流入`~WebTransport~session$を受容するために`~WebTransport~server$により提供された~interfaceを利用するものである。 ◎ An application client is user or developer-provided code, often untrusted, that utilizes the interface offered by the WebTransport client to communicate with an application server. The application server uses the interface offered by the WebTransport server to accept incoming WebTransport sessions.

【 単に応用と記される箇所も多々あるが、 多くは，これらの総称を意味するであろう。 ［ `~WebTransport~client$／`~WebTransport~server$ ］も “応用である” ものと定義されるので、 これらは， “応用の応用” を意味することになる。 】

2.1. ~QUIC, ~WebTransport, ~HTTP3

~QUIC ~version 1 `RFC9000$r は、［ ~flow制御, 輻輳~制御 ］を伴う~secureな~transport~protocolである。 ~QUICは、 ~stream — 多重化し得る，依拠-可能かつ有順序な~byte~streamたち — を介した応用~dataの交換を~supportする。 ~streamの独立性により、 渋滞（ `head-of-line blocking^en ）は軽減され得る。 ~QUICは，~transport~serviceとして~streamを供するが、 その用法については，何かを意見するものではない。 ~streamの適用能は、 `RFC9308$r `~streamの利用＠~RFCx/rfc9308#section-4§にて述べられる。 ◎ QUIC version 1 [RFC9000] is a secure transport protocol with flow control and congestion control. QUIC supports application data exchange via streams; reliable and ordered byte streams that can be multiplexed. Stream independence can mitigate head-of-line blocking. While QUIC provides streams as a transport service, it is unopinionated about their usage. The applicability of streams is described by section 4 of [RFC9308].

`~WebTransport~session$の確立は、 ~HTTP層において，ある資源とヤリトリすることを孕む。 ~Web~UAその他の`~WebTransport~client$用には、 このヤリトリは，~securityの理由から重要になる — とりわけ、［ 当の資源が~WebTransportを利用する用意がある ］ことを確保するために。 ◎ WebTransport session establishment involves interacting at the HTTP layer with a resource. For Web user agents and other WebTransport clients, this interaction is important for security reasons, especially to ensure that the resource is willing to use WebTransport.

~WebTransportは，その~handshake用に~HTTPを要求するが、 ~HTTP3が利用-中にあるときは，［ 確立された~sessionに関係する他のもの ］用には~HTTPは利用されない。 代わりに，［ 確立された~sessionへ それらを~linkする ］ための［ ~header連列を成す~byte列 ］を伴う~QUIC~streamで始まる。 ~streamを成す残りは、 本体であり， ~WebTransportを利用している応用により給された~payloadを運ぶ。 この処理nは、 ~HTTP11越しの~WebSockets `RFC6455$r【！ORIGIN】 に類似する — そこでは、 下層の~byte~streamへの~accessは， どちら側も初期~handshakeを完了した後に可能化される。 ◎ Although WebTransport requires HTTP for its handshake, when HTTP/3 is in use, HTTP is not used for anything else related to an established session. Instead, QUIC streams begin with a header sequence of bytes that links them to the established session. The remainder of the stream is the body, which carries the payload supplied by the application using WebTransport. This process is similar to WebSockets over HTTP/1.1 [ORIGIN], where access to the underlying byte stream is enabled after both sides have completed an initial handshake.

［ ~QUIC, ~HTTP3, ~WebTransport ］は、 `図 1＠#fig-webtransport-layers$ にて示されるように層を成す。 `~WebTransport~session$が確立されたなら、 応用は，~QUICへのおよそ直な~accessを有するようになる。 ◎ The layering of QUIC, HTTP/3, and WebTransport is shown in Figure 1. Once a WebTransport session is established, applications have nearly direct access to QUIC.

2.2. ~protocolの概観

`~WebTransport~server$は、 一般に［ `authority$p 値, `path$p 値 ］（ `RFC3986$r ）が成す~pairにより識別される。 ◎ WebTransport servers in general are identified by a pair of authority value and path value (defined in [RFC3986] Sections 3.2 and 3.3 respectively).

`~HTTP3接続$が確立されるときには、 ~serverは， `SETTINGS_WT_ENABLED$sp `設定$を送信して~HTTP3越しの~WebTransport用の~supportを指示する。 この処理nは、［ どちらの端点も`~WebTransport~stream$を~openすること ］を可能化するために［ 追加的な~HTTP3拡張の利用 ］も折衝する。 ◎ When an HTTP/3 connection is established, the server sends a SETTINGS_WT_ENABLED setting to indicate support for WebTransport over HTTP/3. This process also negotiates the use of additional HTTP/3 extensions to enable both endpoints to open WebTransport streams.

`~WebTransport~session$は、 所与の`~HTTP3接続$の内側で［ 拡張d `CONNECT$m 要請 `RFC9220$r を送信する~client ］により起動される。 ~serverが当の要請を受容する場合，`~WebTransport~session$が確立される。 結果の~streamは， `~CONNECT~stream@ と称され、 その`~stream~ID$は `~session~ID@ と称される。 `~session~ID$は、［ 当の接続の中で所与の`~WebTransport~session$を一意に識別する ］ために【他の~streamにより】利用される。 ◎ WebTransport sessions are initiated inside a given HTTP/3 connection by the client, who sends an extended CONNECT request [RFC9220]. If the server accepts the request, a WebTransport session is established. The resulting stream will be further referred to as a CONNECT stream, and its stream ID is used to uniquely identify a given WebTransport session within the connection. The ID of the CONNECT stream that established a given WebTransport session will be further referred to as a Session ID.

~sessionが確立されたなら、 双方の端点は，次に挙げる仕組みを利用して~dataを交換できるようになる： ◎ After the session is established, the endpoints can exchange data using the following mechanisms:

• ~clientは、 `双方向~stream$を作成でき， その所有者であることを［ 最初の~byte列~内に特別な通達を供する ］ことにより~WebTransportへ転送する。 ◎ A client can create a bidirectional stream and transfer its ownership to WebTransport by providing a special signal in the first bytes.
• ~serverは、 `双方向~stream$を作成でき， その所有者であることを［ 最初の~byte列~内に特別な通達を供する ］ことにより~WebTransportへ転送する。 ◎ A server can create a bidirectional stream and transfer its ownership to WebTransport by providing a special signal in the first bytes.
• ［ ~client, ~server ］どちらも、 ある特別な~stream種別を利用して，`一方向~stream$を作成できる。 ◎ Both client and server can create a unidirectional stream using a special stream type.
• ［ ~client, ~server ］どちらも、 `~HTTP~datagram$ `HTTP-DATAGRAM$r を利用して~datagramを送信できる。 ◎ Both client and server can send datagrams using HTTP Datagrams [HTTP-DATAGRAM].

`~WebTransport~session$が終了されるのは、 それを作成した`~CONNECT~stream$が~closeされたときである。 ◎ A WebTransport session is terminated when the CONNECT stream that created it is closed.

3.1. ~WebTransport能力がある~HTTP3接続の確立-法

~WebTransport能力がある`~HTTP3接続$は、 ~serverに対し，［ ある設定を利用して，~WebTransport用の~supportを~HTTP3越しに通達する ］ことを要求する。 ~clientも、 ~sessionを確立するとき［ 拡張d `CONNECT$m 要請~内に `webtransport-h3$c ~Upgrade~tokenを利用する ］ことにより，~supportを通達する。 ◎ A WebTransport-Capable HTTP/3 connection requires the server to signal support for WebTransport over HTTP/3 using a setting. Clients also signal support by using the "webtransport-h3" upgrade token in extended CONNECT requests when establishing sessions (see Section 9.1).

この文書は、 `SETTINGS_WT_ENABLED$sp 設定を定義する — ~WebTransport~serverは、 それを利用して，自身による~WebTransport用の~supportを指示する。 `SETTINGS_WT_ENABLED^sp 設定~用の既定の値は 0 とする — それは、 当の~serverが~WebTransportを~supportしないことを意味する。 ~clientは、 ~serverから~WebTransportの~supportを指示している設定を受信するまでは， `~WebTransport~session$を確立するよう試みては`ナラナイ^2119。 ◎ This document defines a SETTINGS_WT_ENABLED setting that WebTransport servers use to indicate their support for WebTransport. The default value for the SETTINGS_WT_ENABLED setting is "0", meaning that the server does not support WebTransport. Clients MUST NOT attempt to establish WebTransport sessions until they have received the setting indicating WebTransport support from the server.

~HTTP3越しの~WebTransportは： ◎ ↓

• `RFC9220$r にて述べられるとおり， ~HTTP3における拡張d `CONNECT$m を利用する ⇒ それは、 `SETTINGS_ENABLE_CONNECT_PROTOCOL$sp 設定を定義する。 ◎ WebTransport over HTTP/3 uses extended CONNECT in HTTP/3 as described in [RFC9220], which defines the SETTINGS_ENABLE_CONNECT_PROTOCOL setting.
• `~HTTP3~datagram$と`~capsule~protocol$ `HTTP-DATAGRAM$r 用の~supportを要求する ⇒ ［ ~client, ~server ］どちらも，各自の `SETTINGS$ft ~frame内に［ 値 1 に設定された `SETTINGS_H3_DATAGRAM$sp 設定 `HTTP-DATAGRAM$r ］を送信することにより、 ~HTTP3~datagram用の~supportを指示する。 ◎ WebTransport over HTTP/3 requires support for HTTP/3 datagrams and the Capsule Protocol, and both the client and the server indicate support for HTTP/3 datagrams by sending a SETTINGS_H3_DATAGRAM setting value set to 1 in their SETTINGS frame (see Section 2.1.1 of [HTTP-DATAGRAM]).
• ~QUIC~datagram用の~supportも要求する ⇒ ~supportを指示するためには、［ ~client, ~server ］どちらも，［ 1 以上の値を伴う `max_datagram_frame_size$c ~transport~parameter `QUIC-DATAGRAM$r ］を送信する。 ◎ WebTransport over HTTP/3 also requires support for QUIC datagrams. To indicate support, both the client and the server send a max_datagram_frame_size transport parameter with a value greater than 0 (see Section 3 of [QUIC-DATAGRAM]).
• `RESET-STREAM-AT$r にて定義される `RESET_STREAM_AT$ft ~frameに依拠する ⇒ ~supportを指示するためには、［ ~client, ~server ］どちらも，［ `RESET-STREAM-AT$r `拡張~利用の折衝-法＠~RELIABLERESET#section-3§ にて述べられるとおり， 空な `reset_stream_at^c ~transport~parameterを送信する ］ことにより，この拡張を可能化する。 ◎ WebTransport over HTTP/3 relies on the RESET_STREAM_AT frame defined in [RESET-STREAM-AT]. To indicate support, both the client and the server enable the extension by sending an empty reset_stream_at transport parameter as described in Section 3 of [RESET-STREAM-AT].

要約すると，~HTTP3越しの~WebTransportを： ◎ In summary,＼

• ~supportしている~serverは、 次を送信する ⇒＃ 1 以上の値を伴う `SETTINGS_WT_ENABLED$sp 設定, 値 1 を伴う `SETTINGS_ENABLE_CONNECT_PROTOCOL$sp 設定, 値 1 を伴う `SETTINGS_H3_DATAGRAM$sp 設定, 1 以上の値を伴う `max_datagram_frame_size$c ~transport~parameter, 空な `reset_stream_at^c ~transport~parameter ◎ servers supporting WebTransport over HTTP/3 send: • A SETTINGS_WT_ENABLED setting with a value greater than "0" • A SETTINGS_ENABLE_CONNECT_PROTOCOL setting with a value of "1" • A SETTINGS_H3_DATAGRAM setting with a value of 1 • A max_datagram_frame_size transport parameter with a value greater than 0 • An empty reset_stream_at transport parameter
• ~supportしている~clientは、 次を送信する ⇒＃ 値 1 を伴う `SETTINGS_H3_DATAGRAM$sp 設定, 1 以上の値を伴う `max_datagram_frame_size$c ~transport~parameter, 空な `reset_stream_at^c ~transport~parameter ◎ Clients supporting WebTransport over HTTP/3 send: • A SETTINGS_H3_DATAGRAM setting with a value of 1 • A max_datagram_frame_size transport parameter with a value greater than 0 • An empty reset_stream_at transport parameter

注記： 次の段落は、 ~RFCとして公表する前に除去されることになる。 ◎ [[RFC editor: please remove the following paragraph before publication.]]

~WebTransportの草案~version用に限り ⇒ ~clientは、［ 自身が~supportする~versionを識別する ］ことを~serverに許容するよう， 当の草案に特有な符号点を伴う `SETTINGS_WT_ENABLED$sp も送信しなければ`ナラナイ^2119 — `草案~versionの折衝-法＠#negotiating-draft-version§を見よ。 ◎ For draft versions of WebTransport only, clients MUST also send SETTINGS_WT_ENABLED with the draft-specific codepoint to allow the server to identify the client's supported version; see Section 7.1.

~serverは、 新たな`~WebTransport~session$を確立するための `CONNECT$m 要請が — 他の~messageに加えて — ~clientから `SETTINGS$ft ~frame を受信する前に到着し得ることに注意するべきである （`流入~stream／~datagramの~buffer法＠#buffering-incoming§を見よ）。 ~serverは、 要求される各種［ `設定$, ~transport~parameter ］のうち いずれかに不正な値を伴う `SETTINGS$ft ~frameを受信した場合には， すべての［ 確立-済みな／新たな ］流入`~WebTransport~session$を — `HTTP3$r `不正形な~message＠~HTTPv3#malformed§ にて述べられるとおり — 不正形として扱わなければ`ナラナイ^2119。 ◎ Servers should note that CONNECT requests to establish new WebTransport sessions, in addition to other messages, can arrive before the client's SETTINGS are received (see Section 4.6). If the server receives SETTINGS that do not have correct values for every required setting, or transport parameters that do not have correct values for every required transport parameter, the server MUST treat all established and newly incoming WebTransport sessions as malformed, as described in Section 4.1.2 of [HTTP3].

~clientは、 ~serverの `SETTINGS$ft ~frameが要求される各種［ `設定$, ~transport~parameter ］のうち いずれかに不正な値を伴う場合には， `~WebTransport~session$を確立しては`ナラナイ^2119。 ~clientは、 ~WebTransport用の要件が満たされないとき， ~WebTransport以外の目的に接続を利用するよう望まないならば、 ~debug用に援助するためとして， 当の`~HTTP3接続$を~error~code `WT_REQUIREMENTS_NOT_MET$er で~closeしても`ヨイ^2119。 ◎ A client MUST NOT establish WebTransport sessions if the server's SETTINGS do not have correct values for every required setting or if the server's transport parameters do not have correct values for every required transport parameter. If a client does not wish to use the connection for purposes other than WebTransport when the requirements for WebTransport are not met, the client MAY close the HTTP/3 connection with a WT_REQUIREMENTS_NOT_MET error code to aid in debugging.

注記： 次の段落は、 ~RFCとして公表する前に除去されることになる。 ◎ [[RFC editor: please remove the following paragraph before publication.]]

~WebTransportの草案~version用に限り ⇒ ~serverは、 ~clientから `SETTINGS$ft ~frameを受信するまでは， どの流入~WebTransport要請も処理しては`ナラナイ^2119。 `草案~versionの折衝-法＠#negotiating-draft-version§を見よ。 ◎ For draft versions of WebTransport only, the server MUST NOT process any incoming WebTransport requests until the client's SETTINGS have been received; see Section 7.1.

3.2. 新たな~sessionの作成-法

`~WebTransport~session$は，~HTTP3越しに確立されるので、 `https$c ~URI~scheme `HTTP$r を利用して識別される。 ◎ As WebTransport sessions are established over HTTP/3, they are identified using the https URI scheme (Section 4.2.2 of [HTTP]).

`~WebTransport~client$は、 新たな`~WebTransport~session$を作成するために， ~HTTP拡張d `CONNECT$m 要請を送信する — この要請は： ◎ In order to create a new WebTransport session, a WebTransport client sends an HTTP extended CONNECT request. In this request:

• `protocol^ph 疑似-~header `RFC8441$r を伴い， その値は `webtransport-h3$c をとる。 ◎ The :protocol pseudo-header field ([RFC8441]) MUST be set to webtransport-h3.
• `scheme$ph 疑似-~headerを伴い， その値は `https$c をとる。 ◎ The :scheme field MUST be https.
• ［ `authority$ph, `path$ph ］両~疑似-~headerを伴う — これらは、 欲される`~WebTransport~server$【として動作する】資源を指示する。 ◎ Both the :authority and the :path value MUST be set; these fields identify the desired WebTransport server resource.
• ~clientは~browser~clientである場合、 `Origin$h ~header `RFC6454$r を伴わなければ`ナラナイ^2119 — 他の場合、 この~headerは`任意選択^2119である。 ◎ If the WebTransport session is coming from a browser client, an Origin header [RFC6454] MUST be provided within the request. Otherwise, the header is OPTIONAL.

`~HTTP3~server$は、 受信した拡張d `CONNECT$m 要請が［ `webtransport-h3$c に設定された `protocol^ph ~field ］を伴うならば， 当の要請にて指定された ( `authority$ph 値, `path$ph 値 ) に結付けられた`~WebTransport~server$を有するか否か検査できる。 有さない場合、 状態s~code `404$st `HTTP$r で返信する`ベキ^2119である。 `~WebTransport~server$は： ◎ Upon receiving an extended CONNECT request with a :protocol field set to webtransport-h3, the HTTP/3 server can check if it has a WebTransport server associated with the specified :authority and :path values. If it does not, it SHOULD reply with status code 404 (Section 15.5.5 of [HTTP]).＼

• 当の要請が `Origin$h ~headerを包含するときは、 この~headerを検証yして，［ この~headerに指定された生成元が当の~serverへ~accessすることは許容される ］ことを確保しなければ`ナラナイ^2119 — 検証yに失敗した場合、 状態s~code `403$st `HTTP$r で返信する`ベキ^2119である。 ◎ When the request contains the Origin header, the WebTransport server MUST verify the Origin header to ensure that the specified origin is allowed to access the server in question.＼ If the verification fails, the WebTransport server SHOULD reply with status code 403 (Section 15.5.4 of [HTTP]).＼
• すべての検査に合格したなら、 状態s~code `2xx$st `HTTP$r を返信することにより， `~WebTransport~session$を受容しても`ヨイ^2119。 ◎ If all checks pass, the WebTransport server MAY accept the session by replying with a 2xx series status code, as defined in Section 15.3 of [HTTP].

［ ~client／~server ］の視点からは、 `~WebTransport~session$が確立された時点は， 自身が `2xx$st 応答を［ 受信したとき／送信したとき ］である。 ◎ From the client's perspective, a WebTransport session is established when the client receives a 2xx response. From the server's perspective, a session is established once it sends a 2xx response.

~serverは、 `3xx$st 応答 `HTTP$r を返信して，~redirectionを指示してもよい。 `~WebTransport~client$は、 そのような~redirectに対し，自動的に追従しては`ナラナイ^2119 — 当の~client【！it】は、 当の`~WebTransport~session$用の~dataをすでに送信した場合もあるので。 当の~client【！it】は、 ~redirectについて当の`応用~client$へ通知しても`ヨイ^2119。 ◎ The server may reply with a 3xx response, indicating a redirection (Section 15.4 of [HTTP]). The WebTransport client MUST NOT automatically follow such redirects, as it potentially could have already sent data for the WebTransport session in question; it MAY notify the application client about the redirect.

`CONNECT$m ~methodは`安全$とは見なされないので、 ~clientは，~WebTransportを~0-RTT~packet内では起動し得ない （ `HTTP3$r `早期~data＠~HTTPv3#early-data§を見よ）。 しかしながら， ~WebTransportに関係する`設定$【！ `SETTINGS$ft ~parameter】は、 `HTTP3$r `初期化＠~HTTPv3#settings-initialization§にて述べられるとおり， 前回の~sessionから維持してもよい。 ~serverは、 ~0-RTTを受容する場合には，［ ~openな`~WebTransport~session$の最大な個数／ その他の初期~flow制御~値 ］に対する上限を［ 前回の~sessionの間に折衝した値 ］から抑制しては`ナラナイ^2119 — そのような変更は、 互換でないものと判断され，その結果は `接続~error$( `H3_SETTINGS_ERROR$er ) にならなければ`ナラナイ^2119。 ◎ Clients cannot initiate WebTransport in 0-RTT packets, as the CONNECT method is not considered safe (see Section 10.9 of [HTTP3]). However, WebTransport-related SETTINGS parameters may be retained from the previous session as described in Section 7.2.4.2 of [HTTP3]. If the server accepts 0-RTT, the server MUST NOT reduce the limit of maximum open WebTransport sessions, or other initial flow control values, from the values negotiated during the previous session; such change would be deemed incompatible, and MUST result in a H3_SETTINGS_ERROR connection error.

~HTTP~Upgrade~token `webtransport-h3$c は、 `~capsule~protocol$を `HTTP-DATAGRAM$r にて定義されるとおりに利用する。 `~capsule~protocol$は、 ~serverが `2xx$st 応答を送信するときに折衝される。 `Capsule-Protocol$h ~header `HTTP-DATAGRAM$r は， ~WebTransportには要求されないので、 `~WebTransport端点$は，それを安全に無視できる。 ◎ The "webtransport-h3" HTTP Upgrade Token uses the Capsule Protocol as defined in [HTTP-DATAGRAM]. The Capsule Protocol is negotiated when the server sends a 2xx response. The capsule-protocol header field Section 3.4 of [HTTP-DATAGRAM] is not required by WebTransport and can safely be ignored by WebTransport endpoints.

3.3. 応用~protocolの折衝

~HTTP3越しの~WebTransportは、 ~ALPN拡張 `RFC7301$r に類似な~protocol折衝の仕組みを提供する — その意図は、 既存の~protocolのうち［ ~QUICを利用していて，この機能性に依拠するもの ］の~port法を単純~化することにある。 ◎ WebTransport over HTTP/3 offers a protocol negotiation mechanism, similar to the TLS Application-Layer Protocol Negotiation (ALPN) extension [RFC7301]; the intent is to simplify porting existing protocols that use QUIC and rely on this functionality.

~clientは、 `CONNECT$m 要請~内に `WT-Available-Protocols$h ~headerを内包しても`ヨイ^2119。 この~fieldは、 アリな~protocolたちを選好~順序で列挙する — 最も選好されるものが最初に挙げられるよう。 この~headerを受信した~serverは、 対する成功裡な応答（ `2xx$st ）内に `WT-Protocol$h ~fieldを内包しても`ヨイ^2119。 そうする場合、 ~serverは，この~fieldに［ ~clientからの~listから選んだ いずれか 1 つ ］を内包しなければ`ナラナイ^2119。 ~serverは、 ~clientが相応しい~protocolを内包しなかった場合には， 当の要請を却下しても`ヨイ^2119。 ◎ The client MAY include a WT-Available-Protocols header field in the CONNECT request. The WT-Available-Protocols field enumerates the possible protocols in preference order, with the most preferred protocol listed first. If the server receives such a header, it MAY include a WT-Protocol field in a successful (2xx) response. If it does, the server MUST include a single choice from the client's list in that field. Servers MAY reject the request if the client did not include a suitable protocol.

［ `WT-Available-Protocols@h , `WT-Protocol@h ］は、 どちらも`有構造~field$ `FIELDS$r である。 `WT-Available-Protocols$h は、 `~sf~list$をとるものと定義され， それを成す各~itemの値は`~sf文字列$に限り妥当になる。 `WT-Protocol$h は、 `~sf~item$をとるものと定義され， その値は`~sf文字列$に限り妥当になる。 `~sf文字列$以外の型を成す値は、 `FIELDS$r において推奨されたとおり， ~errorとして扱われなければ`ナラナイ^2119 （その結果，当の~field全体が無視される） — 応用~protocolの折衝が任意選択であり続けることを許容するよう。 どちらの~fieldにおいても，`~sf~parameter$用の意味論は定義されない — それらは、 無視されなければ`ナラナイ^2119。 ◎ Both WT-Available-Protocols and WT-Protocol are Structured Fields [FIELDS]. WT-Available-Protocols is a List. WT-Protocol is defined as an Item. In both cases, the only valid value type is a String. Any value type other than String MUST be treated as an error that causes the entire field to be ignored as recommended in [FIELDS], allowing application protocol negotiation to remain optional. No semantics are defined for parameters on either field; parameters MUST be ignored.

応用~protocolの折衝を要求する~serverは、 `WT-Available-Protocols$h ~headerが［ 無い場合／ 不正形であり無視される場合 ］には，当の~sessionを却下しても`ヨイ^2119。 ◎ A server that requires application protocol negotiation MAY reject the session if the WT-Available-Protocols header field is absent or if it is malformed and therefore ignored.

応用~protocolの折衝を要求する~clientは、 ~serverが成功裡な応答~内に `WT-Protocol$h ~headerを［ 内包しなかった場合／ 内包したが不正形なので無視される場合 ］には， 当の`~WebTransport~session$を~error~code `WT_ALPN_ERROR$er で~closeしなければ`ナラナイ^2119。 ◎ A client that requires application protocol negotiation MUST close the WebTransport session with a WT_ALPN_ERROR error code if the server does not include a WT-Protocol header field, or if it is malformed and therefore ignored, in a successful response.

`WT-Protocol$h ~headerの値は、 当の応答が応対した要請の `WT-Available-Protocols$h ~headerの値を成す いずれかの~itemの値でなければ`ナラナイ^2119 ~clientは、 受信した `WT-Protocol$h ~headerが これを満たさない場合には， 当の`~WebTransport~session$を~error~code `WT_ALPN_ERROR$er で~closeしなければ`ナラナイ^2119。 ◎ If the client sends a WT-Available-Protocols header field and the server responds with a WT-Protocol header field, the value in the WT-Protocol response header field MUST be one of the values listed in WT-Available-Protocols of the request. If the client receives a WT-Protocol value that was not included in its WT-Available-Protocols list, the client MUST close the WebTransport session with a WT_ALPN_ERROR error code.

［ `WT-Available-Protocols$h ／ `WT-Protocol$h ］内に利用される個々の値の意味論は、 当の~WebTransport資源により決定される — ~IANAの `~ALPN~protocol~ID~registry＠~IANA-a/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids$cite に登録することは、 要求されない。 ◎ The semantics of individual values used in WT-Available-Protocols and WT-Protocol are determined by the WebTransport resource in question and are not required to be registered in IANA's "ALPN Protocol IDs" registry.

3.4. 優先度化

各`~WebTransport~session$は、 拡張d `CONNECT$m を利用して起動される。 `RFC9218$r `11＠~HTTPpriority#connect-scheduling§は，［ 拡張-可能な優先度が`~CONNECT~stream$上に送信された~dataに どう適用できるか ］を述べるが、 ~WebTransportは，［ 要請と応答の関係において交換される~dataの種別 ］を拡張する — それには、 追加的な考慮点が要求される。 ◎ WebTransport sessions are initiated using extended CONNECT. While Section 11 of [RFC9218] describes how extensible priorities can be applied to data sent on a CONNECT stream, WebTransport extends the types of data that are exchanged in relation to the request and response, which requires additional considerations.

~WebTransport `CONNECT$m 要請, それに対する応答は、 `Priority$h ~header `RFC9218$r を包含しても`ヨイ^2119。 ~clientは、 `PRIORITY_UPDATE$ft ~frame `RFC9218$r を送信することにより， 優先度化し直しても`ヨイ^2119。 `RFC9218$r に対する拡張においては、［ ~client, ~server ］は， 当の封入している【？】`~WebTransport~session$内に自身が送信するすべての~data — `~capsule$, `~WebTransport~stream$, ~WebTransport~datagram を含む — に［ `RFC9218$r `9＠~HTTPpriority#client-scheduling§, `RFC9218$r `10＠~HTTPpriority#server-scheduling§ ］による~schedule法の指導をどちらも適用することが`推奨される^2119。 ~WebTransportは、 `~WebTransport~session$の中の［ ~streamたち, ~datagramたち ］用に優先度を通達するための仕組みを何も供さない — そのような仕組みは、 ~WebTransportを利用している応用~protocolが定義し得る。 そのような仕組みは、 ある~sessionの中での~schedule法に限り影響し， 同じ`~HTTP3接続$上の他の~dataの~schedule法には影響しないことが`推奨される^2119。 ◎ WebTransport CONNECT requests and responses MAY contain the Priority header field (Section 5 of [RFC9218]); clients MAY reprioritize by sending PRIORITY_UPDATE frames (Section 7 of [RFC9218]). In extension to [RFC9218], it is RECOMMENDED that clients and servers apply the scheduling guidance in both Section 9 of [RFC9218] and Section 10 of [RFC9218] for all data that they send in the enclosing WebTransport session, including Capsules, WebTransport streams and datagrams. WebTransport does not provide any priority signaling mechanism for streams and datagrams within a WebTransport session; such mechanisms can be defined by application protocols using WebTransport. It is RECOMMENDED that such mechanisms only affect scheduling within a session and not scheduling of other data on the same HTTP/3 connection.

`RFC9218$r `8＠~HTTPpriority#merging§における［ ~clientの優先度, ~serverの優先度 ］を併合するための指導は、 `~WebTransport~session$にも適用される。 例えば，ある応答にて `Priority$h ~headerを受信した~clientは、 ある`~WebTransport~session$の優先度に関する自身の~viewを改めることもでき， その結果として流出~dataの~schedule法を改めることもできる。 ◎ The client/server priority merging guidance in Section 8 of [RFC9218] also applies to WebTransport sessions. For example, a client that receives a response Priority header field could alter its view of a WebTransport session priority and alter the scheduling of outgoing data as a result.

端点は、 `~WebTransport~session$たちを優先度化する際に，［ それらが同じ`~HTTP3接続$上の他の~sessionや要請と どう相互作用するか ］について考慮する必要がある。 ◎ Endpoints that prioritize WebTransport sessions need to consider how they interact with other sessions or requests on the same HTTP/3 connection.

4.1. ~transport~prop

`~WebTransport~framework^cite `OVERVIEW$r は、 ~clientが［ 各種~特能 — ［ すべての~WebTransport~protocolを介して可用な~propたちが成す共通な集合 ］を超えて追加的な最適化を許容するかもしれない特能 — の有無を決定する ］ために利用できる［ 任意選択な`~transport~prop＠~WT-OVERVIEW#transport-properties$たちが成す集合 ］を定義する。 ◎ The WebTransport framework [OVERVIEW] defines a set of optional transport properties that clients can use to determine the presence of features which might allow additional optimizations beyond the common set of properties available via all WebTransport protocols.

以下は、 ~HTTP3越しの~WebTransportにおける［ これらの~prop用の~support ］についての詳細である： ◎ Below are details about support in WebTransport over HTTP/3 for the properties defined by the WebTransport framework.

不依拠-可能な送達： ◎ Unreliable Delivery:

~HTTP3越しの~WebTransportは、 `不依拠-可能$な送達を~supportする。 喪失した~stream~data内の~stream結果を~resetしても，もはや伝送し直されなくなる。 ~HTTP3越しの~WebTransportは、 ~datagramも~supportする — それは、 伝送し直されない。 ◎ WebTransport over HTTP/3 supports unreliable delivery. Resetting a stream results in lost stream data no longer being retransmitted. WebTransport over HTTP/3 also supports datagrams, which are not retransmitted.

~pool法 ◎ Pooling:

~HTTP3越しの~WebTransportは、 任意選択な［ ~poolするための~support ］を供する。 ~pool法を~supportしない端点は、 `CONNECT$m 要請に対し，［ ~quota "`1^c" を伴う~rate上限~施策 ］を指示している~header `I-D.ietf-httpapi-ratelimit-headers$r で返信できる。 ◎ WebTransport over HTTP/3 provides optional support for pooling. Endpoints that do not support pooling can reply to CONNECT requests with a header indicating a rate limit policy with a quota of "1" ([I-D.ietf-httpapi-ratelimit-headers]).

4.2. 一方向~stream

`~WebTransport端点$は、 `一方向~stream$を起動できる。 ~HTTP3の`一方向~stream$の種別は、 `0x54^hex でなければ`ナラナイ^2119【！SHALL】。 ~streamの本体は、 順に，次に挙げるものからなっていなければ`ナラナイ^2119【！SHALL】（ `図 2＠#fig-unidi$ ） ⇒＃ `可変長な整数$として符号化された~stream種別, `可変長な整数$として符号化された`~session~ID$, 【~streamの】利用者が指定した~stream~data ◎ WebTransport endpoints can initiate unidirectional streams. The HTTP/3 unidirectional stream type SHALL be 0x54. The body of the stream SHALL be the stream type, followed by the session ID, encoded as a variable-length integer, followed by the user-specified stream data (Figure 2).

一方向~stream {
  ~stream種別 (i) = `0x54^hex,
  `~session~ID$ (i),
  利用者が指定した~stream~data (..)
}
◎
Unidirectional Stream {
  Stream Type (i) = `0x54^hex,
  Session ID (i),
  User-Specified Stream Data (..)
}

4.3. 双方向~stream

~clientが起動した`双方向~stream$は、 ~HTTP3により，すべて要請~streamとして予約される — それは、 各種~規則を伴う~HTTP3~frameたちが成す連列である （ `HTTP3$r `~HTTPの~message~frame法＠~HTTPv3#request-response§, `双方向~stream＠~HTTPv3#request-streams§を見よ）。 ◎ All client-initiated bidirectional streams are reserved by HTTP/3 as request streams, which are a sequence of HTTP/3 frames with a variety of rules (see Sections 4.1 and 6.1 of [HTTP3]).

~WebTransportは、 代替な要請~stream規則を［ 宣言する／利用する ］ことを~clientに許容するよう，~HTTP3を拡張する。 ~clientは、［ `~WebTransportの~support＠#establishing$を指示している設定群 ］を受信したなら，自身が起動した各~双方向~WebTransport~streamに対し ⇒ ［ それを成す最初の~byte列 ］として［ `可変長な整数$として符号化された特別な通達~値 ］を送信して［ 当の~stream上の残りの~byte列がどう利用されるか ］を指示しなければ`ナラナイ^2119。 ◎ WebTransport extends HTTP/3 to allow clients to declare and to use alternative request stream rules. Once a client receives settings indicating WebTransport support (Section 3.1), it MUST send a special signal value, encoded as a variable-length integer, as the first bytes of each bidirectional WebTransport stream it initiates to indicate how the remaining bytes on the stream are used.

~WebTransportは、 ~serverが起動したすべての`双方向~stream$用の規則を定義することにより， ~HTTP3を拡張する。 ~serverは、 `~WebTransport~session$を`確立して＠#establishing$いる流入 `CONNECT$m 要請を受信したなら， その~sessionと伴に利用する`双方向~stream$を~openできる。 ~serverは、［ この~streamを成す最初の~byte列 ］として［ `可変長な整数$として符号化された特別な通達~値 ］を送信しなければ`ナラナイ^2119 — それは、［ この~stream上の残りの~byte列がどう利用されるか ］を指示する。 ◎ WebTransport extends HTTP/3 by defining rules for all server-initiated bidirectional streams. Once a server receives an incoming CONNECT request establishing a WebTransport session (Section 3.1), it can open a bidirectional stream for use with that session and MUST send a special signal value, encoded as a variable-length integer, as the first bytes of the stream in order to indicate how the remaining bytes on the stream are used.

［ ~client, ~server ］は、 通達~値 `0x41^hex を利用して， 双方向~WebTransport~streamを~openする。 これには、 それに結付けられる［ `可変長な整数$として符号化された`~session~ID$ ］が後続する。 残りは、 当の~streamを成す応用~payloadである （ `図 3＠#fig-bidi-client$）。 ◎ Clients and servers use the signal value 0x41 to open a bidirectional WebTransport stream. Following this is the associated session ID, encoded as a variable-length integer; the rest of the stream is the application payload of the WebTransport stream (Figure 3).

双方向~stream {
  通達~値 (i) = 0x41,
  `~session~ID$ (i),
  ~stream本体 (..)
}
◎
Bidirectional Stream {
  Signal Value (i) = 0x41,
  Session ID (i),
  Stream Body (..)
}

この文書は、 特別な通達~値 `0x41^hex を~frame種別 `WT_STREAM$ft として予約する。 それは、 衝突を避けるため，~HTTP3~frame種別として登録されるが、 長さを欠如するので，適正な~HTTP3~frameではない。 `WT_STREAM$ft は，~HTTP3~frame構文の拡張であり、 ~WebTransportを折衝している相手の端点は，それを~supportしなければ`ナラナイ^2119。 この拡張を実装する端点は、 追加的な~frame取扱い要件の~subjectにもなる。 端点は、 要請~streamを成す一番最初の~byte列~以外において， ~HTTP3~stream上に~frame種別 `WT_STREAM$ft を送信しては`ナラナイ^2119。 他の状況下で，この~frame種別を受信した場合、 `接続~error$( `H3_FRAME_ERROR$er ) として扱わなければ`ナラナイ^2119。 ◎ This document reserves the special signal value 0x41 as a WT_STREAM frame type. While it is registered as an HTTP/3 frame type to avoid collisions, WT_STREAM lacks length and is not a proper HTTP/3 frame; it is an extension of HTTP/3 frame syntax that MUST be supported by any peer negotiating WebTransport. Endpoints that implement this extension are also subject to additional frame handling requirements. Endpoints MUST NOT send WT_STREAM as a frame type on HTTP/3 streams other than the very first bytes of a request stream. Receiving this frame type in any other circumstances MUST be treated as a connection error of type H3_FRAME_ERROR.

4.4. ~data~streamの~reset法

`~WebTransport端点$は、 ~WebTransport~data~stream用に［ `RESET_STREAM$ft ／ `STOP_SENDING$ft ］~frameを送信してもよい。 それらの通達は、 当の~WebTransport実装により，応用へ伝播される。 ◎ A WebTransport endpoint may send a RESET_STREAM or a STOP_SENDING frame for a WebTransport data stream. Those signals are propagated by the WebTransport implementation to the application.

~WebTransport応用は、 自身の演算~用に~error~codeを供さなければ`ナラナイ^2119。 ~WebTransportは，~error~code空間を~HTTP3と共有するので、 ~stream用の~WebTransport応用~errorは、 無符号な 32 ~bitな整数 — `0x00000000^hex 〜 `0xffffffff^hex — に制限される。 ~WebTransport実装は、 それらの~error~codeを `WT_APPLICATION_ERROR$er 用に予約された~error範囲の中へ対応付直さなければ`ナラナイ^2119 — `0x00000000^hex は `0x52e4a40fa8db^hex に, `0xffffffff^hex は `0x52e5ac983162^hex に対応するよう。 この範囲の内側には、 `HTTP3$r `~HTTP3~error~code＠~HTTPv3#http-error-codes§により予約-済みな符号点たち { `0x1f^hex ~MUL %N ~PLUS `0x21^hex ； %N は負でない整数 } があることに注意 — これらの符号点は、 ~error~codeたちを対応付けるときには，飛ばされる必要がある （すなわち、 ある予約-済みな符号点を挟んで隣接な 2 個の~HTTP3~error符号点は， 2 個の隣接な~WebTransport応用~error符号点に対応付けられる）。 対応付け用の`疑似-~code例＠#fig-remap-errors$は： ◎ A WebTransport application MUST provide an error code for those operations. Since WebTransport shares the error code space with HTTP/3, WebTransport application errors for streams are limited to an unsigned 32-bit integer, assuming values between 0x00000000 and 0xffffffff. WebTransport implementations MUST remap those error codes into the error range reserved for WT_APPLICATION_ERROR, where 0x00000000 corresponds to 0x52e4a40fa8db, and 0xffffffff corresponds to 0x52e5ac983162. Note that there are codepoints inside that range of form "0x1f * N + 0x21" that are reserved by Section 8.1 of [HTTP3]; those have to be skipped when mapping the error codes (i.e., the two HTTP/3 error codepoints adjacent to a reserved codepoint would map to two adjacent WebTransport application error codepoints). An example pseudocode can be seen in Figure 4.

%first = 0x52e4a40fa8db
%last = 0x52e5ac983162

def webtransport_code_to_http_code(%n):
return %first + %n + floor(%n / 0x1e)

def http_code_to_webtransport_code(%h):
assert(%first <= %h <= %last)
assert((%h - 0x21) % 0x1f != 0)
%shifted = %h - %first
return %shifted - floor(%shifted / 0x1f)

各~WebTransport~data~stream %~stream には、 当の~streamの始めにある~header %~header を通して，ある`~WebTransport~session$ %~session が結付けられる — %~stream を`~reset$すると、 その~data【`~session~ID$】は， `RESET_STREAM$ft ~frameを利用するときに破棄される結果になるかもしれない。 これを防止するため、 ~WebTransport実装は， %~stream を`~reset$するときには `RESET_STREAM_AT$ft ~frame `RESET-STREAM-AT$r を利用しなければナラナイ — その~frameを成す `依拠-可能な~size^i（ `Reliable Size^en ） ~fieldを %~header の~size以上に設定して。 これは、［ %~stream を %~session へ結付けている~ID~field【`~session~ID$】 ］の依拠-可能な送達を確保する。 ◎ WebTransport data streams are associated with sessions through a header at the beginning of the stream; resetting a stream might result in that data being discarded when using a RESET_STREAM frame. To prevent this, WebTransport implementations MUST use the RESET_STREAM_AT frame [RESET-STREAM-AT] with a Reliable Size set to at least the size of the WebTransport header when resetting a WebTransport data stream. This ensures reliable delivery of the ID field associating the data stream with a WebTransport session.

`~WebTransport端点$は、［ 既知な~sessionが結付けられた~stream ］に対しては，それ用の~error~codeを当の~sessionを所有する応用へ回送しなければ`ナラナイ^2119。 類似に，`媒介者$は、 相手の端点から~resetを受信したときは， 対応する~error~codeで そのような~streamを`~reset$しなければ`ナラナイ^2119。 受信した［ `RESET_STREAM$ft ／ `STOP_SENDING$ft ］~frameが［ `WT_APPLICATION_ERROR$er 用に予約された範囲に入らない~error~code ］を伴う場合でも， 当の~streamは`~reset$されたものと見なされるが、 当の~error~codeは，~WebTransport応用~error~codeへは対応付けられない。 ~WebTransport実装は、 これを［ 応用~error~codeを伴わない~stream`~reset$ ］として当の応用へ送達する`ベキ^2119である。 ◎ WebTransport endpoints MUST forward the error code for a stream associated with a known session to the application that owns that session; similarly, intermediaries MUST reset such streams with a corresponding error code when receiving a reset from their peer. If a RESET_STREAM or STOP_SENDING frame is received with an error code outside the range reserved for WT_APPLICATION_ERROR, the stream is still considered reset, but the error code is not mapped to a WebTransport application error code. The WebTransport implementation SHOULD deliver this to the application as a stream reset with no application error code.

4.5. ~datagram

~datagramは、 `~HTTP~datagram$ `HTTP-DATAGRAM$r を利用して送信できる。 ~WebTransport~datagramの~payloadは、 `~HTTP~datagram$を成す `~HTTP~datagram~payload^i ~field内に改変されずに送信される。 それは、 `四分~stream~ID^i ~fieldの直後に後続することに注意 — この~fieldは、 当の~QUIC `DATAGRAM$ft ~frameの~payloadを成す始端にあり， `~WebTransport~session$を確立した`~CONNECT~stream$を指す。 ◎ Datagrams can be sent using HTTP Datagrams. The WebTransport datagram payload is sent unmodified in the "HTTP Datagram Payload" field of an HTTP Datagram (Section 2.1 of [HTTP-DATAGRAM]). Note that the payload field directly follows the Quarter Stream ID field, which is at the start of the QUIC DATAGRAM frame payload and refers to the CONNECT stream that established the WebTransport session.

4.6. 流入~stream／~datagramの~buffer法

~HTTP3越しの~WebTransportにおいては、 ~clientは，`~WebTransport~session$を確立する前に［ ~WebTransport用の~Upgrade~tokenを利用している `CONNECT$m 要請 ］を送信する （`~transport能力がある~HTTP3接続の確立-法＠#establishing§を見よ） ことにより［ ~serverから `SETTINGS$ft ~frameを受信する ］のを待機しなければナラナイ。 これは、［ 所与の`~HTTP3接続$上で~WebTransportの各~versionのうち，どれが利用できるか ］を~clientが常に知れることを確保する。 ◎ In WebTransport over HTTP/3, the client MUST wait for receipt of the server's SETTINGS frame before establishing any WebTransport sessions by sending CONNECT requests using the WebTransport upgrade token (see Section 3.1). This ensures that the client will always know what versions of WebTransport can be used on a given HTTP/3 connection.

しかしながら，~clientは、 `SETTINGS$ft ~frameに加えて，複数個の［ ~WebTransport `CONNECT$m 要請, ~WebTransport~data~stream, ~WebTransport~datagram ］を単独の~flightの中で一括して送信しても`ヨイ^2119。 それらは，順序どおりに到着しないこともあるので、 `~WebTransport~server$は，［ ~streamや~datagram ］を対応する~sessionを伴わずに受信する状況に置かれることもある。 類似に、 ~clientは，~serverが起動した［ ~stream／~datagram ］を［ ~serverから `CONNECT$m 応答~headerを受信する前 ］に受信することもある。 ◎ Clients can, however, send a SETTINGS frame, multiple WebTransport CONNECT requests, WebTransport data streams, and WebTransport datagrams all within a single flight. As those can arrive out of order, a WebTransport server could be put into a situation where it receives a stream or a datagram without a corresponding session. Similarly, a client may receive a server-initiated stream or a datagram before receiving the CONNECT response headers from the server.

この事例を取扱うため、 `~WebTransport端点$は，［ ~stream／~datagram ］を［ ある確立された~sessionに結付けれるようになる ］まで~bufferする`ベキ^2119である。 資源の枯渇を避けるため、 当の端点は，~bufferされる［ ~stream／~datagram ］の個数を制限しなければ`ナラナイ^2119。 ~bufferされた~streamの個数が それを超過したときは、 いずれかの~streamが — ~error~code `WT_BUFFERED_STREAM_REJECTED$er を伴う［ `RESET_STREAM$ft ／ `STOP_SENDING$ft ］を送信する ］ことにより — ~closeされなければ`ナラナイ^2119【！SHALL】。 ~bufferされた~datagramの個数が それを超過したときは、 いずれかの~datagramが落とされなければ`ナラナイ^2119【！SHALL】。 破棄する［ ~stream／~datagram ］としてどれを選ぶかは、 実装に委ねられる。 ◎ To handle this case, WebTransport endpoints SHOULD buffer streams and datagrams until they can be associated with an established session. To avoid resource exhaustion, endpoints MUST limit the number of buffered streams and datagrams. When the number of buffered streams is exceeded, a stream SHALL be closed by sending a RESET_STREAM and/or STOP_SENDING with the WT_BUFFERED_STREAM_REJECTED error code. When the number of buffered datagrams is exceeded, a datagram SHALL be dropped. It is up to an implementation to choose what stream or datagram to discard.

4.7. ~HTTP3 `GOAWAY$ft ~frameとの相互作用

~HTTP3は、 上品な~shutdownの仕組みを定義する （ `HTTP3$r `接続の~shutdown＠~HTTPv3#connection-shutdown§） — それは、 双方の端点に次を許容する ⇒ `GOAWAY$ft ~frameを送信して，もはや新たな流入［ 要請／~push ］を受容しないことを指示する ◎ HTTP/3 defines a graceful shutdown mechanism (Section 5.2 of [HTTP3]) that allows a peer to send a GOAWAY frame indicating that it will no longer accept any new incoming requests or pushes.

`GOAWAY$ft ~frameを受信した~clientは、 当の`~HTTP3接続$に対し，新たな`~WebTransport~session$用の `CONNECT$m 要請を起動し得ない — 同じ相手の端点との新たな`~WebTransport~session$を起動するためには、 新たな`~HTTP3接続$を~openしなければならない。 ◎ A client receiving GOAWAY cannot initiate CONNECT requests for new WebTransport sessions on that HTTP/3 connection; it must open a new HTTP/3 connection to initiate new WebTransport sessions with the same peer.

~HTTP3 `GOAWAY$ft ~frameは、［ すべての`~WebTransport~session$に対し，~shutdownを起動する ］よう応用へ通達するものでもある。 どちらの端点も、 `種別^i `WT_DRAIN_SESSION@cps （ `0x78ae^hex ） を伴う`~capsule$を送信して， 単独の`~WebTransport~session$を~shut-downできる。 ◎ An HTTP/3 GOAWAY frame is also a signal to applications to initiate shutdown for all WebTransport sessions. To shut down a single WebTransport session, either endpoint can send a WT_DRAIN_SESSION (0x78ae) capsule.

WT_DRAIN_SESSION ~capsule {
  種別 (i) = WT_DRAIN_SESSION,
  長さ (i) = 0
}
◎
WT_DRAIN_SESSION Capsule {
  Type (i) = WT_DRAIN_SESSION,
  Length (i) = 0
}

端点は、［ `WT_DRAIN_SESSION$cps `~capsule$／ ~HTTP3 `GOAWAY$ft ~frame ］を［ 送信した／受信した ］（順不同）後でも，［ 当の~sessionの利用を継続しても`ヨイ^2119／ 当の~sessionで新たな~WebTransport~streamを~openしても`ヨイ^2119 ］（順不同）。 通達は、 ~WebTransportを利用している応用~用に意図される — 応用には、 アリな限り，当の~sessionを上品に終了するよう試みることが期待される。 ◎ After sending or receiving either a WT_DRAIN_SESSION capsule or a HTTP/3 GOAWAY frame, an endpoint MAY continue using the session and MAY open new WebTransport streams. The signal is intended for the application using WebTransport, which is expected to attempt to gracefully terminate the session as soon as possible.

`WT_DRAIN_SESSION$cps ~capsuleは、 `端点間$な`~WebTransport~session$が`媒介者$を通過するときに有用になる。 例えば，~backendは、 ~shut-downするときには，媒介者へ `GOAWAY$ft を送信する。 当の媒介者は、 ~clientが面している~session上では， この通達を `WT_DRAIN_SESSION$cps ~capsuleへ変換できる — 当の接続~上で運ばれる他の［ 要請／~session ］に影響iすることなく。 ◎ The WT_DRAIN_SESSION capsule is useful when an end-to-end WebTransport session passes through an intermediary. For example, when the backend shuts down, it sends a GOAWAY to the intermediary. The intermediary can convert this signal to a WT_DRAIN_SESSION capsule on the client-facing session, without impacting other requests or sessions carried on that connection.

4.8. 鍵~用~素材~exporterの利用

~HTTP3越しの~WebTransportは、 ~TLS鍵~用~素材~exporter（ `TLS keying material exporter^en ）の利用を~supportする `RFC8446$r, `7.5＠~RFCx/rfc8446#section-7.5§。 複数の`~WebTransport~session$が同じ下層の~QUIC接続を共有し得るので、 ~WebTransportは、［ 異なる~sessionどうしで鍵~用~素材を分離する ］ために［ ある~TLS~exporterを導出するための仕組み ］を定義する。 応用が所与の`~WebTransport~session$用に［ 指定された［ ~label, 文脈 ］を伴う~exporter ］を要請する場合、 結果の~exporterは， `RFC8446$r `7.5＠~RFCx/rfc8446#section-7.5§ に定義されるとおりの~TLS~exporter — 当の~labelは "`EXPORTER-WebTransport^c" に設定され, 当の文脈は［ 下に定義される `~WebTransport~exporter文脈^i 構造体 ］の直列化に設定されたそれ — でなければ`ナラナイ^2119【！SHALL】。 ◎ WebTransport over HTTP/3 supports the use of TLS keying material exporters Section 7.5 of [RFC8446]. Since the underlying QUIC connection may be shared by multiple WebTransport sessions, WebTransport defines a mechanism for deriving a TLS exporter that separates keying material for different sessions. If the application requests an exporter for a given WebTransport session with a specified label and context, the resulting exporter SHALL be a TLS exporter as defined in Section 7.5 of [RFC8446] with the label set to "EXPORTER-WebTransport" and the context set to the serialization of the "WebTransport Exporter Context" struct as defined below.

~WebTransport~exporter文脈 {
  ~session~ID (64),
  応用から給された~exporter~labelの長さ (8),
  応用から給された~exporter~label (8..),
  応用から給された~exporter文脈の長さ (8),
  応用から給された~exporter文脈 (..)
}
◎
WebTransport Exporter Context {
  WebTransport Session ID (64),
  WebTransport Application-Supplied Exporter Label Length (8),
  WebTransport Application-Supplied Exporter Label (8..),
  WebTransport Application-Supplied Exporter Context Length (8),
  WebTransport Application-Supplied Exporter Context (..)
}

~TLS~exporter~APIは、 `文脈^i ~fieldを省略することを許可するかもしれない。 そのような事例では、 ~TLS 1.3 と同じく， `応用から給された~exporter文脈^i が省略された場合，その長さは 0 になる。 ◎ A TLS exporter API might permit the context field to be omitted. In this case, as with TLS 1.3, the WebTransport Application-Supplied Exporter Context becomes zero-length if omitted.

5.1. ~flow制御の利用の折衝-法

`~WebTransport端点$は、［ 複数の`~WebTransport~session$が下層の~transport接続を共有する ］ことを許容するためには， ~flow制御を可能化しなければ`ナラナイ^2119。 これは、 応用が［ 単独の~session上で過度な資源を消費する, 他の~session用の流通を後回する ］ことを防止する （`~securityの考慮点＠#security-considerations§を見よ）。 ◎ A WebTransport endpoint that allows a WebTransport session to share an underlying transport connection with other WebTransport sessions MUST enable flow control. This prevents an application from consuming excessive resources on a single session and starving traffic for other sessions (see Section 8).

~flow制御は、 双方の端点が［ 次に挙げるいずれかの動作をとることにより， ~flow制御を利用する意図を宣言した ］とき，可能化される： ◎ Flow control is enabled when both endpoints declare their intent to use flow control by taking any of the following actions:

• 0 以外の値を伴う `SETTINGS_WT_INITIAL_MAX_STREAMS_UNI$sp を送信する。 ◎ Sending SETTINGS_WT_INITIAL_MAX_STREAMS_UNI with any value other than "0".
• 0 以外の値を伴う `SETTINGS_WT_INITIAL_MAX_STREAMS_BIDI$sp を送信する。 ◎ Sending SETTINGS_WT_INITIAL_MAX_STREAMS_BIDI with any value other than "0".
• 0 以外の値を伴う `SETTINGS_WT_INITIAL_MAX_DATA$sp を送信する。 ◎ Sending SETTINGS_WT_INITIAL_MAX_DATA with any value other than "0".

どちらの端点も，これらの動作のうち一つ以上をとった場合、 ~flow制御は可能化され， `~flow制御＠#flow-control§にて述べられる制限sすべてが適用される。 ◎ If both endpoints take at least one of these actions, flow control is enabled, and the limits described in the entirety of Section 5 apply.

~flow制御は、 ~serverが~supportする`~WebTransport~session$の個数に関わらず， 可能化され得る。 ◎ Flow control can be enabled regardless of the number of WebTransport sessions a server supports.

~flow制御が可能化されない場合： ◎ If flow control is not enabled,＼

• ~clientは、 複数個の同時な`~WebTransport~session$を確立するよう試みては`ナラナイ^2119。 ◎ clients MUST NOT attempt to establish more than one simultaneous WebTransport session.＼
• ~serverは、［ 下層の~transport接続~上で複数個の~sessionを受信した ］ときは， 過度な`~CONNECT~stream$を `H3_REQUEST_REJECTED$er 状態sで`~reset$しなければ`ナラナイ^2119 （`同時な~session数の制限-法＠#flow-control-limit-sessions§を見よ）。 ◎ A server that receives more than one session on an underlying transport connection when flow control is not enabled MUST reset the excessive CONNECT streams with a H3_REQUEST_REJECTED status (see Section 5.2).
• 端点は、 `~flow制御~capsule$の受領を無視しなければ`ナラナイ^2119 — ［ 相手の端点は，それらが送信された時点では `SETTINGS$ft ~frameをまだ受信してない／ ~packetたちは並替えられた ］かもしれないので。 ◎ Also, if flow control is not enabled, an endpoint MUST ignore receipt of any flow control capsules (see Section 5.6), since the peer might not have received SETTINGS at the time they were sent or packets might have been reordered.

5.2. 同時な~session数の制限-法

~serverは、 資源の過度な消費を防止するためとして， `~HTTP3接続$上の流入`~WebTransport~session$の~rateを制限する`ベキ^2119である。 そうするために可用な仕組みとして、 次が挙げられる： ◎ Servers SHOULD limit the rate of incoming WebTransport sessions on HTTP/3 connections to prevent excessive consumption of resources. To do so, they have multiple mechanisms available:

• `HTTP3$r にて定義される~error~code `H3_REQUEST_REJECTED$er ⇒ これは、 受信している~HTTP3~stackに対し， 当の要請は何ら処理されなかったことを指示する。 ◎ The H3_REQUEST_REJECTED error code defined in Section 8.1 of [HTTP3] indicates to the receiving HTTP/3 stack that the request was not processed in any way.
• ~HTTP状態s~code `429$st `RFC6585$r ⇒ これは、 当の要請は~rate制限-法に因り却下されたことを指示する。 前項と違って、 この通達は，応用へ直に伝播される。 ◎ HTTP status code 429 indicates that the request was rejected due to rate limiting [RFC6585]. Unlike the previous method, this signal is directly propagated to the application.

~WebTransport~serverは、 `CONNECT$m 要請に対する応答において，~WebTransport~clientへ［ ~quota施策, ~service制限s ］を通達するためとして~rate制限-~headerを利用できる （ `I-D.ietf-httpapi-ratelimit-headers$r を見よ）。 これは、 ［ ~clientが~open可能になるものと適理に期待できる~session数 ］についての~hintを~clientに供する。 ~pool法と~flow制御を~supportしない端点は、 同時に複数個の流入~WebTransport~sessionを受容しては`ナラナイ^2119。 ◎ WebTransport servers can use rate limit header fields in responses to CONNECT requests to signal quota policies and service limits to WebTransport clients (see [I-D.ietf-httpapi-ratelimit-headers]). This provides hints to clients about how many sessions they can reasonably expect to be able to open. An endpoint that does not support pooling and flow control MUST NOT accept more than one incoming WebTransport session at a time.

5.3. ~sessionの中の~stream数の制限-法

`WT_MAX_STREAMS$cps `~capsule$は、 `~WebTransport~session$の中の~streamの個数に対する上限を確立する。 ~QUIC `MAX_STREAMS$ft ~frameと同様に、 この~capsuleには 2 つの `種別^i があり， 相手の端点が起動する［ `一方向~stream$, `双方向~stream$ ］用に別々な上限を供する。 ◎ The WT_MAX_STREAMS capsule (Section 5.6.2) establishes a limit on the number of streams within a WebTransport session. Like the QUIC MAX_STREAMS frame (Section 19.11 of [RFC9000]), this capsule has two types that provide separate limits for unidirectional and bidirectional streams that a peer initiates.

~session用の`~CONNECT~stream$は、［ `双方向~stream$, `一方向~stream$ ］どちらの上限にも含まれないことに注意 — ~clientが~openできる`~CONNECT~stream$の個数は、［ ~QUIC~flow制御の~stream上限, ~WebTransport~serverが施行する~rate上限 ］により制限される。 ◎ Note that the CONNECT stream for the session is not included in either the bidirectional or the unidirectional stream limits; the number of CONNECT streams a client can open is limited by QUIC flow control's stream limits and any rate limit that a WebTransport server enforces.

~session~levelの~stream上限は、［ 接続~levelの~stream上限を供する~QUIC `MAX_STREAMS$ft ~frame ］に加えて適用される。 新たな~streamを作成できるのは、 当の~sessionの中で［ ~stream~level, 接続~level ］どちらの上限からも許可される場合に限られる — ~QUIC~stream上限がどう適用されるかの詳細は、 `RFC9000$r `同時並行性の制御-法＠~RFCx/rfc9000#controlling-concurrency§ を見よ。 ◎ The session-level stream limit applies in addition to the QUIC MAX_STREAMS frame, which provides a connection-level stream limit. New streams can only be created within the session if both the stream- and the connection-level limit permit, see Section 4.6 of [RFC9000] for details on how QUIC stream limits are applied.

~QUIC `MAX_STREAMS$ft ~frameとは違って、 この~frame内の値と~QUIC `STREAM^ft ~frame内の`~stream~ID$との間には， 単純な関係性は無い。 このことは、 とりわけ，当の接続~上の~streamに他の利用元もある場合に適用される。 ◎ Unlike the QUIC MAX_STREAMS frame, there is no simple relationship between the value in this frame and stream IDs in QUIC STREAM frames. This especially applies if there are other users of streams on the connection.

`WT_STREAMS_BLOCKED$cps `~capsule$は、 次を指示するために送信できる ⇒ 端点は、 ~session~levelの~stream上限に因り， ~streamを作成-可能でなかった。 ◎ The WT_STREAMS_BLOCKED capsule (Section 5.6.3) can be sent to indicate that an endpoint was unable to create a stream due to the session-level stream limit.

この上限を施行するためには、［ 双方の端点が~openな~stream数について合意できる ］よう［ ~stream~header用に依拠-可能な`~reset$が要求される ］ことに注意。 ◎ Note that enforcing this limit requires reliable resets for stream headers so that both endpoints can agree on the number of streams that are open.

5.4. ~data上限

`WT_MAX_DATA$cps `~capsule$は、 同じ`~WebTransport~session$の中で送信できる~data量に対する上限を確立する。 その `種別^i に対応している各~stream【すなわち，~data~stream？】上に送信される すべての~dataは、 この上限へ向けて数えられる。 ただし、 ~stream~header （ `一方向~stream＠#unidirectional-streams§, `双方向~stream＠#bidirectional-streams§ を見よ） は，この上限からは除外される — この上限が［ 新たな~streamを特定の`~WebTransport~session$へ~linkするために本質的な情報 ］の送信を防止しないようにするため。 ◎ The WT_MAX_DATA capsule (Section 5.6.4) establishes a limit on the amount of data that can be sent within a WebTransport session. This limit counts all data that is sent on streams of the corresponding type, excluding the stream header (see Section 4.2 and Section 4.3). The stream header is excluded from this limit so that this limit does not prevent the sending of information that is essential in linking new streams to a specific WebTransport session.

`~reset$された~stream用に `WT_MAX_DATA$cps を実装するためには、［ ~QUIC~stackが，各~streamの最終-~sizeについての情報を~WebTransport実装に供する ］ことが要求される — `RFC9000$r `~streamの最終-~size＠~RFCx/rfc9000#final-size§ を見よ。 これは、［ 当の~stream上の`送信器$が，`~WebTransport~session$の~flow制御~creditを消費した量 ］について，双方の端点が合意することを保証する。 ◎ For streams that were reset, implementing WT_MAX_DATA requires that the QUIC stack provide the WebTransport implementation with information about the final size of streams; see Section 4.5 of [RFC9000]. This guarantees that both endpoints agree on how much WebTransport session flow control credit was consumed by the sender on that stream.

`WT_DATA_BLOCKED$cps `~capsule$は、 次を指示するために送信できる ⇒ 端点は、 `WT_MAX_DATA$cps ~capsuleにより設定された上限に因り， ~dataを送信-可能でなかった。 ◎ The WT_DATA_BLOCKED capsule (Section 5.6.5) can be sent to indicate that an endpoint was unable to send data due to a limit set by the WT_MAX_DATA capsule.

~HTTP3越しの~WebTransportは， 各~WebTransport~stream用に~nativeな~QUIC~streamを利用するので、 ~streamごとの~data上限は，~QUICにより~nativeに供される （ `RFC9000$r `~data~flowの制御＠~RFCx/rfc9000#data-flow-control§を見よ）。 `WEBTRANS-H2$r【！`I-D.ietf-webtrans-http2$r】 の［ `WT_MAX_STREAM_DATA$cps, `WT_STREAM_DATA_BLOCKED$cps ］`~capsule$は、 利用されない — それらは、 禁制される。 端点は、 これらの~capsuleの受領を~session~errorとして扱わなければ`ナラナイ^2119。 ◎ Because WebTransport over HTTP/3 uses a native QUIC stream for each WebTransport stream, per-stream data limits are provided by QUIC natively (see Section 4.1 of [RFC9000]). The WT_MAX_STREAM_DATA and WT_STREAM_DATA_BLOCKED capsules (Sections 6.6 and 6.9 of [I-D.ietf-webtrans-http2]) are not used and so are prohibited. Endpoints MUST treat receipt of a WT_MAX_STREAM_DATA or a WT_STREAM_DATA_BLOCKED capsule as a session error.

5.5. ~flow制御~用の設定

~flow制御~用の初期~時の上限は、 ~HTTP3 `SETTINGS$ft ~frameを介して， 次に挙げる`設定$【！~parameter】 （`~HTTP3設定~parameterの登録＠#http3-settings§を見よ） に 0 以外の値を供することにより交換される： ◎ Initial flow control limits can be exchanged via HTTP/3 SETTINGS (Section 9.2) by providing non-zero values for

• `SETTINGS_WT_INITIAL_MAX_STREAMS_UNI$sp （を介した `WT_MAX_STREAMS$cps 用の値） ◎ ↓
• `SETTINGS_WT_INITIAL_MAX_STREAMS_BIDI$sp （を介した `WT_MAX_STREAMS$cps 用の値） ◎ WT_MAX_STREAMS via SETTINGS_WT_INITIAL_MAX_STREAMS_UNI and SETTINGS_WT_INITIAL_MAX_STREAMS_BIDI
• `SETTINGS_WT_INITIAL_MAX_DATA$sp （を介した `WT_MAX_DATA$cps 用の値） ◎ WT_MAX_DATA via SETTINGS_WT_INITIAL_MAX_DATA

5.6. ~flow制御~capsule

~HTTP3越しの~WebTransportは、 次に挙げる`~capsule$を~flow制御~用に利用する ⇒＃ `WT_MAX_DATA$cps, `WT_MAX_STREAMS$cps, `WT_DATA_BLOCKED$cps, `WT_STREAMS_BLOCKED$cps ◎終 これらの~capsuleは、 `~flow制御~capsule@ と総称され，いずれも — `HTTP-DATAGRAM$r `~capsule~protocol§1 にて述べられるとおり — `媒介者$による特別な取扱いを定義する。 ◎ WebTransport over HTTP/3 uses several capsules for flow control, and all of these capsules define special intermediary handling as described in Section 3.2 of [HTTP-DATAGRAM]. These capsules, referred to as the "flow control capsules", are WT_MAX_DATA, WT_MAX_STREAMS, WT_DATA_BLOCKED, and WT_STREAMS_BLOCKED.

端点は、［ `WT_MAX_DATA$cps ／ `WT_MAX_STREAMS$cps ］~capsuleを送信する前に［ `WT_DATA_BLOCKED$cps ／ `WT_STREAMS_BLOCKED$cps ］~capsuleを待機しては`ナラナイ^2119 — そうすると、 送信器が 1 回の往復~以上は阻まれることになるので。 端点は、［ ~data~stream／~close~stream ］を消費するに伴い［ `WT_MAX_DATA$cps ／ `WT_MAX_STREAMS$cps ］~capsuleを送信する`ベキ^2119である （~QUICにおいて利用される仕組み — `RFC9000$r `~flow制御~上限の増大-法＠~RFCx/rfc9000#fc-credit§ — に類似な）。 ◎ An endpoint MUST NOT wait for a WT_DATA_BLOCKED or WT_STREAMS_BLOCKED capsule before sending a WT_MAX_DATA or WT_MAX_STREAMS capsule; doing so could result in the sender being blocked for at least an entire round trip. Endpoints SHOULD send WT_MAX_DATA and WT_MAX_STREAMS capsules as they consume data or close streams (similar to the mechanism used in QUIC, see Section 4.2 of [RFC9000]).

WT_MAX_STREAMS ~capsule {
  種別 (i) = 0x190B4D3F..0x190B4D40,
  長さ (i),
  最大~stream数 (i),
}
◎
WT_MAX_STREAMS Capsule {
  Type (i) = 0x190B4D3F..0x190B4D40,
  Length (i),
  Maximum Streams (i),
}

WT_STREAMS_BLOCKED ~capsule {
  種別 (i) = 0x190B4D43..0x190B4D44,
  長さ (i),
  最大~stream数 (i),
}
◎
WT_STREAMS_BLOCKED Capsule {
  Type (i) = 0x190B4D43..0x190B4D44,
  Length (i),
  Maximum Streams (i),
}

WT_MAX_DATA ~capsule {
  種別 (i) = 0x190B4D3D,
  長さ (i),
  最大~data量 (i),
}
◎
WT_MAX_DATA Capsule {
  Type (i) = 0x190B4D3D,
  Length (i),
  Maximum Data (i),
}

WT_DATA_BLOCKED ~capsule {
  種別 (i) = 0x190B4D41,
  長さ (i),
  最大~data量 (i),
}
◎
WT_DATA_BLOCKED Capsule {
  Type (i) = 0x190B4D41,
  Length (i),
  Maximum Data (i),
}

7.1. 草案~versionの折衝-法

注記： この節は、 ~RFCとして公表する前に除去されることになる。 ◎ [[RFC editor: please remove this section before publication.]]

~WebTransport~protocolを成す伝送路~形式の側面は、［ `SETTINGS_WT_ENABLED$sp 設定~用に利用される符号点 ］を変更することにより折衝される。 各~草案~versionは、 `SETTINGS_WT_ENABLED$sp 用に別個な符号点を定義する。 ［ ~client, ~server ］どちらも、［ 自身が~supportする草案~versionに対応している符号点 ］を伴う `SETTINGS_WT_ENABLED^sp を送信しなければ`ナラナイ^2119。 複数の草案~versionを~supportする端点は、 自身が~supportする~versionごとに `SETTINGS_WT_ENABLED$sp 値を送信する — 各~versionは、 異なる設定~識別子を利用するので。 双方の端点が~supportする~versionのうち最も高いものが選定される。 ◎ The wire format aspects of the protocol are negotiated by changing the codepoint used for the SETTINGS_WT_ENABLED setting. Each draft version defines a distinct codepoint for SETTINGS_WT_ENABLED. Both the client and the server MUST send SETTINGS_WT_ENABLED with the codepoint corresponding to their supported draft version. An endpoint that supports multiple draft versions sends a SETTINGS_WT_ENABLED value for each supported version, as each version uses a different setting identifier. The highest version supported by both endpoints is selected.

~data~streamは，［ それに結付けられた~sessionを確立する `CONNECT$m 要請 ］よりも前に~serverに到着し得ることに加え、 ~stream~headerの伝送路~形式は，折衝された~versionに依存するので、 ~serverは， 流入~WebTransport~streamを処理する前に~clientの~versionを知る必要がある。 この理由から， ~serverは、 ~clientの `SETTINGS$ft ~frameを受信するまでは， 流入~WebTransport要請を処理しては`ナラナイ^2119。 ◎ Because data streams can arrive at the server before the CONNECT request that establishes the associated session, and the wire format of the stream header depends on the negotiated version, the server needs to know the client's version before processing any incoming WebTransport streams. For this reason, the server MUST NOT process any incoming WebTransport requests until the client's SETTINGS have been received.

9.1. ~Upgrade~tokenの登録

`HTTP$r `~Upgrade~token~registry＠~HTTPinfra#upgrade.token.registry§により確立された `~HTTP~Upgrade~token~registry＠~IANA-a/http-upgrade-tokens$cite には、 以下に挙げる~entryが追加される。 ◎ The following entry is added to the "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry" registry established by Section 16.7 of [HTTP].

~label "`webtransport-h3@c" は、 ~WebTransport用の~protocolとして~HTTP3が利用されたことを識別する： ◎ The "webtransport-h3" label identifies HTTP/3 used as a protocol for WebTransport:

• 値 ⇒ `webtransport-h3^c ◎ Value: • webtransport
• 記述 ⇒ ~HTTP3越しの~WebTransport ◎ Description: • WebTransport over HTTP/3
• 参照 ⇒ この文書 ◎ Reference: • This document

9.2. ~HTTP3設定~parameterの登録

`HTTP3$r により確立された `~HTTP3設定~registry＠~IANA-a/http3-parameters/http3-parameters.xhtml#http3-parameters-settings$cite には、 以下に挙げる~entryが追加される。 ◎ The following entry is added to the "HTTP/3 Settings" registry established by [HTTP3]:

• 設定~名 ⇒ `SETTINGS_WT_ENABLED@sp ◎ Setting Name: • SETTINGS_WT_ENABLED
• 値 ⇒ `0x2c7cf000^hex ◎ Value: • 0x2c7cf000
• 既定 ⇒ 0 ◎ Default: • 0
• 参照 ⇒ この文書 ◎ Reference: • This document
• 変更~制御者 ⇒ ~IETF ◎ Change Controller: • IETF
• 連絡先 ⇒ ~WebTransport~WG ~MAILTO-WT ◎ Contact: • WebTransport Working Group webtransport@ietf.org

• 設定~名 ⇒ `SETTINGS_WT_INITIAL_MAX_STREAMS_UNI$sp ◎ Setting Name: • SETTINGS_WT_INITIAL_MAX_STREAMS_UNI
• 値 ⇒ `0x2b64^hex ◎ Value: • 0x2b64
• 既定 ⇒ 0 ◎ Default: • 0
• 参照 ⇒ この文書 ◎ Reference: • This document
• 変更~制御者 ⇒ ~IETF ◎ Change Controller: • IETF
• 連絡先 ⇒ ~WebTransport~WG ~MAILTO-WT ◎ Contact: • WebTransport Working Group webtransport@ietf.org

• 設定~名 ⇒ `SETTINGS_WT_INITIAL_MAX_STREAMS_BIDI$sp ◎ Setting Name: • SETTINGS_WT_INITIAL_MAX_STREAMS_BIDI
• 値 ⇒ `0x2b65^hex ◎ Value: • 0x2b65
• 既定 ⇒ 0 ◎ Default: • 0
• 参照 ⇒ この文書 ◎ Reference: • This document
• 変更~制御者 ⇒ ~IETF ◎ Change Controller: • IETF
• 連絡先 ⇒ ~WebTransport~WG ~MAILTO-WT ◎ Contact: • WebTransport Working Group webtransport@ietf.org

• 設定~名 ⇒ `SETTINGS_WT_INITIAL_MAX_DATA$sp ◎ Setting Name: • SETTINGS_WT_INITIAL_MAX_DATA
• 値 ⇒ `0x2b61^hex ◎ Value: • 0x2b61
• 既定 ⇒ 0 ◎ Default: • 0
• 参照 ⇒ この文書 ◎ Reference: • This document
• 変更~制御者 ⇒ ~IETF ◎ Change Controller: • IETF
• 連絡先 ⇒ ~WebTransport~WG ~MAILTO-WT ◎ Contact: • WebTransport Working Group webtransport@ietf.org

9.3. ~frame種別の登録

`HTTP3$r により確立された `~HTTP3~frame種別~registry＠~IANA-a/http3-parameters/http3-parameters.xhtml#http3-parameters-frame-types$cite には、 以下に挙げる~entryが追加される。 ◎ The following entry is added to the "HTTP/3 Frame Type" registry established by [HTTP3]:

`WT_STREAM@ft ~frameは、 ~WebTransport~HTTP3拡張との衝突を避ける目的で，予約される： ◎ The WT_STREAM frame is reserved for the purpose of avoiding collision with WebTransport HTTP/3 extensions:

• 値 ⇒ `0x41^hex ◎ Value: • 0x41
• ~frame種別 ⇒ `WT_STREAM$ft ◎ Frame Type: • WT_STREAM
• 参照 ⇒ この文書 ◎ Reference: • This document
• 変更~制御者 ⇒ ~IETF ◎ Change Controller: • IETF
• 連絡先 ⇒ ~WebTransport~WG ~MAILTO-WT ◎ Contact: • WebTransport Working Group webtransport@ietf.org

9.4. ~stream種別の登録

`HTTP3$r により確立された `~HTTP3~stream種別~registry＠~IANA-a/http3-parameters/http3-parameters.xhtml#http3-parameters-stream-types$cite には、 以下に挙げる~entryが追加される。 ◎ The following entry is added to the "HTTP/3 Stream Type" registry established by [HTTP3]:

種別 `~WebTransport~stream@ は、［ `一方向~stream$が~WebTransportにより利用される ］ことを許容する： ◎ The "WebTransport stream" type allows unidirectional streams to be used by WebTransport:

• 値 ⇒ `0x54^hex ◎ Value: • 0x54
• ~stream種別 ⇒ ~WebTransport~stream ◎ Stream Type: • WebTransport stream
• 参照 ⇒ この文書 ◎ Reference: • This document
• 送信器 ⇒ `両方^i ◎ Sender: • Both
• 変更~制御者 ⇒ ~IETF ◎ Change Controller: • IETF
• 連絡先 ⇒ ~WebTransport~WG ~MAILTO-WT ◎ Contact: • WebTransport Working Group webtransport@ietf.org

9.5. ~HTTP3~error~codeの登録

`HTTP3$r により確立された `~HTTP3~error~code~registry＠~IANA-a/http3-parameters/http3-parameters.xhtml#http3-parameters-error-codes$cite には、 以下に挙げる~entryが追加される。 ◎ The following entries are added to the "HTTP/3 Error Code" registry established by [HTTP3]:

• 名前 ⇒ `WT_BUFFERED_STREAM_REJECTED@er ◎ Name: • WT_BUFFERED_STREAM_REJECTED
• 値 ⇒ `0x3994bd84^hex ◎ Value: • 0x3994bd84
• 記述 ⇒ ~WebTransport~data~streamは、 それに結付けられた~sessionの欠如に因り，却下された。 ◎ Description: • WebTransport data stream rejected due to lack of associated session.
• 参照 ⇒ この文書 ◎ Reference: • This document.
• 変更~制御者 ⇒ ~IETF ◎ Change Controller: • IETF
• 連絡先 ⇒ ~WebTransport~WG ~MAILTO-WT ◎ Contact: • WebTransport Working Group webtransport@ietf.org

• 名前 ⇒ `WT_SESSION_GONE@er ◎ Name: • WT_SESSION_GONE
• 値 ⇒ `0x170d7b68^hex ◎ Value: • 0x170d7b68
• 記述 ⇒ ~WebTransport~data~streamは、 それに結付けられた`~WebTransport~session$が~closeされたため，中止された。 ［ 当の端点は、 当の`~CONNECT~stream$からは もはや読取らない ］ことを指示するためにも利用される。 ◎ Description: • WebTransport data stream aborted because the associated WebTransport session has been closed. Also used to indicate that the endpoint is no longer reading from the CONNECT stream.
• 参照【！仕様】 ⇒ この文書 ◎ Specification: • This document.
• 変更~制御者 ⇒ ~IETF ◎ Change Controller: • IETF
• 連絡先 ⇒ ~WebTransport~WG ~MAILTO-WT ◎ Contact: • WebTransport Working Group webtransport@ietf.org

• 名前 ⇒ `WT_FLOW_CONTROL_ERROR@er ◎ Name: • WT_FLOW_CONTROL_ERROR
• 値 ⇒ `0x045d4487^hex ◎ Value: • 0x045d4487
• 記述 ⇒ `~WebTransport~session$は、 ~flow制御~errorに遭遇したため，中止された。 ◎ Description: • WebTransport session aborted because a flow control error was encountered.
• 参照 ⇒ この文書 ◎ Reference: • This document.
• 変更~制御者 ⇒ ~IETF ◎ Change Controller: • IETF
• 連絡先 ⇒ ~WebTransport~WG ~MAILTO-WT ◎ Contact: • WebTransport Working Group webtransport@ietf.org

• 名前 ⇒ `WT_ALPN_ERROR@er ◎ Name: • WT_ALPN_ERROR
• 値 ⇒ `0x0817b3dd^hex ◎ Value: • 0x0817b3dd
• 記述 ⇒ `~WebTransport~session$は、 応用~protocolの折衝に失敗したので，中止された。 ◎ Description: • WebTransport session aborted because application protocol negotiation failed.
• 参照 ⇒ この文書 ◎ Reference: • This document.
• 変更~制御者 ⇒ ~IETF ◎ Change Controller: • IETF
• 連絡先 ⇒ ~WebTransport~WG ~MAILTO-WT ◎ Contact: • WebTransport Working Group webtransport@ietf.org

• 名前 ⇒ `WT_REQUIREMENTS_NOT_MET@er ◎ Name: • WT_REQUIREMENTS_NOT_MET
• 値 ⇒ `0x212c0d48^hex ◎ Value: • 0x212c0d48
• 記述 ⇒ `~HTTP3接続$は、 ~WebTransport用に要求される特能が~supportされないので， ~closeされた。 ［ ~client, ~server ］どちらかが，ある［ 要求される`設定$【！`SETTINGS$ft ~parameter】／ ~WebTransport用に必要な~transport~parameter ］を欠落である。 ◎ Description: • HTTP/3 connection closed because the features required for WebTransport are not supported. Either the client or server is missing required SETTINGS or transport parameters needed for WebTransport.
• 参照 ⇒ この文書 ◎ Reference: • This document.
• 変更~制御者 ⇒ ~IETF ◎ Change Controller: • IETF
• 連絡先 ⇒ ~WebTransport~WG ~MAILTO-WT ◎ Contact: • WebTransport Working Group webtransport@ietf.org

加えて，次に与える範囲の~entryが登録される： ◎ In addition, the following range of entries is registered:

• 名前 ⇒ `WT_APPLICATION_ERROR@er ◎ Name: • WT_APPLICATION_ERROR
• 値 ⇒ 次を満たす整数 %符号点 ⇒ ［ %符号点 ~GTE `0x52e4a40fa8db^hex ］~AND［ %符号点 ~LTE `0x52e5ac983162^hex ］~AND［ %符号点 ~NIN { `0x1f^hex ~MUL %N ~PLUS `0x21^hex ； %N は負でない整数 } ］ ◎ Value: • 0x52e4a40fa8db to 0x52e5ac983162 inclusive, with the exception of the codepoints of form 0x1f * N + 0x21.
• 記述 ⇒ ~WebTransport応用~error~code ◎ Description: • WebTransport application error codes.
• 参照 ⇒ この文書 ◎ Reference: • This document.
• 変更~制御者 ⇒ ~IETF ◎ Change Controller: • IETF
• 連絡先 ⇒ ~WebTransport~WG ~MAILTO-WT ◎ Contact: • WebTransport Working Group webtransport@ietf.org

9.6. ~capsule種別

`HTTP-DATAGRAM$r により確立された `~HTTP~capsule種別~registry^cite には、 以下に挙げる~entryが追加される。 ◎ The following entries are added to the "HTTP Capsule Types" registry established by [HTTP-DATAGRAM]:

`WT_CLOSE_SESSION$cps `~capsule$ ◎ The WT_CLOSE_SESSION capsule

• 値 ⇒ `0x2843^hex ◎ Value: • 0x2843
• ~capsule種別 ⇒ `WT_CLOSE_SESSION$cps ◎ Capsule Type: • WT_CLOSE_SESSION
• 位置付け ⇒ `恒久的^i ◎ Status: • permanent
• 参照 ⇒ この文書 ◎ Reference: • This document
• 変更~制御者 ⇒ ~IETF ◎ Change Controller: • IETF
• 連絡先 ⇒ ~WebTransport~WG ~MAILTO-WT ◎ Contact: • WebTransport Working Group webtransport@ietf.org
• 注記 ⇒ なし ◎ Notes: • None

`WT_DRAIN_SESSION$cps `~capsule$ ◎: • The WT_DRAIN_SESSION capsule.

• 値 ⇒ `0x78ae^hex ◎ Value: • 0x78ae
• ~capsule種別 ⇒ `WT_DRAIN_SESSION$cps ◎ Capsule Type: • WT_DRAIN_SESSION
• 位置付け ⇒ `暫定的^i （この文書が認可されたなら、 `恒久的^i になる) ◎ Status: • provisional (when this document is approved this will become permanent)
• 参照 ⇒ この文書 ◎ Reference: • This document
• 変更~制御者 ⇒ ~IETF ◎ Change Controller: • IETF
• 連絡先 ⇒ ~WebTransport~WG ~MAILTO-WT ◎ Contact: • WebTransport Working Group webtransport@ietf.org
• 注記 ⇒ なし ◎ Notes: • None

`WT_MAX_STREAMS$cps `~capsule$ ◎ The WT_MAX_STREAMS capsule:

• 値 ⇒ `0x190B4D3F..0x190B4D40^hex ◎ Value: • 0x190B4D3F..0x190B4D40
• ~capsule種別 ⇒ `WT_MAX_STREAMS$cps ◎ Capsule Type: • WT_MAX_STREAMS
• 位置付け ⇒ `恒久的^i ◎ Status: • permanent
• 参照 ⇒ この文書 ◎ Reference: • This document
• 変更~制御者 ⇒ ~IETF ◎ Change Controller: • IETF
• 連絡先 ⇒ ~WebTransport~WG ~MAILTO-WT ◎ Contact: • WebTransport Working Group webtransport@ietf.org
• 注記 ⇒ なし ◎ Notes: • None

`WT_STREAMS_BLOCKED$cps `~capsule$ ◎ The WT_STREAMS_BLOCKED capsule:

• 値 ⇒ `0x190B4D43..0x190B4D44^hex ◎ Value: • 0x190B4D43..0x190B4D44
• ~capsule種別 ⇒ `WT_STREAMS_BLOCKED$cps ◎ Capsule Type: • WT_STREAMS_BLOCKED
• 位置付け ⇒ `恒久的^i ◎ Status: • permanent
• 参照 ⇒ この文書 ◎ Reference: • This document
• 変更~制御者 ⇒ ~IETF ◎ Change Controller: • IETF
• 連絡先 ⇒ ~WebTransport~WG ~MAILTO-WT ◎ Contact: • WebTransport Working Group webtransport@ietf.org
• 注記 ⇒ なし ◎ Notes: • None

`WT_MAX_DATA$cps `~capsule$ ◎ The WT_MAX_DATA capsule:

• 値 ⇒ `0x190B4D3D^hex ◎ Value: • 0x190B4D3D
• ~capsule種別 ⇒ `WT_MAX_DATA$cps ◎ Capsule Type: • WT_MAX_DATA
• 位置付け ⇒ `恒久的^i ◎ Status: • permanent
• 参照 ⇒ この文書 ◎ Reference: • This document
• 変更~制御者 ⇒ ~IETF ◎ Change Controller: • IETF
• 連絡先 ⇒ ~WebTransport~WG ~MAILTO-WT ◎ Contact: • WebTransport Working Group webtransport@ietf.org
• 注記 ⇒ なし ◎ Notes: • None

`WT_DATA_BLOCKED$cps `~capsule$ ◎ The WT_DATA_BLOCKED capsule:

• 値 ⇒ `0x190B4D41^hex ◎ Value: • 0x190B4D41
• ~capsule種別 ⇒ `WT_DATA_BLOCKED$cps ◎ Capsule Type: • WT_DATA_BLOCKED
• 位置付け ⇒ `恒久的^i ◎ Status: • permanent
• 参照 ⇒ この文書 ◎ Reference: • This document
• 変更~制御者 ⇒ ~IETF ◎ Change Controller: • IETF
• 連絡先 ⇒ ~WebTransport~WG ~MAILTO-WT ◎ Contact: • WebTransport Working Group webtransport@ietf.org
• 注記 ⇒ なし ◎ Notes: • None

9.7. ~protocol折衝~HTTP~header

以下に挙げる~HTTP~headerが，~protocolを折衝するために利用される （ `応用~protocolの折衝＠#protocol-negotiation§ ）。 これらは、 `HTTP$r `18.4＠~HTTPinfra#field.name.registration§により確立された `~HTTP~field名~registry＠~IANA-a/http-fields$cite に追加される： ◎ The following HTTP header fields are used for negotiating a protocol (Section 3.3). These are added to the "HTTP Field Name" registry established in Section 18.4 of [HTTP]:

`WT-Available-Protocols$h ~field： ◎ The WT-Available-Protocols field:

• ~field名 ⇒ `WT-Available-Protocols^h ◎ Field Name: • WT-Available-Protocols
• 位置付け ⇒ `恒久的^i ◎ Status: • permanent
• 有構造~型 ⇒ `~sf~list$ ◎ Structured Type: • List
• 参照 ⇒ `応用~protocolの折衝＠#protocol-negotiation§ ◎ Reference: • Section 3.3
• ~comment ⇒ なし ◎ Comments: • None

`WT-Protocol$h ~field： ◎ The WT-Protocol field:

• ~field名 ⇒ `WT-Protocol^h ◎ Field Name: • WT-Protocol
• 位置付け ⇒ `恒久的^i ◎ Status: • permanent
• 有構造~型 ⇒ `~sf~item$ ◎ Structured Type: • Item
• 参照 ⇒ `応用~protocolの折衝＠#protocol-negotiation§ ◎ Reference: • Section 3.3
• ~comment ⇒ なし ◎ Comments: • None