HTTP/3

1.1. ~HTTPの先立つ~version

~HTTP11（ `HTTP/1.1$r ）は、 空白で区切られる~text~fieldを利用して，~HTTP~messageを伝達する。 これらの交換は，ヒトから可読になるが、 ~message形式に空白を利用すると［ 構文解析が複階的になり，変種な挙動を過度に~~容認する ］ようになる。 ◎ HTTP/1.1 ([HTTP/1.1]) uses whitespace-delimited text fields to convey HTTP messages. While these exchanges are human readable, using whitespace for message formatting leads to parsing complexity and excessive tolerance of variant behavior.

~HTTP11は，多重化~層を含まないので、 要請を並列的に~serviceするために複数の~TCP接続を利用することが多い。 しかしながら、 それには，［ 輻輳~制御, ~network効率 ］に負な影響iがある — ~TCPは、 輻輳~制御を［ 複数の接続にまたがって共有する ］ことはないので。 ◎ Because HTTP/1.1 does not include a multiplexing layer, multiple TCP connections are often used to service requests in parallel. However, that has a negative impact on congestion control and network efficiency, since TCP does not share congestion control across multiple connections.

~HTTP2 （ `HTTP/2$r ）は、 ~transport層を改変することなく待時間を改善するため， ~binary~frame法と多重化~層を導入した。 しかしながら、 ~HTTP2の多重化を成す並列的な資質は，~TCPの喪失~回復の仕組みからは可視でないので、 ~packetが［ 喪失される／並替えられる ］と， 作動中な~transactionすべてが — 喪失した~packetにより直に影響iされない~transactionも~~含めて — 停滞する原因になる。 ◎ HTTP/2 ([HTTP/2]) introduced a binary framing and multiplexing layer to improve latency without modifying the transport layer. However, because the parallel nature of HTTP/2's multiplexing is not visible to TCP's loss recovery mechanisms, a lost or reordered packet causes all active transactions to experience a stall regardless of whether that transaction was directly impacted by the lost packet.

1.2. ~QUICへの委任

~QUIC~transport~protocolは、 ~HTTP2の~frame化~層により供されるものに類似な［ ~streamの多重化, ~streamごとの~flow制御 ］を組入れる。 ~QUICは、［ ~stream~levelにおける信頼性, 接続~全体にまたがる輻輳~制御 ］を供することにより，~TCP対応付けに比較して~HTTPの処理能を改善する能力がある。 ~QUICはまた、 ~transport層において，~TLS 1.3 （ `TLS$r ）も組入れる — 稼働している~TLS越しに~TCPに匹敵する機密性と完全性を提供することに加え， ~TCP `Fast Open^i（ `TFO$r ）により接続を設定しておく待時間も改善する。 ◎ The QUIC transport protocol incorporates stream multiplexing and per-stream flow control, similar to that provided by the HTTP/2 framing layer. By providing reliability at the stream level and congestion control across the entire connection, QUIC has the capability to improve the performance of HTTP compared to a TCP mapping. QUIC also incorporates TLS 1.3 ([TLS]) at the transport layer, offering comparable confidentiality and integrity to running TLS over TCP, with the improved connection setup latency of TCP Fast Open ([TFO]).

この文書は、 ~HTTP3を定義する。 それは、 ~HTTP2の設計をかなり取り入れているが， ~HTTP意味論を~QUIC~transport~protocol越しの~HTTPに対応付ける。 ~HTTP3が供する［ ~dataの機密性と完全性の保護／ ~peer認証／ 依拠-可能かつ順序通りな~stream別の送達 ］は、 ~QUICに依拠する。 ~HTTP3は、［ `~stream$の存続期間, ~flow制御 ］の課題を~QUICに委任する一方で， 各`~stream$に対し［ ~HTTP2の~frame法に類似な~binary~frame法 ］を利用する。 ~HTTP2特能のうち、 一部は~QUICに組み込まれ，他は~QUICの上層に実装される。 ◎ This document defines HTTP/3: a mapping of HTTP semantics over the QUIC transport protocol, drawing heavily on the design of HTTP/2. HTTP/3 relies on QUIC to provide confidentiality and integrity protection of data; peer authentication; and reliable, in-order, per-stream delivery. While delegating stream lifetime and flow-control issues to QUIC, a binary framing similar to the HTTP/2 framing is used on each stream. Some HTTP/2 features are subsumed by QUIC, while other features are implemented atop QUIC.

~QUICは、 `QUIC-TRANSPORT$r にて述べられる。 ~HTTP2の全部的な記述は、 `HTTP/2$r を見よ。 ◎ QUIC is described in [QUIC-TRANSPORT]. For a full description of HTTP/2, see [HTTP/2].

2.1. この文書の~~構成

以下の各~節では、 `~HTTP3接続$の~lifecycleの詳細な概観を供する： ◎ The following sections provide a detailed overview of the lifecycle of an HTTP/3 connection:

• `3. 接続の設営と管理＠#connection-setup§ ⇒ ~HTTP3端点が どう発見され， `~HTTP3接続$が どう確立されるかを受持つ。 ◎ "Connection Setup and Management" (Section 3) covers how an HTTP/3 endpoint is discovered and an HTTP/3 connection is established.
• `4. ~HTTP3における~HTTP意味論の表出-法＠#http-request-lifecycle§ ⇒ ~HTTP意味論が ~frameを利用して どう表出されるかを述べる。 ◎ "Expressing HTTP Semantics in HTTP/3" (Section 4) describes how HTTP semantics are expressed using frames.
• `5. 接続の~closure＠#connection-closure§ ⇒ `~HTTP3接続$が どう — ［ 上品に, 中途で ］どちらで — 終了されるかを述べる。 ◎ "Connection Closure" (Section 5) describes how HTTP/3 connections are terminated, either gracefully or abruptly.

後続な各~節では、 この伝送路~protocolと~transportとのヤリトリについて，詳細が述べられる： ◎ The details of the wire protocol and interactions with the transport are described in subsequent sections:

• `6. ~streamの対応付けと用法＠#stream-mapping§ ⇒ `~QUIC~stream$が利用される仕方を述べる。 ◎ "Stream Mapping and Usage" (Section 6) describes the way QUIC streams are used.
• `7. ~HTTP~frame化~層＠#http-framing-layer§ ⇒ ほとんどの~streamに利用される各種~frameを述べる。 ◎ "HTTP Framing Layer" (Section 7) describes the frames used on most streams.
• `8. ~errorの取扱い＠#errors§ ⇒ ~error条件がどう取扱われ，表出されるかを述べる — ［ 特定0の`~stream$, および一体としての接続 ］用に。 ◎ "Error Handling" (Section 8) describes how error conditions are handled and expressed, either on a particular stream or for the connection as a whole.

~~残りの各~節では、 追加的な資源が供される： ◎ Additional resources are provided in the final sections:

• `9. ~HTTP3に対する拡張＠#extensions§ ⇒ 将来の文書において， 新たな能力がどう追加できる／され得るかを述べる。 ◎ "Extensions to HTTP/3" (Section 9) describes how new capabilities can be added in future documents.
• `A. ~HTTP2から移行するための考慮点＠#h2-considerations§ ⇒ ~HTTP2と~HTTP3の より詳細な比較。 ◎ A more detailed comparison between HTTP/2 and HTTP/3 can be found in Appendix A.

2.2. 規約と各種用語

この文書~内の~keyword "MUST" … 【以下、この段落の内容は`~IETF日本語訳 共通~page＠~IETFcommon#requirements-notation$に移譲。】 ◎ The key words "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.

この文書は、 `QUIC-TRANSPORT$r による`可変長な整数$による符号化法を利用する。 ◎ This document uses the variable-length integer encoding from [QUIC-TRANSPORT].

次に挙げる用語が利用される： ◎ The following terms are used:

`中止-@ （ `abort^en ）する ◎ abort:

［ 接続／`~stream$ ］を中途で終了すること — 場合によっては、 ~error条件に因り。 ◎ An abrupt termination of a connection or stream, possibly due to an error condition.

`~client@h3 （ `client^en ） ◎ client:

`~HTTP3接続$を起動する方†の端点。 `~client$h3は`要請$を送信して，~HTTP応答を受信する。 ◎ The endpoint that initiates an HTTP/3 connection. Clients send HTTP requests and receive HTTP responses.

【† `~stream$を起動する方と混同しないように — ~streamは、 どちらの端点からも起動され得る 】【 ~HTTPの`~client$とは別に定義されているが、 その概念に包摂され，~HTTPが`~client$に課す要件も適用されるであろう。 】

`接続^dfn （ `connection^en ） ◎ connection:

~transport~protocolとして~QUICを利用している， 2 つの端点~間の~transport層の接続。 ◎ A transport-layer connection between two endpoints using QUIC as the transport protocol.

`接続~error$ （ `connection error^en ） ◎ connection error:

`~HTTP3接続$全体に影響する~error。 ◎ An error that affects the entire HTTP/3 connection.

`端点^dfn （ `endpoint^en ） ◎ endpoint:

接続の［ `~client$h3, `~server$h3 ］を~~指す総称。 ◎ Either the client or server of the connection.

`~frame^dfn （ `frame^en ） ◎ frame:

~HTTP3における`~stream$上の通信を成す最~小な単位 — その~frame種別に則って構造化された［ ~header, 可変長な~byte列 ］からなる。 ◎ The smallest unit of communication on a stream in HTTP/3, consisting of a header and a variable-length sequence of bytes structured according to the frame type.

“~frame” と呼ばれる~protocol要素は、 この文書, `QUIC-TRANSPORT$r どちらにも存在する。 `QUIC-TRANSPORT$r の~frameが参照される所では、 ~frameの名前に "~QUIC" が前置きされる — 例えば， “~QUIC `CONNECTION_CLOSE^ft ~frame”。 この前置きを伴わない参照は、 `7.2§ にて定義される~frameを指す。 ◎ Protocol elements called "frames" exist in both this document and [QUIC-TRANSPORT]. Where frames from [QUIC-TRANSPORT] are referenced, the frame name will be prefaced with "QUIC". For example, "QUIC CONNECTION_CLOSE frames". References without this preface refer to frames defined in Section 7.2.

`~HTTP3接続@ （ `HTTP/3 connection^en ） ◎ HTTP/3 connection:

~QUIC接続のうち， 折衝された応用~protocolが~HTTP3であるもの。 ◎ A QUIC connection where the negotiated application protocol is HTTP/3.

~peer【 “相手” 】 （ `peer^en ） ◎ peer:

端点。 特定0の端点について論じているとき， ~peerは、 論の首な~subjectの~remoteにある方の端点を指す。 ◎ An endpoint. When discussing a particular endpoint, "peer" refers to the endpoint that is remote to the primary subject of discussion.

【 この訳では、 この用語は利用せず，単に “相手の端点” （ `…'s peer^en ）, “互いの端点” （ `each peer^en ）, “どちらの端点も…”（ `both peers^en ）, 等々と記す。 （結局は、 文脈に応じて，このように訳し分けることになり、 ~peerと端点を使い分けても，さして有用でないので。） 】

`受信器@ （ `receiver^en ） ◎ receiver:

~frameを受信している端点。 ◎ An endpoint that is receiving frames.

【 単に`受信者$（ `recipient^en ）の別名が意図されているようにも思われるが、 はっきりしない。 いずれにせよ、 ~HTTPが定義する`受信者$の概念に包摂され， ~HTTPが`受信者$に課す要件も適用されるであろうが。 】

`送信器@ （ `sender^en ） ◎ sender:

~frameを伝送している端点。 ◎ An endpoint that is transmitting frames.

【 原文の綴りは`送信者$と同じだが、 `受信器$と対を成すので，訳を違えている。 しかしながら、 一部の “送信器” は，`送信者$を意味するかもしれない。 いずれにせよ、 ~HTTPが定義する`送信者$の概念に包摂され， ~HTTPが`送信者$に課す要件も適用されるであろうが。 】

`~server@h3 （ `server^en ） ◎ server:

`~HTTP3接続$を受容する端点。 `~server$h3は、 `要請$を受信して，`応答$を送信する。 ◎ The endpoint that accepts an HTTP/3 connection. Servers receive HTTP requests and send HTTP responses.

【 ~HTTPの`~server$とは別に定義されているが、 その概念に包摂され，~HTTPが`~server$に課す要件も適用されるであろう。 】

`~stream@ （ `QUIC stream^en, 略して `stream^en ） ◎ stream:

~QUIC~transportにより供される［ `一方向$／`双方向$ ］な~byte~stream。 `~HTTP3接続$の中のすべての`~stream$は，~HTTP3~streamと見なせるが、 ~HTTP3の中では，複数の`~stream種別$が定義される。 ◎ A bidirectional or unidirectional bytestream provided by the QUIC transport. All streams within an HTTP/3 connection can be considered "HTTP/3 streams", but multiple stream types are defined within HTTP/3.

`~stream~error$ ◎ stream error:

個々の`~stream$上の応用~levelの~error。 ◎ An application-level error on the individual stream.

`~stream~ID@

【 同じ接続の中の各~streamを一意に識別する整数。 この用語（この訳による追加）は、 原文には明示的な参照が与えられていないが， `QUIC-TRANSPORT$r `2.1＠~QUICv1#section-2.1§ にて定義される。 】

次に挙げる用語は、 `HTTP$r にて定義される ⇒＃ `内容$ `資源$, `~message$, `~UA$, `生成元~server$, `~gateway$, `媒介者$, `~proxy$, `~tunnel$ ◎ The term "content" is defined in Section 6.4 of [HTTP]. ◎ Finally, the terms "resource", "message", "user agent", "origin server", "gateway", "intermediary", "proxy", and "tunnel" are defined in Section 3 of [HTTP].

【 この仕様における用語 `生成元@ は、 `生成元~server$の略記を表す箇所が多い — 文脈に応じて，［ `~URIの生成元＠~HTTPinfra#uri-origin$, `生成元~server$ ］どちらなのか適切に解釈する必要があるが、 明瞭に線引きできず，両義的な箇所もある （ “~URIの生成元~server” のように，明らかに両義的な用法もある）。 】

この文書における~packet図式は、 【~HTTP`~field$ではなく，~frameの】~fieldの［ 順序, ~size ］を~~説明するため， `QUIC-TRANSPORT$r `1.3＠~QUICv1#section-1.3§にて定義される形式を利用する。 ◎ Packet diagrams in this document use the format defined in Section 1.3 of [QUIC-TRANSPORT] to illustrate the order and size of fields.

3.1. ~HTTP3端点の発見-法

~HTTPは、 `権限的$な応答の観念に依拠する — それは、［ `~target~URI$の中で識別された`生成元~server$による`応答~message$ ］が出生した時点（または，~directされた時点）における［ `~target資源$の状態 ］が与えられた下で，［ 当の要請~用に最も適切であるものと決定された応答 ］である。 所与の`~URI$用に`権限的$な`~server$h3を突き止めることは、 `HTTP$r `権限的な~access＠~HTTPinfra#authoritative.access§ にて論じられる。 ◎ HTTP relies on the notion of an authoritative response: a response that has been determined to be the most appropriate response for that request given the state of the target resource at the time of response message origination by (or at the direction of) the origin server identified within the target URI. Locating an authoritative server for an HTTP URI is discussed in Section 4.3 of [HTTP].

"`https$c" ~schemeは、 権限を証明書の所持 — `~client$h3が［ 当の~URIの `authority$p 成分により識別される~host ］用に信用に価すると見なす証明書の所持 — に結付ける。 `~client$h3は、 ~TLS~handshakeにおける~server証明書の受信-時に，［ 当の証明書は、 当の~URIの`生成元~server$に合致するものとして受容-可能である ］ことを — `HTTP$r `https 証明書の検証y＠~HTTPinfra#https.verify§にて述べられる処理nを利用して — 検証yしなければナラナイ。 当の証明書が~URIの`生成元~server$に関して検証yできない場合、 `~client$h3は［ `~server$h3は、 その`生成元$用に`権限的$である ］と見なしてはナラナイ。 ◎ The "https" scheme associates authority with possession of a certificate that the client considers to be trustworthy for the host identified by the authority component of the URI. Upon receiving a server certificate in the TLS handshake, the client MUST verify that the certificate is an acceptable match for the URI's origin server using the process described in Section 4.3.4 of [HTTP]. If the certificate cannot be verified with respect to the URI's origin server, the client MUST NOT consider the server authoritative for that origin.

`~client$h3は、 `https$c ~URIを伴う`資源$への~accessを，次に従って試みてもヨイ： ◎ A client MAY attempt access to a resource with an "https" URI by＼

1. ~host識別子を~IP~addressに解決する。 ◎ resolving the host identifier to an IP address,＼
2. 前段の結果の~addressに指示された~port上へ~QUIC接続を確立する （上で述べたとおり~server証明書の検証を含めて）。 ◎ establishing a QUIC connection to that address on the indicated port (including validation of the server certificate as described above),＼
3. 前段により~secure化された接続~越しに， ~URIを~targetにしている~HTTP3要請`~message$を`~server$h3へ送信する。 ◎ and sending an HTTP/3 request message targeting the URI to the server over that secured connection.＼

他の何らかの仕組みを利用して~HTTP3が選定される場合を除き、 ~TLS~handshakeの間の~ALPN拡張（ `RFC7301$r ）においては，~token "`h3^c" が利用される。 ◎ Unless some other mechanism is used to select HTTP/3, the token "h3" is used in the Application-Layer Protocol Negotiation (ALPN; see [RFC7301]) extension during the TLS handshake.

接続性の問題（例： `blocking^en ~UDP†）は、 ~QUIC接続の確立を失敗させ得る。 この事例では、 `~client$h3は，~TCPに基づく~versionの~HTTPを利用するよう試みるベキである。 【† ~UDPが［何かを阻んでいる／何かにより阻まれている］どちらを意味するのか不明。】 ◎ Connectivity problems (e.g., blocking UDP) can result in a failure to establish a QUIC connection; clients SHOULD attempt to use TCP-based versions of HTTP in this case.

`~server$h3は、 どの~UDP~portで~HTTP3を~serveしてもヨイ — 代替な~serviceの広告は、 常に，明示的な~portを含む。 その場合、 ~URIは［ 明示的な~port, その~schemeに結付けられた既定の~port ］いずれかを包含する。 ◎ Servers MAY serve HTTP/3 on any UDP port; an alternative service advertisement always includes an explicit port, and URIs contain either an explicit port or a default port associated with the scheme.

Alt-Svc: h3=":50781"

3.2. 接続の確立

~HTTP3は、 下層の~transportとして， ~QUIC~version 1 に依拠する。 将来の仕様は、 ~HTTP3における~transportとして， 他の~QUIC~versionの利用を定義してもヨイ。 ◎ HTTP/3 relies on QUIC version 1 as the underlying transport. The use of other QUIC transport versions with HTTP/3 MAY be defined by future specifications.

~QUIC~version 1 は、 その~handshake~protocolとして， ~version 1.3 以上の~TLSを利用する。 ~HTTP3`~client$h3は、［ ~TLS~handshakeの間に`~server$h3への~target~hostを指示する仕組み ］を~supportしなければナラナイ。 当の`~server$h3が~domain名（ `DNS-TERMS$r ）により識別される場合、 `~client$h3は，~SNI （ `~server名~指示^cite（ `Server Name Indication^en ） `RFC6066$r ） ~TLS拡張を送信しなければナラナイ — ~target~hostを指示する代替な仕組みが利用されている場合を除き。 ◎ QUIC version 1 uses TLS version 1.3 or greater as its handshake protocol. HTTP/3 clients MUST support a mechanism to indicate the target host to the server during the TLS handshake. If the server is identified by a domain name ([DNS-TERMS]), clients MUST send the Server Name Indication (SNI; [RFC6066]) TLS extension unless an alternative mechanism to indicate the target host is used.

~QUIC接続は、 `QUIC-TRANSPORT$r にて述べられるとおりに確立される。 ~HTTP3の~supportは、［ 接続を確立する間に， ~TLS~handshakeにおいて~ALPN~token "`h3^c" を選定する ］ことにより指示される。 同じ~handshake内で， 応用~層に属する他の~protocol用の~supportを提供してもヨイ。 ◎ QUIC connections are established as described in [QUIC-TRANSPORT]. During connection establishment, HTTP/3 support is indicated by selecting the ALPN token "h3" in the TLS handshake. Support for other application-layer protocols MAY be offered in the same handshake.

［ 中核~QUIC~protocolに係る接続~levelの~option群 ］が［ 初期~暗号~handshakeにおいて設定される ］間、 ~HTTP3に特有な`設定$群は， `SETTINGS$ft ~frame内で伝達される。 ~QUIC接続が確立されたなら、 両~端点は，［ 各自の`制御~stream$の初期~frameとして， `SETTINGS$ft ~frame ］を送信しなければナラナイ。 ◎ While connection-level options pertaining to the core QUIC protocol are set in the initial crypto handshake, settings specific to HTTP/3 are conveyed in the SETTINGS frame. After the QUIC connection is established, a SETTINGS frame MUST be sent by each endpoint as the initial frame of their respective HTTP control stream.

3.3. 接続の再利用

`~HTTP3接続$は、 複数の要請にまたがって持続的である。 最良な処理能を得るため、 `~client$h3は，［ 次のいずれかの時点までは、 接続を~closeしない ］ことが期待される： ◎ HTTP/3 connections are persistent across multiple requests. For best performance, it is expected that clients will not close connections until＼

• `~server$h3との更なる通信は必要yでないものと決定した （例：利用者が，特定0の~web~pageから どこか他へ~navigateしたとき） ◎ it is determined that no further communication with a server is necessary (for example, when a user navigates away from a particular web page)＼
• `~server$h3から接続が~closeされた ◎ or until the server closes the connection.

`~server$h3への接続が確立されたなら、 この接続を［ ~URIの `authority$p 成分が異なる複数個の要請 ］用に再利用してもヨイ。 `~client$h3は、 既存の接続を新たな`生成元$用に利用するときは， `~server$h3から提示された証明書を検証しなければナラナイ — 新たな`生成元~server$用に， `HTTP$r `証明書の検証＠~HTTPinfra#https.verify§ にて述べられた処理nを利用して。 このことは、 `~client$h3は，~server証明書を — および［ その証明書を検証yするために必要な追加的な情報 ］があれば，それも — 維持する必要があることを含意する — それを行わない`~client$h3は、 追加的な`生成元$用には接続を再利用-可能でないことになる。 ◎ Once a connection to a server endpoint exists, this connection MAY be reused for requests with multiple different URI authority components. To use an existing connection for a new origin, clients MUST validate the certificate presented by the server for the new origin server using the process described in Section 4.3.4 of [HTTP]. This implies that clients will need to retain the server certificate and any additional information needed to verify that certificate; clients that do not do so will be unable to reuse the connection for additional origins.

何らかの理由で，当の証明書は新たな`生成元$に関して受容-可能でない場合、 当の接続を再利用してはナラナイ — 新たな`生成元$用には新たな接続を確立するベキである。 当の証明書を検証yできない理由が［ すでに当の接続に結付けられた他の`生成元$ ］にも適用されるかもしれない場合、 `~client$h3は，［ それらの`生成元$用に~server証明書を検証し直す ］ベキである。 一例として、 ある証明書が［ 失効した／廃止された ］ために，その検証に失敗した場合、 それは，他の`生成元$のうち［ その証明書を権限を確立するために利用したもの ］すべてを無効~化するためにも利用されるかもしれない。 ◎ If the certificate is not acceptable with regard to the new origin for any reason, the connection MUST NOT be reused and a new connection SHOULD be established for the new origin. If the reason the certificate cannot be verified might apply to other origins already associated with the connection, the client SHOULD revalidate the server certificate for those origins. For instance, if validation of a certificate fails because the certificate has expired or been revoked, this might be used to invalidate all other origins for which that certificate was used to establish authority.

`~client$h3は， 所与の ( ~IP~address, ~UDP~port ) に対し、 それらが ある［ ~URI／選定された代替な~service（ `ALTSVC$r ）／環境設定された`~proxy$ ］ — あるいは，これらいずれかの名前を解決した結果 — から導出されたかもしれない所では， 複数個の`~HTTP3接続$を~openするベキでない。 `~client$h3は、 同じ［ ~IP~address, ~UDP~port ］に対し，異なる［ ~transport／~TLS環境設定 ］を利用して，複数個の`~HTTP3接続$を~openしてもヨイが、［ 同じ環境設定を伴う複数個の接続を作成する ］ことは避けるベキである。 ◎ Clients SHOULD NOT open more than one HTTP/3 connection to a given IP address and UDP port, where the IP address and port might be derived from a URI, a selected alternative service ([ALTSVC]), a configured proxy, or name resolution of any of these. A client MAY open multiple HTTP/3 connections to the same IP address and UDP port using different transport or TLS configurations but SHOULD avoid creating multiple connections with the same configuration.

`~server$h3には［ アリな限り長く，~openな`~HTTP3接続$を保守する ］ことが奨励されるが、 必要yな場合は，`遊休中$な接続を終了することも許可される。 どちらかの端点が，`~HTTP3接続$を~closeするものと選んだときは、 当の【！the terminating】端点は， 最初に `GOAWAY$ft ~frameを送信するベキである（`5.2§） — どちらの端点も，［ 以前に送信した~frameが処理されたかどうかを依拠-可能に決定できる ］かつ［ 必要yな残りの~taskがあれば、 それらを上品に［ 完了できる／終了できる ］］よう。 ◎ Servers are encouraged to maintain open HTTP/3 connections for as long as possible but are permitted to terminate idle connections if necessary. When either endpoint chooses to close the HTTP/3 connection, the terminating endpoint SHOULD first send a GOAWAY frame (Section 5.2) so that both endpoints can reliably determine whether previously sent frames have been processed and gracefully complete or terminate any necessary remaining tasks.

`~server$h3は、 特定0の`生成元$ %生成元 に対し，［ `~client$h3が %生成元 用に`~HTTP3接続$を再利用すること ］を望まない場合には、［ 所与の要請に対する応答~内に`状態s~code$ `421$st を送信する ］ことにより［ %生成元 は`権限的$でない ］ことを指示できる — `HTTP$r `誤って~directされた要請の却下-法＠~HTTPsem#routing.reject§を見よ。 ◎ A server that does not wish clients to reuse HTTP/3 connections for a particular origin can indicate that it is not authoritative for a request by sending a 421 (Misdirected Request) status code in response to the request; see Section 7.4 of [HTTP].

4.1. ~HTTPの~message~frame法

`~client$h3は、 `要請~stream$上に`要請$を送信する — それは、 `~client$h3から起動される`双方向~stream$である — `6.1§ を見よ。 `~client$h3は、 所与の`~stream$に送信する要請を 1 個に限らなければナラナイ。 `~server$h3は、 以下に詳細を与えるとおり， 当の要請と同じ`~stream$上で［ 0 個以上の`非最終-応答$, 1 個の`最終-応答$ ］`HTTP$r【！`15＠~HTTPsem#status.codes§】を順に送信する。 ◎ A client sends an HTTP request on a request stream, which is a client-initiated bidirectional QUIC stream; see Section 6.1. A client MUST send only a single request on a given stream. A server sends zero or more interim HTTP responses on the same stream as the request, followed by a single final HTTP response, as detailed below. See Section 15 of [HTTP] for a description of interim and final HTTP responses.

~pushされる応答は、 `~server$h3が起動した`一方向~stream$上に送信される — `6.2.2§を見よ。 `~server$h3は、 標準な応答と同じ方式で［ 0 個以上の`非最終-応答$, 後続する 1 個の`最終-応答$ ］を順に送信する。 ~pushは、 `4.6§にて，より詳細に述べられる。 ◎ Pushed responses are sent on a server-initiated unidirectional QUIC stream; see Section 6.2.2. A server sends zero or more interim HTTP responses, followed by a single final HTTP response, in the same manner as a standard response. Push is described in more detail in Section 4.6.

所与の`~stream$上で受信された［ `要請$のうち 2 個目~以降のもの／ `応答$のうち`最終-応答$に後続するもの ］は、`不正形$として扱わなければナラナイ。 ◎ On a given stream, receipt of multiple requests or receipt of an additional HTTP response following a final HTTP response MUST be treated as malformed.

~HTTP3における 各`~message$（要請／応答）は、 次に挙げるもの `HTTP$r からなる： ◎ An HTTP message (request or response) consists of:

1. `~header節$ ⇒ 1 個の `HEADERS$ft ~frameとして送信される。 これは、当の~messageの`制御~data$も含む。 ◎ the header section, including message control data, sent as a single HEADERS frame,
2. `内容$（省略可能） ⇒ 在るならば，一連の `DATA$ft ~frameとして送信される。 ◎ optionally, the content, if present, sent as a series of DATA frames, and
3. `~trailer節$（省略可能） ⇒ 在るならば， 1 個の `HEADERS$ft ~frameとして送信される。 ◎ optionally, the trailer section, if present, sent as a single HEADERS frame.

【！~header節 `HTTP$r `6.3＠~HTTPinfra#header.fields$】 【！~trailer節 `HTTP$r `6.5＠~HTTPinfra#trailer.fields$】 【！内容 `HTTP$r `6.4＠~HTTPinfra#content§】 ◎ Header and trailer sections are described in Sections 6.3 and 6.5 of [HTTP]; the content is described in Section 6.4 of [HTTP].

妥当でない連列を成す~frameの受領は、 `接続~error$( `H3_FRAME_UNEXPECTED$er ) として扱わなければナラナイ。 特に，次に該当するものは、 妥当でないと見なされる ⇒＃ `HEADERS$ft ~frameより前に来る `DATA$ft ~frame／ `~trailer節$を成す `HEADERS$ft ~frameより後に来る［ `HEADERS$ft ／ `DATA$ft ］~frame ◎ Receipt of an invalid sequence of frames MUST be treated as a connection error of type H3_FRAME_UNEXPECTED. In particular, a DATA frame before any HEADERS frame, or a HEADERS or DATA frame after the trailing HEADERS frame, is considered invalid.＼

他の~frame種別 — とりわけ、未知な~frame種別 — は、 許可されることもあり，当の種別の自前の規則の~subjectになる — `9§を見よ。 ◎ Other frame types, especially unknown frame types, might be permitted subject to their own rules; see Section 9.

`~server$h3は、 `応答~message$を成す一連の~frameの前後や合間に何個でも `PUSH_PROMISE$ft ~frameを送信してもヨイ。 これらの `PUSH_PROMISE$ft ~frameは、 当の応答の一部を成さない — 詳細は`4.6§を見よ。 `PUSH_PROMISE$ft ~frameは、 `~push~stream$上では許可されない — ~pushされた応答のうち `PUSH_PROMISE$ft ~frameを内包するものは、 `接続~error$( `H3_FRAME_UNEXPECTED$er ) として扱わなければナラナイ。 ◎ A server MAY send one or more PUSH_PROMISE frames before, after, or interleaved with the frames of a response message. These PUSH_PROMISE frames are not part of the response; see Section 4.6 for more details. PUSH_PROMISE frames are not permitted on push streams; a pushed response that includes PUSH_PROMISE frames MUST be treated as a connection error of type H3_FRAME_UNEXPECTED.

種別が未知な~frame（`9§） — 予約-済み~frame（`7.2.8§）も含む — は、［ `要請~stream$／`~push~stream$ ］上に， この節に述べられる他の~frameの前後や合間に送信してもヨイ。 ◎ Frames of unknown types (Section 9), including reserved frames (Section 7.2.8) MAY be sent on a request or push stream before, after, or interleaved with other frames described in this section.

［ `HEADERS$ft ／ `PUSH_PROMISE$ft ］~frameは、 ~QPACK`動的~table$に対する更新を参照することもある。 これらの更新は、 当の~message交換の一部を直に成していない間は， 当の`~message$が消費され得る前に［ 受信され, 処理され ］なければならない。 詳細は`4.2§を見よ。 ◎ The HEADERS and PUSH_PROMISE frames might reference updates to the QPACK dynamic table. While these updates are not directly part of the message exchange, they must be received and processed before the message can be consumed. See Section 4.2 for more details.

`転送~符号法$ `HTTP/1.1$r 【！`7＠~HTTPv1#transfer.codings§を見よ】は、 ~HTTP3用には定義されない — `Transfer-Encoding$h ~headerを利用してはナラナイ。 ◎ Transfer codings (see Section 7 of [HTTP/1.1]) are not defined for HTTP/3; the Transfer-Encoding header field MUST NOT be used.

応答は、 複数個の`~message$からなっていてもヨイ — それらのうち最後のものは`最終-応答$, 他すべては`非最終-応答$を成す場合に限り （ `HTTP$r 【！ `1xx$st0 `15.2＠~HTTPsem#status.1xx§】）。 `非最終-応答$は、［ `内容$, `~trailer節$ ］を包含しない。 ◎ A response MAY consist of multiple messages when and only when one or more interim responses (1xx; see Section 15.2 of [HTTP]) precede a final response to the same request. Interim responses do not contain content or trailer sections.

［ `要請$, `応答$ ］の交換は、［ `~client$h3が起動した ある`双方向~stream$ ］を全部的に消費する。 `~client$h3は、 要請を送信した後に，当の`~stream$の送信~部【！for】を~closeしなければナラナイ。 `~client$h3は、 `CONNECT$m ~methodを利用している場合（`4.4§を見よ）を除き，［ 自身による要請に対する応答 ］に依存して`~stream$を~closeしては【！make stream closure】ナラナイ。 `~server$h3は、 `最終-応答$を送信した後に，当の`~stream$の送信~部【！for】を~closeしなければナラナイ。 この時点で、 当の`~QUIC~stream$は，全部的に~closeされる。 ◎ An HTTP request/response exchange fully consumes a client-initiated bidirectional QUIC stream. After sending a request, a client MUST close the stream for sending. Unless using the CONNECT method (see Section 4.4), clients MUST NOT make stream closure dependent on receiving a response to their request. After sending a final response, the server MUST close the stream for sending. At this point, the QUIC stream is fully closed.

`~stream$が~closeされたとき、 これは，最終-~message【`最終-応答$】の終了を指示する。 一部の`~message$は，［ 巨大／際限が無い ］ので、 端点は，部分的な`~message$の処理を — その進捗を為すために十分な~messageを受信したなら — 始めるベキである。 `~server$h3は、 `~client$h3が起動した`~stream$が［ `完全$な応答を供するに十分な~message ］を伴わずに終了した場合には， ~error~code `H3_REQUEST_INCOMPLETE$er で自身の応答~streamを`中止-$するベキである。 ◎ When a stream is closed, this indicates the end of the final HTTP message. Because some messages are large or unbounded, endpoints SHOULD begin processing partial HTTP messages once enough of the message has been received to make progress. If a client-initiated stream terminates without enough of the HTTP message to provide a complete response, the server SHOULD abort its response stream with the error code H3_REQUEST_INCOMPLETE.

`~server$h3は、 `~client$h3から要請~全体を【！送信】受信し終えるに先立って，`完全$な応答を送信できる — 当の応答が［ 当の要請を成す，まだ受信されてない部位 ］に依存しないならば： ◎ A server can send a complete response prior to the client sending an entire request if the response does not depend on any portion of the request that has not been sent and received.＼

• `~server$h3は： ◎ When the server＼

  • 当の要請を成す残りを受信する必要がないときは、 次を順に行ってもヨイ ⇒＃ 当の`要請~stream$の読取りを`中止-$する； `完全$な応答を送信する； 当の`要請~stream$の送信~部を~cleanに~closeする ◎ does not need to receive the remainder of the request, it MAY abort reading the request stream, send a complete response, and cleanly close the sending part of the stream.＼
  • `要請~stream$上の送信を停止するよう，`~client$h3に要請するときは、 ~error~code `H3_NO_ERROR$er を利用するベキである。 ◎ The error code H3_NO_ERROR SHOULD be used when requesting that the client stop sending on the request stream.＼

• `~client$h3は： ◎ Clients＼

  • そのような`完全$な応答を［ 当の要請が中途で終了された結果として，破棄して ］はナラナイ。 `~client$h3は、 常に，どの応答でも — 他の事由により，自身の裁量で — 破棄できるが。 ◎ MUST NOT discard complete responses as a result of having their request terminated abruptly, though clients can always discard responses at their discretion for other reasons.＼
  • `~server$h3が当の要請の読取りを`中止-$しない場合 【すなわち，~error~code `H3_NO_ERROR$er を受信するまでは】、 ~serverからの応答が`完全$であっても，［ 当の要請の`内容$の送信を継続して，`~stream$を通常に~closeする ］ベキである。 ◎ If the server sends a partial or complete response but does not abort reading the request, clients SHOULD continue sending the content of the request and close the stream normally.

4.2. ~HTTP~field

`~message$は、 その~metadataを一連の［ `~field$と呼ばれる，［ ~key, 値 ］からなる~pair 【！`6.3＠~HTTPinfra#header.fields$, `6.5＠~HTTPinfra#trailer.fields$】 ］として運ぶ。 登録-済みな`~field$たちが成す~listは、 `~HTTP~field名~registry＠~IANA-a/http-fields/$cite にて保守される。 ~HTTP2と同様、 ~HTTP3には，［ `~field名$, `Connection$h ~header, `疑似-~header$ ］内に利用する文字に関係する追加的な考慮点がある。 ◎ HTTP messages carry metadata as a series of key-value pairs called "HTTP fields"; see Sections 6.3 and 6.5 of [HTTP]. For a listing of registered HTTP fields, see the "Hypertext Transfer Protocol (HTTP) Field Name Registry" maintained at <https://www.iana.org/assignments/http-fields/>. Like HTTP/2, HTTP/3 has additional considerations related to the use of characters in field names, the Connection header field, and pseudo-header fields.

`~field名$は、 ~ASCII文字の下位集合を包含している文字列である。 `~field名$と`~field値$の特質は、 `HTTP$r `~field名＠~HTTPinfra#fields.names§にて，より詳細に論じられる。 `~field名$は、 符号化するに先立って，それを成す各~文字を小文字に変換しなければナラナイ。 大文字を包含している`~field名$を伴う`~message$【！request or response】は、 `不正形$として扱わなければナラナイ。 ◎ Field names are strings containing a subset of ASCII characters. Properties of HTTP field names and values are discussed in more detail in Section 5.1 of [HTTP]. Characters in field names MUST be converted to lowercase prior to their encoding. A request or response containing uppercase characters in field names MUST be treated as malformed.

~HTTP3は、 接続に特有な`~field$を指示するときに， `Connection$h ~headerを利用しない — この~protocolにおいては、 接続に特有な~metadataは，他の手段により伝達される。 端点は、 ~HTTP3`~field節$内に，接続に特有な`~field$を`生成-$してはナラナイ — そのような`~field$を包含している`~message$は、 `不正形$として扱わなければナラナイ。 ◎ HTTP/3 does not use the Connection header field to indicate connection-specific fields; in this protocol, connection-specific metadata is conveyed by other means. An endpoint MUST NOT generate an HTTP/3 field section containing connection-specific fields; any message containing connection-specific fields MUST be treated as malformed.

これに対する唯一の例外は， `TE$h ~headerであり、 ~HTTP3においては要請~内に在ってもヨイ — 在る場合、 "`trailers^c" 以外の値を包含してはナラナイ。 ◎ The only exception to this is the TE header field, which MAY be present in an HTTP/3 request header; when it is, it MUST NOT contain any value other than "trailers".

~HTTP1x `~message$を~HTTP3へ形式変換している`媒介者$は、 `HTTP$r `Connection§h に論じられたとおり， 接続に特有な~headerを除去しなければナラナイ — さもなければ、 当の`~message$は，他の~HTTP3端点により`不正形$として扱われることになる。 ◎ An intermediary transforming an HTTP/1.x message to HTTP/3 MUST remove connection-specific header fields as discussed in Section 7.6.1 of [HTTP], or their messages will be treated by other HTTP/3 endpoints as malformed.

4.3. ~HTTP制御~data

~HTTP2と同様， ~HTTP3は、 一連の `疑似-~header@ を使役する。 `疑似-~header$の~field名は、 文字 "`:^c" （~ASCII `0x3a^hex ）から始まる。 これらの`疑似-~header$は、 `~message$の`制御~data$ `HTTP$r を伝達する。 【！`6.2＠~HTTPinfra#message.control.data§】 ◎ Like HTTP/2, HTTP/3 employs a series of pseudo-header fields, where the field name begins with the : character (ASCII 0x3a). These pseudo-header fields convey message control data; see Section 6.2 of [HTTP].

`疑似-~header$は、 ~HTTP`~field$ではない。 端点は、 この文書に定義されたもの以外の`疑似-~header$を`生成-$してはナラナイ。 しかしながら、 拡張は，この制約に対する改変を折衝することもできる — `9§を見よ。 ◎ Pseudo-header fields are not HTTP fields. Endpoints MUST NOT generate pseudo-header fields other than those defined in this document. However, an extension could negotiate a modification of this restriction; see Section 9.

`疑似-~header$が妥当になるのは、 それが定義される文脈~内に限られる： ◎ Pseudo-header fields are only valid in the context in which they are defined.＼

• 要請~用に定義された`疑似-~header$は、 応答~内に出現してはナラナイ。 ◎ Pseudo-header fields defined for requests MUST NOT appear in responses;＼
• 応答~用に定義された`疑似-~header$は、 要請~内に出現してはナラナイ。 ◎ pseudo-header fields defined for responses MUST NOT appear in requests.＼
• `疑似-~header$は、 `~trailer節$に出現してはナラナイ。 ◎ Pseudo-header fields MUST NOT appear in trailer sections.＼

端点は、［ 未定義な／妥当でない ］`疑似-~header$を包含する`~message$【！request or response】を`不正形$として扱わなければナラナイ。 ◎ Endpoints MUST treat a request or response that contains undefined or invalid pseudo-header fields as malformed.

すべての`疑似-~header$は、 `~header節$内で，定例の`~header$より前に出現しなければナラナイ。 この条件を満たさない`~message$【！request or response】は、 `不正形$として扱わなければナラナイ。 ◎ All pseudo-header fields MUST appear in the header section before regular header fields. Any request or response that contains a pseudo-header field that appears in a header section after a regular header field MUST be treated as malformed.

4.4. `CONNECT^m ~method

`CONNECT$m ~methodを伴う要請は、 `受信者$が［ `要請~target$【！`request-target$p】により識別される`生成元~server$ ］へ`~tunnel$を確立する。 【！`HTTP$r `9.3.6＠~HTTPsem#CONNECT§】 それは、 首に`~proxy$と伴に利用される — ［ "`https$c" `資源$とヤリトリする目的で， `生成元~server$との~TLS~sessionを確立する ］ために。 ◎ The CONNECT method requests that the recipient establish a tunnel to the destination origin server identified by the request-target; see Section 9.3.6 of [HTTP]. It is primarily used with HTTP proxies to establish a TLS session with an origin server for the purposes of interacting with "https" resources.

`CONNECT$m ~methodは、 ~HTTP1xにおいては［ ~HTTP接続~全体を~remote~hostへの`~tunnel$に変換する ］ために利用される一方で，［ ~HTTP2／~HTTP3 ］においては［ 単独の`~stream$越しに`~tunnel$を確立する ］ために利用される。 ◎ In HTTP/1.x, CONNECT is used to convert an entire HTTP connection into a tunnel to a remote host. In HTTP/2 and HTTP/3, the CONNECT method is used to establish a tunnel over a single stream.

【 この節の以下の記述は、 当の`~proxy$が［ ~clientからの~QUIC接続 ］を［ ~serverへの~TCP接続 ］に切替えている場合を受持つ — ~TCP接続を~QUIC接続に切替えている場合ではなく （それについては、この仕様には言及されていない）。 】

`CONNECT$m 要請は、 次に従って構築しなければナラナイ： ◎ A CONNECT request MUST be constructed as follows:

• `method$ph `疑似-~header$は "`CONNECT^c" に設定する。 ◎ The :method pseudo-header field is set to "CONNECT"
• ［ `scheme$ph, `path$ph ］`疑似-~header$は省略する。 ◎ The :scheme and :path pseudo-header fields are omitted
• `authority$ph `疑似-~header$は、 接続-先の［ ~host, ~port ］を包含する （ `CONNECT$m 要請~用の`要請~target$【！`request-target$p】 `authority-form＠~HTTPv1#p.authority-form$p に等価 — `HTTP$r `~target資源の決定-法＠~HTTPsem#target.resource§を見よ）。 ◎ The :authority pseudo-header field contains the host and port to connect to (equivalent to the authority-form of the request-target of CONNECT requests; see Section 7.1 of [HTTP]).

`要請~stream$は、 転送されることになる~dataを運ぶため， 当の要請の終了まで~openであり続ける。 上に挙げた制約に適合しない`CONNECT$m 要請は、 `不正形$である。 ◎ The request stream remains open at the end of the request to carry the data to be transferred. A CONNECT request that does not conform to these restrictions is malformed.

`CONNECT$m を~supportする`~proxy$は、 `authority$ph `疑似-~header$内に識別された`~server$h3への~TCP接続 （ `RFC0793$r ）を確立する。 この接続が成功裡に確立されたなら、 `~proxy$は， `~client$h3へ `2xx$st0 番台の`状態s~code$を包含している `HEADERS$ft ~frameを送信する。 【！`HTTP$r `15.3＠~HTTPsem#status.2xx§ 】 ◎ A proxy that supports CONNECT establishes a TCP connection ([RFC0793]) to the server identified in the :authority pseudo-header field. Once this connection is successfully established, the proxy sends a HEADERS frame containing a 2xx series status code to the client, as defined in Section 15.3 of [HTTP].

`~stream$上のすべての `DATA$ft ~frameは、 ~TCP接続~上で［ 送信される／受信される ］~dataに対応する。 `~client$h3から送信された `DATA$ft ~frameの~payloadは， `~proxy$により~TCP~serverへ伝送され、 ~TCP~serverから受信された~dataは， `~proxy$により `DATA$ft ~frameの中に梱包される。 ~TCP~segmentの［ ~size, 個数 ］が［ `DATA$ft ~frame／ ~QUIC `STREAM^ft ~frame ］の［ ~size, 個数 ］に予測-可能に対応付けられることは、 保証されないことに注意。 ◎ All DATA frames on the stream correspond to data sent or received on the TCP connection. The payload of any DATA frame sent by the client is transmitted by the proxy to the TCP server; data received from the TCP server is packaged into DATA frames by the proxy. Note that the size and number of TCP segments is not guaranteed to map predictably to the size and number of HTTP DATA or QUIC STREAM frames.

`CONNECT$m ~methodを完了したなら、 当の`~stream$上に送信することが許可されるのは， `DATA$ft ~frameに限られる。 拡張~frameは、 当の拡張の定義により特定的に許可される場合には，利用してもヨイ。 他の既知な~frame種別の受領は、 `接続~error$( `H3_FRAME_UNEXPECTED$er ) として扱わなければナラナイ。 ◎ Once the CONNECT method has completed, only DATA frames are permitted to be sent on the stream. Extension frames MAY be used if specifically permitted by the definition of the extension. Receipt of any other known frame type MUST be treated as a connection error of type H3_FRAME_UNEXPECTED.

~TCP接続は、 どちらの端点からも，~closeできる／され得る。 `~client$h3が`要請~stream$を終了~するとき （すなわち、 当の`~proxy$における受信-`~stream$は， `Data Recvd^i 状態に入った）、 `~proxy$は，［ 自身による~TCP~serverへの接続~上に `FIN^i ~bitを 1 に設定する ］ことになる。 `~proxy$は、［ `FIN^i ~bitが 1 に設定された~packetを受信した ］ときは［ `~client$h3への送信-`~stream$を~closeする ］ことになる。 ~TCP接続は，［ 片~方向だけ~closeされ続けても妥当である ］が［ `~server$h3により拙く取扱われることが多い ］ので、 `~client$h3は，［ `CONNECT$m の~targetから~dataを受信する ］ことを依然として期待している間は［ 送信~用の`~stream$を~closeする ］ベキでない。 ◎ The TCP connection can be closed by either peer. When the client ends the request stream (that is, the receive stream at the proxy enters the "Data Recvd" state), the proxy will set the FIN bit on its connection to the TCP server. When the proxy receives a packet with the FIN bit set, it will close the send stream that it sends to the client. TCP connections that remain half closed in a single direction are not invalid, but are often handled poorly by servers, so clients SHOULD NOT close a stream for sending while they still expect to receive data from the target of the CONNECT.

~TCP接続~errorは、［ `~stream$が中途で終了する ］ことにより通達される。 `~proxy$は、 ~TCP接続における~error — `RST^i ~bitが 1 に設定された~TCP~segmentの受信を含む — があれば， `~stream~error$( `H3_CONNECT_ERROR$er ) として扱う。 ◎ A TCP connection error is signaled by abruptly terminating the stream. A proxy treats any error in the TCP connection, which includes receiving a TCP segment with the RST bit set, as a stream error of type H3_CONNECT_ERROR.

対して，~QUIC接続においては、 `~proxy$は： ◎ Correspondingly,＼

• ［ `~stream$／~QUIC接続 ］で~errorを検出した場合には、 当の~TCP接続を~closeしなければナラナイ。 ◎ if a proxy detects an error with the stream or the QUIC connection, it MUST close the TCP connection.＼

• `~client$h3が［ `~stream$を`~reset$した／ `~stream$からの読取りを`中止-$した ］ことを検出した場合には： ◎ If the proxy detects that the client has reset the stream or aborted reading from the stream,＼

  • 当の~TCP接続を~closeしなければナラナイ。 ◎ it MUST close the TCP connection.＼
  • 当の`~stream$が両~方向とも取消されることを確保するため、 もう一方の方向にも同じ演算を遂行するベキである。 ◎ If the stream is reset or reading is aborted by the client, a proxy SHOULD perform the same operation on the other direction in order to ensure that both directions of the stream are cancelled.＼
• これらの事例すべてにおいて，`~proxy$は、［ `RST^i ~bitが 1 に設定された~TCP~segment ］を — 下層の~TCP実装が それを許可する場合には — 送信するベキである。 ◎ In all these cases, if the underlying TCP implementation permits it, the proxy SHOULD send a TCP segment with the RST bit set.

`CONNECT$m は，任意な`~server$h3への`~tunnel$を作成するので、 `CONNECT$m を~supportする`~proxy$は、 その利用を［ 既知な~portたちが成す集合／ 安全な`要請~target$たちが成す~list ］に制約するベキである — 詳細は、 `HTTP$r `CONNECT§m を見よ。 ◎ Since CONNECT creates a tunnel to an arbitrary server, proxies that support CONNECT SHOULD restrict its use to a set of known ports or a list of safe request targets; see Section 9.3.6 of [HTTP] for more details.

4.5. ~HTTP `Upgrade^h

~HTTP3は、 `HTTP$r の［ `Upgrade$h の仕組み, 【！informational】`状態s~code$ `101$st ］を~supportしない。 【！`Upgrade＠~HTTPsem#field.upgrade§h 】 【！`15.2.2＠~HTTPsem#status.101§ 】 ◎ HTTP/3 does not support the HTTP Upgrade mechanism (Section 7.8 of [HTTP]) or the 101 (Switching Protocols) informational status code (Section 15.2.2 of [HTTP]).

4.6. ~server~push

`~server~push@ は、 `~server$h3が［ 要請, 応答 ］の交換を — `~client$h3が指示された要請を為すものと見越している下で — `~client$h3へ~pushすること（ “ヤリトリ~mode” ）を許可する。 これにより、 ~network利用量と引き換えに，待時間は~~短縮され得る。 ~HTTP3の`~server~push$は、［ `HTTP/2$r `8.2＠~HTTPv2#section-8.2§に述べられるもの ］に類似するが，異なる仕組みを利用する。 ◎ Server push is an interaction mode that permits a server to push a request-response exchange to a client in anticipation of the client making the indicated request. This trades off network usage against a potential latency gain. HTTP/3 server push is similar to what is described in Section 8.2 of [HTTP/2], but it uses different mechanisms.

【 代表的な利用事例として、 ~web~page（~HTML資源）内で利用される様々な下位資源への要請を ~clientが為すものと見越して，~pushするなどが挙げられよう。 】【 `~server~push$を成す［ 要請, 応答 ］は、 別々な~stream上に送信されることに注意 — 要請は，~serverから `PUSH_PROMISE$ft ~frameとして`要請~stream$上に送信される一方で、 応答は，`~push~stream$上に送信される。 】

各`~server~push$には、 `~server$h3により【当の接続の中で】一意な `~push~ID@ がアテガわれる。 `~push~ID$は、 `~HTTP3接続$の存続期間を通して，様々な文脈において当の~pushを指すために利用される。 ◎ Each server push is assigned a unique push ID by the server. The push ID is used to refer to the push in various contexts throughout the lifetime of the HTTP/3 connection.

`~push~ID$空間は、 0 以上`最大~push~ID$以下である。 特に、 `~server$h3は，［ `~client$h3が送信した `MAX_PUSH_ID$ft ~frameを受信するまで ］は~push可能でない。 `~client$h3は、 `MAX_PUSH_ID$ft ~frameを送信して，`~server$h3が~promiseできる~pushの個数を制御する。 `~server$h3は、 `~push~ID$を 0 から連列的に利用するベキである。 ◎ The push ID space begins at zero and ends at a maximum value set by the MAX_PUSH_ID frame. In particular, a server is not able to push until after the client sends a MAX_PUSH_ID frame. A client sends MAX_PUSH_ID frames to control the number of pushes that a server can promise. A server SHOULD use push IDs sequentially, beginning from zero.＼

`~client$h3は、 次のいずれかに該当する場合には，受信した`~push~stream$を `接続~error$( `H3_ID_ERROR$er ) として扱わなければナラナイ ⇒＃ その時点では，まだ `MAX_PUSH_ID$ft ~frameを送信してなかったとき／ それが参照する`~push~ID$は，`最大~push~ID$を超える場合 ◎ A client MUST treat receipt of a push stream as a connection error of type H3_ID_ERROR when no MAX_PUSH_ID frame has been sent or when the stream references a push ID that is greater than the maximum push ID.

`~push~ID$は、［ 当の要請`~message$の`制御~data$と~headerたち ］を運ぶ 1 個以上の `PUSH_PROMISE$ft ~frame内で利用される。 これらの~frameは、 当の~pushを生成した`要請~stream$上に送信される。 これは、［ 当の`~server~push$が `~client要請@ 【`~server~push$を成さない，~clientから起動される “通常の” 要請】 に結付けられること ］を許容する。 同じ`~push~ID$が複数の`要請~stream$上で~promiseされた場合、 それらの要請の（解凍-後における）`~field節$は，次を満たしていなければナラナイ ⇒ ［ 同じ順序で同じ`~field$†を包含する ］かつ［ 各~field†における［ 名前, 値 ］は，どちらも一致する ］ 【†正確には、`~field行l$と思われる】 ◎ The push ID is used in one or more PUSH_PROMISE frames that carry the control data and header fields of the request message. These frames are sent on the request stream that generated the push. This allows the server push to be associated with a client request. When the same push ID is promised on multiple request streams, the decompressed request field sections MUST contain the same fields in the same order, and both the name and the value in each field MUST be identical.

`~push~ID$は、［ その~promiseを最終的に充足する`~push~stream$ ］【の~stream~header】に内包される。 `~push~stream$は、 それが充足する~promiseの`~push~ID$を識別する。 それは、 `4.1§にて述べたとおり，［ ~promiseされた要請に対する応答 ］を包含することになる。 ◎ The push ID is then included with the push stream that ultimately fulfills those promises. The push stream identifies the push ID of the promise that it fulfills, then contains a response to the promised request as described in Section 4.1.

【！finally,】 `~push~ID$は、 `CANCEL_PUSH$ft ~frame内でも利用できる — `7.2.3§を見よ。 `~client$h3は、［ ~promiseされた`資源$を受信したいと望まない ］ことを指示するとき，この~frameを利用する。 `~server$h3は、［ 以前の~promiseを充足するつもりがない ］ことを指示するとき，この~frameを利用する。 ◎ Finally, the push ID can be used in CANCEL_PUSH frames; see Section 7.2.3. Clients use this frame to indicate they do not wish to receive a promised resource. Servers use this frame to indicate they will not be fulfilling a previous promise.

要請には~pushできないものもある。 `~server$h3は、 要請が次に挙げる特質をすべて備えるならば，それを~pushしてもヨイ： ◎ Not all requests can be pushed. A server MAY push requests that have the following properties:

• `~cache可能$である — `HTTP$r `~methodと~caching＠~HTTPsem#cacheable.methods§を見よ ◎ cacheable; see Section 9.2.3 of [HTTP]
• `安全$である `HTTP$r 【！`9.2.1＠~HTTPsem#safe.methods§】 ◎ safe; see Section 9.2.1 of [HTTP]
• `内容$も`~trailer節$も内包しない ◎ does not include request content or a trailer section

`~server$h3は、 `authority$ph `疑似-~header$内に自身が`権限的$な値を内包しなければナラナイ。 `~client$h3は，~pushされた要請に対しては、［ それが指示する`生成元$への接続 ］は検証-済みでない場合には，［ 当の接続~上で，当の`生成元$へ要請を送信する前に行う検証y処理n ］と同じ処理nを遂行しなければナラナイ — `3.3§を見よ。 この検証yに失敗した場合、 `~client$h3は，［ `~server$h3は，当の`生成元$に対し`権限的$である ］と見なしてはナラナイ。 ◎ The server MUST include a value in the :authority pseudo-header field for which the server is authoritative. If the client has not yet validated the connection for the origin indicated by the pushed request, it MUST perform the same verification process it would do before sending a request for that origin on the connection; see Section 3.3. If this verification fails, the client MUST NOT consider the server authoritative for that origin.

~pushされた各~応答には、 1 個以上の`~client要請$が結付けられる： ◎ Each pushed response is associated with one or more client requests.＼

• 当の~pushには、 `要請~stream$のうち［ 当の `PUSH_PROMISE$ft ~frameが受信されたもの ］が結付けられる。 ◎ The push is associated with the request stream on which the PUSH_PROMISE frame was received.＼
• 同じ`~server~push$は、 複数の`要請~stream$上で同じ`~push~ID$を伴う `PUSH_PROMISE$ft ~frameを利用して， 追加的な`~client要請$が結付けられ得る。 ◎ The same server push can be associated with additional client requests using a PUSH_PROMISE frame with the same push ID on multiple request streams.＼
• これらの結付けは，~protocolの運用には影響しないが、 `~UA$は，［ ~pushされた`資源$を利用する方法を裁定するとき ］に それらを考慮してもヨイ。 ◎ These associations do not affect the operation of the protocol, but they MAY be considered by user agents when deciding how to use pushed resources.

【 例えば、 複数の資源が同じ下位~資源を参照していて，それら各~参照ごとに`~server~push$が利用される場合、 複数個の［ それらの各~資源への`~client要請$ ］が結付けられることになろう。 】

`PUSH_PROMISE$ft ~frameの［ 応答を成す ある種の部位t ］に関係がある順序付けは重要である。 `~server$h3は、 `PUSH_PROMISE$ft ~frameを［ この~frameにより~promiseされる応答を参照する［ `HEADERS$ft ／ `DATA$ft ］~frame ］を送信するに先立って，送信するベキである。 これにより、［ `~server$h3により~pushされる`資源$ ］を［ `~client$h3が要請する機会c ］は抑制される。 ◎ Ordering of a PUSH_PROMISE frame in relation to certain parts of the response is important. The server SHOULD send PUSH_PROMISE frames prior to sending HEADERS or DATA frames that reference the promised responses. This reduces the chance that a client requests a resource that will be pushed by the server.

`~push~stream$の~dataは、 並替ngに因り，対応している `PUSH_PROMISE$ft ~frameより前に到着し得る。 `~client$h3が，まだ未知な`~push~ID$を伴う新たな`~push~stream$を受信したとき、［ それに結付けられた`~client要請$, ~pushされた要請の~header ］どちらも未知である。 `~client$h3は、 合致している `PUSH_PROMISE$ft が来る期待の下で， この~stream~dataを~bufferできる。 `~client$h3は、 ~stream~flow制御を利用して，［ `~server$h3が，~pushされる`~stream$に~commitしてよい~data ］の量を制限できる （ `QUIC-TRANSPORT$r `4.1＠~QUICv1#section-4.1§） `~client$h3は、［ 適度な時間~内に，対応している `PUSH_PROMISE$ft ~frameが処理されなかった ］場合には，［ 読取りを`中止-$して，`~push~stream$からすでに読取った~dataを破棄する ］ベキである。 ◎ Due to reordering, push stream data can arrive before the corresponding PUSH_PROMISE frame. When a client receives a new push stream with an as-yet-unknown push ID, both the associated client request and the pushed request header fields are unknown. The client can buffer the stream data in expectation of the matching PUSH_PROMISE. The client can use stream flow control (Section 4.1 of [QUIC-TRANSPORT]) to limit the amount of data a server may commit to the pushed stream. Clients SHOULD abort reading and discard data already read from push streams if no corresponding PUSH_PROMISE frame is processed in a reasonable amount of time.

`~push~stream$上の~dataは、 `~client$h3が~pushを取消した後にも到着し得る。 この事例では、 `~client$h3は， `~error~code$ `H3_REQUEST_CANCELLED$er で当の`~stream$の読取りを`中止-$できる。 これは、 `~server$h3に対し［ 追加的な~dataを転送しないよう依頼する／ 受信しても破棄されることになることを指示する ］。 ◎ Push stream data can also arrive after a client has cancelled a push. In this case, the client can abort reading the stream with an error code of H3_REQUEST_CANCELLED. This asks the server not to transfer additional data and indicates that it will be discarded upon receipt.

`~cache$を実装する`~client$h3は、 ~pushされた応答のうち`~cache可能$なものを （ `HTTP-CACHING$r `~cache内への応答の格納-法＠~HTTPcache#response.cacheability§を見よ ） ~cacheに格納できる。 ~pushされた応答は、 `生成元~server$上で成功裡に検証されたものと見なされる（例： ~pushされた応答を受信した時点に `no-cache$sdir 応答`~cache指令$ `HTTP-CACHING$r【！`5.2.2.4＠~HTTPcache#section-5.2.2.4§】 が在る場合）。 ◎ Pushed responses that are cacheable (see Section 3 of [HTTP-CACHING]) can be stored by the client, if it implements an HTTP cache. Pushed responses are considered successfully validated on the origin server (e.g., if the "no-cache" cache response directive is present; see Section 5.2.2.4 of [HTTP-CACHING]) at the time the pushed response is received.

~pushされた応答が`~cache可能$でない場合、 `~cache$に格納してはナラナイ。 それらは、 応用に別々に可用にしてもヨイ。 ◎ Pushed responses that are not cacheable MUST NOT be stored by any HTTP cache. They MAY be made available to the application separately.

5.1. 遊休中な接続

各~QUIC端点は、 ~handshakeの間に遊休~制限時間を宣言する。 ~QUIC接続が，これより長く `遊休中@ — 受信された~packetが無い~~状態 — であり続けた場合、［ 相手の端点は，接続を~closeした ］ものと見做すことになる。 ~HTTP3実装は、 既存の接続が［ ~QUIC~handshakeの間に折衝された遊休~制限時間† ］より長く`遊休中$になった場合には，［ 新たな要請~用に新たな`~HTTP3接続$を~openする ］必要があり、 遊休~制限時間に近付いている場合には，そうするベキである — `QUIC-TRANSPORT$r `10.1＠~QUICv1#section-10.1§を見よ。 【† 双方の端点が制限時間を宣言した場合，それらの最小になる。】 ◎ Each QUIC endpoint declares an idle timeout during the handshake. If the QUIC connection remains idle (no packets received) for longer than this duration, the peer will assume that the connection has been closed. HTTP/3 implementations will need to open a new HTTP/3 connection for new requests if the existing connection has been idle for longer than the idle timeout negotiated during the QUIC handshake, and they SHOULD do so if approaching the idle timeout; see Section 10.1 of [QUIC-TRANSPORT].

`~client$h3は、［ 要請／`~server~push$ ］用に待機中な応答が在る間は，［ `QUIC-TRANSPORT$r `10.1.2＠~QUICv1#section-10.1.2§にて述べられる ］とおり［ 当の~transportが接続を~openに保つよう要請する ］ことが期待される。 `~client$h3は、［ `~server$h3からの応答を期待しない場合 ］には，［ `遊休中$な接続の制限時間を許容する ］方が［ 不要かもしれない接続を保守する労を費やす ］より選好される。 `~gateway$は、 必要があると見越している下では，接続を保守してもヨイ — `~server$h3へ接続を確立することによる待時間~costを被るより。 `~server$h3は、 接続を能動的に~openに保つベキでない。 ◎ HTTP clients are expected to request that the transport keep connections open while there are responses outstanding for requests or server pushes, as described in Section 10.1.2 of [QUIC-TRANSPORT]. If the client is not expecting a response from the server, allowing an idle connection to time out is preferred over expending effort maintaining a connection that might not be needed. A gateway MAY maintain connections in anticipation of need rather than incur the latency cost of connection establishment to servers. Servers SHOULD NOT actively keep connections open.

5.2. 接続の~shutdown

どちらの端点も、 利用している接続を — それが`遊休中$でないときでも — 停止するものと裁定して， 接続の上品な~closeを起動できる。 端点は、 `GOAWAY$ft ~frameを送信することにより， `~HTTP3接続$の上品な~shutdownを起動する。 `GOAWAY$ft ~frameは、 ある識別子を包含する。 それは、 当の接続における どの範囲の［ 要請／~push ］が［ 処理された, または処理され得る ］かを`受信器$に指示する — ［ `~server$h3／`~client$h3 ］は、 【この識別子として】［ ~clientが起動した`双方向~stream$の`~stream~ID$／ 【（~serverが起動した`~push~stream$の）】`~push~ID$ ］を送信する。 ［ 要請／~push ］のうち，指示された識別子~以上の~IDを伴うものは、 `GOAWAY$ft の`送信器$により却下されることになる（`4.1.1§）。 処理された［ 要請／~push ］が無い場合、 この識別子は 0 でもヨイ。 ◎ Even when a connection is not idle, either endpoint can decide to stop using the connection and initiate a graceful connection close. Endpoints initiate the graceful shutdown of an HTTP/3 connection by sending a GOAWAY frame. The GOAWAY frame contains an identifier that indicates to the receiver the range of requests or pushes that were or might be processed in this connection. The server sends a client-initiated bidirectional stream ID; the client sends a push ID. Requests or pushes with the indicated identifier or greater are rejected (Section 4.1.1) by the sender of the GOAWAY. This identifier MAY be zero if no requests or pushes were processed.

`GOAWAY$ft ~frame内の情報は、［ 当の`~HTTP3接続$の~shutdownに先立って，どの［ 要請／~push ］が受容されたか ］について［ `~client$h3, `~server$h3 ］が合意することを可能化する。 `GOAWAY$ft ~frameの送信に際して，端点は、［ 影響された`~stream$用の~transport状態を片付ける ］ため，［ 要請／~push ］のうち［ 指示された識別子~以上の~IDを伴うもの ］を明示的に取消すベキである（`4.1.1§, `7.2.3§ を見よ）。 端点は、 他の［ 要請／~push ］がさらに到着するに伴い，そうすることを継続するベキである。 ◎ The information in the GOAWAY frame enables a client and server to agree on which requests or pushes were accepted prior to the shutdown of the HTTP/3 connection. Upon sending a GOAWAY frame, the endpoint SHOULD explicitly cancel (see Sections 4.1.1 and 7.2.3) any requests or pushes that have identifiers greater than or equal to the one indicated, in order to clean up transport state for the affected streams. The endpoint SHOULD continue to do so as more requests or pushes arrive.

端点は、 相手の端点から `GOAWAY$ft ~frameを受信して以降は， 当の接続~上で［ 新たな要請を起動しては／ 新たな~pushを~promiseしては ］ナラナイ。 `~client$h3は、 追加的な要請を送信するためとして，新たな接続を確立してもヨイ。 ◎ Endpoints MUST NOT initiate new requests or promise new pushes on the connection after receipt of a GOAWAY frame from the peer. Clients MAY establish a new connection to send additional requests.

一部の［ 要請／~push ］は、 すでに~~通過中にあるかもしれない。 ◎ Some requests or pushes might already be in transit:

• `~client$h3が `GOAWAY$ft ~frameを受信する前に送信した要請は： ◎ ↓

  • その`~stream~ID$が［ `GOAWAY$ft ~frame内に包含された識別子~以上 ］であった場合、 処理されないことになる。 `~client$h3は、 当の要請を異なる~HTTP接続~上で安全に試行し直せる — 試行し直せない場合、 当の要請【！that are in flight when the server closes the connection】は喪失される。 ◎ Upon receipt of a GOAWAY frame, if the client has already sent requests with a stream ID greater than or equal to the identifier contained in the GOAWAY frame, those requests will not be processed. Clients can safely retry unprocessed requests on a different HTTP connection. A client that is unable to retry requests loses all requests that are in flight when the server closes the connection.
  • 他の場合、 処理されたかもしれない — その状態sは、 次のいずれかが生じるまでは，既知にならない ⇒＃ 応答が受信された／ 当の`~stream$が個別に`~reset$された／ 当の要請より低い`~stream~ID$を伴う別の `GOAWAY$ft が受信された／ 接続が終了した ◎ Requests on stream IDs less than the stream ID in a GOAWAY frame from the server might have been processed; their status cannot be known until a response is received, the stream is reset individually, another GOAWAY is received with a lower stream ID than that of the request in question, or the connection terminates.

  `~server$h3は、［ 指示されたもの未満の~IDを伴う`~stream$ ］上の個々の要請のうち，処理しなかったものを却下してもヨイ。 ◎ Servers MAY reject individual requests on streams below the indicated ID if these requests were not processed.

• `~server$h3が `GOAWAY$ft ~frameを受信した場合、 すでに~promiseした~pushのうち［ 当の `GOAWAY$ft ~frameが包含する識別子~以上の`~push~ID$を伴うもの ］は，受容されないことになる。 ◎ If a server receives a GOAWAY frame after having promised pushes with a push ID greater than or equal to the identifier contained in the GOAWAY frame, those pushes will not be accepted.

`~server$h3は， 接続を~closeしつつあることが既知になったときは、 それに気付いた時点で，すぐに — ［ 要請を部分的に処理したか否か ］を［ 相手の端点が知れる ］よう — `GOAWAY$ft ~frameを送信するベキである。 例えば，`~client$h3が `POST$m 要請を［ `~server$h3が~QUIC接続を~closeすると~~同時に送信した ］場合、 ~serverが `GOAWAY$ft ~frameを送信しなかったなら — すなわち、 動作するかもしれなかった要請は，どの`~stream$上のものであったかを指示しなかったなら — ~clientは［ ~serverが，当の要請の処理を開始したかどうか ］を知り得ない。 ◎ Servers SHOULD send a GOAWAY frame when the closing of a connection is known in advance, even if the advance notice is small, so that the remote peer can know whether or not a request has been partially processed. For example, if an HTTP client sends a POST at the same time that a server closes a QUIC connection, the client cannot know if the server started to process that POST request if the server does not send a GOAWAY frame to indicate what streams it might have acted on.

端点は、 【同じ接続~上で】複数個の［ 異なる識別子を指示している `GOAWAY$ft ~frame ］を送信してもヨイが、 それら各~frame内の識別子は， それまでに送信した~frame内の識別子を超えてはナラナイ 【次の段落に述べる “最大~値” を除いて】 — `~client$h3は、 未処理な要請を［ 別の~HTTP接続~上で，すでに試行し直した ］かもしれないので。 受信した `GOAWAY$ft が［ 以前に受信したものを超える識別子 ］を包含している場合、 `接続~error$( `H3_ID_ERROR$er ) として扱わなければナラナイ。 ◎ An endpoint MAY send multiple GOAWAY frames indicating different identifiers, but the identifier in each frame MUST NOT be greater than the identifier in any previous frame, since clients might already have retried unprocessed requests on another HTTP connection. Receiving a GOAWAY containing a larger identifier than previously received MUST be treated as a connection error of type H3_ID_ERROR.

端点は、 接続を上品に~shut-downするよう試みるときは，［ アリな最大~値 （`~server$h3用には ~2_62 − 4 ／ `~client$h3用には ~2_62 − 1 ） に設定された値を伴う `GOAWAY$ft ~frame ］を送信できる。 これは、 相手の端点が新たな［ 要請／~push ］を作成することを停止することを確保する。 当の端点は、 伝送途上にある［ 要請／~push ］が到着するまでの時間を許容した後に，別の `GOAWAY$ft ~frameを — 自身が［ 当の接続の終了~前に，どの［ 要請／~push ］を受容するかもしれないか ］を指示するためとして — 送信できる。 これは、［ 要請を喪失することなく 接続を~cleanに~shut-downできる ］ことを確保する。 ◎ An endpoint that is attempting to gracefully shut down a connection can send a GOAWAY frame with a value set to the maximum possible value (262-4 for servers, 262-1 for clients). This ensures that the peer stops creating new requests or pushes. After allowing time for any in-flight requests or pushes to arrive, the endpoint can send another GOAWAY frame indicating which requests or pushes it might accept before the end of the connection. This ensures that a connection can be cleanly shut down without losing requests.

`~client$h3は、 自身が送信する `GOAWAY$ft 内の `~push~ID^i ~field用の値を より柔軟に選べる。 値 ~2_62 − 1 は、［ `~server$h3は、 すでに~promiseした~pushを充足することを継続できる ］ことを指示する。 それより小さい値は、［ `~client$h3は、［ この値~以上の`~push~ID$を伴う~pushを却下する ］ことになる ］ことを指示する。 `~server$h3と同様に、 `~client$h3は，後続に `GOAWAY$ft ~frameを — それに指定した`~push~ID$が以前に送信した値を超えない限り — 送信してもヨイ。 ◎ A client has more flexibility in the value it chooses for the Push ID field in a GOAWAY that it sends. A value of 262-1 indicates that the server can continue fulfilling pushes that have already been promised. A smaller value indicates the client will reject pushes with push IDs greater than or equal to this value. Like the server, the client MAY send subsequent GOAWAY frames so long as the specified push ID is no greater than any previously sent value.

所与の［ 要請／~push ］が， `GOAWAY$ft の受領により［ 処理されない／受容されない ］（順不同）ことになるものと指示されたときでも、 下層の~transport資源は依然として存在する。 これらの要請を起動した端点は、 ~transport状態を片付けるため，それらを取消せる。 ◎ Even when a GOAWAY indicates that a given request or push will not be processed or accepted upon receipt, the underlying transport resources still exist. The endpoint that initiated these requests can cancel them to clean up transport state.

端点は、 受容した［ 要請, ~push ］すべてを処理したなら，［ 接続が`遊休中$になることを許可できる／ 即時に接続の~closureを起動してもヨイ ］。 端点は、 上品な~shutdownを完了したなら，［ 接続を~closeするときに，`~error~code$ `H3_NO_ERROR$er を利用する ］ベキである。 ◎ Once all accepted requests and pushes have been processed, the endpoint can permit the connection to become idle, or it MAY initiate an immediate closure of the connection. An endpoint that completes a graceful shutdown SHOULD use the H3_NO_ERROR error code when closing the connection.

`~client$h3が`双方向~stream$に可用な~IDすべてを要請たちで消費した場合、 `~server$h3は， `GOAWAY$ft ~frameを送信する必要はない — `~client$h3が更に要請を為すことは可能でないので。 ◎ If a client has consumed all available bidirectional stream IDs with requests, the server need not send a GOAWAY frame, since the client is unable to make further requests.

5.3. 即時な応用 ~closure

~HTTP3実装は、 ~QUIC接続をいつでも即時に~closeできる。 その結果、 ~QUIC `CONNECTION_CLOSE^ft ~frameを送信して， 相手の端点に対し［ 応用~層は、 接続を終了したこと ］を指示することになる。 この~frame内の応用~error~codeは、 相手の端点に対し［ 当の接続は、 なぜ~closeされているか ］を指示する。 ~HTTP3において［ 接続を~closeするとき利用できる`~error~code$ ］については、 `8§を見よ。 ◎ An HTTP/3 implementation can immediately close the QUIC connection at any time. This results in sending a QUIC CONNECTION_CLOSE frame to the peer indicating that the application layer has terminated the connection. The application error code in this frame indicates to the peer why the connection is being closed. See Section 8 for error codes that can be used when closing a connection in HTTP/3.

接続を~closeする前に、［ 一部の要請を試行し直すことを`~client$h3に許容するため ］として， `GOAWAY$ft ~frameを送信してもヨイ。 `GOAWAY$ft ~frameを［ ~QUIC `CONNECTION_CLOSE^ft ~frameと同じ~packet ］内に内包すれば、 それが`~client$h3により受信される機会cは高まる。 ◎ Before closing the connection, a GOAWAY frame MAY be sent to allow the client to retry some requests. Including the GOAWAY frame in the same packet as the QUIC CONNECTION_CLOSE frame improves the chances of the frame being received by clients.

~openな`~stream$は、 明示的に~closeされなかった場合でも， 接続が~closeされたとき暗黙的に~closeされる — `QUIC-TRANSPORT$r `10.2＠~QUICv1#section-10.2§を見よ。 ◎ If there are open streams that have not been explicitly closed, they are implicitly closed when the connection is closed; see Section 10.2 of [QUIC-TRANSPORT].

5.4. ~transportの~closure

~QUIC~transportは、 様々な理由で［ 応用~層に対し，接続が終了されたことを指示する ］こともある。 これは、 次に挙げるいずれに因ることもあろう ⇒＃ 相手の端点による明示的な~closure／ ~transport~levelの~error／ 接続性を中断するような~network~topologyにおける変化 ◎ For various reasons, the QUIC transport could indicate to the application layer that the connection has terminated. This might be due to an explicit closure by the peer, a transport-level error, or a change in network topology that interrupts connectivity.

ある接続が `GOAWAY$ft ~frameを伴わずに終了した場合、 `~client$h3は，［ 自身が一部分でも送信した要請 ］を［ 処理されたかもしれないと見做さなければ ］ナラナイ。 ◎ If a connection terminates without a GOAWAY frame, clients MUST assume that any request that was sent, whether in whole or in part, might have been processed.

6.1. 双方向~stream

`~client$h3が起動した`双方向~stream$は、 どれも［ `要請$, `応答$ ］用に利用される。 `双方向~stream$は、 それ自体で，［ 要請, 対する応答（たち） ］を相関できることを確保する。 これらの`~stream$を指して， `要請~stream@ という。 ◎ All client-initiated bidirectional streams are used for HTTP requests and responses. A bidirectional stream ensures that the response can be readily correlated with the request. These streams are referred to as request streams.

このことは、 `~client$h3からの最初の要請は `~QUIC~stream$ 0 に， 後続な各~要請は `~QUIC~stream$ 4, 8, …等々【 4 の倍数】に生じることを意味する。 これらの`~stream$を~openすることを許可するため、 ~HTTP3`~server$h3は［ 許可される`~stream$の個数 ］および［ 初期~stream~flow制御~窓 ］用に 0 でない最小~値を環境設定するベキである。 並列性を不必要に制限しないよう、 `要請~stream$は，~~同時に 100 個~以上が許可されるベキである。 ◎ This means that the client's first request occurs on QUIC stream 0, with subsequent requests on streams 4, 8, and so on. In order to permit these streams to open, an HTTP/3 server SHOULD configure non-zero minimum values for the number of permitted streams and the initial stream flow-control window. So as to not unnecessarily limit parallelism, at least 100 request streams SHOULD be permitted at a time.

~HTTP3では、 `~server$h3から起動される`双方向~stream$は，利用されない — 拡張は、 そのような`~stream$の利用を定義することもできるが。 `~client$h3は、 そのような拡張が折衝されてない限り， `~server$h3から起動された`双方向~stream$の受領を `接続~error$( `H3_STREAM_CREATION_ERROR$er ) として扱わなければナラナイ。 ◎ HTTP/3 does not use server-initiated bidirectional streams, though an extension could define a use for these streams. Clients MUST treat receipt of a server-initiated bidirectional stream as a connection error of type H3_STREAM_CREATION_ERROR unless such an extension has been negotiated.

6.2. 一方向~stream

`一方向~stream$は、 いずれの方向においても，［ その`~stream種別$により指示される，ある範囲の目的 ］に利用される。 `~stream種別$は、 ~streamの始端にて`可変長な整数$として送信される。 この整数に後続する~dataの形式と構造は、 `~stream種別$により決定される。 【`~stream種別$を指示する~fieldは、`双方向~stream$には定義されていないことに注意。】 ◎ Unidirectional streams, in either direction, are used for a range of purposes. The purpose is indicated by a stream type, which is sent as a variable-length integer at the start of the stream. The format and structure of data that follows this integer is determined by the stream type.

`一方向~stream$の~stream~header {
  `~stream種別$ (i),
}
◎
Unidirectional Stream Header {
  Stream Type (i),
}

この文書においては、 【`一方向~stream$の】`~stream種別$として［ `制御~stream$, `~push~stream$ ］が定義される。 `QPACK$r は、 追加的な`~stream種別$として， 2 種を定義する。 他の`~stream種別$は、 ~HTTP3に対する拡張により定義され得る — 詳細は`9§を見よ。 一部の`~stream種別$は、 予約-済みである（`6.2.3§）。 ◎ Two stream types are defined in this document: control streams (Section 6.2.1) and push streams (Section 6.2.2). [QPACK] defines two additional stream types. Other stream types can be defined by extensions to HTTP/3; see Section 9 for more details. Some stream types are reserved (Section 6.2.3).

`~HTTP3接続$の存続期間の早期~~段階における処理能は、 `一方向~stream$上の~dataの［ 作成, 交換 ］に敏感である。 これらの`~stream$の［ 個数／~flow制御~窓 ］を過度に制約する端点は、 相手の端点が［ 上限に早く到達して，阻まれる ］ようになる機会cを増やすことになる。 特に，実装は、 相手の端点が次を望むこともあると見なすべきである ⇒ 利用することが許可された`一方向~stream$のうち一部において， 予約-済み~streamの挙動を行使する（`6.2.3§）。 ◎ The performance of HTTP/3 connections in the early phase of their lifetime is sensitive to the creation and exchange of data on unidirectional streams. Endpoints that excessively restrict the number of streams or the flow-control window of these streams will increase the chance that the remote peer reaches the limit early and becomes blocked. In particular, implementations should consider that remote peers may wish to exercise reserved stream behavior (Section 6.2.3) with some of the unidirectional streams they are permitted to use.

互いの端点は、 `制御~stream$用に 1 個以上の`一方向~stream$を作成する必要がある。 ~QPACKは、 2 個の`一方向~stream$を追加的に要求する。 他の拡張は、 更なる`~stream$を要求するかもしれない。 したがって、 どちらの端点も【！both clients and servers】，送信する~transport~parameter群は［ 相手の端点が 3 個以上の`一方向~stream$を作成する ］ことを許容しなければナラナイ。 これらの~transport~parameterは、 各`一方向~stream$に対し，［ 1024 ~byte以上の~flow制御~credit ］も供するベキである。 ◎ Each endpoint needs to create at least one unidirectional stream for the HTTP control stream. QPACK requires two additional unidirectional streams, and other extensions might require further streams. Therefore, the transport parameters sent by both clients and servers MUST allow the peer to create at least three unidirectional streams. These transport parameters SHOULD also provide at least 1,024 bytes of flow-control credit to each unidirectional stream.

端点には、［ 相手の端点が、 ~criticalな`一方向~stream$を作成する前に， 初期~creditをすべて消費した場合 ］に［ `一方向~stream$をさらに作成するための追加的な~credit ］を是認することは，要求されないことに注意。 端点は、 最初に［ `制御~stream$, および 義務的な拡張により要求される`一方向~stream$ （~QPACK用の符号化器~stream, 復号器~streamなど） ］を作成してから［ 相手の端点により許容されるとおり，追加的な`~stream$を作成する ］ベキである。 ◎ Note that an endpoint is not required to grant additional credits to create more unidirectional streams if its peer consumes all the initial credits before creating the critical unidirectional streams. Endpoints SHOULD create the HTTP control stream as well as the unidirectional streams required by mandatory extensions (such as the QPACK encoder and decoder streams) first, and then create additional streams as allowed by their peer.

~stream~headerが［ `受信者$が~supportしない`~stream種別$ ］を指示する場合、 その意味論は未知なので， `~stream$を成す残りを消費し得ない。 未知な`~stream種別$の`受信者$は、 当の`~stream$の読取りを`中止-$するか， 流入してくる~dataを更に処理することなく破棄しなければナラナイ。 `受信者$は、 読取りを`中止-$した場合は，［ `~error~code$ `H3_STREAM_CREATION_ERROR$er／ 予約-済み~error~code（`~HTTP3~error~code§） ］を利用するベキである。 `受信者$は、 未知な`~stream種別$を`接続~error$【！of any kind】と見なしてはナラナイ。 ◎ If the stream header indicates a stream type that is not supported by the recipient, the remainder of the stream cannot be consumed as the semantics are unknown. Recipients of unknown stream types MUST either abort reading of the stream or discard incoming data without further processing. If reading is aborted, the recipient SHOULD use the H3_STREAM_CREATION_ERROR error code or a reserved error code (Section 8.1). The recipient MUST NOT consider unknown stream types to be a connection error of any kind.

ある種の`~stream種別$は、 接続~状態に影響し得る。 よって，`受信者$は、 `~stream種別$を読取るに先立って， `一方向~stream$から流入してくる~dataを破棄するベキでない。 ◎ As certain stream types can affect connection state, a recipient SHOULD NOT discard data from incoming unidirectional streams prior to reading the stream type.

実装は、 `~stream種別$を［ 相手の端点が それを~supportするか否か ］を知る前に送信してもヨイ。 しかしながら、 `~stream種別$のうち， 既存の~protocol成分 — ~QPACKや他の拡張も含む — の［ 状態／意味論 ］を改変し得るものは、［ 相手の端点が それを~supportすること ］を知るまで，送信してはナラナイ。 ◎ Implementations MAY send stream types before knowing whether the peer supports them. However, stream types that could modify the state or semantics of existing protocol components, including QPACK or other extensions, MUST NOT be sent until the peer is known to support them.

`送信器$は、 他が指定されない限り， `一方向~stream$を［ ~closeできる／`~reset$できる ］。 `受信器$は、［ ~closeされて／`~reset$されて ］いる`一方向~stream$を，その~stream~headerの `reception^en に先立って追認しなければナラナイ【？】。 ◎ A sender can close or reset a unidirectional stream unless otherwise specified. A receiver MUST tolerate unidirectional streams being closed or reset prior to the reception of the unidirectional stream header.

~push~streamの~stream~header {
  `~stream種別$ (i) = `0x01^hex,
  `~push~ID$ (i),
}
◎
Push Stream Header {
  Stream Type (i) = 0x01,
  Push ID (i),
}

7.1. ~frame~layout

すべての~frameは、 次の形式を伴う： ◎ All frames have the following format:

~HTTP3~frame形式 {
  種別 (i),
  長さ (i),
  ~frame~payload (..),
}
◎
HTTP/3 Frame Format {
  Type (i),
  Length (i),
  Frame Payload (..),
}

各~frameは、 次に挙げる~fieldを含む： ◎ A frame includes the following fields:

`種別^i ◎ Type:

`可変長な整数$ — 当の~frame種別を識別する。 ◎ A variable-length integer that identifies the frame type.

`長さ^i ◎ Length:

`可変長な整数$ — 当の~frame~payloadの長さを~byte数で述べる。 ◎ A variable-length integer that describes the length in bytes of the Frame Payload.

`~frame~payload^i ◎ Frame Payload:

~payload — その意味論は、 `種別^i ~fieldにより決定される。 ◎ A payload, the semantics of which are determined by the Type field.

各~frameの~payloadは、 正確に［ その記述~内に識別される~field 【`種別^i, `長さ^i 以外】 ］を包含しなければナラナイ。 ~frame~payloadが，それらの~field［ より後に追加的な~byte列を包含する／の終端より前に終了する ］場合、 `接続~error$( `H3_FRAME_ERROR$er ) として扱わなければナラナイ。 特に、 冗長な長さ符号化法は，自己-整合なことが検証yされなければナラナイ — `10.8§を見よ。 ◎ Each frame's payload MUST contain exactly the fields identified in its description. A frame payload that contains additional bytes after the identified fields or a frame payload that terminates before the end of the identified fields MUST be treated as a connection error of type H3_FRAME_ERROR. In particular, redundant length encodings MUST be verified to be self-consistent; see Section 10.8.

ある`~stream$が~cleanに終了された時点で， 当の`~stream$上の最後の~frameが切落とされた場合、 `接続~error$( `H3_FRAME_ERROR$er ) として扱わなければナラナイ。 中途で終了された`~stream$は、 ある~frame内の どの地点でも，`~reset$され得る。 ◎ When a stream terminates cleanly, if the last frame on the stream was truncated, this MUST be treated as a connection error of type H3_FRAME_ERROR. Streams that terminate abruptly may be reset at any point in a frame.

7.2. ~frame定義

`DATA$ft ~frame {
  種別 (i) = 0x00,
  長さ (i),
  ~data (..),
}
◎
DATA Frame {
  Type (i) = 0x00,
  Length (i),
  Data (..),
}

`HEADERS$ft ~frame {
  種別 (i) = `0x01^hex,
  長さ (i),
  符号化された`~field節$ (..),
}
◎
HEADERS Frame {
  Type (i) = 0x01,
  Length (i),
  Encoded Field Section (..),
}

`CANCEL_PUSH$ft ~frame {
  種別 (i) = 0x03,
  長さ (i),
  `~push~ID$ (i),
}
◎
CANCEL_PUSH Frame {
  Type (i) = 0x03,
  Length (i),
  Push ID (i),
}

`設定$ {
  識別子 (i),
  値 (i),
}

`SETTINGS$ft ~frame {
  種別 (i) = 0x04,
  長さ (i),
  設定(..) ...,
}
◎
Setting {
  Identifier (i),
  Value (i),
}

SETTINGS Frame {
  Type (i) = 0x04,
  Length (i),
  Setting (..) ...,
}

`PUSH_PROMISE$ft ~frame {
  種別 (i) = 0x05,
  長さ (i),
  `~push~ID$ (i),
  符号化された`~field節$ (..),
}
◎
PUSH_PROMISE Frame {
  Type (i) = 0x05,
  Length (i),
  Push ID (i),
  Encoded Field Section (..),
}

`GOAWAY$ft ~frame {
  種別 (i) = 0x07,
  長さ (i),
  `~stream~ID$または`~push~ID$ (i),
}
◎
GOAWAY Frame {
  Type (i) = 0x07,
  Length (i),
  Stream ID/Push ID (i),
}

`MAX_PUSH_ID$ft ~frame {
  種別 (i) = 0x0d,
  長さ (i),
  `~push~ID$ (i),
}
◎
MAX_PUSH_ID Frame {
  Type (i) = 0x0d,
  Length (i),
  Push ID(i),
}

8.1. ~HTTP3~error~code

以下に挙げる `~error~code@ は、 次に挙げる利用-用に定義される ⇒＃ `~stream$を中途で終了するとき／ `~stream$の読取りを`中止-$するとき／ `~HTTP3接続$を即時に~closeするとき ◎ The following error codes are defined for use when abruptly terminating streams, aborting reading of streams, or immediately closing HTTP/3 connections.

`H3_NO_ERROR@er ( `0x0100^hex )

~errorなし。 これは、 当の［ 接続／`~stream$ ］は~closeされる必要があるが， 通達する~errorは無いときに利用される。 ◎ No error. This is used when the connection or stream needs to be closed, but there is no error to signal.

`H3_GENERAL_PROTOCOL_ERROR@er ( `0x0101^hex )

次のいずれか ⇒＃ 相手の端点は、より特定な`~error~code$に合致しない仕方で~protocol要件に違反した ／ 端点は、より特定な`~error~code$を利用することを辞退した ◎ Peer violated protocol requirements in a way that does not match a more specific error code or endpoint declines to use the more specific error code.

`H3_INTERNAL_ERROR@er ( `0x0102^hex )

~HTTP~stack内に内部~errorが生じた。 ◎ An internal error has occurred in the HTTP stack.

`H3_STREAM_CREATION_ERROR@er ( `0x0103^hex )

端点は、［ 自身が受容しない`~stream$を相手の端点が作成した ］ことを検出した。 ◎ The endpoint detected that its peer created a stream that it will not accept.

`H3_CLOSED_CRITICAL_STREAM@er ( `0x0104^hex )

`~HTTP3接続$により要求される`~stream$が［ ~closeされた／`~reset$された ］。 ◎ A stream required by the HTTP/3 connection was closed or reset.

`H3_FRAME_UNEXPECTED@er ( `0x0105^hex )

次のいずれかに該当する~frameを受信した ⇒＃ 現在の状態において許可されてない／ 現在の`~stream$上で許可されてない ◎ A frame was received that was not permitted in the current state or on the current stream.

`H3_FRAME_ERROR@er ( `0x0106^hex )

次のいずれかに該当する~frameを受信した ⇒＃ ~layout要件を満足していない／ ~sizeが妥当でない ◎ A frame that fails to satisfy layout requirements or with an invalid size was received.

`H3_EXCESSIVE_LOAD@er ( `0x0107^hex )

端点は、［ 相手の端点が［ 過度な負荷を生成しているように見える挙動 ］を呈している ］ことを検出した。 ◎ The endpoint detected that its peer is exhibiting a behavior that might be generating excessive load.

`H3_ID_ERROR@er ( `0x0108^hex )

ある［ `~stream~ID$／`~push~ID$ ］が不正に利用された — 次に該当する場合など ⇒＃ 上限を超過している／ 上限を減らしている／ 再利用されている ◎ A stream ID or push ID was used incorrectly, such as exceeding a limit, reducing a limit, or being reused.

`H3_SETTINGS_ERROR@er ( `0x0109^hex )

端点は、 `SETTINGS$ft ~frameの~payload内に~errorを検出した。 ◎ An endpoint detected an error in the payload of a SETTINGS frame.

`H3_MISSING_SETTINGS@er ( `0x010a^hex )

`制御~stream$における最初の~frameとして， `SETTINGS$ft ~frameが受信されなかった。 ◎ No SETTINGS frame was received at the beginning of the control stream.

`H3_REQUEST_REJECTED@er ( `0x010b^hex )

`~server$h3は、 応用~処理を遂行することなく，要請を却下した。 ◎ A server rejected a request without performing any application processing.

`H3_REQUEST_CANCELLED@er ( `0x010c^hex )

［ 要請, 対する応答（~pushされた応答も含む） ］いずれかが取消された。 ◎ The request or its response (including pushed response) is cancelled.

`H3_REQUEST_INCOMPLETE@er ( `0x010d^hex )

`~client$h3の`~stream$は、 全部的に形成された要請を包含することなく終了された。 ◎ The client's stream terminated without containing a fully formed request.

`H3_MESSAGE_ERROR@er ( `0x010e^hex )

`~message$は`不正形$であり，処理できなかった。 ◎ An HTTP message was malformed and cannot be processed.

`H3_CONNECT_ERROR@er ( `0x010f^hex )

`CONNECT$m 要請に対する応答において確立された~TCP接続は、 ~resetされたか異常に~closeされた。 ◎ The TCP connection established in response to a CONNECT request was reset or abnormally closed.

`H3_VERSION_FALLBACK@er ( `0x0110^hex )

要請された演算は、 ~HTTP3越しには~serveし得ない。 要請した端点【！peer】は、 ~HTTP11越しに試行し直すべきである。 ◎ The requested operation cannot be served over HTTP/3. The peer should retry over HTTP/1.1.

`~error~code$ ~IN { `0x1f^hex ~MUL %N ~PLUS `0x21^hex ； %N は負でない整数 } は、［ 未知な`~error~code$は、 `H3_NO_ERROR$er に等価として扱うものとする要件（`9§） ］を行使するためとして予約される。 実装は， `H3_NO_ERROR$er を送信する所では、 何らかの確率で［ それに代えて，この空間から`~error~code$を選定する ］ベキである。 ◎ Error codes of the format 0x1f * N + 0x21 for non-negative integer values of N are reserved to exercise the requirement that unknown error codes be treated as equivalent to H3_NO_ERROR (Section 9). Implementations SHOULD select an error code from this space with some probability when they would have sent H3_NO_ERROR.

10.1. ~server権限

~HTTP3は、 ~HTTPによる権限の定義に依拠する。 権限の確立-法に対する~securityの考慮点は、 `HTTP$r `権限の確立-法＠~HTTPinfra#establishing.authority§ にて論じられる。 ◎ HTTP/3 relies on the HTTP definition of authority. The security considerations of establishing authority are discussed in Section 17.1 of [HTTP].

10.2. 非同一-~protocol攻撃

［ ~TLS, ~QUIC ］の~handshakeにおける~ALPNの利用は、 応用~層の~byte列が処理される前に，~target応用~protocolを確立する。 これは、 両~端点は［ 相手の端点が同じ~protocolを利用していることについて，強く確約される ］ことを確保する。 ◎ The use of ALPN in the TLS and QUIC handshakes establishes the target application protocol before application-layer bytes are processed. This ensures that endpoints have strong assurances that peers are using the same protocol.

これは、 すべての非同一-~protocol攻撃からの保護を保証するものではない。 `QUIC-TRANSPORT$r `21.5＠~QUICv1#section-21.5§ は、［ 認証された~transportを利用していない端点に対し，要請の偽造を遂行する ］ために，~QUIC~packetの平文を利用できる仕方をいくつか述べる。 ◎ This does not guarantee protection from all cross-protocol attacks. Section 21.5 of [QUIC-TRANSPORT] describes some ways in which the plaintext of QUIC packets can be used to perform request forgery against endpoints that don't use authenticated transports.

10.3. 媒介者~capsule化~攻撃

~HTTP3における~fieldの符号化法は、［ ~HTTPに利用される構文においては妥当でない`~field名$ 【！`HTTP$r `5.1＠~HTTPinfra#fields.names§】 ］の表出を許容する。 `~message$【！request or response】が妥当でない`~field名$を包含している場合、 `不正形$として扱わなければナラナイ。 したがって，`媒介者$は、 妥当でない`~field名$を包含している~HTTP3`~message$【！request or response】を~HTTP11`~message$には翻訳できない。 ◎ The HTTP/3 field encoding allows the expression of names that are not valid field names in the syntax used by HTTP (Section 5.1 of [HTTP]). Requests or responses containing invalid field names MUST be treated as malformed. Therefore, an intermediary cannot translate an HTTP/3 request or response containing an invalid field name into an HTTP/1.1 message.

類似に、 ~HTTP3は，妥当でない`~field値$も~transportし得る。 符号化し得る ほとんどの値は，~fieldの構文解析を改めないが、［ `CR$P （~ASCII `0x0d^hex ）, `LF$P （~ASCII `0x0a^hex ）, ~NULL文字（~ASCII `0x00^hex ） ］は、［ 逐語的に翻訳される場合，攻撃者により悪用される ］かもしれない。 `~message$【！request or response】を成す ある`~field値$が許可されない文字を包含する場合、 当の~messageを`不正形$として扱わなければナラナイ。 妥当な文字は、 `field-content$p ~ABNF規則 `HTTP$r 【！`5.5＠~HTTPinfra#fields.values§】 に定義される。 ◎ Similarly, HTTP/3 can transport field values that are not valid. While most values that can be encoded will not alter field parsing, carriage return (ASCII 0x0d), line feed (ASCII 0x0a), and the null character (ASCII 0x00) might be exploited by an attacker if they are translated verbatim. Any request or response that contains a character not permitted in a field value MUST be treated as malformed. Valid characters are defined by the "field-content" ABNF rule in Section 5.5 of [HTTP].

10.4. ~pushされた応答を~cacheする能

~pushされた応答は、 `~client$h3からの明示的な要請を伴わない — 当の要請は、 `~server$h3により `PUSH_PROMISE$ft ~frame内に供される。 ◎ Pushed responses do not have an explicit request from the client; the request is provided by the server in the PUSH_PROMISE frame.

~pushされた応答に対する~cachingは、［ `Cache-Control$h ~header内の`生成元~server$により供される指導 ］に基づいてアリである。 しかしながら，これは、 単独の`~server$h3が複数の~tenant【 “~~入居者” 】を~hostする場合に課題をもたらし得る。 例えば、 ある`~server$h3は，［ 複数の利用者~それぞれに，自身の~URI空間の小さな部位を提供する ］かもしれない。 ◎ Caching responses that are pushed is possible based on the guidance provided by the origin server in the Cache-Control header field. However, this can cause issues if a single server hosts more than one tenant. For example, a server might offer multiple users each a small portion of its URI space.

複数の~tenantが，同じ`~server$h3上の空間を共有する所では、 当の`~server$h3は，［ 各~tenantが［ 自身が権限を有さない`資源$ ］の`表現$を~push可能でない ］ことを確保しなければナラナイ。 これを施行することに失敗すると、 ある~tenantが［ ~cacheから~serveされることになる，ある`表現$ ］を供して［ `権限的$な~tenantが供する実際の`表現$ ］を上書きすることを許容することになる。 ◎ Where multiple tenants share space on the same server, that server MUST ensure that tenants are not able to push representations of resources that they do not have authority over. Failure to enforce this would allow a tenant to provide a representation that would be served out of cache, overriding the actual representation that the authoritative tenant provides.

`~client$h3には、 ~pushされた応答のうち［ それに対し`生成元~server$は`権限的$でないもの ］を却下することが要求される — `4.6§を見よ。 ◎ Clients are required to reject pushed responses for which an origin server is not authoritative; see Section 4.6.

10.5. ~DoS攻撃に対する考慮点

`~HTTP3接続$は、［ ~HTTP11／~HTTP2 ］接続より多量な演算-資源の~commitmentを~~請求し得る。 ［ ~field圧縮, ~flow制御 ］の利用は、［ より多くの状態を格納するための，資源の~commitment ］に依存する。 これらの特能~用の各`設定$は、［ これらの特能~用の~memory~commitmentが，厳密に ある~~限界に抑えられる ］ことを確保する。 ◎ An HTTP/3 connection can demand a greater commitment of resources to operate than an HTTP/1.1 or HTTP/2 connection. The use of field compression and flow control depend on a commitment of resources for storing a greater amount of state. Settings for these features ensure that memory commitments for these features are strictly bounded.

`PUSH_PROMISE$ft ~frameの個数は、 類似な流儀で拘束される。 `~server~push$を受容する`~client$h3は、 同時に発行される`~push~ID$の個数を制限するベキである。 ◎ The number of PUSH_PROMISE frames is constrained in a similar fashion. A client that accepts server push SHOULD limit the number of push IDs it issues at a time.

処理~容量は、 状態~容量ほど効果的には防護できない。 ◎ Processing capacity cannot be guarded as effectively as state capacity.

未定義な~protocol要素のうち［ 相手の端点に無視するよう要求するもの ］を送信する能は、［ 相手の端点に追加的な処理~時間を費やすよう仕向ける ］ために濫用され得る。 これは、複数の［ 未定義な `SETTINGS$ft ~parameter／ 未知な~frame種別／ 未知な`~stream種別$ ］を設定することにより行われるかもしれない。 しかしながら、 一部の利用 — ［ 解することが任意選択な拡張／ 流通~分析に対する耐性を増やすための~padding ］など — は，まったく正当であることに注意。 ◎ The ability to send undefined protocol elements that the peer is required to ignore can be abused to cause a peer to expend additional processing time. This might be done by setting multiple undefined SETTINGS parameters, unknown frame types, or unknown stream types. Note, however, that some uses are entirely legitimate, such as optional-to-understand extensions and padding to increase resistance to traffic analysis.

`~field節$の圧縮は、 処理n用の資源を浪費する何らかの機会も提供する — 潜在的な濫用についての詳細は、 `QPACK$r `7＠~RFCx/rfc9204#section-7§を見よ。 ◎ Compression of field sections also offers some opportunities to waste processing resources; see Section 7 of [QPACK] for more details on potential abuses.

これらすべての特能 — すなわち、 `~server~push$, 未知な~protocol要素, ~field圧縮 — には、 正当な利用がある。 これらの特能は、［ 不必要／過度 ］に利用されたときに限り，負担になる。 ◎ All these features -- i.e., server push, unknown protocol elements, field compression -- have legitimate uses. These features become a burden only when they are used unnecessarily or to excess.

そのような挙動を監視しない端点は、 自身を~DoS攻撃の~riskに晒すことになる。 実装は、 これらの特能の利用を追跡して，その利用に対し制限sを設定するベキである。 端点は、 不審な活動を`接続~error$( `H3_EXCESSIVE_LOAD$er ) として扱ってもヨイが、 偽陽性は，妥当な［ 接続／要請 ］を妨害する結果になる。 ◎ An endpoint that does not monitor such behavior exposes itself to a risk of denial-of-service attack. Implementations SHOULD track the use of these features and set limits on their use. An endpoint MAY treat activity that is suspicious as a connection error of type H3_EXCESSIVE_LOAD, but false positives will result in disrupting valid connections and requests.

10.6. 圧縮の利用

圧縮は、 秘匿~dataが［ 攻撃者の制御~下にある~dataと同じ文脈で圧縮された場合 ］に，それを回復することを攻撃者に許容し得る。 ~HTTP3は、 `~field節$の圧縮を可能化する（`4.2§）。 以下に挙げる懸念は、 圧縮を行う`内容~符号法$ `HTTP$r【！`8.4.1＠~HTTPsem#content.codings§】 の利用にも適用される。 ◎ Compression can allow an attacker to recover secret data when it is compressed in the same context as data under attacker control. HTTP/3 enables compression of fields (Section 4.2); the following concerns also apply to the use of HTTP compressed content-codings; see Section 8.4.1 of [HTTP].

~webの特性を悪用する攻撃として，圧縮に対しデモ-可能なものがある （例：`BREACH$r ）。 攻撃者は、 複数の要請を — 各自が包含している平文を変えながら — 誘導して，結果の暗号文の長さを観測する — それらのうち，秘匿~dataについての推測が正しいものは、 他より短い長さを露呈する。 ◎ There are demonstrable attacks on compression that exploit the characteristics of the web (e.g., [BREACH]). The attacker induces multiple requests containing varying plaintext, observing the length of the resulting ciphertext in each, which reveals a shorter length when a guess about the secret is correct.

~secure~channel上で通信している実装は、［ 機密的な~data, 攻撃者により制御される~data ］どちらも内包する内容を — 各~data~sourceに別々な圧縮~文脈が利用されない限り — 圧縮してはナラナイ。 ~data~sourceを依拠-可能に決定できない場合、 圧縮を利用してはナラナイ。 ◎ Implementations communicating on a secure channel MUST NOT compress content that includes both confidential and attacker-controlled data unless separate compression contexts are used for each source of data. Compression MUST NOT be used if the source of data cannot be reliably determined.

`~field節$の圧縮に関する更なる考慮点は、 `QPACK$r にて述べられる。 ◎ Further considerations regarding the compression of field sections are described in [QPACK].

10.7. ~paddingと流通~分析

~paddingは、 ~frame内容の正確な~sizeを隠蔽するために利用でき， ~HTTPの中の特定の攻撃を軽減するために供される — 例えば、 圧縮された内容が［ 攻撃者により制御される平文, 秘匿~data ］どちらも内包する所における攻撃 （例：`BREACH$r ）。 ◎ Padding can be used to obscure the exact size of frame content and is provided to mitigate specific attacks within HTTP, for example, attacks where compressed content includes both attacker-controlled plaintext and secret data (e.g., [BREACH]).

~HTTP2は、［ 接続を流通~分析に対する耐性を高める ］ために ［ `PADDING^ft ~frame／ 他の~frame内では `~padding^i ~field ］ 一部の~frame内で `~padding^i ~field を使役する 【`7702$errata（Reported）： ~HTTP2は `PADDING^ft ~frameを定義しない】 。 ~HTTP3は，そのような所では、 ~transport層による~paddingに依拠するか， `7.2.8§, `6.2.3§にて論じた予約-済みな［ ~frame, `~stream種別$ ］を使役する。 これらの~paddingを成す手法は、 次に挙げるものに関して異なる結果を生産する ⇒＃ ~paddingの粒度／ 保護されている情報に関係がある~paddingが どう配列されるか／ ~paddingは~packet喪失の事例にも適用されるかどうか／ 実装が~paddingを どう制御し得るか ◎ Where HTTP/2 employs PADDING frames and Padding fields in other frames to make a connection more resistant to traffic analysis, HTTP/3 can either rely on transport-layer padding or employ the reserved frame and stream types discussed in Sections 7.2.8 and 6.2.3. These methods of padding produce different results in terms of the granularity of padding, how padding is arranged in relation to the information that is being protected, whether padding is applied in the case of packet loss, and how an implementation might control padding.

予約-済み`~stream種別$は、 当の接続が`遊休中$のときでも，［ 送信の流通があるかのような外見を与える ］ために利用され得る。 ~HTTP流通は，急激に増えることが多いので、 そのような流通の外見は，［ 送信される~dataが成す~streamが均一に出現するようにして、 そのような急増の［ 時機／所要時間 ］を隠蔽する ］ために利用され得る。 しかしながら，［ そのような流通であっても，`受信器$により~flow制御される ］ので、［ そのような`~stream$を速やかに排出して，追加的な~flow制御~creditを供する ］ことの失敗は，［ `送信器$が本物の流通を送信する能 ］を制限し得る。 ◎ Reserved stream types can be used to give the appearance of sending traffic even when the connection is idle. Because HTTP traffic often occurs in bursts, apparent traffic can be used to obscure the timing or duration of such bursts, even to the point of appearing to send a constant stream of data. However, as such traffic is still flow controlled by the receiver, a failure to promptly drain such streams and provide additional flow-control credit can limit the sender's ability to send real traffic.

圧縮に依拠する攻撃を軽減するためには、 圧縮を［ 不能化する／制限する ］方が，対抗措置としての~paddingより好ましいかもしれない。 ◎ To mitigate attacks that rely on compression, disabling or limiting compression might be preferable to padding as a countermeasure.

~paddingの利用による結果の保護は、［ 見た目より劣ることが，即時に明白になる ］かもしれない。 冗長な~paddingは、 逆効果にもなり得る。 ~paddingは、 最良でも，［ 攻撃者にとって観測する必要がある~frameの個数を増やす ］ことにより［ 攻撃者が長さ情報を推定することをより困難にする ］ものでしかない。 不正に実装された~padding~schemeは、 容易に打破され得る。 特に， ~random化された~paddingが供する保護は、 その分布が予測-可能な場合，わずかしかない。 類似に，［ ~payloadの~sizeを固定するような~padding ］は、［ ~payloadの~sizeが固定された~sizeの境界を超える ］に伴い，情報を公開する — それは、 攻撃者が平文を制御できる場合には，アリになり得る。 ◎ Use of padding can result in less protection than might seem immediately obvious. Redundant padding could even be counterproductive. At best, padding only makes it more difficult for an attacker to infer length information by increasing the number of frames an attacker has to observe. Incorrectly implemented padding schemes can be easily defeated. In particular, randomized padding with a predictable distribution provides very little protection; similarly, padding payloads to a fixed size exposes information as payload sizes cross the fixed-sized boundary, which could be possible if an attacker can control plaintext.

10.8. ~frameの構文解析

いくつかの~protocol要素は、 入子にされた長さ要素を包含する — 概して，［ `可変長な整数$を包含している明示的な長さ ］を伴う~frameの形で。 これは，用心を怠ると~security~riskの元にもなり得るので、 実装は，［ ~frameの長さが，それが包含する~fieldたちの長さに正確に合致する ］ことを確保しなければナラナイ。 ◎ Several protocol elements contain nested length elements, typically in the form of frames with an explicit length containing variable-length integers. This could pose a security risk to an incautious implementer. An implementation MUST ensure that the length of a frame exactly matches the length of the fields it contains.

10.9. 早期~data

~HTTP3で~0-RTTを利用しているときは、 再現（ `replay^en ）攻撃に晒されるので， `HTTP-REPLAY$r による反-再現~用の軽減策を適用しなければナラナイ。 ~HTTP3に `HTTP-REPLAY$r を適用するとき、［ ~TLS層への参照は，~QUICの中で遂行される~handshakeを指す ］一方で［ 応用~dataへのすべての参照は，`~stream$の内容を指す ］。 ◎ The use of 0-RTT with HTTP/3 creates an exposure to replay attack. The anti-replay mitigations in [HTTP-REPLAY] MUST be applied when using HTTP/3 with 0-RTT. When applying [HTTP-REPLAY] to HTTP/3, references to the TLS layer refer to the handshake performed within QUIC, while all references to application data refer to the contents of streams.

10.10. 移転

ある種の~HTTP実装は、 ~log取りや~access制御の目的で，`~client$h3の~addressを利用する。 ~QUIC`~client$h3の~addressは，接続の間に変化し得るので （加えて、 将来の~versionは，複数~addressの同時な利用を~supportするかもしれない）、 そのような実装は，［ `~client$h3の現在の~address（たち）を，それ（ら）が関連するときには能動的に検索取得する ］か［ 元の~addressが変更され得ることを明示的に受容する ］必要がある。 ◎ Certain HTTP implementations use the client address for logging or access-control purposes. Since a QUIC client's address might change during a connection (and future versions might support simultaneous use of multiple addresses), such implementations will need to either actively retrieve the client's current address or addresses when they are relevant or explicitly accept that the original address might change.

10.11. ~privacyの考慮点

~HTTP3を成す特性のうちいくつかは、 単独の［ `~client$h3／`~server$h3 ］における各~動作を時間~越しに相関する機会を観測者に供する。 これらには、 次が含まれる ⇒＃ 各`設定$の値／ 刺激に対する反応の時機／ 各`設定$により制御される特能の取扱い ◎ Several characteristics of HTTP/3 provide an observer an opportunity to correlate actions of a single client or server over time. These include the value of settings, the timing of reactions to stimulus, and the handling of any features that are controlled by settings.

これらにより［ 挙動において観測-可能な相違 ］が生じる所では、 これらは［ 特定の`~client$h3を指紋収集するための基礎 ］としても利用され得る。 ◎ As far as these create observable differences in behavior, they could be used as a basis for fingerprinting a specific client.

~HTTP3は［ 単独の~QUIC接続を利用する ］ことを選好するが、 それは，［ ある~site上での利用者の活動の相関 ］を許容する。 ［ ある接続を異なる`生成元$用にも再利用する ］ことは、［ それらの`生成元$にまたがる活動の相関 ］を許容する。 ◎ HTTP/3's preference for using a single QUIC connection allows correlation of a user's activity on a site. Reusing connections for different origins allows for correlation of activity across those origins.

~QUICの特能には、 即時な応答を請求するものもある — それらは、 ある端点により［ 相手の端点への待時間を測定する ］ために利用され得る。 このことは、［ ある種の局面において，~privacyに対する含意がある ］かもしれない。 ◎ Several features of QUIC solicit immediate responses and can be used by an endpoint to measure latency to their peer; this might have privacy implications in certain scenarios.

11.1. ~HTTP3識別~文字列の登録

この文書は、 `RFC7301$r にて確立された `~TLS~ALPN~protocol~ID~registry＠~IANA-a/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids$cite 内に，~HTTP3の識別~用として新たな登録を作成する。 ◎ This document creates a new registration for the identification of HTTP/3 in the "TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry established in [RFC7301].

文字列 "`h3^c" は、 ~HTTP3を識別する： ◎ The "h3" string identifies HTTP/3:

• ~protocol ⇒ ~HTTP3 ◎ Protocol: • HTTP/3
• 識別~連列 ⇒ `0x68 0x33^hex （ "`h3^c" ） ◎ Identification Sequence: • 0x68 0x33 ("h3")
• 仕様 ⇒ この文書 ◎ Specification: • This document

11.2. 新たな~registry

この文書にて作成された新たな~registryは、［ `QUIC-TRANSPORT$r `22.1＠~QUICv1#section-22.1§にて文書化された~QUIC登録~施策 ］の下で運用される。 これらの各~registryは，いずれも： ◎ New registries created in this document operate under the QUIC registration policy documented in Section 22.1 of [QUIC-TRANSPORT].＼

• `QUIC-TRANSPORT$r `22.1.1＠~QUICv1#section-22.1.1§ 内に挙げられた共通な~fieldたちが成す集合を含む。 ◎ These registries all include the common set of fields listed in Section 22.1.1 of [QUIC-TRANSPORT].＼

• "`Hypertext Transfer Protocol version 3 (HTTP/3)^en" を冠する見出しの下で収集される。

  【 この訳では、 一律に "~HTTP3…" のみを冠するよう略記する — 引用符も省いた上で。 】

  ◎ These registries are collected under the "Hypertext Transfer Protocol version 3 (HTTP/3)" heading.

• 初期~割振nは： ◎ The initial allocations in these registries are all＼

  • 位置付けとして， `恒久的^i がアテガわれる。 ◎ assigned permanent status and＼
  • 変更~制御者として，~IETFを挙げる。 ◎ list a change controller of the IETF and＼
  • 連絡先として，~HTTP~WG（ ietf-http-wg@w3.org ）を挙げる。 ◎ a contact of the HTTP working group (ietf-http-wg@w3.org).

A.1. ~stream

~HTTP3は、 ~HTTP2より多数の`~stream$（ ~2_62 − 1 個まで）の利用を許可する。 ~stream識別子~空間の枯渇については，どちらも同じ考慮点が適用されるが、 当の空間は ずっと広く，~QUICにおける他の上限 — 接続~flow制御~窓に対する上限など — の方が先に達する見込みが高い。 ◎ HTTP/3 permits use of a larger number of streams (262-1) than HTTP/2. The same considerations about exhaustion of stream identifier space apply, though the space is significantly larger such that it is likely that other limits in QUIC are reached first, such as the limit on the connection flow-control window.

~HTTP3における`~stream$の同時並行性は、 ~HTTP2とは対照的に，~QUICにより管理される。 ~QUICは、［ すべての~dataが受信され， 送信した~dataが相手の端点により承認された ］とき，`~stream$は~closeされたものと見なす。 ~HTTP2は、［ ~transportに， `END_STREAM^i ~bitを包含している~frameが~commitされた ］とき，~streamは~closeされたものと見なす。 その結果、 ~streamは，等価な交換に対し~HTTP2より長期間 “作動中” にあり続けれる。 ~HTTP3`~server$h3は、 ~HTTP2に等価な同時並行性を達成するために， より多数の同時並行な［ `~client$h3から起動される`双方向~stream$ ］を許可することを — 期待される用法~patternに依存して — 選ぶかもしれない。 ◎ In contrast to HTTP/2, stream concurrency in HTTP/3 is managed by QUIC. QUIC considers a stream closed when all data has been received and sent data has been acknowledged by the peer. HTTP/2 considers a stream closed when the frame containing the END_STREAM bit has been committed to the transport. As a result, the stream for an equivalent exchange could remain "active" for a longer period of time. HTTP/3 servers might choose to permit a larger number of concurrent client-initiated bidirectional streams to achieve equivalent concurrency to HTTP/2, depending on the expected usage patterns.

~HTTP2においては、 ~flow制御の~subjectになるのは`~message$【！request or response】の`内容$【！bodies】（ `DATA$ft ~frameの~payload）に限られる。 ~HTTP3においては、 すべての~HTTP3~frameが`~QUIC~stream$上に送信されるので， すべての`~stream$上の すべての~frameが~flow制御される。 ◎ In HTTP/2, only request and response bodies (the frame payload of DATA frames) are subject to flow control. All HTTP/3 frames are sent on QUIC streams, so all frames on all streams are flow controlled in HTTP/3.

`一方向~stream$の`~stream種別$は，【`~push~stream$の】他にも在るので、 ~HTTP3は，［ 同時並行な`一方向~stream$の個数のみに依拠して， 同時並行な伝送途上にある~pushの個数を制御する ］ことはない。 代わりに，~HTTP3`~client$h3は、 `MAX_PUSH_ID$ft ~frameを利用して， ~HTTP3`~server$h3から受信される~pushの個数を制御する。 ◎ Due to the presence of other unidirectional stream types, HTTP/3 does not rely exclusively on the number of concurrent unidirectional streams to control the number of concurrent in-flight pushes. Instead, HTTP/3 clients use the MAX_PUSH_ID frame to control the number of pushes received from an HTTP/3 server.

A.2. ~HTTP~frame種別

~HTTP2における~frame法を成す概念のうち多くは、 ~QUIC上では省ける — 当の~transportが それらを処するので。 ~frameは，すでに`~stream$上にあるので、 ~frameの~stream番号は，省略できる。 ~frameは，多重化を阻まないので （~QUICの多重化は、この層より下で生じる）、 `variable-maximum-length^en【？】 な~packet用の~supportは，除去できる。 ~streamの終了nは，~QUICにより取扱われるので、 `END_STREAM^i ~flagは，要求されない。 これにより、［ 汎用な~frame~layoutから `~flag群^i ~fieldを除去する ］ことが許可される。 ◎ Many framing concepts from HTTP/2 can be elided on QUIC, because the transport deals with them. Because frames are already on a stream, they can omit the stream number. Because frames do not block multiplexing (QUIC's multiplexing occurs below this layer), the support for variable-maximum-length packets can be removed. Because stream termination is handled by QUIC, an END_STREAM flag is not required. This permits the removal of the Flags field from the generic frame layout.

~frame~payloadは、 `HTTP/2$r から広く取り入れられた。 しかしながら、 ~QUICは，~HTTP2にも在る多くの特能（例：~flow制御）を含む — それらは、 ~HTTP3による~HTTP対応付けに実装し直されることはない。 結果として、 ~HTTP2~frame種別のうち いくつかは，~HTTP3には要求されない。 ~HTTP2により定義された~frameが もはや利用されない所では、 ~HTTP2実装と~HTTP3実装の間の~port能を最大~化するため， 当の~frame~IDは予約-済みにされる。 しかしながら、 同じ~frame種別が どちらの対応付けにも出現するとしても，互いの意味論は一致しない。 ◎ Frame payloads are largely drawn from [HTTP/2]. However, QUIC includes many features (e.g., flow control) that are also present in HTTP/2. In these cases, the HTTP mapping does not re-implement them. As a result, several HTTP/2 frame types are not required in HTTP/3. Where an HTTP/2-defined frame is no longer used, the frame ID has been reserved in order to maximize portability between HTTP/2 and HTTP/3 implementations. However, even frame types that appear in both mappings do not have identical semantics.

多くの相違点は、 ~HTTP2は［ すべての`~stream$にまたがる，~frameどうしの絶対的な順序付け ］を供する一方で，~QUICは［ これを各`~stream$に限り保証すること ］を供する事実から発生する。 結果として、 ある~frame種別が［ 異なる`~stream$からの~frameであっても、 送信された順序で受信されることになる ］とすることを前提にした場合、 ~HTTP3は，それらを非互換化することになる。 ◎ Many of the differences arise from the fact that HTTP/2 provides an absolute ordering between frames across all streams, while QUIC provides this guarantee on each stream only. As a result, if a frame type makes assumptions that frames from different streams will still be received in the order sent, HTTP/3 will break them.

以下では、［ ~HTTP2用の特能を~HTTP3に順応する いくつかの例 ］および［ ~HTTP2拡張を~HTTP3に変換している拡張~frameの実装者 ］向けの一般的な指導を述べる。 ◎ Some examples of feature adaptations are described below, as well as general guidance to extension frame implementors converting an HTTP/2 extension to HTTP/3.

A.3. ~HTTP2用の設定~parameter

~HTTP2からの重要な相違は、 その`設定$群が［ `制御~stream$の最初の~frameとして一度しか送信されず， それ以降は変更し得ない ］ことにある。 これは、 変更の同期法をめぐる多くの際どい事例を排する。 ◎ An important difference from HTTP/2 is that settings are sent once, as the first frame of the control stream, and thereafter cannot change. This eliminates many corner cases around synchronization of changes.

~HTTP2が`SETTINGS$ft ~frameを介して指定する ~transport~levelの~optionのうち一部は、 ~HTTP3においては，~QUIC~transport~parameterにより取って代わられる。 ~HTTP~levelの設定のうち，~HTTP3において維持されるものは、 ~HTTP2におけるものと同じ値をとる。 取って代わられた`設定$は、 予約-済みであり，それらの受領は~errorになる。 ［ 維持される値, 予約-済みな値 ］の論点は、 `7.2.4.1§を見よ。 ◎ Some transport-level options that HTTP/2 specifies via the SETTINGS frame are superseded by QUIC transport parameters in HTTP/3. The HTTP-level setting that is retained in HTTP/3 has the same value as in HTTP/2. The superseded settings are reserved, and their receipt is an error. See Section 7.2.4.1 for discussion of both the retained and reserved values.

各~HTTP2 `SETTINGS$ft ~parameterが どう対応付けられるかを以下に挙げる： ◎ Below is a listing of how each HTTP/2 SETTINGS parameter is mapped:

`SETTINGS_HEADER_TABLE_SIZE^sp ( `0x01^hex )

`QPACK$r を見よ。 ◎ See [QPACK].

`SETTINGS_ENABLE_PUSH^sp ( `0x02^hex )

これは、 `MAX_PUSH_ID$ft ~frameへの支持を受けて，除去された。 それは、 `~server~push$に もっと細かい制御を供する。 ~HTTP3の `SETTINGS$ft ~frame内で識別子 `0x02^hex （ `SETTINGS_ENABLE_PUSH^sp ~parameterに対応する） を伴う`設定$を指定することは、 ~errorである。 ◎ This is removed in favor of the MAX_PUSH_ID frame, which provides a more granular control over server push. Specifying a setting with the identifier 0x02 (corresponding to the SETTINGS_ENABLE_PUSH parameter) in the HTTP/3 SETTINGS frame is an error.

`SETTINGS_MAX_CONCURRENT_STREAMS^sp ( `0x03^hex )

~QUICは、 その~flow制御~logicの一部として， ~openな`~stream~ID$の最~大を制御する。 ~HTTP3の `SETTINGS$ft ~frame内で識別子 `0x03^hex （ `SETTINGS_MAX_CONCURRENT_STREAMS^sp ~parameterに対応する） を伴う`設定$を指定することは、 ~errorである。 ◎ QUIC controls the largest open stream ID as part of its flow-control logic. Specifying a setting with the identifier 0x03 (corresponding to the SETTINGS_MAX_CONCURRENT_STREAMS parameter) in the HTTP/3 SETTINGS frame is an error.

`SETTINGS_INITIAL_WINDOW_SIZE^sp ( `0x04^hex )

~QUICでは、 初期~transport~handshakeにおいて，［ `~stream$, 接続 ］両者の~flow制御~窓~sizeを指定することが要求される。 ~HTTP3の `SETTINGS$ft ~frame内で識別子 `0x04^hex （ `SETTINGS_INITIAL_WINDOW_SIZE^sp ~parameterに対応する） を伴う`設定$を指定することは、 ~errorである。 ◎ QUIC requires both stream and connection flow-control window sizes to be specified in the initial transport handshake. Specifying a setting with the identifier 0x04 (corresponding to the SETTINGS_INITIAL_WINDOW_SIZE parameter) in the HTTP/3 SETTINGS frame is an error.

`SETTINGS_MAX_FRAME_SIZE^sp ( `0x05^hex )

~HTTP3においては、 この`設定$に等価なものは無い。 ~HTTP3の `SETTINGS$ft ~frame内で識別子 `0x05^hex （ `SETTINGS_MAX_FRAME_SIZE^sp ~parameterに対応する） を伴う`設定$を指定することは、 ~errorである。 ◎ This setting has no equivalent in HTTP/3. Specifying a setting with the identifier 0x05 (corresponding to the SETTINGS_MAX_FRAME_SIZE parameter) in the HTTP/3 SETTINGS frame is an error.

`SETTINGS_MAX_HEADER_LIST_SIZE^sp ( `0x06^hex )

この`設定~識別子$は、 `SETTINGS_MAX_FIELD_SECTION_SIZE$sp に改称された。 ◎ This setting identifier has been renamed SETTINGS_MAX_FIELD_SECTION_SIZE.

~HTTP3においては、 各 `設定~値$は — ~HTTP2における固定長な 32 ~bitの~fieldではなく — `可変長な整数@ （ ［ 6 ~bit／ 14 ~bit／ 30 ~bit／ 62 ~bit ］いずれか） になる 【`参照＠~QUICv1#integer-encoding$】。 この符号化法が生産する結果は，より短くなることが多いが、 32 ~bit空間を全部的に利用する`設定$が生産する結果は，より長くなり得る。 ~HTTP2から~portされた`設定$群は、［ より効率的に符号化するため，それらの値を 30 ~bitに制限する一方で、 31 ~bit以上が要求される場合は， 62 ~bit空間を用立てる ］よう定義し直すことを選ぶかもしれない。 ◎ In HTTP/3, setting values are variable-length integers (6, 14, 30, or 62 bits long) rather than fixed-length 32-bit fields as in HTTP/2. This will often produce a shorter encoding, but can produce a longer encoding for settings that use the full 32-bit space. Settings ported from HTTP/2 might choose to redefine their value to limit it to 30 bits for more efficient encoding or to make use of the 62-bit space if more than 30 bits are required.

各`設定$は、 ~HTTP2用と~HTTP3用に別々に定義される必要がある。 単純にするため、 `HTTP/2$r にて定義される各`設定$の~IDは，予約-済みにされる。 ~HTTP3における`設定$の識別子~空間は，ずっと広いので（ 16 ~bit → 62 ~bit ）、 多くの~HTTP3`設定$には，等価な~HTTP2符号点は無いことに注意。 `11.2.2§を見よ。 ◎ Settings need to be defined separately for HTTP/2 and HTTP/3. The IDs of settings defined in [HTTP/2] have been reserved for simplicity. Note that the settings identifier space in HTTP/3 is substantially larger (62 bits versus 16 bits), so many HTTP/3 settings have no equivalent HTTP/2 code point. See Section 11.2.2.

`~QUIC~stream$は、 順序通りに到着しないかもしれない — 端点には、［ 相手の端点の`設定$群が到着するまで待機せずに，他の`~stream$に応答する ］ことを勧める。 `7.2.4.2§を見よ。 ◎ As QUIC streams might arrive out of order, endpoints are advised not to wait for the peers' settings to arrive before responding to other streams. See Section 7.2.4.2.

A.4. ~HTTP2~error~code

~QUICには、 ~HTTP2が供するものと同じ［ “~stream~error”, “接続~error” ］の概念がある。 しかしながら， ~HTTP2と~HTTP3の相違点から、 `~error~code$は，これらの~version間で直に~port可能でない。 ◎ QUIC has the same concepts of "stream" and "connection" errors that HTTP/2 provides. However, the differences between HTTP/2 and HTTP/3 mean that error codes are not directly portable between versions.

`HTTP/2$r `7＠~HTTPv2#section-7§にて定義される ~HTTP2用の各種~error~codeは、 次に従って，~HTTP3用の`~error~code$へ論理的に対応付けられる： ◎ The HTTP/2 error codes defined in Section 7 of [HTTP/2] logically map to the HTTP/3 error codes as follows:

`NO_ERROR^er ( `0x00^hex )

`H3_NO_ERROR$er に対応付けられる。 ◎ H3_NO_ERROR in Section 8.1.

`PROTOCOL_ERROR^er ( `0x01^hex )

`H3_GENERAL_PROTOCOL_ERROR$er に対応付けられる — ただし、 より特定な`~error~code$が定義される事例は除く。 そのような事例は、［ `H3_FRAME_UNEXPECTED$er, `H3_MESSAGE_ERROR$er, `H3_CLOSED_CRITICAL_STREAM$er ］を含む。 ◎ This is mapped to H3_GENERAL_PROTOCOL_ERROR except in cases where more specific error codes have been defined. Such cases include H3_FRAME_UNEXPECTED, H3_MESSAGE_ERROR, and H3_CLOSED_CRITICAL_STREAM defined in Section 8.1.

`INTERNAL_ERROR^er ( `0x02^hex )

`H3_INTERNAL_ERROR$er に対応付けられる。 ◎ H3_INTERNAL_ERROR in Section 8.1.

`FLOW_CONTROL_ERROR^er ( `0x03^hex )

適用-可能でない — ~QUICが，~flow制御を取扱うので。 ◎ Not applicable, since QUIC handles flow control.

`SETTINGS_TIMEOUT^er ( `0x04^hex )

適用-可能でない — `SETTINGS$ft の承認は定義されないので。 ◎ Not applicable, since no acknowledgment of SETTINGS is defined.

`STREAM_CLOSED^er ( `0x05^hex )

適用-可能でない — ~QUICが，~stream管理を取扱うので。 ◎ Not applicable, since QUIC handles stream management.

`FRAME_SIZE_ERROR^er ( `0x06^hex )

`H3_FRAME_ERROR$er に対応付けられる。 ◎ H3_FRAME_ERROR error code defined in Section 8.1.

`REFUSED_STREAM^er ( `0x07^hex )

要請は処理されなかったことを指示するときは、 `H3_REQUEST_REJECTED$er が利用される。 他の場合、 適用-可能でない — ~QUICが，~stream管理を取扱うので。 ◎ H3_REQUEST_REJECTED (in Section 8.1) is used to indicate that a request was not processed. Otherwise, not applicable because QUIC handles stream management.

`CANCEL^er ( `0x08^hex )

`H3_REQUEST_CANCELLED$er に対応付けられる。 ◎ H3_REQUEST_CANCELLED in Section 8.1.

`COMPRESSION_ERROR^er ( `0x09^hex )

`QPACK$r にて複数の~error~codeが定義される。 ◎ Multiple error codes are defined in [QPACK].

`CONNECT_ERROR^er ( `0x0a^hex )

`H3_CONNECT_ERROR$er に対応付けられる。 ◎ H3_CONNECT_ERROR in Section 8.1.

`ENHANCE_YOUR_CALM^er ( `0x0b^hex )

`H3_EXCESSIVE_LOAD$er に対応付けられる。 ◎ H3_EXCESSIVE_LOAD in Section 8.1.

`INADEQUATE_SECURITY^er ( `0x0c^hex )

適用-可能でない — ~QUICが［ すべての接続に対し，不足ない~securityを供する ］ものと見做されるので。 ◎ Not applicable, since QUIC is assumed to provide sufficient security on all connections.

`HTTP_1_1_REQUIRED^er ( `0x0d^hex )

`H3_VERSION_FALLBACK$er に対応付けられる。 ◎ H3_VERSION_FALLBACK in Section 8.1.

~error~codeは、 ~HTTP2用, ~HTTP3用に別々に定義される必要がある。 `11.2.3§を見よ。 ◎ Error codes need to be defined for HTTP/2 and HTTP/3 separately. See Section 11.2.3.