http3-ja.html

<!DOCTYPE html><html lang="ja"><head><meta charset="utf-8">
<title>RFC 9114 — HTTP/3 （日本語訳）</title>

<link rel="stylesheet" href="common.css" type="text/css">
<link rel="stylesheet" href="http-common.css" type="text/css">
<style>
.settings-parameter,
.frame-type,
.error-code {
	font-family: sans-serif0, sans-serif;
	color: var(--K-color);
}

.frame-diagram {
	margin: 0;
}

.frame-diagram > span[lang="en"] {
	white-space: pre;
}
</style>


<script src="common0.js"></script>
<script src="http-common.js"></script>
<script src="common1.js" async></script>

<script>

Object.assign(source_data.st_phrase, {
	'431': 'Request Header Fields Too Large',
});

</script>

<script type="text/plain" id="_source_data">

●●options
spec_title:HTTP/3
	spec_date:2022-06-06
trans_update:2023-12-27
source_checked:220600
page_state_key:HTTP
original_url:https://httpwg.org/specs/rfc9114.html
abbr_url:HTTPv3
spec_status:IETFPR
no_original_dfn:true
ref_rfc:true
trans_1st_pub:2022-10-02

●●class_map
ft:frame-type
er:error-code
hex:hex-value
sp:settings-parameter

●●tag_map
ft:code
er:code
hex:span
sp:code

●●original_id_map

●●mdn_urls

●●link_map

st.431:~RFC6585#status-431
p.start-line:~HTTPv1#p.start-line

h.Alt-Svc:~RFCx/rfc7838#section-3

ph.method:#ph-method
ph.scheme:#ph-scheme
ph.authority:#ph-authority
ph.path:#ph-path
ph.status:#ph-status


er.H3_CLOSED_CRITICAL_STREAM:#H3_CLOSED_CRITICAL_STREAM
er.H3_CONNECT_ERROR:#H3_CONNECT_ERROR
er.H3_EXCESSIVE_LOAD:#H3_EXCESSIVE_LOAD
er.H3_FRAME_ERROR:#H3_FRAME_ERROR
er.H3_FRAME_UNEXPECTED:#H3_FRAME_UNEXPECTED
er.H3_GENERAL_PROTOCOL_ERROR:#H3_GENERAL_PROTOCOL_ERROR
er.H3_ID_ERROR:#H3_ID_ERROR
er.H3_INTERNAL_ERROR:#H3_INTERNAL_ERROR
er.H3_MESSAGE_ERROR:#H3_MESSAGE_ERROR
er.H3_MISSING_SETTINGS:#H3_MISSING_SETTINGS
er.H3_NO_ERROR:#H3_NO_ERROR
er.H3_REQUEST_CANCELLED:#H3_REQUEST_CANCELLED
er.H3_REQUEST_INCOMPLETE:#H3_REQUEST_INCOMPLETE
er.H3_REQUEST_REJECTED:#H3_REQUEST_REJECTED
er.H3_SETTINGS_ERROR:#H3_SETTINGS_ERROR
er.H3_STREAM_CREATION_ERROR:#H3_STREAM_CREATION_ERROR
er.H3_VERSION_FALLBACK:#H3_VERSION_FALLBACK

sp.SETTINGS_MAX_FIELD_SECTION_SIZE:#SETTINGS_MAX_FIELD_SECTION_SIZE

ft.CANCEL_PUSH:#frame-cancel-push
ft.DATA:#frame-data
ft.GOAWAY:#frame-goaway
ft.HEADERS:#frame-headers
ft.HTTP Framing Layer:#http-framing-layer
ft.MAX_PUSH_ID:#frame-max-push-id
ft.PUSH_PROMISE:#frame-push-promise
ft.SETTINGS:#frame-settings

sdir.no-cache:~HTTPcache#cache-response-directive.no-cache

	●用語
h3.~client:#h3-client
h3.~server:#h3-server
受信器:#h3-receiver
送信器:#h3-sender
中止-:#abort
~HTTP3接続:#h3-connection
~stream:#quic-stream
~QUIC~stream:#quic-stream
~stream~ID:#quic-stream-id
一方向~stream:#quic-unidirectional-stream
一方向:#quic-unidirectional-stream
双方向~stream:#quic-bidirectional-stream
双方向:#quic-bidirectional-stream
~stream~error:#quic-stream-error
~stream種別:#h3-stream-type
制御~stream:#h3-control-stream
	#control-streams
要請~stream:#h3-request-stream
	#request-streams
~push~stream:#h3-push-stream
	#push-streams
	#errors
接続~error:#quic-connection-error
	#errors
~error~code:#h3-error-code
~server~push:#h3-server-push
	~server~push:#server-push
~push~ID:#h3-push-id
最大~push~ID:#h3-max-push-id
不正形:#malformed-message
~client要請:#client-request

疑似-~header:#pseudo-header
生成元:#origin
遊休中:#idle
	却下-:#rejected-request
設定:#setting
設定~識別子:#setting-identifier
設定~値:#setting-value
可変長な整数:#variable-length-integer

権限的:~HTTPinfra#authoritative

標準~化:~RFCx/rfc8126#section-4.9
仕様が要求される:~RFCx/rfc8126#section-4.6
~reset:~QUICv1#section-2.4
終了:~QUICv1#section-2.4
動的~table:~HTTPWG/rfc9204.html#header-table-dynamic

	●§

3:#connection-setup
3.1:#discovery
3.1.2:#other-schemes
3.3:#connection-reuse
4:#http-request-lifecycle
4.1.1:#request-cancellation
4.1.2:#malformed
4.1:#request-response
4.2.2:#header-size-constraints
4.2:#header-formatting
4.4:#connect
4.6:#server-push
5:#connection-closure
5.2:#connection-shutdown
6:#stream-mapping
6.1:#request-streams
6.2.1:#control-streams
6.2.2:#push-streams
6.2.3:#stream-grease
6.2:#unidirectional-streams
7:#http-framing-layer
7.2.1:#frame-data
7.2.2:#frame-headers
7.2.3:#frame-cancel-push
7.2.4.1:#settings-parameters
7.2.4.2:#settings-initialization
7.2.4:#frame-settings
7.2.5:#frame-push-promise
7.2.6:#frame-goaway
7.2.7:#frame-max-push-id
7.2.8:#frame-reserved
7.2:#frames
8:#errors
~HTTP3~error~code:#http-error-codes
8.1:#http-error-codes
9:#extensions
10.8:#frame-parsing
11.1:#iana-alpn
11.2.1:#iana-frames
11.2.2:#iana-settings
11.2.3:#iana-error-codes
11.2.4:#iana-stream-types
11.2:#iana-policy
A.2.1:#h2-diff-priority
A.2:#h2-frames
A.3:#h2-settings
A:#h2-considerations


●●words_table1

QUICv1:https://www.rfc-editor.org/rfc/rfc9000
HTTPv2:https://httpwg.org/specs/rfc9113.html
RFC6585:http-status-code-428-429-431-511-ja.html

2_62:2<sup>62</sup>

●●words_table

	●略称／名称
IESG:
IP:
ALPN:
UDP:
HPACK:
QPACK:
QUIC:
HTTP1x:HTTP/1.x
HTTP2:HTTP/2
HTTP3:HTTP/3
0-RTT:
1-RTT:
SNI:

	$h:Alt-Svc
	$h:Upgrade1
	^ft:ALTSVC
	^ft:CONNECTION_CLOSE
	^i:Fast Open
	^i:Flag
	^i:Alt-Svc
	^i:FIN
	^i:RST
	^i:END_STREAM
	^i:TIME_WAIT
	~padding^i:Padding
	~push~ID^i:Push ID
	~HTTP2~frame種別~registry^cite:"HTTP/2 Frame Type" registry
	~HTTP3~frame種別~registry^cite:"HTTP/3 Frame Types" registry
	~HTTP2設定~registry^cite:"HTTP/2 Settings" registry
	~HTTP3設定~registry^cite:"HTTP/3 Settings" registry
	~HTTP2~error~code~registry^cite:"HTTP/2 Error Code" registry
	~HTTP3~error~code~registry^cite:"HTTP/3 Error Code" registry
	~HTTP3~stream種別~registry^cite:"HTTP/3 Stream Types" registry
	~HTTP~field名~registry$cite:"Hypertext Transfer Protocol (HTTP) Field Name Registry" maintained at &lt;https://www.iana.org/assignments/http-fields/&gt;
	~TLS~ALPN~protocol~ID~registry^cite:"TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry
	~server名~指示^cite／^en:Server Name Indication
	仕様が要求される:Specification Required
	標準~化:Standards Action
	~IESG認可:IESG Approval

	●network
受信器:receiver::~
送信器:sender::~
発行-:issue:~
多重化:multiplexing::~
輻輳:congestion::~
順序通り:in-order:順序どおり
	順序通りでない:out-of-order
	順序通り〜ない:out of order
全順序:total order:~
	全順序~法:total ordering
順序付ける:orderする:~
並列性:parallelism::~
確立:establishment:~
一方向:unidirectional::~
接続性:connectivity::~
到着-:arrive:~
hostname::::ホスト名
segment:
handshake::::ハンドシェイク
窓:window::~::ウインドウ
datagram::::データグラム
ticket:
credit:
hop:
topology::::トポロジー
reset:
peer:
移転:migration::~

	相手の端点:'s peer
	相手の端点:the remote peer
	互いの端点:each peer
	どちらの端点も:both peers
	要請した端点:peer
	~frame法:framing
	~frame化~層:framing layer
	~~渋滞／^en:head-of-line blocking
	片~方向だけ~closeされ:half closed in a single direction
	~~通過中:in transit
	伝送途上:in flight
	伝送途上にある:in-flight
	急激に増える:occurs in burst
	急増:bursts

	●処理
放棄-:abandon:~
未圧縮:uncompressed::~
解凍-:decompress::~
時機:timing::~
存続期間:lifetime::~
中途で:abruptに::~
	中途で終了-:abrupt termination
遊休:idle::~
遊休中:idle::~
片付ける:clean upする:~
未処理:unprocessed:~
総和:sum:~
提示-:present:~
停滞:stall:~
散発的:intermittent:~
不定期:indefinite:~
切落とさ:truncateさ:切り落とさ

増やす:increaseする:~
増やせ:increaseでき:~
commitment:
commit:
shutdown:
shut-down:shut down
clean:
待機中:outstanding:~
制限時間:timeout::~
	制限時間:time out
設営:setup::~
引継ぎ:resumption:~
保つ:keepする:~
優先順位付け:prioritization:~
渡され:passされ:~
渡す:passする:~
早期:early:~

	〜しつつある:in advance
	それに気付いた時点で，すぐに:even if the advance notice is small
	なり次第:as soon as
	終えるまでは:prior to
	~~短縮され得る:potential 〜 gain
	^en:blocking
	^en:reception
	妨げる:prevent
	妨げな:prevent

	●形式
可変長:variable-length:長さ可変
	可変:variable
	^en:variable-maximum-length
固定-:fix:~
	固定された~size:fixed-sized
固定長:fixed-length:長さ固定
配列-:arrange:~
梱包-:package:~
符号点:code point::~::コードポイント
不正形:malformed:~
構造化-:structure::~

	`CR$P :carriage return
	`LF$P :line feed
	~NULL文字:null character
	$p:request-target
	$p:authority-form
	$p:authority
	$p:cookie-pair
	request-line$p:request line
	status-line$p:status line

	●保安
呈-:exhibit:~
確率:probability:~
逐語的:verbatim:~
正当:legitimate:~
浪費-:waste:~
負担:burden:~
偽陽性:false positive:~
妨害-:disrupt:~
防護-:guard:~
分析:analysis:~
被る:incurする:~
能動的:active:~
推定-:infer:~
観測者:observer::~
刺激:stimulus:~
請求-:solicit:~
	~~請求-:demand
偽造:forgery:~
平文:plaintext::~
暗号文:ciphertext::~
秘匿:secret:~
隠蔽-:obscure:~
対抗措置:countermeasure:~
逆効果:counterproductive:~
打破-:defeat:~
分布:distribution:~
証明書:certificate::~
晒し:exposeし:~
晒す:exposeする:~
晒され:exposeされ:~
	晒され:creates an exposure
	信用に価する:trustworthy
廃止-:revoke::~
耐性:resistance:~
	耐性を高める:make a connection more resistant
暗号:crypto::~
再現:replay::~
	反-再現:anti-replay
誘導-:induce:~
排出-:drain:~
	速やかに排出-:promptly drain

	信用に価する:trustworthy
	用心深い:cautious
	用心を怠ると:to a incautious implementer
	〜があるかのような外見:appearance
	〜の外見:apparent
	送信される~dataが成す~streamが均一に出現する:even to the point of appearing to send a constant stream of data

	●仕様
異常:abnormal:~
地点:point:~
助言-:advise:~
拙く:poorに:~
辞退-:decline:~
連絡先:contact:~
類似性:similarity:~
出発-:depart:~
短所:shortcoming:~
収容-:accommodate:~
枯渇:exhaustion:~
排-:eliminate:~
有益:beneficial:~
流儀:fashion:~
承認-:acknowledge:~
承認:acknowledgment:~
明白:obvious:~
専門家:expert:~
考査者:reviewer:~
排他的:exclusive:~
発生-:arise:~
裁量:discretion:~
特質:property:~
有効果:effective:有効
協調-:coordinate:~
選ぶ:chooseする:~
選んで:chooseして:~
選んだ:chooseした:~
過度:excessive:~
	過度:to exces
合意-:agree:~
合意:agreement:~
	合意に至らなくなり得る:could lead to disagreement
基礎:basis:~
表出:expression:~
粒度:granularity:~
処-:deal:~
冗長:redundant:~
信頼性:reliability:~
略語化-:abbreviate:~
省ける:elideできる:~
正しさ:correctness:~
行使-:exercise:~
デモ-:demonstrate::~
	デモ-可能:demonstrable
可読:readable:~
本物の:realな:~
順応-:adapt:~
	~HTTP2用の特能を~HTTP3に順応する:adaptation
義務的:mandatory:~
理解:understanding:~
移行-:transition:~
不審:suspicious:~
管理上の:administrativeな::~
確約-:assure:~
	強く確約される:have strong assurances
新種:variation:~
重複n:duplication:重複
人々:people:~
先駆け:precursor:~
前置き:preface:~
別物:distinct:~
所持:possession:~
変種:variant:~
割振n:allocation::割り振り
衝突:collision:~
出発点:departure:~
記号的:symbolic:~
概略的:brief:~
利用量:usage:~
格上げ:promote:~
追認-:tolerate:~
総合的:overall:~
critical:
任意選択して:optして:任意で選んで
潜在的:potential:~
lifecycle:
balance::::バランス
アテガい:assignment::あてがい
並立的:parallel:~
認可:approval:~

	発見-法:discovery
	不要:not be needed
	効果を発揮する:comes into effect
	方々:people
	まだ未知な~as-yet-unknown
	用意がある:willing to
	応用~層:application-layer
	に関して:with regard to
	に関して:with respect to
	至らす:lead
	用立てる:make use
	組み込まれ:subsume
	ある:bear
	単純にするため:for simplicity
	〜を冠する見出し:heading
	係る:pertain
	~~主要な:key
	とは限らない:do not necessarily
	取り決め:arrangement
	用意があること:willingness
	肯定する:positive
	にもなり得る:could prove
	に関する:regarding
	~~義務:obligated to do
	複階的になる〜 ~~容認する:leads to 〜 complexity 〜 tolerance of
	それ自体で:readily
	解することは任意選択な:optional-to-understand
	よりも比較的安上がり:relatively inexpensive when compared to
	際どい:corner
	難があって:suffer
	見越している下で:in anticipation of
	満足していない:fails to satisfy
	膨大な:enormous
	強く確約される:have strong assurances
	中でも:Among others,
	多大な:substantial
	取って代わられ:supersed
	支持を受けて:in favor of
	頂いた:received
	良い:good
	好ましい:preferable
	望ましい:desirable
	に則って:according
	単に:merely
	反-:anti-
	図:figure
	原因になる／もたらし:caused
	仕向ける:cause
	課して:impose
	見込みが高い:likely
	堅い:hard
	決まった:hard
	見た目:seem
	不足ない:sufficient
	~WG:working-group
	に関して:in terms of
	〜を指して:referred to as
	指摘-:point out
	雇われている:employment
	の設計は〜とする所:premise
	~~容認:tolerance
	により生じ得る:for what might be
	上げる:for better
	から:out of
	あり得るかどうか:possible
	早期~~段階:early phase
	高めるため:To allow for better
	定義し直:redefine
	定義し直:redefinition
	も~~含めて:regardless of whether
	試行し直:retried
	突き止める:locating
	~~広範な~class:broad class
	〜の元に:pose
	もっと細かい:granular
	より柔軟に選べる:has more flexibility 〜 it chooses
	したがって:consequently
	~supportしない:unsupported
	制限されない:unlimited
	ので、:Due to
	のみに:exclusively on
	呼ばれ:called
	もはや関心がない:no longer of interest
	注記-:note
	事実:fact
	~~構成:organization
	〜と引き換えに:trades off 〜 against
	匹敵するもの:comparable
	匹敵する:comparable
	勧める:advised
	互いに並立的にアテガう:the assignments parallel each other
	かなり取り入れて:heavily drawing
	強く参考にして:strongly informed by
	広く取り入れら:largely drawn
	広く:largely
	-:informational
	費やす:expend
	~~説明:illustrate
	高まる:improve
	次の表:Table
	-:Table
	:figure

	●言い換え
	時間~内:amount of time
	可能でない:unable
	順に:followed by
	圧縮を行う:compressed
	~streamを~closeしては:make stream closure
	~IN { }:of the format
	生成元$:HTTP origin
	非最終-応答$:interim HTTP response
	最終-応答$:final HTTP response
	制御~stream$:HTTP control stream
	疑似-~header:pseudo-header field
	要請$:HTTP request
	応答$:HTTP response
	~message$:HTTP message
	~message$:requests and responses
	~message$:request or response
	~message$:requests or responses
	［要請, 応答］:request-response
	応答~header:HTTP response header field
	~field節$:fields
	~HTTP`~field節$:HTTP field section
	~proxy$:~HTTP`~proxy$
	~HTTP`状態s~code$:HTTP status codes
	~cache$:HTTP cache
	~client$:HTTP client
	所与の`~URI$:HTTP URI
	`最大~push~ID$:greater than currently allowed on the connection
	`制御~stream$以外の`~stream$:a different stream
	~QUIC~transport:The transport
	可変長な整数$:QUIC variable-length integer
	~stream~ID$:QUIC stream ID
	`~server$h3:server endpoint

	これより長く:longer than this duration
	何かが合致しないこと:mismatch
	同じ`~push~ID$を伴う各 `PUSH_PROMISE$ft ~frameごとに:the request header sections for resources promised multiple times 〜 receives a push ID that has already been promised
	~push~streamの~stream~header:push stream header
	~push~streamの~stream~header:unidirectional stream header
	~transport層と~session層:transport and session layers
	内容:bodies
	まだ設定されない:unset
	さもなければ:being permissive
	対して，~QUIC接続においては:correspondingly
	†:(1)／this is indicated in Table 1 with a (1)
	~flow制御:flow-control
	~HTTP2より長期間:for a longer period of time
	~serverから~clientへの~server-to-client
	~clientから~serverへの~client-to-server
	~DoS攻撃:denial-of-service
	`~trailer節$を成す:trailing
	非~HTTP:~non-HTTP
	停滞する:experience a stall
	実装し直-:re-implemen
	~port能:portability
	~port可能:portable
	最大~化:maximize
	他へ~navigateする:navigates away from
	検証し直す:revalidate
	~byte~stream:bytestream
	たちが成す~list:listing of
	下位-成分:subcomponent
	生産し直:reproduce
	`完全$であっても、:partial or complete
	〜から起動される:〜-initiated
	を~cacheする能:cacheability
	~access制御:access-control
	〜から:beginning from
	前後や合間:before, after, or interleaved with
	成分:part
	成分:portion
	〜部:part
	部位t:part
	出生した:origination
	~directされた時点:at the direction of
	無効~化:invalidate
	生じた~error:occurrence of error
	~transport層の:transport-layer
	終端~近く:toward the end of
	いずれか:long
	［~key, 値］が成す:pair~key-value~pair
	処理される見込みを高める:increase the likelihood of processing
	→:versus
	{ 〜 } に入る:(in hexadecimal; inclusive)
	2 個の:pair
	送信~部:for sending
	複数個の 〜ない:only be 〜 once
	最初の~frameとして:beginning
	確立されたなら:once 〜 exists
	~transport層の:transport-layer
	~byte列:sequences of bytes
	重ねて:a second
	双方向~stream$:bidirectional QUIC stream
	一方向~stream$:unidirectional QUIC stream
	`一方向~stream$の`~stream種別$:unidirectional stream type

	●未分類
後続に:subsequentに:後続して
後続-:follow:~
喪失-:lose:~
喪失:loss:~
	喪失され:lost
別々で:separateで:~
並替えら:reorderさ:並び替えら
tenant::::テナント

	~log取り:logging
	減らせな:reduce
	減らし:reduce
	より多くの:greater
	より多量な:greater
	多量な:large amount
	細切れにされた多数の:disproportionate
	またがり:span
	ある~~限界に抑えられる:bounded
	際限が無い:unbounded
	内容~符号法:content-coding
	変えながら:varying
	流出していく:outgoing
	流入してくる:incoming
	出くわした:see
	長期にわたって:over a long period
	上層:atop
	:Microsoft

	●他
	非:non-
	現在:currently
	残りの:remaining
	番台:series
	巨大:very large
	各自の:respective
	一連の:sequence
	する所では:as far as
	一部分でも:whether in whole or in part
	~~同時に:at a time
	時点に:at the time of
	どの時点であれ:at any point
	どの地点でも:at any point
	この時点で:at this point
	しばらくは:for some time
	いつでも:at any time
	めぐる:around
	まったく:entirely
	逆:reverse
	最終的に:ultimately
	最終的な:ultimate
	あらゆる:every
	それ以降:thereafter
	より長い／より長く:longer
	最も近く:closest
	一体としての:as a whole
	最~大:largest
	最~小:smallest
	より多数:larger
	ずっと広い:significantly larger
	ずっと広い:substantially larger
	より広い:larger
	より大きい:larger
	より小さい:smaller
	超える:cross
	より大きい:greater
	を超えて:greater
	を超えない:no greater than
	以上:or greater
	わずか:very little
	な限り長く:as long as
	一部でも:partially or fully
	どの程度:how much
	近付いている:approaching
	より低い:lower
	より短く／より短い:shorter
	成す残り:remainder of
	一連の:a series of
	小さな／小さい:small
	以前に:previously
	以前の:previous
	-済みでない:has not yet
	より高い:higher
	始める／始まる:begin
	始めて／始め:beginning
	始めた:begun
	入った:enter
	広~範囲な:broad range of
	様々な:variety
	にまたがる:across
	置いた:make
	抗して:against
	後で:later
	~~残りの:final
	各部:parts of
	早く:early
	低-:low-
	〜ごとの:per-
	未満の:below

●●ref_key_map
ALTSVC:RFC7838
DNSTERMS:RFC8499
HPACK:RFC7541
QPACK:RFC9204
HTTPREPLAY:RFC8470
TFO:RFC7413
QUICTRANSPORT:RFC9000

●●ref_normative

[ALTSVC]
    Nottingham, M., McManus, P., and J. Reschke, ＜HTTP Alternative Services＞, ~RFC7838, April 2016
[COOKIES]
    Barth, A., ＜HTTP State Management Mechanism＞, ~RFC6265, April 2011
[HTTP]
    Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., ＜HTTP Semantics＞, STD 97, ~RFC9110, June 2022
    URL: https://httpwg.org/specs/rfc9110.html
[HTTP-CACHING]
    Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., ＜HTTP Caching＞, STD 98, ~RFC9111, June 2022
    URL: https://httpwg.org/specs/rfc9111.html
[HTTP-REPLAY]
    Thomson, M., Nottingham, M., and W. Tarreau, ＜Using Early Data in HTTP＞, ~RFC8470, September 2018
[QPACK]
    Krasic, C., Bishop, M., and A. Frindell, Ed., ＜QPACK: Field Compression for HTTP/3＞, ~RFC9204, June 2022
[QUIC-TRANSPORT]
    Iyengar, J., Ed. and M. Thomson, Ed., ＜QUIC: A UDP-Based Multiplexed and Secure Transport＞, ~RFC9000, May 2021
[RFC0793]
    Postel, J., ＜Transmission Control Protocol＞, STD 7, ~RFC793, September 1981
[RFC2119]
    Bradner, S., ＜Key words for use in RFCs to Indicate Requirement Levels＞, BCP 14, ~RFC2119, March 1997
[RFC6066]
    Eastlake 3rd, D., ＜Transport Layer Security (TLS) Extensions: Extension Definitions＞, ~RFC6066, January 2011
[RFC7301]
    Friedl, S., Popov, A., Langley, A., and E. Stephan, ＜Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension＞, ~RFC7301, July 2014
[RFC8126]
    Cotton, M., Leiba, B., and T. Narten, ＜Guidelines for Writing an IANA Considerations Section in RFCs＞, BCP 26, ~RFC8126, June 2017
[RFC8174]
    Leiba, B., ＜Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words＞, BCP 14, ~RFC8174, May 2017
[URI]
    Berners-Lee, T., Fielding, R., and L. Masinter, ＜Uniform Resource Identifier (URI): Generic Syntax＞, STD 66, ~RFC3986, January 2005

●●ref_informative

[BREACH]
    Gluck, Y., Harris, N., and A. Prado, ＜BREACH: Reviving the CRIME Attack＞, July 2013, URL: http://breachattack.com/resources/BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf
[DNS-TERMS]
    Hoffman, P., Sullivan, A., and K. Fujiwara, ＜DNS Terminology＞, BCP 219, ~RFC8499, January 2019
[HPACK]
    Peon, R. and H. Ruellan, ＜HPACK: Header Compression for HTTP/2＞, ~RFC7541, May 2015
[HTTP/1.1]
    Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., ＜HTTP/1.1＞, STD 99, ~RFC9112
    URL: https://httpwg.org/specs/rfc9112.html
[HTTP/2]
    Thomson, M., Ed. and C. Benfield, Ed., ＜HTTP/2＞, ~RFC9113, June 2022
    URL: https://httpwg.org/specs/rfc9113.html
[RFC6585]
    Nottingham, M. and R. Fielding, ＜Additional HTTP Status Codes＞, ~RFC6585, April 2012
[RFC8164]
    Nottingham, M. and M. Thomson, ＜Opportunistic Security for HTTP/2＞, ~RFC8164, May 2017
[TFO]
    Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, ＜TCP Fast Open＞, ~RFC7413, December 2014
[TLS]
    Rescorla, E., ＜The Transport Layer Security (TLS) Protocol Version 1.3＞, ~RFC8446, August 2018


●●trans_metadata
<p>
~THIS_PAGEは、
~IETF により Internet Standard として公表された，
<a href="~SPEC_URL">HTTP/3</a> （RFC 9114）
を日本語に翻訳したものです。
~PUB
</p>

●●spec_metadata
公表者
	Internet Engineering Task Force (IETF)
RFC
	9114
分類
	Standards Track
日付
	2022 年 6 月
編集／著作者アドレス
	<a href="mbishop@evequefou.be">Mike Bishop</a> (Akamai)
履歴
	https://datatracker.ietf.org/doc/rfc9114/
現在の位置付け, 正誤表, フィードバックの方法
	https://www.rfc-editor.org/info/rfc9114
	（この訳には 2023-11-15 時点までの正誤表の内容（ Rejected 以外）も含めている）
</script>

</head>
<body>


<header>
	<hgroup>
<h1>HTTP/3</h1>
<p>RFC 9114 — HTTP/3</p>
	</hgroup>
</header>

<div id="MAIN" hidden>
	<section id="rfc.abstract">
◎要約

<p>
~QUIC~transport~protocolは、
~HTTP用の~transportにおいて望ましい特能をいくつか備える
— ~stream多重化, ~streamごとの~flow制御, 低-待時間な接続の確立, など。
この文書は、
~QUIC越しの~HTTP用に~HTTP意味論の対応付けを述べる。
この文書はまた、［
~HTTP2特能のうち，~QUICに組み込まれるもの
］を識別して，［
~HTTP2用の拡張を~HTTP3にどう~portできるか
］を述べる。
◎
The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3.
</p>

	</section>
	<section id="rfc.status">
<h2 title="Status of This Memo">このメモの位置付け</h2>

<p class="trans-note">【
この節の内容は
`~IETF日本語訳 共通~page＠~IETFcommon#status$に移譲。
】</p>

	</section>
	<section id="rfc.copyrightnotice">
<h2 title="Copyright Notice">著作権の告知</h2>

<p lang="en">
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
</p>

<p class="trans-note">【
以下、この節の他の内容は
`~IETF日本語訳 共通~page＠~IETFcommon#copyright-notice$に移譲。
】</p>

	</section>

<main id="MAIN0">

	<section id="introduction">
<h2 title="Introduction">1. 序論</h2>

<p>
~HTTP意味論（ `HTTP$r ）は、
~Internet上の広~範囲な~serviceに利用される。
これらの意味論は、［
~HTTP11, ~HTTP2
］と伴に最も共通的に利用されてきた。
~HTTP11は、様々な［
~transport層, ~session層
］越しに利用されてきた。
一方で，
~HTTP2は、首に~TLS越しの~TCPと伴に利用されてきた。
~HTTP3は、
同じ意味論を新たな~transport~protocol
— ~QUIC —
越しに~supportする。
◎
HTTP semantics ([HTTP]) are used for a broad range of services on the Internet. These semantics have most commonly been used with HTTP/1.1 and HTTP/2. HTTP/1.1 has been used over a variety of transport and session layers, while HTTP/2 has been used primarily with TLS over TCP. HTTP/3 supports the same semantics over a new transport protocol: QUIC.
</p>

		<section id="prior-versions-of-http">
<h3 title="Prior Versions of HTTP">1.1. ~HTTPの先立つ~version</h3>

<p>
~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.
</p>

<p>
~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.
</p>

<p>
~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.
</p>

		</section>
		<section id="delegation-to-quic">
<h3 title="Delegation to QUIC">1.2. ~QUICへの委任</h3>

<p>
~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]).
</p>

<p>
この文書は、
~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.
</p>

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

		</section>
	</section>
	<section id="http3-protocol-overview">
<h2 title="HTTP/3 Protocol Overview">2. ~HTTP3~protocolの概観</h2>

<p>
~HTTP3は、
~QUIC~transport~protocolを利用して，［
~HTTP意味論~用の~transport
］および［
~HTTP2に類似な，内部的な~frame化~層
］を供する。
◎
HTTP/3 provides a transport for HTTP semantics using the QUIC transport protocol and an internal framing layer similar to HTTP/2.
</p>

<p>
`~client$h3は、
ある端点に~HTTP3`~server$h3が存在することが知れたなら，~QUIC接続を~openする。
~QUICは、［
~protocol折衝, ~streamに基づく多重化, ~flow制御
］を供する。
~HTTP3端点の発見-法は、
`3.1§にて述べられる。
◎
Once a client knows that an HTTP/3 server exists at a certain endpoint, it opens a QUIC connection. QUIC provides protocol negotiation, stream-based multiplexing, and flow control. Discovery of an HTTP/3 endpoint is described in Section 3.1.
</p>

<p>
各`~stream$の中で，
~HTTP3通信を成す基本的な単位は、
~frameである（`7.2§）。
各~frame種別は、
異なる目的を~serveする。
例えば［
`HEADERS$ft, `DATA$ft
］~frameは、
`~message$【！requests and responses】の基礎を形成する
（`4.1§）。
接続~全体に適用される~frameは、
専用な`制御~stream$上で伝達される。
◎
Within each stream, the basic unit of HTTP/3 communication is a frame (Section 7.2). Each frame type serves a different purpose. For example, HEADERS and DATA frames form the basis of HTTP requests and responses (Section 4.1). Frames that apply to the entire connection are conveyed on a dedicated control stream.
</p>

<p>
要請の多重化は、
`~QUIC~stream$抽象-化を利用して遂行される
— それは、
`QUIC-TRANSPORT$r `2＠~QUICv1#section-2§ にて述べられる。
各［
要請, 応答
］~pairは、
単独の`~QUIC~stream$を消費する。
各~streamは互いに独立なので、
ある~streamに
— ~packet喪失により阻まれるなど —
難があっても，
他の~streamの進捗を妨げない。
◎
Multiplexing of requests is performed using the QUIC stream abstraction, which is described in Section 2 of [QUIC-TRANSPORT]. Each request-response pair consumes a single QUIC stream. Streams are independent of each other, so one stream that is blocked or suffers packet loss does not prevent progress on other streams.
</p>

<p>
`~server~push$は、
~HTTP2 （ `HTTP/2$r ）にて導入された “ヤリトリ~mode” であり、
`~client$h3が指示された要請を為すものと見越している下で，
`~server$h3が`~client$h3へ［
要請, 応答
］の交換を~pushすることを許可する。
これにより、
~network利用量と引き換えに，待時間は~~短縮され得る。
`~server~push$は、
いくつかの~HTTP3~frame
— `PUSH_PROMISE$ft, `MAX_PUSH_ID$ft, `CANCEL_PUSH$ft など —
を利用して管理される。
◎
Server push is an interaction mode introduced in HTTP/2 ([HTTP/2]) 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. Several HTTP/3 frames are used to manage server push, such as PUSH_PROMISE, MAX_PUSH_ID, and CANCEL_PUSH.
</p>

<p>
~HTTP2と同じく、［
要請／応答
］の`~field節$は，伝送~用に圧縮される。
~HPACK （ `HPACK$r ）は、
圧縮された`~field節$の順序通りな伝送（~QUICでは供されない保証）に依拠する。
~HTTP3は、
~HPACKを~QPACK（ `QPACK$r ）に置換する。
~QPACKは，~field~table状態を［
改変する／追跡する
］ために別々な`一方向~stream$を利用する一方で、
符号化された`~field節$は，それを改変することなく~tableの状態を指す。
◎
As in HTTP/2, request and response fields are compressed for transmission. Because HPACK ([HPACK]) relies on in-order transmission of compressed field sections (a guarantee not provided by QUIC), HTTP/3 replaces HPACK with QPACK ([QPACK]). QPACK uses separate unidirectional streams to modify and track field table state, while encoded field sections refer to the state of the table without modifying it.
</p>

		<section id="document-organization">
<h3 title="Document Organization">2.1. この文書の~~構成</h3>

<p>
以下の各~節では、
`~HTTP3接続$の~lifecycleの詳細な概観を供する：
◎
The following sections provide a detailed overview of the lifecycle of an HTTP/3 connection:
</p>
<ul>
	<li>
`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.
</li>
	<li>
`4. ~HTTP3における~HTTP意味論の表出-法＠#http-request-lifecycle§
⇒
~HTTP意味論が ~frameを利用して どう表出されるかを述べる。
◎
"Expressing HTTP Semantics in HTTP/3" (Section 4) describes how HTTP semantics are expressed using frames.
</li>
	<li>
`5. 接続の~closure＠#connection-closure§
⇒
`~HTTP3接続$が どう
— ［
上品に, 中途で
］どちらで —
終了されるかを述べる。
◎
"Connection Closure" (Section 5) describes how HTTP/3 connections are terminated, either gracefully or abruptly.
</li>
</ul>

<p>
後続な各~節では、
この伝送路~protocolと~transportとのヤリトリについて，詳細が述べられる：
◎
The details of the wire protocol and interactions with the transport are described in subsequent sections:
</p>
<ul>
	<li>
`6. ~streamの対応付けと用法＠#stream-mapping§
⇒
`~QUIC~stream$が利用される仕方を述べる。
◎
"Stream Mapping and Usage" (Section 6) describes the way QUIC streams are used.
</li>
	<li>
`7. ~HTTP~frame化~層＠#http-framing-layer§
⇒
ほとんどの~streamに利用される各種~frameを述べる。
◎
"HTTP Framing Layer" (Section 7) describes the frames used on most streams.
</li>
	<li>
`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.
</li>
</ul>

<p>
~~残りの各~節では、
追加的な資源が供される：
◎
Additional resources are provided in the final sections:
</p>
<ul>
	<li>
`9. ~HTTP3に対する拡張＠#extensions§
⇒
将来の文書において，
新たな能力がどう追加できる／され得るかを述べる。
◎
"Extensions to HTTP/3" (Section 9) describes how new capabilities can be added in future documents.
</li>
	<li>
`A. ~HTTP2から移行するための考慮点＠#h2-considerations§
⇒
~HTTP2と~HTTP3の より詳細な比較。
◎
A more detailed comparison between HTTP/2 and HTTP/3 can be found in Appendix A.
</li>
</ul>

		</section>
		<section id="conventions-and-terminology">
<h3 title="Conventions and Terminology">2.2. 規約と各種用語</h3>

<p>
この文書~内の~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.
</p>

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

<p>
次に挙げる用語が利用される：
◎
The following terms are used:
</p>
<dl>
	<dt>
`中止-@
（ `abort^en ）する
◎
abort:
</dt>
	<dd>
［
接続／`~stream$
］を中途で終了すること
— 場合によっては、
~error条件に因り。
◎
An abrupt termination of a connection or stream, possibly due to an error condition.
</dd>

	<dt>
`~client@h3
（ `client^en ）
◎
client:
</dt>
	<dd>
`~HTTP3接続$を起動する方†の端点。
`~client$h3は`要請$を送信して，~HTTP応答を受信する。
◎
The endpoint that initiates an HTTP/3 connection. Clients send HTTP requests and receive HTTP responses.
</dd>
	<dd class="trans-note">【†
`~stream$を起動する方と混同しないように
— ~streamは、
どちらの端点からも起動され得る
】【
~HTTPの`~client$とは別に定義されているが、
その概念に包摂され，~HTTPが`~client$に課す要件も適用されるであろう。
】</dd>

	<dt>
`接続^dfn
（ `connection^en ）
◎
connection:
</dt>
	<dd>
~transport~protocolとして~QUICを利用している，
2 つの端点~間の~transport層の接続。
◎
A transport-layer connection between two endpoints using QUIC as the transport protocol.
</dd>

	<dt>
<dfn>`接続~error$</dfn>
（ `connection error^en ）
◎
connection error:
</dt>
	<dd>
`~HTTP3接続$全体に影響する~error。
◎
An error that affects the entire HTTP/3 connection.
</dd>

	<dt>
`端点^dfn
（ `endpoint^en ）
◎
endpoint:
</dt>
	<dd>
接続の［
`~client$h3, `~server$h3
］を~~指す総称。
◎
Either the client or server of the connection.
</dd>

	<dt>
`~frame^dfn
（ `frame^en ）
◎
frame:
</dt>
	<dd>
~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.
</dd>
	<dd>
“~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.
</dd>

	<dt>
`~HTTP3接続@
（ `HTTP/3 connection^en ）
◎
HTTP/3 connection:
</dt>
	<dd>
~QUIC接続のうち，
折衝された応用~protocolが~HTTP3であるもの。
◎
A QUIC connection where the negotiated application protocol is HTTP/3.
</dd>

	<dt>
<dfn>~peer</dfn>【 “相手” 】
（ `peer^en ）
◎
peer:
</dt>
	<dd>
端点。
特定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.
</dd>
	<dd class="trans-note">【
この訳では、
この用語は利用せず，単に
“相手の端点” （ `…'s peer^en ）,
“互いの端点” （ `each peer^en ）,
“どちらの端点も…”（ `both peers^en ）,
等々と記す。
（結局は、
文脈に応じて，このように訳し分けることになり、
~peerと端点を使い分けても，さして有用でないので。）
】</dd>

	<dt>
`受信器@
（ `receiver^en ）
◎
receiver:
</dt>
	<dd>
~frameを受信している端点。
◎
An endpoint that is receiving frames.
</dd>
	<dd class="trans-note">【
単に`受信者$（ `recipient^en ）の別名が意図されているようにも思われるが、
はっきりしない。
いずれにせよ、
~HTTPが定義する`受信者$の概念に包摂され，
~HTTPが`受信者$に課す要件も適用されるであろうが。
】</dd>

	<dt>
`送信器@
（ `sender^en ）
◎
sender:
</dt>
	<dd>
~frameを伝送している端点。
◎
An endpoint that is transmitting frames.
</dd>
	<dd class="trans-note">【
原文の綴りは`送信者$と同じだが、
`受信器$と対を成すので，訳を違えている。
しかしながら、
一部の “送信器” は，`送信者$を意味するかもしれない。
いずれにせよ、
~HTTPが定義する`送信者$の概念に包摂され，
~HTTPが`送信者$に課す要件も適用されるであろうが。
】</dd>

	<dt>
`~server@h3
（ `server^en ）
◎
server:
</dt>
	<dd>
`~HTTP3接続$を受容する端点。
`~server$h3は、
`要請$を受信して，`応答$を送信する。
◎
The endpoint that accepts an HTTP/3 connection. Servers receive HTTP requests and send HTTP responses.
</dd>
	<dd class="trans-note">【
~HTTPの`~server$とは別に定義されているが、
その概念に包摂され，~HTTPが`~server$に課す要件も適用されるであろう。
】</dd>

	<dt>
`~stream@
（ `QUIC stream^en, 略して `stream^en ）
◎
stream:
</dt>
	<dd>
~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.
</dd>

	<dt>
<dfn>`~stream~error$</dfn>
◎
stream error:
</dt>
	<dd>
個々の`~stream$上の応用~levelの~error。
◎
An application-level error on the individual stream.
</dd>

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

<p>
次に挙げる用語は、
`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].
</p>

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

<p>
この文書における~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.
</p>

		</section>
	</section>
	<section id="connection-setup">
<h2 title="Connection Setup and Management">3. 接続の設営と管理</h2>

		<section id="discovery">
<h3 title="Discovering an HTTP/3 Endpoint">3.1. ~HTTP3端点の発見-法</h3>

<p>
~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].
</p>

<p>
"`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.
</p>

<p>
`~client$h3は、
`https$c ~URIを伴う`資源$への~accessを，次に従って試みてもヨイ：
◎
A client MAY attempt access to a resource with an "https" URI by＼
</p>
<ol>
	<li>
~host識別子を~IP~addressに解決する。
◎
resolving the host identifier to an IP address,＼
</li>
	<li>
前段の結果の~addressに指示された~port上へ~QUIC接続を確立する
（上で述べたとおり~server証明書の検証を含めて）。
◎
establishing a QUIC connection to that address on the indicated port (including validation of the server certificate as described above),＼
</li>
	<li>
前段により~secure化された接続~越しに，
~URIを~targetにしている~HTTP3要請`~message$を`~server$h3へ送信する。
◎
and sending an HTTP/3 request message targeting the URI to the server over that secured connection.＼
</li>
</ol>

<p>
他の何らかの仕組みを利用して~HTTP3が選定される場合を除き、
~TLS~handshakeの間の<abbr title="Application-Layer Protocol Negotiation">~ALPN</abbr>拡張（ `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.
</p>

<p>
接続性の問題（例： `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.
</p>

<p>
`~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.
</p>

			<section id="alt-svc">
<h4 title="HTTP Alternative Services">3.1.1. ~HTTP代替~service</h4>

<p>
`生成元$【！~HTTP生成元】は、
等価な~HTTP3端点の可用性を広告できる
— ［
`Alt-Svc$h 応答~header／
~HTTP2 `ALTSVC^ft ~frame （ `ALTSVC$r ）
］を介して［
~ALPN~token "`h3^c"
］を利用することにより。
【 “`Alt Svc^en” は、 `Alternative Services^en （代替~service）の略称。】
◎
An HTTP origin can advertise the availability of an equivalent HTTP/3 endpoint via the Alt-Svc HTTP response header field or the HTTP/2 ALTSVC frame ([ALTSVC]) using the "h3" ALPN token.
</p>

<div class="example">
<p>
例えば，`生成元$は、
`応答$内に次の~headerを含めることにより，［
同じ~hostnameにおける~UDP~port 50781 上で，~HTTP3が可用であった
］ことを指示することもできる：
◎
For example, an origin could indicate in an HTTP response that HTTP/3 was available on UDP port 50781 at the same hostname by including the following header field:
</p>

<pre class="lang-http">
Alt-Svc: h3=":50781"
</pre>
</div>

<p>
`~client$h3は、［
~HTTP3の~supportを指示している `Alt-Svc^i ~record
］を受信したときは，それに指示された［
~host, ~port
］に対し~QUIC接続を確立しようと試みてもヨイ
— この接続に成功した場合，`~client$h3は、
この文書にて述べる対応付けを利用して，`要請$を送信できる。
◎
On receipt of an Alt-Svc record indicating HTTP/3 support, a client MAY attempt to establish a QUIC connection to the indicated host and port; if this connection is successful, the client can send HTTP requests using the mapping described in this document.
</p>

			</section>
			<section id="other-schemes">
<h4 title="Other Schemes">3.1.2. 他の~scheme</h4>

<p>
~HTTPは，~transport~protocolに依存しないが、
"`http$c" ~schemeは，［
`authority$p 【 “権限” 】成分の中で【 `host$p により】識別される~host
］が何であれ，権限を［
その~hostの［
【 `port$p により】指示された~port
］上で，~TCP接続を受信する能
］に結付ける。
~HTTP3は，~TCPを利用しないので、
~HTTP3を［
"`http$c" ~URIにより識別される`資源$
］を得るための［
`権限的$な`~server$h3への直な~access
］に利用することはできない。
しかしながら，
`ALTSVC$r などの~protocol拡張は、［
`権限的$かつ~HTTP3越しに到達-可能かもしれない，
他の【すなわち， "`http^c" 以外の】~service
］を識別するために，`権限的$な`~server$h3を許可する。
◎
Although HTTP is independent of the transport protocol, the "http" scheme associates authority with the ability to receive TCP connections on the indicated port of whatever host is identified within the authority component. Because HTTP/3 does not use TCP, HTTP/3 cannot be used for direct access to the authoritative server for a resource identified by an "http" URI. However, protocol extensions such as [ALTSVC] permit the authoritative server to identify other services that are also authoritative and that might be reachable over HTTP/3.
</p>

<p>
`~client$h3は、［
~schemeが "`https$c" でない`生成元$への要請
］を為すに先立って，［
当の`~server$h3は， "`https^c" ~schemeを~serveする用意がある
］ことを確保しなければナラナイ。
~schemeに "`http$c" を伴う`生成元$に対し，これを成遂げる試験的な手法は、
`RFC8164$r にて述べられる【それは、~HTTP2用だが】。
将来には、
様々な~scheme用に他の仕組みも定義され得る。
◎
Prior to making requests for an origin whose scheme is not "https", the client MUST ensure the server is willing to serve that scheme. For origins whose scheme is "http", an experimental method to accomplish this is described in [RFC8164]. Other mechanisms might be defined for various schemes in the future.
</p>

			</section>
		</section>
		<section id="connection-establishment">
<h3 title="Connection Establishment">3.2. 接続の確立</h3>

<p>
~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.
</p>

<p>
~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.
</p>

<p>
~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.
</p>

<p>
［
中核~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.
</p>

		</section>
		<section id="connection-reuse">
<h3 title="Connection Reuse">3.3. 接続の再利用</h3>

<p>
`~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＼
</p>
<ul>
	<li>
`~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)＼
</li>
	<li>
`~server$h3から接続が~closeされた
◎
or until the server closes the connection.
</li>
</ul>

<p>
`~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.
</p>

<p>
何らかの理由で，当の証明書は新たな`生成元$に関して受容-可能でない場合、
当の接続を再利用してはナラナイ
— 新たな`生成元$用には新たな接続を確立するベキである。
当の証明書を検証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.
</p>

<p>
`~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.
</p>

<p>
`~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.
</p>

<p>
`~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].
</p>

		</section>
	</section>
	<section id="http-request-lifecycle">
<h2 title="Expressing HTTP Semantics in HTTP/3">4. ~HTTP3における~HTTP意味論の表出-法</h2>

		<section id="request-response">
<h3 title="HTTP Message Framing">4.1. ~HTTPの~message~frame法</h3>

<p>
`~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.
</p>

<p>
~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.
</p>

<p>
所与の`~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.
</p>

<p>
~HTTP3における
各`~message$（要請／応答）は、
次に挙げるもの `HTTP$r からなる：
◎
An HTTP message (request or response) consists of:
</p>
<ol>
	<li>
`~header節$
⇒
1 個の `HEADERS$ft ~frameとして送信される。
これは、当の~messageの`制御~data$も含む。
◎
the header section, including message control data, sent as a single HEADERS frame,
</li>
	<li>
`内容$（省略可能）
⇒
在るならば，一連の `DATA$ft ~frameとして送信される。
◎
optionally, the content, if present, sent as a series of DATA frames, and
</li>
	<li>
`~trailer節$（省略可能）
⇒
在るならば，
1 個の `HEADERS$ft ~frameとして送信される。
◎
optionally, the trailer section, if present, sent as a single HEADERS frame.
</li>
</ol>

<p>
【！~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].
</p>

<p>
妥当でない連列を成す~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.＼
</p>

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

<p>
`~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.
</p>

<p>
種別が未知な~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.
</p>

<p>
［
`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.
</p>

<p>
`転送~符号法$ `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.
</p>

<p>
応答は、
複数個の`~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.
</p>

<p>
［
`要請$, `応答$
］の交換は、［
`~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.
</p>

<p>
`~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.
</p>

<p>
`~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.＼
</p>
<ul>
	<li>
<p>
`~server$h3は：
◎
When the server＼
</p>
		<ul>
			<li>
当の要請を成す残りを受信する必要がないときは、
次を順に行ってもヨイ
⇒＃
当の`要請~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.＼
</li>
			<li>
`要請~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.＼
</li>
		</ul>
	</li>
	<li>
<p>
`~client$h3は：
◎
Clients＼
</p>
		<ul>
			<li>
そのような`完全$な応答を［
当の要請が中途で終了された結果として，破棄して
］はナラナイ。
`~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.＼
</li>
			<li>
`~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.
</li>
		</ul>
	</li>
</ul>

			<section id="request-cancellation">
<h4 title="Request Cancellation and Rejection">4.1.1. 要請の取消nと却下</h4>

<p>
`要請~stream$が~openされたなら、
どちらの端点も，当の要請を取消してヨイ。
`~client$h3は、［
対する応答に もはや関心がない場合
］に要請を取消す。
`~server$h3は、［
応答-可能でない場合／応答しないことを選んだ場合
］に要請を取消す。
`~server$h3は，すでに処理を始めた要請に対しては、
アリなときは，［
それを取消すことなく，適切な`状態s~code$を伴う`応答$を送信する
］ことが`推奨される^2119。
◎
Once a request stream has been opened, the request MAY be cancelled by either endpoint. Clients cancel requests if the response is no longer of interest; servers cancel requests if they are unable to or choose not to respond. When possible, it is RECOMMENDED that servers send an HTTP response with an appropriate status code rather than cancelling a request it has already begun processing.
</p>

<p>
実装は、
方向を問わず，依然として~openな`~stream$を中途で終了することにより，
要請を取消すベキである。
そうするためには、
実装は，`~stream$の［
送信~部を`~reset$して，
受信~部に対する読取りを`中止-$する
］
— `QUIC-TRANSPORT$r `2.4＠~QUICv1#section-2.4§を見よ。
◎
Implementations SHOULD cancel requests by abruptly terminating any directions of a stream that are still open. To do so, an implementation resets the sending parts of streams and aborts reading on the receiving parts of streams; see Section 2.4 of [QUIC-TRANSPORT].
</p>

<p>
`~server$h3が，応用の処理を遂行することなく要請を取消すとき、
当の要請は，
`却下された^dfn
ものと見なされる。
`~server$h3は、
自身の応答~streamを~error~code `H3_REQUEST_REJECTED$er で`中止-$するベキである。
この文脈における
`処理された^dfn
は、
`~stream$からの何らかの~dataが，
より高い層を成す何らかの~software
— 結果として何らかの動作をとるかもしれないそれ —
に渡されたことを意味する。
`~client$h3は、
当の要請を
— それは、［
まったく送信されず，後で試行し直すことが許容された
］かのように —
`~server$h3により却下されたものと扱える。
◎
When the server cancels a request without performing any application processing, the request is considered "rejected". The server SHOULD abort its response stream with the error code H3_REQUEST_REJECTED. In this context, "processed" means that some data from the stream was passed to some higher layer of software that might have taken some action as a result. The client can treat requests rejected by the server as though they had never been sent at all, thereby allowing them to be retried later.
</p>

<p>
`~server$h3は、
自身が一部でも処理した要請~用には，
`~error~code$ `H3_REQUEST_REJECTED$er を利用してはナラナイ。
`~server$h3は、
要請を部分的に処理した後に応答を放棄するときは，
応答~streamを`~error~code$ `H3_REQUEST_CANCELLED$er で`中止-$するベキである。
◎
Servers MUST NOT use the H3_REQUEST_REJECTED error code for requests that were partially or fully processed. When a server abandons a response after partial processing, it SHOULD abort its response stream with the error code H3_REQUEST_CANCELLED.
</p>

<p>
`~client$h3は、
要請を取消すときは，
`~error~code$ `H3_REQUEST_CANCELLED$er を利用するベキである。
`~server$h3は、
この`~error~code$の受領に際しては，［
【要請に対する】処理を何も遂行してなかった場合には、
`~error~code$ `H3_REQUEST_REJECTED$er を利用して，応答を中途で終了して
］もヨイ。
`~client$h3は、
`~error~code$ `H3_REQUEST_REJECTED$er を利用してはナラナイ
— ただし、
`~server$h3が，この`~error~code$で［
`要請~stream$の~closureを要請した
］ときは除く
【この例外は何のためにある？】。
◎
Client SHOULD use the error code H3_REQUEST_CANCELLED to cancel requests. Upon receipt of this error code, a server MAY abruptly terminate the response using the error code H3_REQUEST_REJECTED if no processing was performed. Clients MUST NOT use the H3_REQUEST_REJECTED error code, except when a server has requested closure of the request stream with this error code.
</p>

<p>
ある`~stream$が，`完全$な応答を受信した後に取消された場合、
`~client$h3は，当の応答を
— その取消nを無視して —
利用してもヨイ。
しかしながら，応答を部分的に受信した後に取消された場合、
当の応答を利用するベキでない。
`~client$h3が要請を安全に試行し直せるのは、
その~methodが
— `GET$m, `PUT$m, `DELETE$m など —
`冪等$である場合に限られ，
他の要請は自動的に試行し直すベキでない
— ただし、
何らかの手段により［
当の要請の`~method$とは独立に，当の要請の意味論は`冪等$であることを知った場合／
元の要請は決して適用されないことを検出した場合
］を除く。
詳細は、
`HTTP$r `冪等~method＠~HTTPsem#idempotent.methods§を見よ。
◎
If a stream is cancelled after receiving a complete response, the client MAY ignore the cancellation and use the response. However, if a stream is cancelled after receiving a partial response, the response SHOULD NOT be used. Only idempotent actions such as GET, PUT, or DELETE can be safely retried; a client SHOULD NOT automatically retry a request with a non-idempotent method unless it has some means to know that the request semantics are idempotent independent of the method or some means to detect that the original request was never applied. See Section 9.2.2 of [HTTP] for more details.
</p>

			</section>
			<section id="malformed">
<h4 title="Malformed Requests and Responses">4.1.2. 不正形な~message【！request or response】</h4>

<p>
`~message$【！request or response】が
`不正形@
である（ `malformed^en 【 “~~正しく形成されていない” 】）とは、［
他では妥当【！sequence of frames】であるが，次のいずれかに因り妥当でないもの
］をいう：
◎
A malformed request or response is one that is an otherwise valid sequence of frames but is invalid due to:
</p>
<ul>
	<li>
禁制された［
`~field$／`疑似-~header$
］が在る
◎
the presence of prohibited fields or pseudo-header fields,
</li>
	<li>
義務的な`疑似-~header$が無い
◎
the absence of mandatory pseudo-header fields,
</li>
	<li>
いずれかの`疑似-~header$の値が妥当でない
◎
invalid values for pseudo-header fields,
</li>
	<li>
ある`疑似-~header$が，`~field$より後に在る
◎
pseudo-header fields after fields,
</li>
	<li>
妥当でない~message連列を成している
【例：`最終-応答$に後続している`非最終-応答$】
◎
an invalid sequence of HTTP messages,
</li>
	<li>
ある`~field名$が大文字を内包している
◎
the inclusion of uppercase field names, or
</li>
	<li>
ある［
`~field名$／~field値
］が妥当でない文字を内包している
◎
the inclusion of invalid characters in field names or values.
</li>
</ul>

<p class="trans-note">【
これらは、
網羅的ではない
— 一般に，何をもって`不正形$とされるかは、
この仕様~内の各所にて個別に指定される
（例：次の段落）。
】</p>

<p>
`~message$【！request or response】のうち［
`Content-Length$h ~headerを包含するときは、
`内容$も伴う
］ものと定義されたもの【！`HTTP$r `Content-Length§h】は、
その`~field値$が［
受信した `DATA$ft ~frameの長さの総和
］に等しくない場合には，`不正形$とされる。
応答のうち［
`Content-Length$h が在っても、
`内容$は決して伴わない
］ものと定義されたものは、
`内容$を内包する `DATA$ft ~frameが無い場合でも，［
0 でない値をとる `Content-Length$h ~header
］を伴い得る。
◎
A request or response that is defined as having content when it contains a Content-Length header field (Section 8.6 of [HTTP]) is malformed if the value of the Content-Length header field does not equal the sum of the DATA frame lengths received. A response that is defined as never having content, even when a Content-Length is present, can have a non-zero Content-Length header field even though no content is included in DATA frames.
</p>

<p>
`~message$【！request or response】を処理する（`~tunnel$として動作していない）`媒介者$は、
`不正形$な`~message$【！request or response】を回送してはナラナイ。
`不正形$な`~message$【！request or response】が検出されたときは、
`~stream~error$( `H3_MESSAGE_ERROR$er )
として扱わなければナラナイ。
◎
Intermediaries that process HTTP requests or responses (i.e., any intermediary not acting as a tunnel) MUST NOT forward a malformed request or response. Malformed requests or responses that are detected MUST be treated as a stream error of type H3_MESSAGE_ERROR.
</p>

<p>
`~server$h3は，
`不正形$な要請に対しては、
`~stream$を［
~closeする／`~reset$する
］に先立って，
当の~errorを指示している`応答$を送信してもヨイ。
`~client$h3は、
`不正形$な応答を受容してはナラナイ。
これらの要件は、
~HTTPに対する［
共通的な，いくつかの型の攻撃
］に抗して保護することが意図されることに注意。
これらの要件は、
故意に厳密である
— さもなければ、
実装は，これらの脆弱性を晒し得るので。
◎
For malformed requests, a server MAY send an HTTP response indicating the error prior to closing or resetting the stream. Clients MUST NOT accept a malformed response. Note that these requirements are intended to protect against several types of common attacks against HTTP; they are deliberately strict because being permissive can expose implementations to these vulnerabilities.
</p>

			</section>
		</section>
		<section id="header-formatting">
<h3 title="HTTP Fields">4.2. ~HTTP~field</h3>

<p>
`~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 &lt;https://www.iana.org/assignments/http-fields/&gt;. 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.
</p>

<p>
`~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.
</p>

<p>
~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.
</p>

<p>
これに対する唯一の例外は，
`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".
</p>

<p>
~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.
</p>

			<section id="field-compression">
<h4 title="Field Compression">4.2.1. ~field圧縮</h4>

<p>
`QPACK$r は、
~HPACKの新種を述べる
— それは、［
圧縮により，~~渋滞（ `head-of-line blocking^en ）が どの程度~生じるか
］に対する制御を符号化器に与える。
これは、
圧縮~効率と待時間を~balanceすることを符号化器に許容する。
~HTTP3は、
~QPACKを利用して，［
`~header節$, `~trailer節$
］
— `~header節$内に在る`制御~data$も含む —
を圧縮する。
◎
[QPACK] describes a variation of HPACK that gives an encoder some control over how much head-of-line blocking can be caused by compression. This allows an encoder to balance compression efficiency with latency. HTTP/3 uses QPACK to compress header and trailer sections, including the control data present in the header section.
</p>

<p>
圧縮~効率を上げるため、
圧縮する前に，
`Cookie$h ~header （ `COOKIES$r ）を複数の別々な`~field行l$に
— 各`~field行l$が 1 個以上の `cookie-pair＠~HTTPcookie#p.cookie-pair$p を伴うよう —
分割してもヨイ。
解凍された`~field節$が複数個の~cookie`~field行l$を包含する場合、
それらは、［
~HTTP2, ~HTTP3
］以外の文脈
— ~HTTP11接続や汎用な~HTTP~server応用など —
へ渡す前に，［
2 ~byteからなる区切子 "`; ^c"（~ASCII `0x3b^hex, `0x20^hex ）
］を利用して 1 個の~byte文字列に連結しなければナラナイ。
◎
To allow for better compression efficiency, the Cookie header field ([COOKIES]) MAY be split into separate field lines, each with one or more cookie-pairs, before compression. If a decompressed field section contains multiple cookie field lines, these MUST be concatenated into a single byte string using the two-byte delimiter of "; " (ASCII 0x3b, 0x20) before being passed into a context other than HTTP/2 or HTTP/3, such as an HTTP/1.1 connection, or a generic HTTP server application.
</p>

			</section>
			<section id="header-size-constraints">
<h4 title="Header Size Constraints">4.2.2. ~header~sizeに対する拘束</h4>

<p>
~HTTP3実装は、
自身が個々の`~message$上で受容する［
~headerの最大~size
］に上限を課してもヨイ。
`~server$h3は、
受信した`~header節$が自身が取扱う用意がある~sizeを超えるときは，
`状態s~code$ `431$st （ `RFC6585$r ）を送信できる。
`~client$h3は、
自身が処理できない応答を破棄できる。
`~field節$【！~field~list】の~sizeは、
未圧縮なときの~sizeに基づいて，~byte数で計算される
— ［
`~field名$, `~field値$
］の長さ, および［
各`~field$用の 32 ~byteの~overhead【 `QPACK$r にて定義される】
］も含めて。
◎
An HTTP/3 implementation MAY impose a limit on the maximum size of the message header it will accept on an individual HTTP message. A server that receives a larger header section than it is willing to handle can send an HTTP 431 (Request Header Fields Too Large) status code ([RFC6585]). A client can discard responses that it cannot process. The size of a field list is calculated based on the uncompressed size of fields, including the length of the name and value in bytes plus an overhead of 32 bytes for each field.
</p>

<p>
実装は、
相手の端点に，この上限を助言したいと望む場合には、
`SETTINGS_MAX_FIELD_SECTION_SIZE$sp ~parameter内に~byte数として伝達できる。
この~parameterを受信した実装は、
指示された~sizeを超過する`~header$【！HTTP message header】を送信するベキでない
— 相手の端点は、
それを処理するのを拒否する見込みが高いので。
しかしながら，
`~message$は、
`生成元~server$に達する前に，いくつかの`媒介者$を辿ることもあり
（ `HTTP$r `媒介者＠~HTTPinfra#intermediaries§）、
この上限は，`~message$を処理する各~実装により別々に適用されるので、
この上限を<del>下回る</del><ins>超える</ins>†`~message$は，受容されることは保証されない。
◎
If an implementation wishes to advise its peer of this limit, it can be conveyed as a number of bytes in the SETTINGS_MAX_FIELD_SECTION_SIZE parameter. An implementation that has received this parameter SHOULD NOT send an HTTP message header that exceeds the indicated size, as the peer will likely refuse to process it. However, an HTTP message can traverse one or more intermediaries before reaching the origin server; see Section 3.7 of [HTTP]. Because this limit is applied separately by each implementation that processes the message, messages below this limit are not guaranteed to be accepted.
</p>

<p class="trans-note">【†
`7238$errata（Reported）
】【
この節が`~trailer$にも適用されるかどうかは不明。
】【
~headerの~sizeは、
`~field行l$の~sizeかもしれない。
】</p>

			</section>
		</section>
		<section id="http-control-data">
<h3 title="HTTP Control Data">4.3. ~HTTP制御~data</h3>

<p>
~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].
</p>

<p>
`疑似-~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.
</p>

<p>
`疑似-~header$が妥当になるのは、
それが定義される文脈~内に限られる：
◎
Pseudo-header fields are only valid in the context in which they are defined.＼
</p>
<ul>
	<li>
要請~用に定義された`疑似-~header$は、
応答~内に出現してはナラナイ。
◎
Pseudo-header fields defined for requests MUST NOT appear in responses;＼
</li>
	<li>
応答~用に定義された`疑似-~header$は、
要請~内に出現してはナラナイ。
◎
pseudo-header fields defined for responses MUST NOT appear in requests.＼
</li>
	<li>
`疑似-~header$は、
`~trailer節$に出現してはナラナイ。
◎
Pseudo-header fields MUST NOT appear in trailer sections.＼
</li>
</ul>

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

<p>
すべての`疑似-~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.
</p>

			<section id="request-pseudo-header-fields">
<h4 title="Request Pseudo-Header Fields">4.3.1. 要請~用の疑似-~header</h4>

<p>
要請~用には、
次に挙げる`疑似-~header$が定義される：
◎
The following pseudo-header fields are defined for requests:
</p>

<dl>
	<dt>
`method@ph
</dt>
	<dd>
~HTTP`~method$を包含する。
`HTTP$r 【！`9＠~HTTPsem#methods§】
◎
Contains the HTTP method (Section 9 of [HTTP])
</dd>

	<dt>
`scheme@ph
</dt>
	<dd>
`~target~URI$の `scheme$p 成分を包含する。
`URI$r
【！`3.1＠~RFCx/rfc3986#section-3.1§】
◎
Contains the scheme portion of the target URI (Section 3.1 of [URI]).
</dd>
	<dd>
`scheme@ph `疑似-~header$は、
~schemeに［
"`http$c" ／ "`https$c"
］を伴う~URIに制約されない。
［
`~proxy$／`~gateway$
］は、
要請を非~HTTP~scheme用に翻訳し得る
— 非~HTTP~serviceとヤリトリする~HTTPの利用を可能化するよう。
◎
The :scheme pseudo-header is not restricted to URIs with scheme "http" and "https". A proxy or gateway can translate requests for non-HTTP schemes, enabling the use of HTTP to interact with non-HTTP services.
</dd>
	<dd>
"`https$c" 以外の~schemeを利用するときの指導は、
`3.1.2§を見よ。
◎
See Section 3.1.2 for guidance on using a scheme other than "https".
</dd>

	<dt>
`authority@ph
</dt>
	<dd>
`~target~URI$の `authority$p （権限）成分
（ `URI$r 【！`3.2＠~RFCx/rfc3986#section-3.2§】）
を包含する。
`authority$p は、
~schemeに［
"`http$c" ／ "`https$c"
］を伴う~URI用には，［
非推奨にされた `userinfo$p 下位-成分
］を内包してはナラナイ。
◎
Contains the authority portion of the target URI (Section 3.2 of [URI]). The authority MUST NOT include the deprecated userinfo subcomponent for URIs of scheme "http" or "https".
</dd>
	<dd>
~HTTP11の `request-line＠~HTTPv1#p.request-line$p を正確aに生産し直せることを確保するため、［
`~method$に特有な形をとる`要請~target$を伴う~HTTP11要請
］から翻訳するときには，この`疑似-~header$を省略しなければナラナイ
— `HTTP$r `~target資源の決定-法＠~HTTPsem#target.resource§を見よ。
~HTTP3要請を直に生成する`~client$h3は、
`Host$h ~headerに代えて， `authority$ph `疑似-~header$を利用するベキである。
`媒介者$は，~HTTP3要請を~HTTP11要請に変換するときは、
`Host$h `~field$が無かった場合には，それを［
`authority$ph `疑似-~header$の値を複製する
］ことにより作成しなければナラナイ。
◎
To ensure that the HTTP/1.1 request line can be reproduced accurately, this pseudo-header field MUST be omitted when translating from an HTTP/1.1 request that has a request target in a method-specific form; see Section 7.1 of [HTTP]. Clients that generate HTTP/3 requests directly SHOULD use the :authority pseudo-header field instead of the Host header field. An intermediary that converts an HTTP/3 request to HTTP/1.1 MUST create a Host field if one is not present in a request by copying the value of the :authority pseudo-header field.
</dd>

	<dt>
`path@ph
</dt>
	<dd>
`~target~URI$の［
~path, ~query
］成分を包含する。
（
<del>`path-absolute＠~RFCx/rfc3986#section-3.3$p</del>
<ins>`absolute-path$p</ins>
【`7014$errata（Verified）】
生成規則,
後続する省略可能な［
文字 "`?^c" （~ASCII `0x3f^hex ）, `query$p 生成規則
］が成す並び `URI$r
【！`3.3＠~RFCx/rfc3986#section-3.3§】
【！`3.4＠~RFCx/rfc3986#section-3.4§】
）。
◎
Contains the path and query parts of the target URI (the "path-absolute" production and optionally a ? character (ASCII 0x3f) followed by the "query" production; see Sections 3.3 and 3.4 of [URI].
</dd>
	<dd>
この`疑似-~header$は、［
"`http$c" ／ "`https$c"
］~URI用には，空にしてはナラナイ。
~path成分を包含しない［
"`http$c" ／ "`https$c"
］~URIは、
値 "`/^c" （~ASCII `0x2f^hex ）を内包しなければナラナイ。
`OPTIONS$m 要請は、
~path成分を内包しない場合は，
`path$ph `疑似-~header$用に値 "`*^c" (ASCII `0x2a^hex ）を内包する
— `HTTP$r `~target資源の決定-法＠~HTTPsem#target.resource§を見よ。
◎
This pseudo-header field MUST NOT be empty for "http" or "https" URIs; "http" or "https" URIs that do not contain a path component MUST include a value of / (ASCII 0x2f). An OPTIONS request that does not include a path component includes the value * (ASCII 0x2a) for the :path pseudo-header field; see Section 7.1 of [HTTP].
</dd>
</dl>

<p>
すべての~HTTP3要請は、［
`method$ph, `scheme$ph, `path$ph
］`疑似-~header$用に，正確に 1 個の値を内包しなければナラナイ
— ただし、
`CONNECT$m 要請の場合は除く（`4.4§を見よ）。
◎
All HTTP/3 requests MUST include exactly one value for the :method, :scheme, and :path pseudo-header fields, unless the request is a CONNECT request; see Section 4.4.
</p>

<p>
`scheme$ph `疑似-~header$により識別される~schemeが `authority$p 成分を義務的としている場合
（ ［
"`http$c", "`https$c"
］を含む）、
当の要請は，［
`authority$ph `疑似-~header$／
`Host$h ~header
］どちらかは包含しなければナラナイ
— いずれも、
在るならば，値は空にしてはナラナイ。
両~header【！~field】とも在る場合、
同じ値を包含しなければナラナイ。
`authority$p 成分が［
~schemeにより義務的とされておらず，`要請~target$内に供されなかった
］場合、
当の要請は，［
`authority$ph `疑似-~header$／
`Host$h ~header
］を包含してはナラナイ。
◎
If the :scheme pseudo-header field identifies a scheme that has a mandatory authority component (including "http" and "https"), the request MUST contain either an :authority pseudo-header field or a Host header field. If these fields are present, they MUST NOT be empty. If both fields are present, they MUST contain the same value. If the scheme does not have a mandatory authority component and none is provided in the request target, the request MUST NOT contain the :authority pseudo-header or Host header fields.
</p>

<p>
`要請$のうち［
義務的な`疑似-~header$が省略されたもの／
ある`疑似-~header$が妥当でない値を包含するもの
］は、
`不正形$である。
◎
An HTTP request that omits mandatory pseudo-header fields or contains invalid values for those pseudo-header fields is malformed.
</p>

<p>
~HTTP3は、［
~HTTP11においては `request-line＠~HTTPv1#p.request-line$p が内包していた，
~version識別子
］を運ぶ仕方を定義しない。
~HTTP3における要請の~protocol~versionは、
暗黙的に "`3.0^c" になる。
◎
HTTP/3 does not define a way to carry the version identifier that is included in the HTTP/1.1 request line. HTTP/3 requests implicitly have a protocol version of "3.0".
</p>

			</section>
			<section id="response-pseudo-header-fields">
<h4 title="Response Pseudo-Header Fields">4.3.2. 応答~用の疑似-~header</h4>

<p>
応答~用には、
`status@ph
`疑似-~header$のみが定義される
— それは、
`状態s~code$ `HTTP$r【！`15＠~HTTPsem#status.codes§】 を運ぶ。
すべての応答は、
この`疑似-~header$を内包しなければナラナイ
— さもなければ、
当の応答は`不正形$である【！`4.1.2§】。
◎
For responses, a single ":status" pseudo-header field is defined that carries the HTTP status code; see Section 15 of [HTTP]. This pseudo-header field MUST be included in all responses; otherwise, the response is malformed (see Section 4.1.2).
</p>

<p>
~HTTP3は、［
~HTTP11においては `status-line＠~HTTPv1#p.status-line$p が内包していた，［
~version識別子／`事由~句$
］］を運ぶ仕方を定義しない。
~HTTP3における応答の~protocol~versionは、
暗黙的に "`3.0^c" になる。
◎
HTTP/3 does not define a way to carry the version or reason phrase that is included in an HTTP/1.1 status line. HTTP/3 responses implicitly have a protocol version of "3.0".
</p>

			</section>
		</section>
		<section id="connect">
<h3 title="The CONNECT Method">4.4. `CONNECT^m ~method</h3>

<p>
`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.
</p>

<p>
`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.
</p>

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

<p>
`CONNECT$m 要請は、
次に従って構築しなければナラナイ：
◎
A CONNECT request MUST be constructed as follows:
</p>
<ul>
	<li>
`method$ph `疑似-~header$は "`CONNECT^c" に設定する。
◎
The :method pseudo-header field is set to "CONNECT"
</li>
	<li>
［
`scheme$ph, `path$ph
］`疑似-~header$は省略する。
◎
The :scheme and :path pseudo-header fields are omitted
</li>
	<li>
`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]).
</li>
</ul>

<p>
`要請~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.
</p>

<p>
`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].
</p>

<p>
`~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.
</p>

<p>
`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.
</p>

<p>
~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.
</p>

<p>
~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.
</p>

<p>
対して，~QUIC接続においては、
`~proxy$は：
◎
Correspondingly,＼
</p>
<ul>
	<li>
［
`~stream$／~QUIC接続
］で~errorを検出した場合には、
当の~TCP接続を~closeしなければナラナイ。
◎
if a proxy detects an error with the stream or the QUIC connection, it MUST close the TCP connection.＼
</li>
	<li>
<p>
`~client$h3が［
`~stream$を`~reset$した／
`~stream$からの読取りを`中止-$した
］ことを検出した場合には：
◎
If the proxy detects that the client has reset the stream or aborted reading from the stream,＼
</p>
		<ul>
			<li>
当の~TCP接続を~closeしなければナラナイ。
◎
it MUST close the TCP connection.＼
</li>
			<li>
当の`~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.＼
</li>
		</ul>
	</li>
	<li>
これらの事例すべてにおいて，`~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.
</li>
</ul>

<p>
`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.
</p>

		</section>
		<section id="http-upgrade">
<h3 title="HTTP Upgrade">4.5. ~HTTP `Upgrade^h</h3>

<p>
~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]).
</p>

		</section>
		<section id="server-push">
<h3 title="Server Push">4.6. ~server~push</h3>

<p>
`~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.
</p>

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

<p>
各`~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.
</p>

<p>
`~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.＼
</p>

<p>
`~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.
</p>

<p>
`~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.
</p>

<p>
`~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.
</p>

<p>
【！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.
</p>

<p>
要請には~pushできないものもある。
`~server$h3は、
要請が次に挙げる特質をすべて備えるならば，それを~pushしてもヨイ：
◎
Not all requests can be pushed. A server MAY push requests that have the following properties:
</p>
<ul>
	<li>
`~cache可能$である
— `HTTP$r `~methodと~caching＠~HTTPsem#cacheable.methods§を見よ
◎
cacheable; see Section 9.2.3 of [HTTP]
</li>
	<li>
`安全$である
`HTTP$r 【！`9.2.1＠~HTTPsem#safe.methods§】
◎
safe; see Section 9.2.1 of [HTTP]
</li>
	<li>
`内容$も`~trailer節$も内包しない
◎
does not include request content or a trailer section
</li>
</ul>

<p>
`~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.
</p>

<div class="p">
<p>
`~client$h3は、［
受信した `PUSH_PROMISE$ft ~frameが運んでいる要請
］が次のいずれかに該当する場合…：
</p>
<ul>
	<li>
`~cache可能$でない
</li>
	<li>
`安全$であることが既知でない
</li>
	<li>
要請の`内容$が在ることを指示する
</li>
	<li>
［
`~server$h3は、
それ【が指示する`生成元$】に対し`権限的$である
］とは見なされない
</li>
</ul>
<p>
…場合：
</p>
<ul>
	<li>
`CANCEL_PUSH$ft ~frameを送信するベキである。
</li>
	<li>
対する応答が在ったとしても，それを［
利用しては／~cacheしては
］ナラナイ。
</li>
</ul>
◎
Clients SHOULD send a CANCEL_PUSH frame upon receipt of a PUSH_PROMISE frame carrying a request that is not cacheable, is not known to be safe, that indicates the presence of request content, or for which it does not consider the server authoritative. Any corresponding responses MUST NOT be used or cached.
</div>

<p>
~pushされた各~応答には、
1 個以上の`~client要請$が結付けられる：
◎
Each pushed response is associated with one or more client requests.＼
</p>
<ul>
	<li>
当の~pushには、
`要請~stream$のうち［
当の `PUSH_PROMISE$ft ~frameが受信されたもの
］が結付けられる。
◎
The push is associated with the request stream on which the PUSH_PROMISE frame was received.＼
</li>
	<li>
同じ`~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.＼
</li>
	<li>
これらの結付けは，~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.
</li>
</ul>

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

<p>
`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.
</p>

<p>
`~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.
</p>

<p>
`~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.
</p>

<p>
`~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.
</p>

<p>
~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.
</p>

		</section>
	</section>
	<section id="connection-closure">
<h2 title="Connection Closure">5. 接続の~closure</h2>

<p>
`~HTTP3接続$が確立されたなら、
~closeされるまで，時間~越しに多数の`~message$【！request or response】用に利用できる。
接続の~closureは、
いくつか異なる仕方で起こり得る。
◎
Once established, an HTTP/3 connection can be used for many requests and responses over time until the connection is closed. Connection closure can happen in any of several different ways.
</p>

		<section id="idle-connections">
<h3 title="Idle Connections">5.1. 遊休中な接続</h3>

<p>
各~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].
</p>

<p>
`~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.
</p>

		</section>
		<section id="connection-shutdown">
<h3 title="Connection Shutdown">5.2. 接続の~shutdown</h3>

<p>
どちらの端点も、
利用している接続を
— それが`遊休中$でないときでも —
停止するものと裁定して，
接続の上品な~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.
</p>

<p>
`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.
</p>

<p>
端点は、
相手の端点から `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.
</p>

<p>
一部の［
要請／~push
］は、
すでに~~通過中にあるかもしれない。
◎
Some requests or pushes might already be in transit:
</p>
<ul>
	<li>
<p>
`~client$h3が `GOAWAY$ft ~frameを受信する前に送信した要請は：
◎
↓</p>
		<ul>
			<li>
その`~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.
</li>
			<li>
他の場合、
処理されたかもしれない
— その状態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.
</li>
		</ul>
<p>
`~server$h3は、［
指示されたもの未満の~IDを伴う`~stream$
］上の個々の要請のうち，処理しなかったものを却下してもヨイ。
◎
Servers MAY reject individual requests on streams below the indicated ID if these requests were not processed.
</p>
	</li>
	<li>
`~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.
</li>
</ul>

<p>
`~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.
</p>

<p>
端点は、
【同じ接続~上で】複数個の［
異なる識別子を指示している `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.
</p>

<p>
端点は、
接続を上品に~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.
</p>

<p>
`~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.
</p>

<p>
所与の［
要請／~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.
</p>

<p>
端点は、
受容した［
要請, ~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.
</p>

<p>
`~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.
</p>

		</section>
		<section id="immediate-application-closure">
<h3 title="Immediate Application Closure">5.3. 即時な応用 ~closure</h3>

<p>
~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.
</p>

<p>
接続を~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.
</p>

<p>
~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].
</p>

		</section>
		<section id="transport-closure">
<h3 title="Transport Closure">5.4. ~transportの~closure</h3>

<p>
~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.
</p>

<p>
ある接続が `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.
</p>

		</section>
	</section>
	<section id="stream-mapping">
<h2 title="Stream Mapping and Usage">6. ~streamの対応付けと用法</h2>

<p>
`~QUIC~stream$は、
依拠-可能かつ順序通りな［
~byte列の送達
］を供するが、
異なる`~QUIC~stream$どうしにおける送達の順序については，何も保証されない。
~QUICの~version 1 においては、
~HTTP~frameを包含している~stream~dataは，
~QUIC `STREAM^ft ~frameにより運ばれるが、
この~frame法は，~HTTP~frame化~層からは不可視である。
【~QUIC】~transport層は、
依拠-可能な~byte~streamを応用に公開するよう，
受信した~stream~dataを~bufferして順序付ける。
~QUICは，［
同じ~streamの中の順序通りでない送達
］も許可するが、
~HTTP3は，この特能を用立てない。
◎
A QUIC stream provides reliable in-order delivery of bytes, but makes no guarantees about order of delivery with regard to bytes on other streams. In version 1 of QUIC, the stream data containing HTTP frames is carried by QUIC STREAM frames, but this framing is invisible to the HTTP framing layer. The transport layer buffers and orders received stream data, exposing a reliable byte stream to the application. Although QUIC permits out-of-order delivery within a stream, HTTP/3 does not make use of this feature.
</p>

<p>
`~QUIC~stream$には、
`一方向~stream@
— その起動元から`受信器$への~dataに限り運ぶもの —
も，
`双方向~stream@
— 両~方向に~dataを運ぶもの —
もある。
`~stream$は、［
`~client$h3, `~server$h3
］どちらからも起動できる。
`~QUIC~stream$についての，より詳細は、
`QUIC-TRANSPORT$r `2＠~QUICv1#section-2§を見よ。
◎
QUIC streams can be either unidirectional, carrying data only from initiator to receiver, or bidirectional, carrying data in both directions. Streams can be initiated by either the client or the server. For more detail on QUIC streams, see Section 2 of [QUIC-TRANSPORT].
</p>

<p>
~HTTPの`~field$その他の~dataが~QUIC越しに送信されるときは、
~QUIC層が~stream管理のほとんどを取扱う。
~HTTPは、
~QUICを利用しているときは，多重化を別々に行う必要はない
— `~QUIC~stream$越しに送信される~dataは、
常に，［
特定0の~HTTP~transaction／
`~HTTP3接続$~全体の文脈
］に対応付けられる。
◎
When HTTP fields and data are sent over QUIC, the QUIC layer handles most of the stream management. HTTP does not need to do any separate multiplexing when using QUIC: data sent over a QUIC stream always maps to a particular HTTP transaction or to the entire HTTP/3 connection context.
</p>

		<section id="request-streams">
<h3 title="Bidirectional Streams">6.1. 双方向~stream</h3>

<p>
`~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.
</p>

<p>
このことは、
`~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.
</p>

<p>
~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.
</p>

		</section>
		<section id="unidirectional-streams">
<h3 title="Unidirectional Streams">6.2. 一方向~stream</h3>

<p>
`一方向~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.
</p>

<figure>
<pre class="frame-diagram">
`一方向~stream$の~stream~header {
  `~stream種別$ (i),
}
◎
Unidirectional Stream Header {
  Stream Type (i),
}
</pre>
<figcaption>
図 1：
`一方向~stream$の~stream~header
◎
Figure 1: Unidirectional Stream Header
</figcaption></figure>

<p>
この文書においては、
【`一方向~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).
</p>

<p>
`~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.
</p>

<p>
互いの端点は、
`制御~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.
</p>

<p>
端点には、［
相手の端点が、
~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.
</p>

<p>
~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.
</p>

<p>
ある種の`~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.
</p>

<p>
実装は、
`~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.
</p>

<p>
`送信器$は、
他が指定されない限り，
`一方向~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.
</p>

			<section id="control-streams">
<h4 title="Control Streams">6.2.1. 制御~stream</h4>

<p>
`制御~stream@
は、
`~stream種別$ `0x00^hex により指示される。
この`~stream$上の~dataは、
`7.2§ にて定義されるとおり，
一連の~HTTP3~frameからなる。
◎
A control stream is indicated by a stream type of 0x00. Data on this stream consists of HTTP/3 frames, as defined in Section 7.2.
</p>

<p>
双方の端点【！Each side】は、
接続の始めに 1 個の`制御~stream$を起動してから，
この`~stream$上の最初の~frameとして `SETTINGS$ft ~frameを送信しなければナラナイ。
この`~stream$の【にて受信された】最初の~frameの~frame種別が他の種別である場合、
`接続~error$( `H3_MISSING_SETTINGS$er )
として扱わなければナラナイ。
どちらの端点も【自身が起動する】`制御~stream$は、
 1 個に限り許可される
— `制御~stream$であると主張している 2 個目の~streamの受領は、
`接続~error$( `H3_STREAM_CREATION_ERROR$er )
として扱わなければナラナイ。
`送信器$は、
`制御~stream$を~closeしてはナラナイ。
`受信器$は、
`制御~stream$を~closeするよう`送信器$に要請してはナラナイ。
どの時点であれ，
どちらかの`制御~stream$が~closeされた場合、
`接続~error$( `H3_CLOSED_CRITICAL_STREAM$er )
として扱わなければナラナイ。
`接続~error$は、
`8§にて述べられる。
◎
Each side MUST initiate a single control stream at the beginning of the connection and send its SETTINGS frame as the first frame on this stream. If the first frame of the control stream is any other frame type, this MUST be treated as a connection error of type H3_MISSING_SETTINGS. Only one control stream per peer is permitted; receipt of a second stream claiming to be a control stream MUST be treated as a connection error of type H3_STREAM_CREATION_ERROR. The sender MUST NOT close the control stream, and the receiver MUST NOT request that the sender close the control stream. If either control stream is closed at any point, this MUST be treated as a connection error of type H3_CLOSED_CRITICAL_STREAM. Connection errors are described in Section 8.
</p>

<p>
`制御~stream$の内容は，他の`~stream$の挙動を管理するために利用されるので、
端点は，［
相手の端点の`制御~stream$が阻まれないことを保つよう，十分な~flow制御~creditを供する
］ベキである。
◎
Because the contents of the control stream are used to manage the behavior of other streams, endpoints SHOULD provide enough flow-control credit to keep the peer's control stream from becoming blocked.
</p>

<p>
【`制御~stream$用には、】
1 個の`双方向~stream$ではなく，
2 個の`一方向~stream$が利用される。
これは、［
可能になり次第，~dataを送信する
］ことを どちらの端点にも許容する。
［
`~client$h3, `~server$h3
］どちらが~stream~dataを最初に送信-可能になるかは、
~QUIC接続~上で~0-RTTが可用かどうかに依存する。
◎
A pair of unidirectional streams is used rather than a single bidirectional stream. This allows either peer to send data as soon as it is able. Depending on whether 0-RTT is available on the QUIC connection, either client or server might be able to send stream data first.
</p>

			</section>
			<section id="push-streams">
<h4 title="Push Streams">6.2.2. ~push~stream</h4>

<p>
`~server~push$は，
~HTTP2において導入された任意選択な特能であり、
要請が為される前に，`~server$h3が応答を起動することを許容する。
詳細は`4.6§を見よ。
◎
Server push is an optional feature introduced in HTTP/2 that allows a server to initiate a response before a request has been made. See Section 4.6 for more details.
</p>

<p>
`~push~stream@
は、
`~stream種別$ `0x01^hex により指示され，
それが充足する~promiseの［
`可変長な整数$として符号化された`~push~ID$
］が後続する。
この`~stream$上の残りの~dataは、［
`7.2§にて定義される，一群の~HTTP3~frame
］からなり，
~promiseされた`~server~push$を
— `4.1§にて定義されるとおり —
［
0 個以上の`非最終-応答$,
後続する 1 個の`最終-応答$
］により充足する。
`~server~push$, `~push~ID$は、
`4.6§にて述べられる。
◎
A push stream is indicated by a stream type of 0x01, followed by the push ID of the promise that it fulfills, encoded as a variable-length integer. The remaining data on this stream consists of HTTP/3 frames, as defined in Section 7.2, and fulfills a promised server push by zero or more interim HTTP responses followed by a single final HTTP response, as defined in Section 4.1. Server push and push IDs are described in Section 4.6.
</p>

<p>
~pushできるのは`~server$h3に限られる
— `~server$h3は、
`~client$h3が起動した`~push~stream$を受信したときは，
`接続~error$( `H3_STREAM_CREATION_ERROR$er )
として扱わなければナラナイ。
◎
Only servers can push; if a server receives a client-initiated push stream, this MUST be treated as a connection error of type H3_STREAM_CREATION_ERROR.
</p>

<figure>
<pre class="frame-diagram">
~push~streamの~stream~header {
  `~stream種別$ (i) = `0x01^hex,
  `~push~ID$ (i),
}
◎
Push Stream Header {
  Stream Type (i) = 0x01,
  Push ID (i),
}
</pre>
<figcaption>
図 2：
~push~streamの~stream~header
◎
Figure 2: Push Stream Header
</figcaption></figure>

<p>
`~client$h3は、
`~push~stream$に対しては，［
その~stream~headerの読取りを終えるまでは，~streamの読取りを`中止-$しない
］ベキである
— さもなければ、
`~client$h3と`~server$h3の間で，［
どの`~push~ID$をすでに消費したか
］について合意に至らなくなり得るので。
◎
A client SHOULD NOT abort reading on a push stream prior to reading the push stream header, as this could lead to disagreement between client and server on which push IDs have already been consumed.
</p>

<p>
同じ`~push~ID$を複数個の`~push~stream$の~stream~headerに内包してナラナイ。
`~client$h3は、
そのような~push~IDの利用を検出した場合，
`接続~error$( `H3_ID_ERROR$er )
として扱わなければナラナイ。
◎
Each push ID MUST only be used once in a push stream header. If a client detects that a push stream header includes a push ID that was used in another push stream header, the client MUST treat this as a connection error of type H3_ID_ERROR.
</p>

			</section>
			<section id="stream-grease">
<h4 title="Reserved Stream Types">6.2.3. 予約-済み~stream種別</h4>

<p>
`~stream種別$
~IN { `0x1f^hex ~MUL %N ~PLUS `0x21^hex ； %N は負でない整数 }
は、［
未知な種別は無視するものとする要件
］を行使するためとして予約される。
これらの`~stream$は：
◎
Stream types of the format 0x1f * N + 0x21 for non-negative integer values of N are reserved to exercise the requirement that unknown types be ignored. These streams＼
</p>
<ul>
	<li>
意味論は無く，応用~層にて~paddingが欲されるときに送信され得る。
◎
have no semantics, and they can be sent when application-layer padding is desired.＼
</li>
	<li>
現在~転送されている~dataが無い接続~上に送信してもヨイ。
◎
They MAY also be sent on connections where no data is currently being transferred.＼
</li>
	<li>
それを受信した端点は、
それに意味があるものと見なしてはナラナイ。
◎
Endpoints MUST NOT consider these streams to have any meaning upon receipt.
</li>
</ul>

<p>
`~stream$の~payload, その長さは、
送信している実装が選ぶ任意の方式で選定される。
実装は、
予約-済み`~stream種別$を送信するときには，
当の`~stream$を~cleanに終了しても`~reset$してもヨイ
— `~reset$するときは、［
`~error~code$ `H3_NO_ERROR$er ／
予約-済み~error~code（`~HTTP3~error~code§）
］を利用するベキである。
◎
The payload and length of the stream are selected in any manner the sending implementation chooses. When sending a reserved stream type, the implementation MAY either terminate the stream cleanly or reset it. When resetting the stream, either the H3_NO_ERROR error code or a reserved error code (Section 8.1) SHOULD be used.
</p>

			</section>
		</section>
	</section>
	<section id="http-framing-layer">
<h2 title="HTTP Framing Layer">7. ~HTTP~frame化~層</h2>

<p>
~HTTP3【！~HTTP】の~frameは、
`6§にて述べたとおり，`~QUIC~stream$上で運ばれる。
~HTTP3は、
3 種の
`~stream種別@
— `制御~stream$, `要請~stream$, `~push~stream$ —
を定義する。
この節は、
~HTTP3における各種~frameの形式, それらが どの`~stream種別$にて許可されるかを述べる
— その概観は、
次の表tを見よ。
~HTTP2~frameと~HTTP3~frameの比較は、
`A.2§にて供される。
◎
HTTP frames are carried on QUIC streams, as described in Section 6. HTTP/3 defines three stream types: control stream, request stream, and push stream. This section describes HTTP/3 frame formats and their permitted stream types; see Table 1 for an overview. A comparison between HTTP/2 and HTTP/3 frames is provided in Appendix A.2.
</p>

<div id="stream-frame-mapping">
<table>
<caption>
表t 1
— ~HTTP3の~frameと`~stream種別$の概観
</caption>
<thead>
<tr><th>~frame
<th>`制御~stream$
<th>`要請~stream$
<th>`~push~stream$
<th>§
<tbody>

<tr><td>`DATA$ft
<td>不可
<td>可
<td>可
<td>`7.2.1§

<tr><td>`HEADERS$ft
<td>不可
<td>可
<td>可
<td>`7.2.2§

<tr><td>`CANCEL_PUSH$ft
<td>可
<td>不可
<td>不可
<td>`7.2.3§

<tr><td>`SETTINGS$ft
<td>可 †
<td>不可
<td>不可
<td>`7.2.4§

<tr><td>`PUSH_PROMISE$ft
<td>不可
<td>可
<td>不可
<td>`7.2.5§

<tr><td>`GOAWAY$ft
<td>可
<td>不可
<td>不可
<td>`7.2.6§

<tr><td>`MAX_PUSH_ID$ft
<td>可
<td>不可
<td>不可
<td>`7.2.7§

<tr><td>予約-済みなもの
<td>可
<td>可
<td>可
<td>`7.2.8§
</table>

◎
Table 1: HTTP/3 Frames and Stream Type Overview
◎
Frame｜Control Stream｜Request Stream｜Push Stream｜Section
DATA ｜No｜Yes｜Yes｜Section 7.2.1
HEADERS ｜No｜Yes｜Yes｜Section 7.2.2
CANCEL_PUSH ｜Yes｜No｜No｜Section 7.2.3
SETTINGS ｜Yes (1)｜No｜No｜Section 7.2.4
PUSH_PROMISE ｜No｜Yes｜No｜Section 7.2.5
GOAWAY ｜Yes｜No｜No｜Section 7.2.6
MAX_PUSH_ID ｜Yes｜No｜No｜Section 7.2.7
Reserved｜Yes｜Yes｜Yes｜Section 7.2.8
</div>

<p>†
`SETTINGS$ft ~frameが生じ得るのは、
`制御~stream$を成す最初の~frameに限られる。
特有な指導は、
関連な節にて供される。
◎
The SETTINGS frame can only occur as the first frame of a Control stream; this is indicated in Table 1 with a (1). Specific guidance is provided in the relevant section.
</p>

<p>
~QUIC~frameと違って、
~HTTP3~frameは，複数個の~packetに またがり得ることに注意。
◎
Note that, unlike QUIC frames, HTTP/3 frames can span multiple packets.
</p>

		<section id="frame-layout">
<h3 title="Frame Layout">7.1. ~frame~layout</h3>

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

<figure>
<pre class="frame-diagram">
~HTTP3~frame形式 {
  種別 (i),
  長さ (i),
  ~frame~payload (..),
}
◎
HTTP/3 Frame Format {
  Type (i),
  Length (i),
  Frame Payload (..),
}
</pre>
<figcaption>
~HTTP3~frame形式
◎
Figure 3: HTTP/3 Frame Format
</figcaption></figure>

<p>
各~frameは、
次に挙げる~fieldを含む：
◎
A frame includes the following fields:
</p>
<dl>
	<dt>
`種別^i
◎
Type:
</dt>
	<dd>
`可変長な整数$
— 当の~frame種別を識別する。
◎
A variable-length integer that identifies the frame type.
</dd>

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

	<dt>
`~frame~payload^i
◎
Frame Payload:
</dt>
	<dd>
~payload
— その意味論は、
`種別^i ~fieldにより決定される。
◎
A payload, the semantics of which are determined by the Type field.
</dd>
</dl>

<p>
各~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.
</p>

<p>
ある`~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.
</p>

		</section>
		<section id="frames">
<h3 title="Frame Definitions">7.2. ~frame定義</h3>

			<section id="frame-data">
<h4>7.2.1. `DATA^ft</h4>

<p>
`DATA^ft ~frame（種別 `0x00^hex ）は、
`~message$【！request or response】の`内容$に結付けられる
任意な［
可変長な~byte列
］たちを伝達する。
◎
DATA frames (type=0x00) convey arbitrary, variable-length sequences of bytes associated with HTTP request or response content.
</p>

<p>
`DATA^ft ~frameには、
ある`~message$【！request or response】が結付けられなければナラナイ。
ある `DATA^ft ~frameが`制御~stream$上で受信された場合、
`受信者$は，
`接続~error$( `H3_FRAME_UNEXPECTED$er )
で応答しなければナラナイ。
◎
DATA frames MUST be associated with an HTTP request or response. If a DATA frame is received on a control stream, the recipient MUST respond with a connection error of type H3_FRAME_UNEXPECTED.
</p>

<figure>
<pre class="frame-diagram">
`DATA$ft ~frame {
  種別 (i) = 0x00,
  長さ (i),
  ~data (..),
}
◎
DATA Frame {
  Type (i) = 0x00,
  Length (i),
  Data (..),
}
</pre>
<figcaption>
`DATA^ft ~frame
◎
Figure 4: DATA Frame
</figcaption></figure>

			</section>
			<section id="frame-headers">
<h4>7.2.2. `HEADERS^ft</h4>

<p>
`HEADERS^ft ~frame（種別 `0x01^hex ）は、
`~field節$を運ぶために利用され，~QPACKを利用して符号化される。
詳細は `QPACK$r を見よ。
◎
The HEADERS frame (type=0x01) is used to carry an HTTP field section that is encoded using QPACK. See [QPACK] for more details.
</p>

<figure>
<pre class="frame-diagram">
`HEADERS$ft ~frame {
  種別 (i) = `0x01^hex,
  長さ (i),
  符号化された`~field節$ (..),
}
◎
HEADERS Frame {
  Type (i) = 0x01,
  Length (i),
  Encoded Field Section (..),
}
</pre>
<figcaption>
`HEADERS^ft ~frame
◎
Figure 5: HEADERS Frame
</figcaption></figure>

<p>
`HEADERS^ft ~frameが送信され得るのは、［
`要請~stream$／`~push~stream$
］上に限られる。
`HEADERS^ft ~frameが`制御~stream$上で受信された場合、
`受信者$は，
`接続~error$( `H3_FRAME_UNEXPECTED$er )
で応答しなければナラナイ。
◎
HEADERS frames can only be sent on request streams or push streams. If a HEADERS frame is received on a control stream, the recipient MUST respond with a connection error of type H3_FRAME_UNEXPECTED.
</p>

			</section>
			<section id="frame-cancel-push">
<h4>7.2.3. `CANCEL_PUSH^ft</h4>

<p>
`CANCEL_PUSH^ft ~frame（種別 `0x03^hex ）は、
`~push~stream$が受信されるに先立って，
`~server~push$の取消nを要請するために利用される。
`CANCEL_PUSH^ft ~frameは、
`~server~push$を［
`可変長な整数$として符号化された`~push~ID$
］により識別する
（`4.6§を見よ）。
◎
The CANCEL_PUSH frame (type=0x03) is used to request cancellation of a server push prior to the push stream being received. The CANCEL_PUSH frame identifies a server push by push ID (see Section 4.6), encoded as a variable-length integer.
</p>

<p>
`~client$h3が送信した `CANCEL_PUSH^ft ~frameは、［
~promiseされた`資源$を受信したいと望まない
］ことを指示する。
`~server$h3は，当の`資源$の送信を中止するベキであるが、
そうするための仕組みは，対応している`~push~stream$の状態に依存する。
`~server$h3は、
当の`~push~stream$をまだ作成していなかった場合，新たなそれを作成しない。
`~push~stream$が~openな場合、
`~server$h3は，その~streamを中途で終了するベキである。
`~push~stream$はすでに終了~されていた場合、
`~server$h3は，当の~streamを［
それでも中途で終了しても何も動作をとらなくても
］ヨイ。
◎
When a client sends a CANCEL_PUSH frame, it is indicating that it does not wish to receive the promised resource. The server SHOULD abort sending the resource, but the mechanism to do so depends on the state of the corresponding push stream. If the server has not yet created a push stream, it does not create one. If the push stream is open, the server SHOULD abruptly terminate that stream. If the push stream has already ended, the server MAY still abruptly terminate the stream or MAY take no action.
</p>

<p>
`~server$h3は、［
`CANCEL_PUSH^ft ~frameを送信する
］ことにより，［
以前に送信した~promiseを充足しない
］ことを指示する。
`~client$h3は、［
対応している~promiseが充足される
］ことを期待できない
— ［
~promiseされた応答を すでに受信して処理した場合
］は別として。
`~server$h3は、［
`~push~stream$を~openしたかどうか
］に関わらず［
~promiseを充足しないことにする
］ものと決定したときには，［
`CANCEL_PUSH^ft ~frameを送信する
］ベキである。
`~server$h3は、［
`~stream$を すでに~openしていた場合
］には，
~stream上の送信を`~error~code$ `H3_REQUEST_CANCELLED$er で`中止-$できる。
◎
A server sends a CANCEL_PUSH frame to indicate that it will not be fulfilling a promise that was previously sent. The client cannot expect the corresponding promise to be fulfilled, unless it has already received and processed the promised response. Regardless of whether a push stream has been opened, a server SHOULD send a CANCEL_PUSH frame when it determines that promise will not be fulfilled. If a stream has already been opened, the server can abort sending on the stream with an error code of H3_REQUEST_CANCELLED.
</p>

<p>
`CANCEL_PUSH^ft ~frameの送信は、
既存の`~push~stream$の状態に対する直な効果は無い。
`~client$h3は、［
対応している`~push~stream$をすでに受信した
］ときには，［
`CANCEL_PUSH^ft ~frameを送信する
］ベキでない。
`~push~stream$は、［
`~client$h3が `CANCEL_PUSH^ft ~frameを送信した後
］にも到着し得る
— `~server$h3は、
`CANCEL_PUSH^ft を処理しなかったかもしれないので。
その場合，`~client$h3は、
当の`~stream$の読取りを`~error~code$ `H3_REQUEST_CANCELLED$er で`中止-$するベキである。
◎
Sending a CANCEL_PUSH frame has no direct effect on the state of existing push streams. A client SHOULD NOT send a CANCEL_PUSH frame when it has already received a corresponding push stream. A push stream could arrive after a client has sent a CANCEL_PUSH frame, because a server might not have processed the CANCEL_PUSH. The client SHOULD abort reading the stream with an error code of H3_REQUEST_CANCELLED.
</p>

<p>
`CANCEL_PUSH^ft ~frameは、
`制御~stream$上に送信される。
`制御~stream$以外の~stream上で受信された `CANCEL_PUSH^ft ~frameは、
`接続~error$( `H3_FRAME_UNEXPECTED$er )
として扱わなければナラナイ。
◎
A CANCEL_PUSH frame is sent on the control stream. Receiving a CANCEL_PUSH frame on a stream other than the control stream MUST be treated as a connection error of type H3_FRAME_UNEXPECTED.
</p>

<figure>
<pre class="frame-diagram">
`CANCEL_PUSH$ft ~frame {
  種別 (i) = 0x03,
  長さ (i),
  `~push~ID$ (i),
}
◎
CANCEL_PUSH Frame {
  Type (i) = 0x03,
  Length (i),
  Push ID (i),
}
</pre>
<figcaption>
`CANCEL_PUSH^ft ~frame
◎
Figure 6: CANCEL_PUSH Frame
</figcaption></figure>

<p>
`CANCEL_PUSH^ft ~frameは、［
`可変長な整数$として符号化された`~push~ID$
］を運ぶ。
`~push~ID^i ~fieldは、
取消されている`~server~push$を識別する
— `4.6§を見よ。
受信した `CANCEL_PUSH^ft ~frameが，
それが参照する`~push~ID$が`最大~push~ID$を超える場合、
`接続~error$( `H3_ID_ERROR$er )
として扱わなければナラナイ。
◎
The CANCEL_PUSH frame carries a push ID encoded as a variable-length integer. The Push ID field identifies the server push that is being cancelled; see Section 4.6. If a CANCEL_PUSH frame is received that references a push ID greater than currently allowed on the connection, this MUST be treated as a connection error of type H3_ID_ERROR.
</p>

<p>
`~client$h3が受信した `CANCEL_PUSH^ft ~frameは、
並替ngに因り，［
まだ `PUSH_PROMISE$ft ~frameにより言及されてない`~push~ID$
］を識別するかもしれない。
`~server$h3は、
受信した `CANCEL_PUSH^ft ~frameの`~push~ID$が［
まだ `PUSH_PROMISE$ft ~frameにより言及されてない
］場合には，
`接続~error$( `H3_ID_ERROR$er )
として扱わなければナラナイ。
◎
If the client receives a CANCEL_PUSH frame, that frame might identify a push ID that has not yet been mentioned by a PUSH_PROMISE frame due to reordering. If a server receives a CANCEL_PUSH frame for a push ID that has not yet been mentioned by a PUSH_PROMISE frame, this MUST be treated as a connection error of type H3_ID_ERROR.
</p>

			</section>
			<section id="frame-settings">
<h4>7.2.4. `SETTINGS^ft</h4>

<p>
`SETTINGS^ft ~frame（種別 `0x04^hex ）は、
環境設定~parameterを伝達する
— それは、
【自身の】選好や相手の端点に対する拘束の挙動など，端点が どう通信するかに影響する。
個々の `SETTINGS^ft ~parameterを指して，
`設定@
ともいう。
各`設定$~parameterの
⇒
識別子を指して，
`設定~識別子@
ともいう。／
値を指して，
`設定~値@
ともいう。
◎
The SETTINGS frame (type=0x04) conveys configuration parameters that affect how endpoints communicate, such as preferences and constraints on peer behavior. Individually, a SETTINGS parameter can also be referred to as a "setting"; the identifier and value of each setting parameter can be referred to as a "setting identifier" and a "setting value".
</p>

<p>
`SETTINGS^ft ~frameは、
常に，`~HTTP3接続$~全体に適用される
— 決して，単独の`~stream$ではなく。
互いの端点は、
各`制御~stream$【！`6.2.1§】の最初の~frameとして
`SETTINGS^ft ~frameを送信しなければナラナイ
— それは、
後続な~frameとして送信してはナラナイ。
端点は、
ある`制御~stream$上で `SETTINGS^ft ~frameを重ねて受信した場合には，
`接続~error$( `H3_FRAME_UNEXPECTED$er )
で応答しなければナラナイ。
◎
SETTINGS frames always apply to an entire HTTP/3 connection, never a single stream. A SETTINGS frame MUST be sent as the first frame of each control stream (see Section 6.2.1) by each peer, and it MUST NOT be sent subsequently. If an endpoint receives a second SETTINGS frame on the control stream, the endpoint MUST respond with a connection error of type H3_FRAME_UNEXPECTED.
</p>

<p>
端点は、
`SETTINGS^ft ~frameを`制御~stream$以外の`~stream$上に送信してはナラナイ。
端点は、
`SETTINGS^ft ~frameを`制御~stream$以外の【！different】`~stream$上で受信した場合には、
`接続~error$( `H3_FRAME_UNEXPECTED$er )
で応答しなければナラナイ。
◎
SETTINGS frames MUST NOT be sent on any stream other than the control stream. If an endpoint receives a SETTINGS frame on a different stream, the endpoint MUST respond with a connection error of type H3_FRAME_UNEXPECTED.
</p>

<p>
各 `SETTINGS^ft ~parameterは、
折衝されない
— それらは、［
それを送信した相手の端点の特性を述べる／
それを受信した相手の端点により利用され得る
］。
しかしながら、
`SETTINGS^ft の利用は，折衝を含意し得る：
互いの端点は、
`SETTINGS^ft を利用して，自身が~supportする値たちが成す集合を広告する。
各`設定$の定義は、
互いの端点が［
この 2 つの集合をどう組合せて，どの選択を利用するものと結論するか
］を述べる。
`SETTINGS^ft は、［
当の選択の効果がいつ発揮されるか
］を［
識別するための仕組み
］は供さない。
◎
SETTINGS parameters are not negotiated; they describe characteristics of the sending peer that can be used by the receiving peer. However, a negotiation can be implied by the use of SETTINGS: each peer uses SETTINGS to advertise a set of supported values. The definition of the setting would describe how each peer combines the two sets to conclude which choice will be used. SETTINGS does not provide a mechanism to identify when the choice takes effect.
</p>

<p>
互いの端点は、
同じ~parameter用に異なる値を広告し得る。
例えば、
`~client$h3は［
応答における巨大な`~field節$を消費する用意がある
］かもしれない一方で，
`~server$h3は［
要請の~sizeについて，もっと用心深い
］かもしれない。
◎
Different values for the same parameter can be advertised by each peer. For example, a client might be willing to consume a very large response field section, while servers are more cautious about request size.
</p>

<p>
`SETTINGS^ft ~frame内に
同じ`設定~識別子$が複数回~生じてはナラナイ。
`受信器$は、
重複な`設定~識別子$が在る場合には，
`接続~error$( `H3_SETTINGS_ERROR$er )
として扱ってもヨイ。
◎
The same setting identifier MUST NOT occur more than once in the SETTINGS frame. A receiver MAY treat the presence of duplicate setting identifiers as a connection error of type H3_SETTINGS_ERROR.
</p>

<p>
`SETTINGS^ft ~frameを成す~payloadは、
0 個以上の~parameterからなる。
各~parameterは、
`設定$の［
識別子, 値
］からなり，どちらも`可変長な整数$として符号化される。
◎
The payload of a SETTINGS frame consists of zero or more parameters. Each parameter consists of a setting identifier and a value, both encoded as QUIC variable-length integers.
</p>

<figure>
<pre class="frame-diagram">
`設定$ {
  識別子 (i),
  値 (i),
}

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

SETTINGS Frame {
  Type (i) = 0x04,
  Length (i),
  Setting (..) ...,
}
</pre>
<figcaption>
`SETTINGS^ft ~frame
◎
Figure 7: SETTINGS Frame
</figcaption></figure>

<p>
実装は、
設定~parameterのうち，自身が解さない識別子を伴うものを無視しなければナラナイ。
◎
An implementation MUST ignore any parameter with an identifier it does not understand.
</p>

				<section id="settings-parameters">
<h5 title="Defined SETTINGS Parameters">7.2.4.1. 定義-済み `SETTINGS^ft ~parameter</h5>

<p>
~HTTP3においては、
次に挙げる`設定$が定義される：
◎
The following settings are defined in HTTP/3:
</p>
<dl>
	<dt>
`SETTINGS_MAX_FIELD_SECTION_SIZE@sp
( `0x06^hex )
</dt>
	<dd>
既定の値は制限されない。
用法は`4.2.2§を見よ
◎
The default value is unlimited. See Section 4.2.2 for usage.
</dd>
</dl>

<p>
`設定~識別子$
~IN { `0x1f^hex ~MUL %N ~PLUS `0x21^hex ； %N は負でない整数 }
は、［
未知な識別子は無視するとする要件
］を行使するためとして予約される。
そのような`設定$には、
定義される意味は無く，実装が選定する どの値もとり得る。
端点は、
自身の `SETTINGS^ft ~frame内に，そのような`設定$を 1 個以上は内包するベキである。
端点は、
そのような`設定$の受領に際して，それに意味があると見なしてはナラナイ。
◎
Setting identifiers of the format 0x1f * N + 0x21 for non-negative integer values of N are reserved to exercise the requirement that unknown identifiers be ignored. Such settings have no defined meaning. Endpoints SHOULD include at least one such setting in their SETTINGS frame. Endpoints MUST NOT consider such settings to have any meaning upon receipt.
◎
Because the setting has no defined meaning, the value of the setting can be any value the implementation selects.
</p>

<p>
`HTTP/2$rにて定義された`設定~識別子$のうち
対応する~HTTP3`設定$は無いものも予約される（`11.2.2§）。
これらの予約-済みな`設定$は、
送信してはナラナイ。
これらの予約-済みな`設定$の受領は、
`接続~error$( `H3_SETTINGS_ERROR$er )
として扱わなければナラナイ。
◎
Setting identifiers that were defined in [HTTP/2] where there is no corresponding HTTP/3 setting have also been reserved (Section 11.2.2). These reserved settings MUST NOT be sent, and their receipt MUST be treated as a connection error of type H3_SETTINGS_ERROR.
</p>

<p>
追加的な`設定$は、
~HTTP3に対する拡張により定義され得る
— 詳細は`9§を見よ。
◎
Additional settings can be defined by extensions to HTTP/3; see Section 9 for more details.
</p>

				</section>
				<section id="settings-initialization">
<h5 title="Initialization">7.2.4.2. 初期化</h5>

<p>
~HTTP実装は、
相手の端点の［
各`設定$についての現在の理解
］に基づいて妥当でなくなるような［
~frame／要請
］を送信してはナラナイ。
◎
An HTTP implementation MUST NOT send frames or requests that would be invalid based on its current understanding of the peer's settings.
</p>

<p>
すべての`設定$は、
初期~値から始まる。
互いの端点は、
相手の端点の `SETTINGS^ft ~frameが到着する前までは，
これらの初期~値を利用して各`~message$を送信するベキである
— `設定$群を運んでいる~packetは、［
喪失され得る／遅延され得る
］ので。
各`設定$は、
`SETTINGS^ft ~frameが到着したとき，その新たな値に変更される。
◎
All settings begin at an initial value. Each endpoint SHOULD use these initial values to send messages before the peer's SETTINGS frame has arrived, as packets carrying the settings can be lost or delayed. When the SETTINGS frame arrives, any settings are changed to their new values.
</p>

<p>
これにより、［
`~message$を送信する前に `SETTINGS^ft ~frameを待機する必要
］は除去される。
端点は、
`SETTINGS^ft ~frameを送信するに先立って，
相手の端点から~dataが受信されることを要求してはナラナイ
— `設定$群は、
~transportが~dataの送信~用に準備済みになり次第，送信しなければナラナイ。
◎
This removes the need to wait for the SETTINGS frame before sending messages. Endpoints MUST NOT require any data to be received from the peer prior to sending the SETTINGS frame; settings MUST be sent as soon as the transport is ready to send data.
</p>

<p>
`~client$h3による各`設定$の`~server$h3における初期~値は、
当の設定の既定の値になる。
◎
For servers, the initial value of each client setting is the default value.
</p>

<p>
`~client$h3が~1-RTT~QUIC接続を利用している場合
⇒
`~server$h3による各`設定$の`~client$h3における初期~値は、
当の設定の既定の値になる。
各［
~1-RTT~key【？】
］は、［
~QUICにより処理されている `SETTINGS^ft を包含している~packet
］に先立って，常に可用になる
— `~server$h3が `SETTINGS^ft を即時に送信する場合でも。
`~client$h3は、［
要請を送信する前に `SETTINGS^ft が到着するまで不定期に待機する
］ベキでないが、
最初の要請を送信する前に `SETTINGS^ft が処理される見込みを高めるため，
受信した各~datagramを処理するベキである。
◎
For clients using a 1-RTT QUIC connection, the initial value of each server setting is the default value. 1-RTT keys will always become available prior to the packet containing SETTINGS being processed by QUIC, even if the server sends SETTINGS immediately. Clients SHOULD NOT wait indefinitely for SETTINGS to arrive before sending requests, but they SHOULD process received datagrams in order to increase the likelihood of processing SETTINGS before sending the first request.
</p>

<p>
~0-RTT~QUIC接続が利用されているときは：
◎
When a 0-RTT QUIC connection is being used,＼
</p>
<ul>
	<li>
~serverによる各`設定$の`~client$h3における初期~値は、
以前の~sessionにおいて利用された値になる。
`~client$h3は、
引継ぎ情報が供された所では，［
`~HTTP3接続$において`~server$h3が供した`設定$群
］を格納するベキであるが、
ある種の事例においては，`設定$群を格納しないことを任意選択してもヨイ
（例：
`SETTINGS^ft ~frameより前に，
~session~ticketを受信した場合）。
`~client$h3は、
~0-RTTを試みるときには，以前に格納した`設定$群
— 格納した`設定~値$が無い`設定$に対しては，それらの既定の値 —
に準拠しなければナラナイ。
`~server$h3から，新たな`設定$群が供されたなら、
`~client$h3は，それらの値に準拠しなければナラナイ。
◎
the initial value of each server setting is the value used in the previous session. Clients SHOULD store the settings the server provided in the HTTP/3 connection where resumption information was provided, but they MAY opt not to store settings in certain cases (e.g., if the session ticket is received before the SETTINGS frame). A client MUST comply with stored settings -- or default values if no values are stored -- when attempting 0-RTT. Once a server has provided new settings, clients MUST comply with those values.
</li>
	<li>
`~server$h3は、
自身が広告した`設定$群を記憶しておくことも，あるいは［
完全性が保護された［
値【`設定~値$】の複製
］］を~ticket内に格納して，~0-RTT~dataを受容するときに その情報を回復する
］こともできる。
`~server$h3は、
~0-RTT~dataを受容するかどうか決定するとき，~HTTP3`設定~値$たちを利用する。
`~server$h3は、［
`~client$h3により記憶された`設定$群が，自身の現在の`設定$群と “互換” である
］こと
— すなわち、［
記憶された`設定$群に準拠している`~client$h3が，
`~server$h3の現在の`設定$群に違反していない
］こと —
を決定できない場合は，
~0-RTT~dataを受容してはナラナイ。
◎
A server can remember the settings that it advertised or store an integrity-protected copy of the values in the ticket and recover the information when accepting 0-RTT data. A server uses the HTTP/3 settings values in determining whether to accept 0-RTT data. If the server cannot determine that the settings remembered by a client are compatible with its current settings, it MUST NOT accept 0-RTT data. Remembered settings are compatible if a client complying with those settings would not violate the server's current settings.
</li>
	<li>
<p>
~0-RTTを受容した`~server$h3は、
後続に［
以前と異なる`設定$群を供する `SETTINGS^ft ~frame
］を送信してもヨイ
— そのような `SETTINGS^ft ~frameを成す`設定$群は：
◎
A server MAY accept 0-RTT and subsequently provide different settings in its SETTINGS frame.＼
</p>
		<ul>
			<li>
［
`~client$h3による当の~0-RTT~dataにより違反され得る
］ように［
値の上限を抑制しては／値を改めては
］ナラナイ。
◎
If 0-RTT data is accepted by the server, its SETTINGS frame MUST NOT reduce any limits or alter any values that might be violated by the client with its 0-RTT data.＼
</li>
			<li>
各`設定$のうち，その既定の値と相違するものすべてを内包しなければナラナイ。
◎
The server MUST include all settings that differ from their default values.＼
</li>
		</ul>
<p>
そのような `SETTINGS^ft ~frameを受信した`~client$h3は、
その`設定$群が次のいずれかに該当する場合には，
`接続~error$( `H3_SETTINGS_ERROR$er )
として扱わなければナラナイ：
◎
↓</p>
		<ul>
			<li>
以前に指定された`設定$群と “互換” でない。
◎
If a server accepts 0-RTT but then sends settings that are not compatible with the previously specified settings, this MUST be treated as a connection error of type H3_SETTINGS_ERROR.＼
</li>
	<li>
以前に`設定~値$として［
既定でない, かつ`~client$h3が解する値
］が指定された`設定$が省略されている
（`設定~識別子$が予約-済みなものは別として）。
◎
If a server accepts 0-RTT but then sends a SETTINGS frame that omits a setting value that the client understands (apart from reserved setting identifiers) that was previously specified to have a non-default value, this MUST be treated as a connection error of type H3_SETTINGS_ERROR.
</li>
		</ul>
	</li>
</ul>

				</section>
			</section>
			<section id="frame-push-promise">
<h4>7.2.5. `PUSH_PROMISE^ft</h4>

<p>
`PUSH_PROMISE$ft ~frame（種別 `0x05^hex ）は、
`要請~stream$上で，`~server$h3から`~client$h3へ［
~promiseされた要請の`~header節$
］を運ぶために利用される。
◎
The PUSH_PROMISE frame (type=0x05) is used to carry a promised request header section from server to client on a request stream.
</p>

<figure>
<pre class="frame-diagram">
`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 (..),
}
</pre>
<figcaption>
`PUSH_PROMISE$ft ~frame
◎
Figure 8: PUSH_PROMISE Frame
</figcaption></figure>

<p>
この~payloadは、
次に挙げるものからなる：
◎
The payload consists of:
</p>

<dl>
	<dt>
`~push~ID$
◎
Push ID:
</dt>
	<dd>
当の`~server~push$【！operation】を識別する`可変長な整数$。
`~push~ID$は、［
`~push~stream$の~stream~header（`4.6§）,
`CANCEL_PUSH$ft ~frame
］内で利用される。
◎
A variable-length integer that identifies the server push operation. A push ID is used in push stream headers (Section 4.6) and CANCEL_PUSH frames.
</dd>

	<dt>
符号化された`~field節$
◎
Encoded Field Section:
</dt>
	<dd>
~QPACKで符号化された［
~promiseされた応答
］用の要請~header群。
詳細は `QPACK$r を見よ。
◎
QPACK-encoded request header fields for the promised response. See [QPACK] for more details.
</dd>
</dl>

<p>
`~server$h3は、
`~client$h3が供した`最大~push~ID$【！ `MAX_PUSH_ID$ft ~frame`7.2.7§】を超える`~push~ID$を利用してはナラナイ。
`~client$h3は、
自身が広告したものを超える`~push~ID$を包含する `PUSH_PROMISE$ft ~frameの受領を
`接続~error$( `H3_ID_ERROR$er )
として扱わなければナラナイ。
◎
A server MUST NOT use a push ID that is larger than the client has provided in a MAX_PUSH_ID frame (Section 7.2.7). A client MUST treat receipt of a PUSH_PROMISE frame that contains a larger push ID than the client has advertised as a connection error of H3_ID_ERROR.
</p>

<p>
`~server$h3は、
複数の `PUSH_PROMISE$ft ~frame内で同じ`~push~ID$を利用してもヨイ。
そうする場合、
その~frameを成す`~field節$
— ~promiseした資源~用の要請の`~header節$【！~header集合】 —
は，解凍-後において同じ順序で同じ`~field$†を包含しなければナラナイ
— 各~field†を成す［
名前, 値
］は、
どちらも正確に合致しなければナラナイ。
◎
A server MAY use the same push ID in multiple PUSH_PROMISE frames. If so, the decompressed request header sets MUST contain the same fields in the same order, and both the name and the value in each field MUST be exact matches.＼
</p>

<p class="trans-note">【†
正確には、
`~field行l$と思われる
（`~field節$を成すのは，~fieldではなく~field行lなので）。
これには、
`疑似-~header$も含まれると思われる。
】</p>

<p>
`~client$h3は、
各 `PUSH_PROMISE$ft ~frameごとに，その`~field節$を［
それまでに受信した同じ`~push~ID$を伴う `PUSH_PROMISE$ft ~frameの`~field節$
］と比較するベキであり、
何かが合致しないことを検出した場合には，
`接続~error$( `H3_GENERAL_PROTOCOL_ERROR$er )
で応答しなければナラナイ
— 解凍した`~field節$が正確に合致した場合，~pushされた内容を［
当の `PUSH_PROMISE$ft ~frameが受信された`~stream$
］に結付けるベキである。
◎
Clients SHOULD compare the request header sections for resources promised multiple times. If a client receives a push ID that has already been promised and detects a mismatch, it MUST respond with a connection error of type H3_GENERAL_PROTOCOL_ERROR. If the decompressed field sections match exactly, the client SHOULD associate the pushed content with each stream on which a PUSH_PROMISE frame was received.
</p>

<p>
同じ`~push~ID$への重複な参照を許容することは、
首に，［
同時並行な要請【~clientからの要請？】による重複n
］を抑制するためにある。
`~server$h3は、
`~push~ID$を長期にわたって再利用することを避けるベキである。
`~client$h3は、
`~server~push$応答を “消費する”
— すなわち、
それらを時間~越しに維持して再利用することはない —
見込みが高い。
`~client$h3は、［
すでに消費して破棄した`~push~ID$を利用する `PUSH_PROMISE$ft ~frame
］に出くわした場合，当の~promiseを無視するよう強制される。
◎
Allowing duplicate references to the same push ID is primarily to reduce duplication caused by concurrent requests. A server SHOULD avoid reusing a push ID over a long period. Clients are likely to consume server push responses and not retain them for reuse over time. Clients that see a PUSH_PROMISE frame that uses a push ID that they have already consumed and discarded are forced to ignore the promise.
</p>

<p>
`~client$h3は、
`制御~stream$上で `PUSH_PROMISE$ft ~frameを受信した場合には，
`接続~error$( `H3_FRAME_UNEXPECTED$er )
で応答しなければナラナイ。
◎
If a PUSH_PROMISE frame is received on the control stream, the client MUST respond with a connection error of type H3_FRAME_UNEXPECTED.
</p>

<p>
`~client$h3は、
`PUSH_PROMISE$ft ~frameを送信してはナラナイ。
`~server$h3は、
`PUSH_PROMISE$ft ~frameの受領を
`接続~error$( `H3_FRAME_UNEXPECTED$er )
として扱わなければナラナイ。
◎
A client MUST NOT send a PUSH_PROMISE frame. A server MUST treat the receipt of a PUSH_PROMISE frame as a connection error of type H3_FRAME_UNEXPECTED.
</p>

<p>
`~server~push$の総合的な仕組みの記述は、
`4.6§ を見よ。
◎
See Section 4.6 for a description of the overall server push mechanism.
</p>

			</section>
			<section id="frame-goaway">
<h4>7.2.6. `GOAWAY^ft</h4>

<p>
`GOAWAY^ft ~frame（種別 `0x07^hex ）は、［
`~HTTP3接続$の上品な~shutdownを起動する
］ために，
どちらの端点からも利用される。
`GOAWAY^ft は、
端点に次を許容する
⇒
それまでに受信した［
要請／~push
］の処理は完遂する一方で、
新たな［
要請／~push
］を受容することは停止する。
◎
The GOAWAY frame (type=0x07) is used to initiate graceful shutdown of an HTTP/3 connection by either endpoint. GOAWAY allows an endpoint to stop accepting new requests or pushes while still finishing processing of previously received requests and pushes.＼
</p>

<p>
`GOAWAY^ft は、
~server保守の様な管理上の動作を可能化する。
`GOAWAY^ft 自体は、
接続を~closeしない。
◎
This enables administrative actions, like server maintenance. GOAWAY by itself does not close a connection.
</p>

<figure>
<pre class="frame-diagram">
`GOAWAY$ft ~frame {
  種別 (i) = 0x07,
  長さ (i),
  `~stream~ID$または`~push~ID$ (i),
}
◎
GOAWAY Frame {
  Type (i) = 0x07,
  Length (i),
  Stream ID/Push ID (i),
}
</pre>
<figcaption>
`GOAWAY^ft ~frame
◎
Figure 9: GOAWAY Frame
</figcaption></figure>

<p>
`GOAWAY^ft ~frameは、
常に，`制御~stream$上に送信される。
`~server$h3からの `GOAWAY^ft ~frameは、［
`~client$h3が起動した`双方向~stream$用の`~stream~ID$
］を`可変長な整数$として符号化したものを運ぶ。
`~client$h3は、
他の種別の`~stream~ID$を包含している `GOAWAY^ft ~frameの受領を
`接続~error$( `H3_ID_ERROR$er )
として扱わなければナラナイ。
◎
The GOAWAY frame is always sent on the control stream. In the server-to-client direction, it carries a QUIC stream ID for a client-initiated bidirectional stream encoded as a variable-length integer. A client MUST treat receipt of a GOAWAY frame containing a stream ID of any other type as a connection error of type H3_ID_ERROR.
</p>

<p>
`~client$h3からの `GOAWAY^ft ~frameは、
`~push~ID$を`可変長な整数$として符号化したものを運ぶ。
◎
In the client-to-server direction, the GOAWAY frame carries a push ID encoded as a variable-length integer.
</p>

<p>
`GOAWAY^ft ~frameは、
特定の`~stream$ではなく，当の接続~全体に適用される。
`~client$h3は、
`制御~stream$以外の`~stream$上の `GOAWAY^ft ~frameを
`接続~error$( `H3_FRAME_UNEXPECTED$er )
として扱わなければナラナイ。
◎
The GOAWAY frame applies to the entire connection, not a specific stream. A client MUST treat a GOAWAY frame on a stream other than the control stream as a connection error of type H3_FRAME_UNEXPECTED.
</p>

<p>
`GOAWAY^ft ~frameの利用についての情報は、
`5.2§を見よ。
◎
See Section 5.2 for more information on the use of the GOAWAY frame.
</p>

			</section>
			<section id="frame-max-push-id">
<h4>7.2.7. `MAX_PUSH_ID^ft</h4>

<p>
`MAX_PUSH_ID^ft ~frame（種別 `0x0d^hex ）は、
`~server$h3が起動できる`~server~push$の個数を制御するためにあり，
`~client$h3により利用される。
これは、
`最大~push~ID@
— `~server$h3が［
`PUSH_PROMISE$ft ／ `CANCEL_PUSH$ft
］~frame内で利用できる`~push~ID$用の最大~値 —
を設定する。
したがって，これは、
`~server$h3が起動できる`~push~stream$の個数を
— ~QUIC~transportにより保守される上限に加えて —
制限する。
◎
The MAX_PUSH_ID frame (type=0x0d) is used by clients to control the number of server pushes that the server can initiate. This sets the maximum value for a push ID that the server can use in PUSH_PROMISE and CANCEL_PUSH frames. Consequently, this also limits the number of push streams that the server can initiate in addition to the limit maintained by the QUIC transport.
</p>

<p>
`MAX_PUSH_ID^ft ~frameは、
常に，`制御~stream$上に送信される。
他の`~stream$上での `MAX_PUSH_ID^ft ~frameの受領は、
`接続~error$( `H3_FRAME_UNEXPECTED$er )
として扱わなければナラナイ。
◎
The MAX_PUSH_ID frame is always sent on the control stream. Receipt of a MAX_PUSH_ID frame on any other stream MUST be treated as a connection error of type H3_FRAME_UNEXPECTED.
</p>

<p>
`~server$h3は、
`MAX_PUSH_ID^ft ~frameを送信してはナラナイ。
`~client$h3は、
`MAX_PUSH_ID^ft ~frameの受領を
`接続~error$( `H3_FRAME_UNEXPECTED$er )
として扱わなければナラナイ。
◎
A server MUST NOT send a MAX_PUSH_ID frame. A client MUST treat the receipt of a MAX_PUSH_ID frame as a connection error of type H3_FRAME_UNEXPECTED.
</p>

<p>
`最大~push~ID$は、
`~HTTP3接続$を作成した時点では，まだ設定されない
— すなわち、
`~server$h3は， `MAX_PUSH_ID^ft ~frameを受信するまでは~pushし得ない。
`~client$h3は、［
~promiseされた`~server~push$
］の個数を
— `~server$h3が`~server~push$を［
充足する／取消す
］に伴い —
管理したいと望むときは、
`MAX_PUSH_ID^ft ~frameを送信することにより，`最大~push~ID$を増やせる。
◎
The maximum push ID is unset when an HTTP/3 connection is created, meaning that a server cannot push until it receives a MAX_PUSH_ID frame. A client that wishes to manage the number of promised server pushes can increase the maximum push ID by sending MAX_PUSH_ID frames as the server fulfills or cancels server pushes.
</p>

<figure>
<pre class="frame-diagram">
`MAX_PUSH_ID$ft ~frame {
  種別 (i) = 0x0d,
  長さ (i),
  `~push~ID$ (i),
}
◎
MAX_PUSH_ID Frame {
  Type (i) = 0x0d,
  Length (i),
  Push ID(i),
}
</pre>
<figcaption>
`MAX_PUSH_ID^ft ~frame
◎
Figure 10: MAX_PUSH_ID Frame
</figcaption></figure>

<p>
`MAX_PUSH_ID^ft ~frameは、
`最大~push~ID$を識別する`可変長な整数$を運ぶ
— `4.6§を見よ。
`MAX_PUSH_ID^ft ~frameは、
`最大~push~ID$を減らせない
— 以前に受信したものより小さい値を包含する
`MAX_PUSH_ID^ft ~frameの受領は、
`接続~error$( `H3_ID_ERROR$er )
として扱わなければナラナイ。
◎
The MAX_PUSH_ID frame carries a single variable-length integer that identifies the maximum value for a push ID that the server can use; see Section 4.6. A MAX_PUSH_ID frame cannot reduce the maximum push ID; receipt of a MAX_PUSH_ID frame that contains a smaller value than previously received MUST be treated as a connection error of type H3_ID_ERROR.
</p>

			</section>
			<section id="frame-reserved">
<h4 title="Reserved Frame Types">7.2.8. 予約-済み~frame種別</h4>

<p>
~frame種別
~IN { `0x1f^hex ~MUL %N ~PLUS `0x21^hex ； %N は負でない整数 }
は、［
未知な種別は無視するものとする要件（`9§）
］を行使するためとして予約される。
これらの~frameには、
意味論は無い
— これらは、
`~stream$を問わず，~frameの送信が許容される所なら どこで送信してもヨイ。
これは、
応用~層における~padding用の利用を可能化する。
端点は、
これらの~frameの受領に際して，意味があるものと見なしてはナラナイ。
◎
Frame types of the format 0x1f * N + 0x21 for non-negative integer values of N are reserved to exercise the requirement that unknown types be ignored (Section 9). These frames have no semantics, and they MAY be sent on any stream where frames are allowed to be sent. This enables their use for application-layer padding. Endpoints MUST NOT consider these frames to have any meaning upon receipt.
</p>

<p>
この~frameの~payload, その長さは、
実装が選ぶ任意の方式で選定される。
◎
The payload and length of the frames are selected in any manner the implementation chooses.
</p>

<p>
~HTTP2にて利用されていた~frame種別のうち，対応している~HTTP3~frame種別が無いものも予約される（`11.2.1§）。
これらの種別に属する~frameは、
送信してはナラナイ
— これらの受領は、
`接続~error$( `H3_FRAME_UNEXPECTED$er )
として扱わなければナラナイ。
◎
Frame types that were used in HTTP/2 where there is no corresponding HTTP/3 frame have also been reserved (Section 11.2.1). These frame types MUST NOT be sent, and their receipt MUST be treated as a connection error of type H3_FRAME_UNEXPECTED.
</p>

			</section>
		</section>
	</section>
	<section id="errors">
<h2 title="Error Handling">8. ~errorの取扱い</h2>

<p>
~QUICは、［
`~stream$が成功裡に完了できないときには、
その~streamを中途で終了して（`~reset$して），その事由を通信する
］ことを応用に許容する
— `QUIC-TRANSPORT$r `2.4＠~QUICv1#section-2.4§を見よ。
これを指して，
`~stream~error@
という。
~HTTP3実装は、［
`~QUIC~stream$を~closeして，当の~errorの種別を通信する
］ものと裁定できる。
伝送路における`~error~code$の符号化法は、
`~HTTP3~error~code§にて定義される。
`~stream~error$は
~error条件を指示する~HTTPの`状態s~code$とは別物である。
`~stream~error$は，
`送信器$が全部的な`~message$【！request or response】を［
転送しなかった／消費しなかった
］ことを指示する一方で、
`状態s~code$は，［
要請の結果は成功裡に受信された
］ことを指示する。
◎
When a stream cannot be completed successfully, QUIC allows the application to abruptly terminate (reset) that stream and communicate a reason; see Section 2.4 of [QUIC-TRANSPORT]. This is referred to as a "stream error". An HTTP/3 implementation can decide to close a QUIC stream and communicate the type of error. Wire encodings of error codes are defined in Section 8.1. Stream errors are distinct from HTTP status codes that indicate error conditions. Stream errors indicate that the sender did not transfer or consume the full request or response, while HTTP status codes indicate the result of a request that was successfully received.
</p>

<p>
類似に，~QUICは、
接続~全体を終了する必要がある場合に，
事由を通信する仕組みを供する
— `QUIC-TRANSPORT$r `5.3＠~QUICv1#section-5.3§を見よ。
これ【そのような事由】を指して，
`接続~error@
という。
`~stream~error$と類似に、
~HTTP3実装は，
~QUIC接続を終了できる
— その際には、
`~HTTP3~error~code§に挙げる`~error~code$を利用して事由を通信できる。
◎
If an entire connection needs to be terminated, QUIC similarly provides mechanisms to communicate a reason; see Section 5.3 of [QUIC-TRANSPORT]. This is referred to as a "connection error". Similar to stream errors, an HTTP/3 implementation can terminate a QUIC connection and communicate the reason using an error code from Section 8.1.
</p>

<p class="trans-note">【
この訳では、
所与の`~error~code$ %~error~code に対し：
［
種別 %~error~code を伴う`~stream~error$
］を
“`~stream~error$( %~error~code )”
と表記する。
［
種別 %~error~code を伴う`接続~error$
］を
“`接続~error$( %~error~code )”
と表記する。
】</p>

<p>
［
`~stream$／接続
］を~closeするときの事由は， “~error” と呼ばれるが、
これらの動作は，［
当の接続や，どちらかの実装
］に伴う問題を指示するとは限らない。
例えば、
`~stream$は，［
要請された`資源$がもはや必要ない場合
］には`~reset$され得る。
◎
Although the reasons for closing streams and connections are called "errors", these actions do not necessarily indicate a problem with the connection or either implementation. For example, a stream can be reset if the requested resource is no longer needed.
</p>

<p>
端点は、
ある種の状況下では，
`~stream~error$を
— 当の`~stream$上の条件に呼応して，接続~全体を~closeするよう —
`接続~error$として扱うことを選んでもヨイ。
実装は、
この選択を為す前に，【対する応答を】待機中な要請に対する影響iを考慮する必要がある。
◎
An endpoint MAY choose to treat a stream error as a connection error under certain circumstances, closing the entire connection in response to a condition on a single stream. Implementations need to consider the impact on outstanding requests before making this choice.
</p>

<p>
新たな`~error~code$は，折衝を伴わずに定義され得るので（`9§を見よ）、［
`~error~code$が期待されない文脈における，その利用／
未知な`~error~code$の受領
］は、
`H3_NO_ERROR$er に等価として扱わなければナラナイ。
しかしながら，`~stream$を~closeすることは、
当の`~error~code$に関わらず，他の効果も伴い得る
— 例えば， `4.1§を見よ。
◎
Because new error codes can be defined without negotiation (see Section 9), use of an error code in an unexpected context or receipt of an unknown error code MUST be treated as equivalent to H3_NO_ERROR. However, closing a stream can have other effects regardless of the error code; for example, see Section 4.1.
</p>

		<section id="http-error-codes">
<h3 title="HTTP/3 Error Codes">8.1. ~HTTP3~error~code</h3>

<p>
以下に挙げる
`~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.
</p>
<dl>
	<dt>
`H3_NO_ERROR@er
( `0x0100^hex )
</dt>
	<dd>
~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.
</dd>

	<dt>
`H3_GENERAL_PROTOCOL_ERROR@er
( `0x0101^hex )
</dt>
	<dd>
次のいずれか
⇒＃
相手の端点は、より特定な`~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.
</dd>

	<dt>
`H3_INTERNAL_ERROR@er
( `0x0102^hex )
</dt>
	<dd>
~HTTP~stack内に内部~errorが生じた。
◎
An internal error has occurred in the HTTP stack.
</dd>

	<dt>
`H3_STREAM_CREATION_ERROR@er
( `0x0103^hex )
</dt>
	<dd>
端点は、［
自身が受容しない`~stream$を相手の端点が作成した
］ことを検出した。
◎
The endpoint detected that its peer created a stream that it will not accept.
</dd>

	<dt>
`H3_CLOSED_CRITICAL_STREAM@er
( `0x0104^hex )
</dt>
	<dd>
`~HTTP3接続$により要求される`~stream$が［
~closeされた／`~reset$された
］。
◎
A stream required by the HTTP/3 connection was closed or reset.
</dd>

	<dt>
`H3_FRAME_UNEXPECTED@er
( `0x0105^hex )
</dt>
	<dd>
次のいずれかに該当する~frameを受信した
⇒＃
現在の状態において許可されてない／
現在の`~stream$上で許可されてない
◎
A frame was received that was not permitted in the current state or on the current stream.
</dd>

	<dt>
`H3_FRAME_ERROR@er
( `0x0106^hex )
</dt>
	<dd>
次のいずれかに該当する~frameを受信した
⇒＃
~layout要件を満足していない／
~sizeが妥当でない
◎
A frame that fails to satisfy layout requirements or with an invalid size was received.
</dd>

	<dt>
`H3_EXCESSIVE_LOAD@er
( `0x0107^hex )
</dt>
	<dd>
端点は、［
相手の端点が［
過度な負荷を生成しているように見える挙動
］を呈している
］ことを検出した。
◎
The endpoint detected that its peer is exhibiting a behavior that might be generating excessive load.
</dd>

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

	<dt>
`H3_SETTINGS_ERROR@er
( `0x0109^hex )
</dt>
	<dd>
端点は、
`SETTINGS$ft ~frameの~payload内に~errorを検出した。
◎
An endpoint detected an error in the payload of a SETTINGS frame.
</dd>

	<dt>
`H3_MISSING_SETTINGS@er
( `0x010a^hex )
</dt>
	<dd>
`制御~stream$における最初の~frameとして，
`SETTINGS$ft ~frameが受信されなかった。
◎
No SETTINGS frame was received at the beginning of the control stream.
</dd>

	<dt>
`H3_REQUEST_REJECTED@er
( `0x010b^hex )
</dt>
	<dd>
`~server$h3は、
応用~処理を遂行することなく，要請を却下した。
◎
A server rejected a request without performing any application processing.
</dd>

	<dt>
`H3_REQUEST_CANCELLED@er
( `0x010c^hex )
</dt>
	<dd>
［
要請, 対する応答（~pushされた応答も含む）
］いずれかが取消された。
◎
The request or its response (including pushed response) is cancelled.
</dd>

	<dt>
`H3_REQUEST_INCOMPLETE@er
( `0x010d^hex )
</dt>
	<dd>
`~client$h3の`~stream$は、
全部的に形成された要請を包含することなく終了された。
◎
The client's stream terminated without containing a fully formed request.
</dd>

	<dt>
`H3_MESSAGE_ERROR@er
( `0x010e^hex )
</dt>
	<dd>
`~message$は`不正形$であり，処理できなかった。
◎
An HTTP message was malformed and cannot be processed.
</dd>

	<dt>
`H3_CONNECT_ERROR@er
( `0x010f^hex )
</dt>
	<dd>
`CONNECT$m 要請に対する応答において確立された~TCP接続は、
~resetされたか異常に~closeされた。
◎
The TCP connection established in response to a CONNECT request was reset or abnormally closed.
</dd>

	<dt>
`H3_VERSION_FALLBACK@er
( `0x0110^hex )
</dt>
	<dd>
要請された演算は、
~HTTP3越しには~serveし得ない。
要請した端点【！peer】は、
~HTTP11越しに試行し直すべきである。
◎
The requested operation cannot be served over HTTP/3. The peer should retry over HTTP/1.1.
</dd>
</dl>

<p>
`~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.
</p>

		</section>
	</section>
	<section id="extensions">
<h2 title="Extensions to HTTP/3">9. ~HTTP3に対する拡張</h2>

<p>
~HTTP3は、
この節に述べられる制限の中で，~protocolの拡張を許可する。
~protocol拡張は、［
追加的な~serviceを供する／
~protocolのいずれかの側面を改める
］ためとして，利用できる。
拡張が有効果になる視野は、
単独の`~HTTP3接続$の中に限られる。
◎
HTTP/3 permits extension of the protocol. Within the limitations described in this section, protocol extensions can be used to provide additional services or alter any aspect of the protocol. Extensions are effective only within the scope of a single HTTP/3 connection.
</p>

<p>
このことは、
この文書~内に定義される~protocol要素に適用され，
~HTTP拡張-用にある既存の~option
— 新たな［
~method／`状態s~code$／~field
］を定義するなど —
には影響しない。
◎
This applies to the protocol elements defined in this document. This does not affect the existing options for extending HTTP, such as defining new methods, status codes, or fields.
</p>

<p>
拡張は、
新たな
⇒＃
~frame種別（`7.2§）／
`設定$（`7.2.4.1§）／
`~error~code$（`8§）／
`一方向~stream$の`~stream種別$（`6.2§）
◎終
を利用するためとして許可される。
これらの拡張~地点を管理するため、
次に挙げる~registryが確立された
⇒＃
~frame種別~registry（`11.2.1§）／
設定~registry（`11.2.2§）／
~error~code~registry（`11.2.3§）／
~stream種別~registry（`11.2.4§）
◎
Extensions are permitted to use new frame types (Section 7.2), new settings (Section 7.2.4.1), new error codes (Section 8), or new unidirectional stream types (Section 6.2). Registries are established for managing these extension points: frame types (Section 11.2.1), settings (Section 11.2.2), error codes (Section 11.2.3), and stream types (Section 11.2.4).
</p>

<p>
実装は、
拡張-可能な どの~protocol要素においても［
未知な／~supportしない
］値を無視しなければナラナイ。
実装は，`一方向~stream$が［
未知な／~supportしない
］`~stream種別$【！種別】を伴う場合には、
当の~stream上の~dataを破棄するか，
その読取りを`中止-$しなければナラナイ。
このことは、
拡張は，
これらの どの拡張~地点も
— 先立つ［
取り決めや折衝
］を伴うことなく —
安全に利用できることを意味する。
しかしながら，
特定の所在において既知な~frame種別が要求される所
— `制御~stream$【！`6.2.1§】の最初の~frameとしての `SETTINGS$ft ~frameなど —
では、
未知な~frame種別は，その要件を満足しないので~errorとして扱うベキである。
◎
Implementations MUST ignore unknown or unsupported values in all extensible protocol elements. Implementations MUST discard data or abort reading on unidirectional streams that have unknown or unsupported types. This means that any of these extension points can be safely used by extensions without prior arrangement or negotiation. However, where a known frame type is required to be in a specific location, such as the SETTINGS frame as the first frame of the control stream (see Section 6.2.1), an unknown frame type does not satisfy that requirement and SHOULD be treated as an error.
</p>

<p>
拡張のうち［
既存の~protocol成分の意味論を変更し得るもの
］は、
利用する前に折衝しなければナラナイ。
例えば，
ある拡張が `HEADERS$ft ~frameの~layoutを変更する場合、［
相手の端点から，これが受容-可能であることを肯定する通達が与えられる
］までは，利用し得ない。
［
そのような改訂された~layoutが，いつ効果を発揮するか
］について協調することは、
複階的にもなり得る。
そのようなわけで、
新たな識別子を［
既存の~protocol要素の新たな定義
］用に割振る方が，効果的になる見込みが高い。
◎
Extensions that could change the semantics of existing protocol components MUST be negotiated before being used. For example, an extension that changes the layout of the HEADERS frame cannot be used until the peer has given a positive signal that this is acceptable. Coordinating when such a revised layout comes into effect could prove complex. As such, allocating new identifiers for new definitions of existing protocol elements is likely to be more effective.
</p>

<p>
この文書は，
拡張の利用を折衝する手法として特定の何かを義務付けないが、
ある`設定$（`7.2.4.1§）を その目的にも利用できることを注記する。
どちらの端点も［
拡張を利用する用意があることを指示する値
］を設定した場合、
当の拡張を利用できる。
拡張の折衝~用に`設定$が利用される場合、
その既定の値は［
当の`設定$が省略された場合、拡張は不能化される
］ような流儀で定義しなければナラナイ。
◎
This document does not mandate a specific method for negotiating the use of an extension, but it notes that a setting (Section 7.2.4.1) could be used for that purpose. If both peers set a value that indicates willingness to use the extension, then the extension can be used. If a setting is used for extension negotiation, the default value MUST be defined in such a fashion that the extension is disabled if the setting is omitted.
</p>

	</section>
	<section id="security-considerations">
<h2 title="Security Considerations">10. ~securityの考慮点</h2>

<p>
~HTTP3に対する~securityの考慮点は，
~TLSを伴う~HTTP2に対する考慮点に匹敵するものになるはずである。
しかしながら，
`HTTP/2$r `10＠~HTTPv2#section-10§ による考慮点のうち多くは、
`QUIC-TRANSPORT$r に適用され，その文書にて論じられる。
◎
The security considerations of HTTP/3 should be comparable to those of HTTP/2 with TLS. However, many of the considerations from Section 10 of [HTTP/2] apply to [QUIC-TRANSPORT] and are discussed in that document.
</p>

		<section id="server-authority">
<h3 title="Server Authority">10.1. ~server権限</h3>

<p>
~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].
</p>

		</section>
		<section id="cross-protocol-attacks">
<h3 title="Cross-Protocol Attacks">10.2. 非同一-~protocol攻撃</h3>

<p>
［
~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.
</p>

<p>
これは、
すべての非同一-~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.
</p>

		</section>
		<section id="intermediary-encapsulation-attacks">
<h3 title="Intermediary-Encapsulation Attacks">10.3. 媒介者~capsule化~攻撃</h3>

<p>
~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.
</p>

<p>
類似に、
~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].
</p>

		</section>
		<section id="cacheability-of-pushed-responses">
<h3 title="Cacheability of Pushed Responses">10.4. ~pushされた応答を~cacheする能</h3>

<p>
~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.
</p>

<p>
~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.
</p>

<p>
複数の~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.
</p>

<p>
`~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.
</p>

		</section>
		<section id="denial-of-service-considerations">
<h3 title="Denial-of-Service Considerations">10.5. ~DoS攻撃に対する考慮点</h3>

<p>
`~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.
</p>

<p>
`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.
</p>

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

<p>
未定義な~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.
</p>

<p>
`~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.
</p>

<p>
これらすべての特能
— すなわち、
`~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.
</p>

<p>
そのような挙動を監視しない端点は、
自身を~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.
</p>

			<section id="limits-on-field-section-size">
<h4 title="Limits on Field Section Size">10.5.1. ~field節の~sizeに対する上限</h4>

<p>
巨大な`~field節$ （`4.1§）は、
実装に多量な状態を~commitさせ得る。
~route法に~criticalな~headerは、
`~header節$の終端~近くに出現し得る
— その場合、
`~header節$を最終的な行先へ~streamするのを妨げる。
この順序付け, その他の理由
— ~cacheの正しさを確保しているなど —
は、［
端点が`~header節$全体を~bufferする必要がある見込みが高い
］ことを意味する。
`~field節$の~sizeには決まった上限は無いので、
一部の端点は，［
一連の~header用に多量な可用な~memoryを~commitする
］よう強制されることもある。
◎
A large field section (Section 4.1) can cause an implementation to commit a large amount of state. Header fields that are critical for routing can appear toward the end of a header section, which prevents streaming of the header section to its ultimate destination. This ordering and other reasons, such as ensuring cache correctness, mean that an endpoint likely needs to buffer the entire header section. Since there is no hard limit to the size of a field section, some endpoints could be forced to commit a large amount of available memory for header fields.
</p>

<p>
端点は、
`SETTINGS_MAX_FIELD_SECTION_SIZE$sp `設定$を利用して，［
`~field節$の~sizeに適用され得る上限
］を相手の端点に助言できる（`4.2.2§）。
この`設定$は，助言的でしかないので、
端点は，［
この上限を超過する`~field節$を送信して，`~message$【！request or response】が`不正形$として扱われる~riskをとる
］ことを選んでもヨイ。
この`設定$は，`~HTTP3接続$に特有なので、
どの`~message$【！request or response】も，
より低い未知な上限を課す~hopに遭遇することもある。
`媒介者$は、
この問題を［
異なる~peerたちにより提示された値を渡す
］ことで避けるよう試みれるが、
そうする~~義務はない。
◎
An endpoint can use the SETTINGS_MAX_FIELD_SECTION_SIZE (Section 4.2.2) setting to advise peers of limits that might apply on the size of field sections. This setting is only advisory, so endpoints MAY choose to send field sections that exceed this limit and risk having the request or response being treated as malformed. This setting is specific to an HTTP/3 connection, so any request or response could encounter a hop with a lower, unknown limit. An intermediary can attempt to avoid this problem by passing on values presented by different peers, but they are not obligated to do so.
</p>

<p>
`~server$h3は、
受信した`~field節$が自身が取扱う用意がある~sizeを超える場合には，
`状態s~code$ `431$st （ `RFC6585$r ）を送信できる。
`~client$h3は、
自身が処理できない応答を破棄できる。
◎
A server that receives a larger field section than it is willing to handle can send an HTTP 431 (Request Header Fields Too Large) status code ([RFC6585]). A client can discard responses that it cannot process.
</p>

			</section>
			<section id="connect-issues">
<h4 title="CONNECT Issues">10.5.2. `CONNECT^m ~methodの課題</h4>

<p>
`CONNECT$m ~methodは、
`~proxy$上で細切れにされた多数の負荷を作成するために利用され得る
— `~stream$の作成は、
~TCP接続の作成と保守よりも比較的安上がりなので。
したがって、
`CONNECT$m を~supportする`~proxy$は，［
自身が同時に受容する要請の個数
］において他より保守的かもしれない。
◎
The CONNECT method can be used to create disproportionate load on a proxy, since stream creation is relatively inexpensive when compared to the creation and maintenance of a TCP connection. Therefore, a proxy that supports CONNECT might be more conservative in the number of simultaneous requests it accepts.
</p>

<p>
`~proxy$は、
~TCP接続~用にも［
`CONNECT$m 要請を運ぶ`~stream$を~closeすることを超える，何らかの資源
］を保守するかもしれない
— 流出していく~TCP接続は、
`TIME_WAIT^i 状態にあり続けるので。
これを織り込むため、
`~proxy$は，［
~TCP接続が終了した後しばらくは、
`~QUIC~stream$の上限を増やすことを遅延する
］かもしれない。
◎
A proxy might also maintain some resources for a TCP connection beyond the closing of the stream that carries the CONNECT request, since the outgoing TCP connection remains in the TIME_WAIT state. To account for this, a proxy might delay increasing the QUIC stream limits for some time after a TCP connection terminates.
</p>

			</section>
		</section>
		<section id="use-of-compression">
<h3 title="Use of Compression">10.6. 圧縮の利用</h3>

<p>
圧縮は、
秘匿~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].
</p>

<p>
~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.
</p>

<p>
~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.
</p>

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

		</section>
		<section id="padding-and-traffic-analysis">
<h3 title="Padding and Traffic Analysis">10.7. ~paddingと流通~分析</h3>

<p>
~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]).
</p>

<p>
~HTTP2は、［
接続を流通~分析に対する耐性を高める
］ために
<del>［
`PADDING^ft ~frame／
他の~frame内では `~padding^i ~field
］</del>
<ins>
一部の~frame内で `~padding^i ~field
</ins>
を使役する
【`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.
</p>

<p>
予約-済み`~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.
</p>

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

<p>
~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.
</p>

		</section>
		<section id="frame-parsing">
<h3 title="Frame Parsing">10.8. ~frameの構文解析</h3>

<p>
いくつかの~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.
</p>

		</section>
		<section id="early-data">
<h3 title="Early Data">10.9. 早期~data</h3>

<p>
~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.
</p>

		</section>
		<section id="migration">
<h3 title="Migration">10.10. 移転</h3>

<p>
ある種の~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.
</p>

		</section>
		<section id="privacy-considerations">
<h3 title="Privacy Considerations">10.11. ~privacyの考慮点</h3>

<p>
~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.
</p>

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

<p>
~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.
</p>

<p>
~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.
</p>

		</section>
	</section>
	<section id="iana-considerations">
<h2 title="IANA Considerations">11. ~IANA考慮点</h2>

<p>
この文書は、
新たな~ALPN~protocol~IDを登録する（`11.1§）／
［
~HTTP3における符号点のアテガい
］を管理する新たな~registryを作成する。
◎
This document registers a new ALPN protocol ID (Section 11.1) and creates new registries that manage the assignment of code points in HTTP/3.
</p>

		<section id="iana-alpn">
<h3 title="Registration of HTTP/3 Identification String">11.1. ~HTTP3識別~文字列の登録</h3>

<p>
この文書は、
`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].
</p>

<p>
文字列 "`h3^c" は、
~HTTP3を識別する：
◎
The "h3" string identifies HTTP/3:
</p>
<ul>
	<li>
~protocol
⇒
~HTTP3
◎
Protocol:
• HTTP/3
</li>
	<li>
識別~連列
⇒
 `0x68 0x33^hex （ "`h3^c" ）
◎
Identification Sequence:
• 0x68 0x33 ("h3")
</li>
	<li>
仕様
⇒
この文書
◎
Specification:
• This document
</li>
</ul>

		</section>
		<section id="iana-policy">
<h3 title="New Registries">11.2. 新たな~registry</h3>

<p>
この文書にて作成された新たな~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].＼
</p>
<ul>
	<li>
`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].＼
</li>
	<li>
<p>
"`Hypertext Transfer Protocol version 3 (HTTP/3)^en" を冠する見出しの下で収集される。
</p>
<p class="trans-note">【
この訳では、
一律に "~HTTP3…" のみを冠するよう略記する
— 引用符も省いた上で。
】</p>
◎
These registries are collected under the "Hypertext Transfer Protocol version 3 (HTTP/3)" heading.
</li>
	<li>
<p>
初期~割振nは：
◎
The initial allocations in these registries are all＼
</p>
		<ul>
			<li>
位置付けとして， `恒久的^i がアテガわれる。
◎
assigned permanent status and＼
</li>
			<li>
変更~制御者として，~IETFを挙げる。
◎
list a change controller of the IETF and＼
</li>
			<li>
連絡先として，~HTTP~WG（ <code>ietf-http-wg@w3.org</code> ）を挙げる。
◎
a contact of the HTTP working group (ietf-http-wg@w3.org).
</li>
		</ul>
	</li>
</ul>

			<section id="iana-frames">
<h4 title="Frame Types">11.2.1. ~frame種別</h4>

<p>
この文書は、
~HTTP3~frame種別~code用に
`~HTTP3~frame種別~registry＠~IANA-a/http3-parameters/http3-parameters.xhtml#http3-parameters-frame-types$cite
を確立する。
それは、
62 ~bit空間を統治する。
この~registryは、
~QUIC~registry施策に従う
— `11.2§を見よ。
この~registryにおける恒久的な登録は、
`仕様が要求される$とする施策を利用してアテガわれる
— ただし，範囲 { `0x00^hex 〜 `0x3f^hex } に入る値は、［
`標準~化$／`~IESG認可＠~RFCx/rfc8126#section-4.10$
］の下でアテガわれる
`RFC8126$r 。
◎
This document establishes a registry for HTTP/3 frame type codes. The "HTTP/3 Frame Types" registry governs a 62-bit space. This registry follows the QUIC registry policy; see Section 11.2. Permanent registrations in this registry are assigned using the Specification Required policy ([RFC8126]), except for values between 0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using Standards Action or IESG Approval as defined in Sections 4.9 and 4.10 of [RFC8126].
</p>

<p>
この~registryは，
`HTTP/2$r にて定義される
`~HTTP2~frame種別~registry＠~IANA-a/http2-parameters/http2-parameters.xhtml#frame-type$cite
とは別々であるが、
~code空間が重合する所では，
互いに並立的にアテガうことが好ましい。
ある~entryが一方の~registry内にしか無い場合、
無関係な運用に対応している値をアテガうことを避けるよう，あらゆる労が為されるベキである。
専門家~考査者は、
無関係な登録が対応している~registry内の同じ値と競合するときは，
それを却下してもヨイ。
◎
While this registry is separate from the "HTTP/2 Frame Type" registry defined in [HTTP/2], it is preferable that the assignments parallel each other where the code spaces overlap. If an entry is present in only one registry, every effort SHOULD be made to avoid assigning the corresponding value to an unrelated operation. Expert reviewers MAY reject unrelated registrations that would conflict with the same value in the corresponding registry.
</p>

<p>
この~registryにおける各 恒久的な登録は、
`11.2§にて述べた共通な~fieldに加えて，
次に挙げる~fieldを含まなければナラナイ：
◎
In addition to common fields as described in Section 11.2, permanent registrations in this registry MUST include the following field:
</p>
<ul>
	<li>
~frame種別
⇒
当の~frame種別~用の［
名前／~label
］。
◎
Frame Type:
• A name or label for the frame type.
</li>
</ul>

<p>
~frame種別の仕様は［
~frame~layout, その意味論の記述
］を含まなければナラナイ
— 当の~frameを成す各部のうち条件付きで在るものも含めて。
◎
Specifications of frame types MUST include a description of the frame layout and its semantics, including any parts of the frame that are conditionally present.
</p>

<p>
次の表tに挙げる各~entryは、
この文書により登録された：
◎
The entries in Table 2 are registered by this document.
</p>

<div id="iana-frame-table">
<table>
<caption>
表t 2
— 初期~HTTP3~frame種別
</caption>
<thead>
<tr><th>~frame種別<th>値
<th>仕様
<tbody>

<tr><td>`DATA$ft
<td>`0x00^hex
<td>`7.2.1§

<tr><td>`HEADERS$ft
<td>`0x01^hex
<td>`7.2.2§

<tr><td>予約-済み
<td>`0x02^hex
<td>この文書

<tr><td>`CANCEL_PUSH$ft
<td>`0x03^hex
<td>`7.2.3§

<tr><td>`SETTINGS$ft
<td>`0x04^hex
<td>`7.2.4§

<tr><td>`PUSH_PROMISE$ft
<td>`0x05^hex
<td>`7.2.5§

<tr><td>予約-済み
<td>`0x06^hex
<td>この文書

<tr><td>`GOAWAY$ft
<td>`0x07^hex
<td>`7.2.6§

<tr><td>予約-済み
<td>`0x08^hex
<td>この文書

<tr><td>予約-済み
<td>`0x09^hex
<td>この文書

<tr><td>`MAX_PUSH_ID$ft
<td>`0x0d^hex
<td>`7.2.7§
</table>

◎
Table 2: Initial HTTP/3 Frame Types
◎
Frame Type｜Value｜Specification
DATA｜0x00｜Section 7.2.1
HEADERS｜0x01｜Section 7.2.2
Reserved｜0x02｜This document
CANCEL_PUSH｜0x03｜Section 7.2.3
SETTINGS｜0x04｜Section 7.2.4
PUSH_PROMISE｜0x05｜Section 7.2.5
Reserved｜0x06｜This document
GOAWAY｜0x07｜Section 7.2.6
Reserved｜0x08｜This document
Reserved｜0x09｜This document
MAX_PUSH_ID｜0x0d｜Section 7.2.7
</div>

<p>
各~code
~IN { `0x1f^hex ~MUL %N ~PLUS `0x21^hex ； %N は負でない整数 } 
（すなわち, `0x21^hex, `0x40^hex, ..., `0x3ffffffffffffffe^hex ）
は
⇒＃
~IANAによりアテガわれてはナラナイ／
アテガわれた値たちが成す~list内に出現してはナラナイ
◎
Each code of the format 0x1f * N + 0x21 for non-negative integer values of N (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe) MUST NOT be assigned by IANA and MUST NOT appear in the listing of assigned values.
</p>

			</section>
			<section id="iana-settings">
<h4 title="Settings Parameters">11.2.2. 設定~parameter</h4>

<p>
この文書は、
~HTTP3`設定$用に
`~HTTP3設定~registry＠~IANA-a/http3-parameters/http3-parameters.xhtml#http3-parameters-settings$cite
を確立する。
それは、
62 ~bit空間を統治する。
この~registryは、
~QUIC~registry施策に従う
— `11.2§を見よ。
この~registryにおける恒久的な登録は、
`仕様が要求される$とする施策を利用してアテガわれる
— ただし，範囲 { `0x00^hex 〜 `0x3f^hex } に入る値は、［
`標準~化$／`~IESG認可＠~RFCx/rfc8126#section-4.10$
］の下でアテガわれる
`RFC8126$r 。
◎
This document establishes a registry for HTTP/3 settings. The "HTTP/3 Settings" registry governs a 62-bit space. This registry follows the QUIC registry policy; see Section 11.2. Permanent registrations in this registry are assigned using the Specification Required policy ([RFC8126]), except for values between 0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using Standards Action or IESG Approval as defined in Sections 4.9 and 4.10 of [RFC8126].
</p>

<p>
この~registryは，
`HTTP/2$r にて定義される
`~HTTP2設定~registry＠~IANA-a/http2-parameters/http2-parameters.xhtml#settings^cite
とは別々であるが、
~code空間が重合する所では，
互いに並立的にアテガうことが好ましい。
ある~entryが一方の~registry内にしか無い場合、
無関係な運用に対応している値をアテガうことを避けるよう，あらゆる労が為されるベキである。
専門家~考査者は、
無関係な登録が［
対応している~registry内の同じ値
］と競合するときは，
それを却下してもヨイ。
◎
While this registry is separate from the "HTTP/2 Settings" registry defined in [HTTP/2], it is preferable that the assignments parallel each other. If an entry is present in only one registry, every effort SHOULD be made to avoid assigning the corresponding value to an unrelated operation. Expert reviewers MAY reject unrelated registrations that would conflict with the same value in the corresponding registry.
</p>

<p>
この~registryにおける各 恒久的な登録は、
`11.2§にて述べた共通な~fieldに加えて，
次に挙げる~fieldを含まなければナラナイ：
◎
In addition to common fields as described in Section 11.2, permanent registrations in this registry MUST include the following fields:
</p>
<ul>
	<li>
設定~名
⇒
当の設定~用の記号的な名前。
設定~名を指定することは、
任意選択~である。
◎
Setting Name:
• A symbolic name for the setting. Specifying a setting name is optional.
</li>
	<li>
既定
⇒
他が指示されない場合における，設定の値。
既定は、
アリな値のうち，最も制約的なものにするベキである。
◎
Default:
• The value of the setting unless otherwise indicated. A default SHOULD be the most restrictive possible value.
</li>
</ul>

<p>
次の表tに挙げる各~entryは、
この文書により登録された：
◎
The entries in Table 3 are registered by this document.
</p>

<div id="iana-setting-table">
<table>
<caption>
表t 3
— 初期~HTTP3設定
</caption>
<thead>
<tr><th>設定~名
<th>値
<th>仕様
<th>既定
<tbody>

<tr><td>予約-済み
<td>`0x00^hex 
<td>この文書
<td>可用でない

<tr><td>予約-済み
<td>`0x02^hex 
<td>この文書
<td>可用でない

<tr><td>予約-済み
<td>`0x03^hex 
<td>この文書
<td>可用でない

<tr><td>予約-済み
<td>`0x04^hex 
<td>この文書
<td>可用でない

<tr><td>予約-済み
<td>`0x05^hex 
<td>この文書
<td>可用でない

<tr><td>MAX_FIELD_SECTION_SIZE
<td>`0x06^hex 
<td>`7.2.4.1§
<td>制限されない
</table>

◎
Table 3: Initial HTTP/3 Settings
◎
Setting Name｜Value｜Specification｜Default
Reserved｜0x00｜This document｜N/A
Reserved｜0x02｜This document｜N/A
Reserved｜0x03｜This document｜N/A
Reserved｜0x04｜This document｜N/A
Reserved｜0x05｜This document｜N/A
MAX_FIELD_SECTION_SIZE｜0x06｜Section 7.2.4.1｜Unlimited
</div>

<p>
整形の理由から、
設定~名は，接頭辞 `SETTINGS_^c を除去することにより略語化できる。
◎
For formatting reasons, setting names can be abbreviated by removing the 'SETTINGS_' prefix.
</p>

<p>
各~code
~IN { `0x1f^hex ~MUL %N ~PLUS `0x21^hex ； %N は負でない整数 } 
（すなわち, `0x21^hex, `0x40^hex, ..., `0x3ffffffffffffffe^hex ）
は
⇒＃
~IANAによりアテガわれてはナラナイ／
アテガわれた値たちが成す~list内に出現してはナラナイ
◎
Each code of the format 0x1f * N + 0x21 for non-negative integer values of N (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe) MUST NOT be assigned by IANA and MUST NOT appear in the listing of assigned values.
</p>

			</section>
			<section id="iana-error-codes">
<h4 title="Error Codes">11.2.3. ~error~code</h4>

<p>
この文書は、
~HTTP3`~error~code$用に
`~HTTP3~error~code~registry＠~IANA-a/http3-parameters/http3-parameters.xhtml#http3-parameters-error-codes$cite
を確立する。
それは、
62 ~bit空間を統治する。
この~registryは、
~QUIC~registry施策に従う
— `11.2§を見よ。
この~registryにおける恒久的な登録は、
`仕様が要求される$とする施策を利用してアテガわれる
— ただし，範囲 { `0x00^hex 〜 `0x3f^hex } に入る値は、［
`標準~化$／`~IESG認可＠~RFCx/rfc8126#section-4.10$
］の下でアテガわれる
`RFC8126$r 。
◎
This document establishes a registry for HTTP/3 error codes. The "HTTP/3 Error Codes" registry manages a 62-bit space. This registry follows the QUIC registry policy; see Section 11.2. Permanent registrations in this registry are assigned using the Specification Required policy ([RFC8126]), except for values between 0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using Standards Action or IESG Approval as defined in Sections 4.9 and 4.10 of [RFC8126].
</p>

<p>
`~error~code$用の登録には、
当の`~error~code$の記述を含めることが要求される。
専門家~考査者は、［
新たな登録に対し，既存の`~error~code$との重複nがあり得るかどうかを精査する
］ことを勧める。
既存の登録の利用は、
奨励されるが，義務付けられない。
`~HTTP2~error~code~registry＠~IANA-a/http2-parameters/http2-parameters.xhtml#error-code$cite
内に登録された値の利用は、
忌避される
— 専門家~考査者は、
そのような登録を却下してもヨイ。
◎
Registrations for error codes are required to include a description of the error code. An expert reviewer is advised to examine new registrations for possible duplication with existing error codes. Use of existing registrations is to be encouraged, but not mandated. Use of values that are registered in the "HTTP/2 Error Code" registry is discouraged, and expert reviewers MAY reject such registrations.
</p>

<p>
この~registryにおける各 恒久的な登録は、
`11.2§にて述べた共通な~fieldに加えて，
次に挙げる 2 つの追加的な~fieldを含まなければナラナイ：
◎
In addition to common fields as described in Section 11.2, this registry includes two additional fields. Permanent registrations in this registry MUST include the following field:
</p>
<ul>
	<li>
名前
⇒
当の`~error~code$用の名前。
◎
Name:
• A name for the error code.
</li>
	<li>
記述
⇒
当の`~error~code$の意味論を成す概略的な記述。
◎
Description:
• A brief description of the error code semantics.
</li>
</ul>

<p>
次の表tに挙げる各~entryは、
この文書により登録された。
これらの`~error~code$は、
~HTTP2~error~codeとの衝突を避けるため，［
`仕様が要求される$とする施策に対し運用する範囲
］から選定された
— これらの`~error~code$の仕様は、
いずれも，`~HTTP3~error~code§にて与えられる
【なので、原文の表tにある “仕様” 列は省略する】：
◎
The entries in Table 4 are registered by this document. These error codes were selected from the range that operates on a Specification Required policy to avoid collisions with HTTP/2 error codes.
</p>

<div id="iana-error-table">
<table>
<caption>
表t 4
— 初期~HTTP3`~error~code$
</caption>
<thead>
<tr><th>名前
<th>値
<th>記述
<tbody>

<tr><td>`H3_NO_ERROR$er
<td>`0x0100^hex 
<td>
~errorなし

<tr><td>`H3_GENERAL_PROTOCOL_ERROR$er
<td>`0x0101^hex 
<td>
一般~protocol~error

<tr><td>`H3_INTERNAL_ERROR$er
<td>`0x0102^hex 
<td>
内部~error

<tr><td>`H3_STREAM_CREATION_ERROR$er
<td>`0x0103^hex 
<td>
~stream作成~error

<tr><td>`H3_CLOSED_CRITICAL_STREAM$er
<td>`0x0104^hex 
<td>
~criticalな`~stream$が~closeされた

<tr><td>`H3_FRAME_UNEXPECTED$er
<td>`0x0105^hex 
<td>
~frameは現在の状態においては許可されない

<tr><td>`H3_FRAME_ERROR$er
<td>`0x0106^hex 
<td>
~frameは［~layout／~size］規則に違反した

<tr><td>`H3_EXCESSIVE_LOAD$er
<td>`0x0107^hex 
<td>
相手の端点は過度な負荷を生成している

<tr><td>`H3_ID_ERROR$er
<td>`0x0108^hex 
<td>
ある識別子が不正に利用された

<tr><td>`H3_SETTINGS_ERROR$er
<td>`0x0109^hex 
<td>
`SETTINGS$ft ~frameが妥当でない値を包含していた

<tr><td>`H3_MISSING_SETTINGS$er
<td>`0x010a^hex 
<td>
`SETTINGS$ft ~frameが受信されなかった

<tr><td>`H3_REQUEST_REJECTED$er
<td>`0x010b^hex 
<td>
要請は処理されなかった

<tr><td>`H3_REQUEST_CANCELLED$er
<td>`0x010c^hex 
<td>
~dataはもはや必要ない

<tr><td>`H3_REQUEST_INCOMPLETE$er
<td>`0x010d^hex 
<td>
`~stream$が早期に終了された

<tr><td>`H3_MESSAGE_ERROR$er
<td>`0x010e^hex 
<td>
不正形な`~message$

<tr><td>`H3_CONNECT_ERROR$er
<td>`0x010f^hex 
<td>
`CONNECT$m 要請に対する~TCP［
~reset／~error
］

<tr><td>`H3_VERSION_FALLBACK$er
<td>`0x0110^hex 
<td>
~HTTP11越しに試行し直す
</table>

◎
Table 4: Initial HTTP/3 Error Codes
◎
Name｜Value｜Description｜Specification
H3_NO_ERROR ｜0x0100｜No error｜Section 8.1
H3_GENERAL_PROTOCOL_ERROR ｜0x0101｜General protocol error｜Section 8.1
H3_INTERNAL_ERROR ｜0x0102｜Internal error｜Section 8.1
H3_STREAM_CREATION_ERROR ｜0x0103｜Stream creation error｜Section 8.1
H3_CLOSED_CRITICAL_STREAM ｜0x0104｜Critical stream was closed｜Section 8.1
H3_FRAME_UNEXPECTED ｜0x0105｜Frame not permitted in the current state｜Section 8.1
H3_FRAME_ERROR ｜0x0106｜Frame violated layout or size rules｜Section 8.1
H3_EXCESSIVE_LOAD ｜0x0107｜Peer generating excessive load｜Section 8.1
H3_ID_ERROR ｜0x0108｜An identifier was used incorrectly｜Section 8.1
H3_SETTINGS_ERROR ｜0x0109｜SETTINGS frame contained invalid values｜Section 8.1
H3_MISSING_SETTINGS ｜0x010a｜No SETTINGS frame received｜Section 8.1
H3_REQUEST_REJECTED ｜0x010b｜Request not processed｜Section 8.1
H3_REQUEST_CANCELLED ｜0x010c｜Data no longer needed｜Section 8.1
H3_REQUEST_INCOMPLETE ｜0x010d｜Stream terminated early｜Section 8.1
H3_MESSAGE_ERROR ｜0x010e｜Malformed message｜Section 8.1
H3_CONNECT_ERROR ｜0x010f｜TCP reset or error on CONNECT request｜Section 8.1
H3_VERSION_FALLBACK ｜0x0110｜Retry over HTTP/1.1｜Section 8.1
</div>

<p>
各~code
~IN { `0x1f^hex ~MUL %N ~PLUS `0x21^hex ； %N は負でない整数 } 
（すなわち, `0x21^hex, `0x40^hex, ..., `0x3ffffffffffffffe^hex ）
は
⇒＃
~IANAによりアテガわれてはナラナイ／
アテガわれた値たちが成す~list内に出現してはナラナイ
◎
Each code of the format 0x1f * N + 0x21 for non-negative integer values of N (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe) MUST NOT be assigned by IANA and MUST NOT appear in the listing of assigned values.
</p>

			</section>
			<section id="iana-stream-types">
<h4 title="Stream Types">11.2.4. ~stream種別</h4>

<p>
この文書は、
~HTTP3の`一方向~stream$の`~stream種別$用に
`~HTTP3~stream種別~registry＠~IANA-a/http3-parameters/http3-parameters.xhtml#http3-parameters-stream-types$cite
を確立する。
それは、
62 ~bit空間を統治する。
この~registryは、
~QUIC~registry施策に従う
— `11.2§を見よ。
この~registryにおける恒久的な登録は、
`仕様が要求される$とする施策を利用してアテガわれる
— ただし，範囲 { `0x00^hex 〜 `0x3f^hex } に入る値は、［
`標準~化$／`~IESG認可＠~RFCx/rfc8126#section-4.10$
］の下でアテガわれる
`RFC8126$r 。
◎
This document establishes a registry for HTTP/3 unidirectional stream types. The "HTTP/3 Stream Types" registry governs a 62-bit space. This registry follows the QUIC registry policy; see Section 11.2. Permanent registrations in this registry are assigned using the Specification Required policy ([RFC8126]), except for values between 0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using Standards Action or IESG Approval as defined in Sections 4.9 and 4.10 of [RFC8126].
</p>

<p>
この~registryにおける各 恒久的な登録は、
`11.2§にて述べた共通な~fieldに加えて，
次に挙げる~fieldを含まなければナラナイ：
◎
In addition to common fields as described in Section 11.2, permanent registrations in this registry MUST include the following fields:
</p>
<ul>
	<li>
`~stream種別$
⇒
当の`~stream種別$用の名前または~label。
◎
Stream Type:
• A name or label for the stream type.
</li>
	<li>
`送信器$
⇒
`~HTTP3接続$において この種別の~streamを起動してよいとされる端点
— 次のいずれか
⇒
`~client^i ／ `~server^i ／ `両方^i
◎
Sender:
• Which endpoint on an HTTP/3 connection may initiate a stream of this type. Values are "Client", "Server", or "Both".
</li>
</ul>

<p>
恒久的な登録~用の仕様は、
当の`~stream種別$の記述を含まなければナラナイ
— ~stream内容の~layoutと意味論も含めて。
◎
Specifications for permanent registrations MUST include a description of the stream type, including the layout and semantics of the stream contents.
</p>

<p>
次の表tに挙げる各~entryは、
この文書により登録された：
◎
The entries in Table 5 are registered by this document.
</p>

<div id="iana-stream-type-table">
<table>
<caption>
表t 5
— 初期`~stream種別$
</caption>
<thead>
<tr><th>`~stream種別$
<th>値
<th>仕様
<th>送信器
<tbody>

<tr><td>`制御~stream$
<td>`0x00^hex 
<td>`6.2.1§
<td>両方

<tr><td>`~push~stream$
<td>`0x01^hex 
<td>`4.6§
<td>`~server^i
</table>

◎
Table 5: Initial Stream Types
◎
Stream Type｜Value｜Specification｜Sender
Control Stream｜0x00｜Section 6.2.1｜Both
Push Stream｜0x01｜Section 4.6｜Server
</div>

<p>
各~code
~IN { `0x1f^hex ~MUL %N ~PLUS `0x21^hex ； %N は負でない整数 } 
（すなわち, `0x21^hex, `0x40^hex, ..., `0x3ffffffffffffffe^hex ）
は
⇒＃
~IANAによりアテガわれてはナラナイ／
アテガわれた値たちが成す~list内に出現してはナラナイ
◎
Each code of the format 0x1f * N + 0x21 for non-negative integer values of N (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe) MUST NOT be assigned by IANA and MUST NOT appear in the listing of assigned values.
</p>

			</section>
		</section>
	</section>
	<section id="h2-considerations">
<h2 title="Appendix A. Considerations for Transitioning from HTTP/2">A. ~HTTP2から移行するための考慮点</h2>

<p>
~HTTP3は、
~HTTP2を強く参考にしており，多くの類似性がある。
この節では
⇒＃
~HTTP3を設計するにあたって とられた~approachを述べる／
~HTTP2からの重要な相違点を指摘する／
~HTTP2拡張を~HTTP3へ対応付ける方法を述べる
◎
HTTP/3 is strongly informed by HTTP/2, and it bears many similarities. This section describes the approach taken to design HTTP/3, points out important differences from HTTP/2, and describes how to map HTTP/2 extensions into HTTP/3.
</p>

<p>
~HTTP3の設計は、［
~HTTP2との類似性は、
好ましいが，堅い要件ではない
］とする所から始まった。
~HTTP3は、
~HTTP2から出発して，
~QUICと~TCPが相違する所で［
~QUIC特能（`~stream$など）の利点をとる／
重要な短所（全順序~法の欠如など）を収容する
］。
~HTTP3は，~~主要な側面
— `~stream$と［
要請, 応答
］の関係性など —
において~HTTP2に類似するが、
その設計の詳細は，~HTTP2とは かなり異なる。
◎
HTTP/3 begins from the premise that similarity to HTTP/2 is preferable, but not a hard requirement. HTTP/3 departs from HTTP/2 where QUIC differs from TCP, either to take advantage of QUIC features (like streams) or to accommodate important shortcomings (such as a lack of total ordering). While HTTP/3 is similar to HTTP/2 in key aspects, such as the relationship of requests and responses to streams, the details of the HTTP/3 design are substantially different from HTTP/2.
</p>

<p>
この節では、
いくつかの重要な出発点が注記される。
◎
Some important departures are noted in this section.
</p>

		<section id="h2-streams">
<h3 title="A.1. Streams">A.1. ~stream</h3>

<p>
~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.
</p>

<p>
~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.
</p>

<p>
~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.
</p>

<p>
`一方向~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.
</p>

		</section>
		<section id="h2-frames">
<h3 title="A.2. HTTP Frame Types">A.2. ~HTTP~frame種別</h3>

<p>
~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.
</p>

<p>
~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.
</p>

<p>
多くの相違点は、
~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.
</p>

<p>
以下では、［
~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.
</p>

			<section id="h2-diff-priority">
<h4 title="A.2.1. Prioritization Differences">A.2.1. 優先順位付けの相違点</h4>

<p>
~HTTP2は、
`PRIORITY^ft ~frame内に
— および，（省略可能な）`HEADERS^ft ~frame内にも —
優先度のアテガいを指定する。
~HTTP3は、
優先度を通達する手段を供さない。
◎
HTTP/2 specifies priority assignments in PRIORITY frames and (optionally) in HEADERS frames. HTTP/3 does not provide a means of signaling priority.
</p>

<p>
優先度の明示的な通達-法は無いが、［
優先順位付けが，良い処理能を達成するために重要でない
］ことを意味するわけではないことに注意。
◎
Note that, while there is no explicit signaling for priority, this does not mean that prioritization is not important for achieving good performance.
</p>

			</section>
			<section id="field-compression-differences">
<h4 title="A.2.2. Field Compression Differences">A.2.2. ~field圧縮の相違点</h4>

<p>
~HPACKは、
順序通りな送達を前提とする下で設計された：
符号化された一連の`~field節$は、
端点にて，それらが符号化された順序と同じ順序で到着しなければ（および復号されなければ）ならない。
これは、
互いの端点における動的な状態が同期cし続けることを確保する。
◎
HPACK was designed with the assumption of in-order delivery. A sequence of encoded field sections must arrive (and be decoded) at an endpoint in the same order in which they were encoded. This ensures that the dynamic state at the two endpoints remains in sync.
</p>

<p>
~QUICは，この全順序~法を供さないので、
~HTTP3は，
~QPACKと呼ばれるものを利用する。
それは，~HPACKの改変された~versionであり、
すべての改変を［
単独の`一方向~stream$を利用して，`動的~table$に対し為す
］ことにより，更新の全順序を確保する。
符号化された`~field節$を包含する すべての~frameは、
単に，所与の時点に当の~tableの状態を
— それを改変することなく —
参照する。
◎
Because this total ordering is not provided by QUIC, HTTP/3 uses a modified version of HPACK, called QPACK. QPACK uses a single unidirectional stream to make all modifications to the dynamic table, ensuring a total order of updates. All frames that contain encoded fields merely reference the table state at a given time without modifying it.
</p>

<p>
追加的な詳細は、
`QPACK$r が供する。
◎
[QPACK] provides additional details.
</p>

			</section>
			<section id="flow-control-differences">
<h4 title="A.2.3. Flow-Control Differences">A.2.3. ~flow制御の相違点</h4>

<p>
~HTTP2は、
~streamの~flow制御~用の仕組みを指定する。
すべての~HTTP2~frameは，~stream上に送達されるが、
~flow制御の~subjectになるのは， `DATA$ft ~frameの~payloadに限られる。
~QUICは、
`~stream$上に送信される［
~stream~dataと［
この文書にて定義されるすべての~HTTP3~frame種別
］］用に~flow制御を供する。
したがって、
すべての［
~frame~header, ~frame~payload
］が~flow制御の~subjectになる。
◎
HTTP/2 specifies a stream flow-control mechanism. Although all HTTP/2 frames are delivered on streams, only the DATA frame payload is subject to flow control. QUIC provides flow control for stream data and all HTTP/3 frame types defined in this document are sent on streams. Therefore, all frame headers and payload are subject to flow control.
</p>

			</section>
			<section id="guidance-for-new-frame-type-definitions">
<h4 title="A.2.4. Guidance for New Frame Type Definitions">A.2.4. 新たな~frame種別~定義~用の指導</h4>

<p>
~HTTP3における~frame種別~定義は、
~QUICの`可変長な整数$による符号化法を利用することが多い。
特に，`~stream~ID$は、
この符号化法を利用する
— それは、
アリな値として，~HTTP2に利用される符号化法より広い範囲を許容する。
~HTTP3における一部の~frameは、
`~stream~ID$（例：`~push~ID$）以外の識別子を利用する。
拡張~frame種別の符号化法が`~stream~ID$を内包する場合、
当の符号化法を定義し直すことが必要yであるかもしれない。
◎
Frame type definitions in HTTP/3 often use the QUIC variable-length integer encoding. In particular, stream IDs use this encoding, which allows for a larger range of possible values than the encoding used in HTTP/2. Some frames in HTTP/3 use an identifier other than a stream ID (e.g., push IDs). Redefinition of the encoding of extension frame types might be necessary if the encoding includes a stream ID.
</p>

<p>
汎用な~HTTP3~frameには、 `~flag群^i（ `Flags^en ） ~fieldは無いので、
~flag群が在ることに依存する~frameは，それ用の空間を［
当の~frameの~payload成す一部に割振る
］必要がある。
◎
Because the Flags field is not present in generic HTTP/3 frames, those frames that depend on the presence of flags need to allocate space for flags as part of their frame payload.
</p>

<p>
これらの課題を除けば、
~HTTP2用の~frame種別~拡張は、
概して，単純に［
~HTTP2における~stream 0 を~HTTP3における`制御~stream$に置換する
］ことで，~QUICに~port可能になる。
~HTTP3拡張は、［
順序付けが在るものと見做さないが，順序付けにより害されることもない
］ので，~HTTP2に~port可能になることが期待される。
◎
Other than these issues, frame type HTTP/2 extensions are typically portable to QUIC simply by replacing stream 0 in HTTP/2 with a control stream in HTTP/3. HTTP/3 extensions will not assume ordering, but would not be harmed by ordering, and are expected to be portable to HTTP/2.
</p>

			</section>
			<section id="comparison-of-http2-and-http3-frame-types">
<h4 title="A.2.5. Comparison of HTTP/2 and HTTP/3 Frame Types">A.2.5. ~HTTP2~frame種別と~HTTP3~frame種別の比較</h4>

<dl>
	<dt>
`DATA$ft
( `0x00^hex )
</dt>
	<dd>
~paddingは、
~HTTP3~frameにおいては定義されない。
`7.2.1§を見よ。
◎
Padding is not defined in HTTP/3 frames. See Section 7.2.1.
</dd>

	<dt>
`HEADERS$ft
( `0x01^hex )
</dt>
	<dd>
`HEADERS$ft の `PRIORITY^ft 領域は、
~HTTP3~frameにおいては定義されない。
~paddingは、
~HTTP3~frameにおいては定義されない。
`7.2.2§を見よ。
◎
The PRIORITY region of HEADERS is not defined in HTTP/3 frames. Padding is not defined in HTTP/3 frames. See Section 7.2.2.
</dd>

	<dt>
`PRIORITY^ft
( `0x02^hex )
</dt>
	<dd>
`A.2.1§にて述べたとおり、
~HTTP3は，優先度を通達するための手段を供さない。
◎
As described in Appendix A.2.1, HTTP/3 does not provide a means of signaling priority.
</dd>

	<dt>
`RST_STREAM^ft
( `0x03^hex )
</dt>
	<dd>
~HTTP3には、
`RST_STREAM^ft ~frameは存在しない
— ~QUICが，`~stream$の~lifecycle管理を供するので。
同じ符号点は、
`CANCEL_PUSH$ft ~frame（`7.2.3§）用に利用される。
◎
RST_STREAM frames do not exist in HTTP/3, since QUIC provides stream lifecycle management. The same code point is used for the CANCEL_PUSH frame (Section 7.2.3).
</dd>

	<dt>
`SETTINGS$ft
( `0x04^hex )
</dt>
	<dd>
`SETTINGS$ft ~frameは、
接続の始めに限り送信される。
`7.2.4§, `A.3§を見よ。
◎
SETTINGS frames are sent only at the beginning of the connection. See Section 7.2.4 and Appendix A.3.
</dd>

	<dt>
`PUSH_PROMISE$ft
( `0x05^hex )
</dt>
	<dd>
`PUSH_PROMISE$ft ~frameは、
`~stream$を参照しない
— 代わりに、
`~push~stream$は，
`~push~ID$を利用して `PUSH_PROMISE$ft ~frameを参照する。
`7.2.5§を見よ。
◎
The PUSH_PROMISE frame does not reference a stream; instead, the push stream references the PUSH_PROMISE frame using a push ID. See Section 7.2.5.
</dd>

	<dt>
`PING^ft
( `0x06^hex )
</dt>
	<dd>
~HTTP3には `PING^ft ~frameは存在しない
— ~QUICが等価な機能性を供するので。
◎
PING frames do not exist in HTTP/3, as QUIC provides equivalent functionality.
</dd>

	<dt>
`GOAWAY$ft
( `0x07^hex )
</dt>
	<dd>
`GOAWAY$ft は、
`~error~code$を包含しない。
`~client$h3から`~server$h3への方向においては、
それは，`~server$h3が起動した`~stream~ID$の代わりに`~push~ID$を運ぶ。
`7.2.6§を見よ。
◎
GOAWAY does not contain an error code. In the client-to-server direction, it carries a push ID instead of a server-initiated stream ID. See Section 7.2.6.
</dd>

	<dt>
`WINDOW_UPDATE^ft
( `0x08^hex )
</dt>
	<dd>
~HTTP3には、
`WINDOW_UPDATE^ft ~frameは存在しない
— ~QUICが~flow制御を供するので。
◎
WINDOW_UPDATE frames do not exist in HTTP/3, since QUIC provides flow control.
</dd>

	<dt>CONTINUATION
( `0x09^hex )
</dt>
	<dd>
~HTTP3には、
`CONTINUATION^ft ~frameは存在しない
— 代わりに［
`HEADERS$ft ／ `PUSH_PROMISE$ft
］~frameには，
~HTTP2より大きいものが許可される。
◎
CONTINUATION frames do not exist in HTTP/3; instead, larger HEADERS/PUSH_PROMISE frames than HTTP/2 are permitted.
</dd>
</dl>

<p>
~HTTP2に対する拡張により定義された~frame種別のうち，~HTTP3にも適用-可能なものは、
~HTTP3用にも別々に登録する必要がある。
単純にするため、
`HTTP/2$r にて定義される各~frameの~IDは，予約-済みにされる。
~HTTP3における~frame種別~空間は，ずっと広いので（ 8 ~bit → 62 ~bit ）、
多くの~HTTP3~frame種別には，等価な~HTTP2符号点は無いことに注意。
`11.2.1§を見よ。
◎
Frame types defined by extensions to HTTP/2 need to be separately registered for HTTP/3 if still applicable. The IDs of frames defined in [HTTP/2] have been reserved for simplicity. Note that the frame type space in HTTP/3 is substantially larger (62 bits versus 8 bits), so many HTTP/3 frame types have no equivalent HTTP/2 code points. See Section 11.2.1.
</p>

			</section>
		</section>
		<section id="h2-settings">
<h3 title="A.3. HTTP/2 SETTINGS Parameters">A.3. ~HTTP2用の設定~parameter</h3>

<p>
~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.
</p>

<p>
~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.
</p>

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

<dl>
	<dt>
`SETTINGS_HEADER_TABLE_SIZE^sp
( `0x01^hex )
</dt>
	<dd>
`QPACK$r を見よ。
◎
See [QPACK].
</dd>

	<dt>
`SETTINGS_ENABLE_PUSH^sp
( `0x02^hex )
</dt>
	<dd>
これは、
`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.
</dd>

	<dt>
`SETTINGS_MAX_CONCURRENT_STREAMS^sp
( `0x03^hex )
</dt>
	<dd>
~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.
</dd>

	<dt>
`SETTINGS_INITIAL_WINDOW_SIZE^sp
( `0x04^hex )
</dt>
	<dd>
~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.
</dd>

	<dt>
`SETTINGS_MAX_FRAME_SIZE^sp
( `0x05^hex )
</dt>
	<dd>
~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.
</dd>

	<dt>
`SETTINGS_MAX_HEADER_LIST_SIZE^sp
( `0x06^hex )
</dt>
	<dd>
この`設定~識別子$は、
`SETTINGS_MAX_FIELD_SECTION_SIZE$sp に改称された。
◎
This setting identifier has been renamed SETTINGS_MAX_FIELD_SECTION_SIZE.
</dd>
</dl>

<p>
~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.
</p>

<p>
各`設定$は、
~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.
</p>

<p>
`~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.
</p>

		</section>
		<section id="http2-error-codes">
<h3 title="A.4. HTTP/2 Error Codes">A.4. ~HTTP2~error~code</h3>

<p>
~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.
</p>

<p>
`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:
</p>

<dl>
	<dt>
`NO_ERROR^er
( `0x00^hex )
</dt>
	<dd>
`H3_NO_ERROR$er に対応付けられる。
◎
H3_NO_ERROR in Section 8.1.
</dd>

	<dt>
`PROTOCOL_ERROR^er
( `0x01^hex )
</dt>
	<dd>
`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.
</dd>

	<dt>
`INTERNAL_ERROR^er
( `0x02^hex )
</dt>
	<dd>
`H3_INTERNAL_ERROR$er に対応付けられる。
◎
H3_INTERNAL_ERROR in Section 8.1.
</dd>

	<dt>
`FLOW_CONTROL_ERROR^er
( `0x03^hex )
</dt>
	<dd>
適用-可能でない
— ~QUICが，~flow制御を取扱うので。
◎
Not applicable, since QUIC handles flow control.
</dd>

	<dt>
`SETTINGS_TIMEOUT^er
( `0x04^hex )
</dt>
	<dd>
適用-可能でない
— `SETTINGS$ft の承認は定義されないので。
◎
Not applicable, since no acknowledgment of SETTINGS is defined.
</dd>

	<dt>
`STREAM_CLOSED^er
( `0x05^hex )
</dt>
	<dd>
適用-可能でない
— ~QUICが，~stream管理を取扱うので。
◎
Not applicable, since QUIC handles stream management.
</dd>

	<dt>
`FRAME_SIZE_ERROR^er
( `0x06^hex )
</dt>
	<dd>
`H3_FRAME_ERROR$er に対応付けられる。
◎
H3_FRAME_ERROR error code defined in Section 8.1.
</dd>

	<dt>
`REFUSED_STREAM^er
( `0x07^hex )
</dt>
	<dd>
要請は処理されなかったことを指示するときは、
`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.
</dd>

	<dt>
`CANCEL^er
( `0x08^hex )
</dt>
	<dd>
`H3_REQUEST_CANCELLED$er に対応付けられる。
◎
H3_REQUEST_CANCELLED in Section 8.1.
</dd>

	<dt>
`COMPRESSION_ERROR^er
( `0x09^hex )
</dt>
	<dd>
`QPACK$r にて複数の~error~codeが定義される。
◎
Multiple error codes are defined in [QPACK].
</dd>

	<dt>
`CONNECT_ERROR^er
( `0x0a^hex )
</dt>
	<dd>
`H3_CONNECT_ERROR$er に対応付けられる。
◎
H3_CONNECT_ERROR in Section 8.1.
</dd>

	<dt>
`ENHANCE_YOUR_CALM^er
( `0x0b^hex )
</dt>
	<dd>
`H3_EXCESSIVE_LOAD$er に対応付けられる。
◎
H3_EXCESSIVE_LOAD in Section 8.1.
</dd>

	<dt>
`INADEQUATE_SECURITY^er
( `0x0c^hex )
</dt>
	<dd>
適用-可能でない
— ~QUICが［
すべての接続に対し，不足ない~securityを供する
］ものと見做されるので。
◎
Not applicable, since QUIC is assumed to provide sufficient security on all connections.
</dd>

	<dt>
`HTTP_1_1_REQUIRED^er
( `0x0d^hex )
</dt>
	<dd>
`H3_VERSION_FALLBACK$er に対応付けられる。
◎
H3_VERSION_FALLBACK in Section 8.1.
</dd>
</dl>

<p>
~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.
</p>

			<section id="mapping-between-http2-and-http3-errors">
<h4 title="A.4.1. Mapping between HTTP/2 and HTTP/3 Errors">A.4.1. ~HTTP2~errorと~HTTP3~errorの間の対応付け</h4>

<p>
~HTTP2と~HTTP3を相互に変換する`媒介者$は、
`上流$からも~error条件に遭遇し得る。
生じた~errorを`下流$へ通信することは有用になるが、
~error~codeは，接続に局所的な問題
— 一般には、
伝播してもイミを成さない問題 —
を広く反映する。
◎
An intermediary that converts between HTTP/2 and HTTP/3 may encounter error conditions from either upstream. It is useful to communicate the occurrence of errors to the downstream, but error codes largely reflect connection-local problems that generally do not make sense to propagate.
</p>

<p>
`媒介者$は、
`上流$にある`生成元$からの~errorに遭遇したときは、［
~~広範な~classの~error用に相応しい`状態s~code$ `502$st
］などを送信することにより，そのことを指示できる。
◎
An intermediary that encounters an error from an upstream origin can indicate this by sending an HTTP status code such as 502 (Bad Gateway), which is suitable for a broad class of errors.
</p>

<p>
~errorを伝播することが有益になる事例も，稀にある
— それを当の`受信器$に最も近く合致している~error種別に対応付けることにより。
例えば，`生成元$から
~HTTP2~stream~error( `REFUSED_STREAM^ft )
を受信した`媒介者$は、［
当の要請は処理されなかったので，要請を安全に試行し直せる
］ことについて明瞭な通達を得たことになる。
［
この~error条件を
~HTTP3`~stream~error$( `H3_REQUEST_REJECTED$er )
として`~client$h3へ伝播する
］ことは、［
当の~clientが，最も適切と判断する動作をとる
］ことを許容する。
逆~方向においては，
`媒介者$は、［
`H3_REQUEST_CANCELLED$er で`~stream$を終了することにより指示された，
`~client要請$の取消n
］を渡すことが有益であると判断するかもしれない
— `4.1.1§を見よ。
◎
There are some rare cases where it is beneficial to propagate the error by mapping it to the closest matching error type to the receiver. For example, an intermediary that receives an HTTP/2 stream error of type REFUSED_STREAM from the origin has a clear signal that the request was not processed and that the request is safe to retry. Propagating this error condition to the client as an HTTP/3 stream error of type H3_REQUEST_REJECTED allows the client to take the action it deems most appropriate. In the reverse direction, the intermediary might deem it beneficial to pass on client request cancellations that are indicated by terminating a stream with H3_REQUEST_CANCELLED; see Section 4.1.1.
</p>

<p>
~errorどうしの変換は、
論理的な対応付けにおいて述べられる。
互いの~error~codeは、
重合しない空間~内で定義される
— 偶発的に［
~target~version用には［
不適切／未知
］な~error~codeを利用する結果
］になる変換に抗して保護するため。
`媒介者$には、
`~stream~error$を`接続~error$に格上げすることが許可されるが、［
一時的／散発的
］な~errorにより生じ得る`~HTTP3接続$の~costを自覚するべきである。
◎
Conversion between errors is described in the logical mapping. The error codes are defined in non-overlapping spaces in order to protect against accidental conversion that could result in the use of inappropriate or unknown error codes for the target version. An intermediary is permitted to promote stream errors to connection errors but they should be aware of the cost to the HTTP/3 connection for what might be a temporary or intermittent error.
</p>

			</section>
		</section>
	</section>
	<section id="acknowledgments">
<h2 title="Acknowledgments">謝辞</h2>

<p>
この文書の先駆けである，
`draft-shade-quic-http2-mapping^cite の著作者
`Robbie Shade^en, `Mike Warres^en
両氏に。
◎
Robbie Shade and Mike Warres were the authors of draft-shade-quic-http2-mapping, a precursor of this document.
</p>

<p>
~IETF~QUIC~WGは、
多くの人々から，膨大な量の~supportを頂いた。
中でも，次に挙げる方々は、
この文書に多大な貢献を供された：
◎
The IETF QUIC Working Group received an enormous amount of support from many people. Among others, the following people provided substantial contributions to this document:
</p>

<ul lang="en">
<li>Bence Beky
<li>Daan De Meyer
<li>Martin Duke
<li>Roy Fielding
<li>Alan Frindell
<li>Alessandro Ghedini
<li>Nick Harper
<li>Ryan Hamilton
<li>Christian Huitema
<li>Subodh Iyengar
<li>Robin Marx
<li>Patrick McManus
<li>Luca Niccolini
<li><span lang="ja">奥 一穂</span> (Kazuho Oku)
<li>Lucas Pardue
<li>Roberto Peon
<li>Julian Reschke
<li>Eric Rescorla
<li>Martin Seemann
<li>Ben Schwartz
<li>Ian Swett
<li>Willy Taureau
<li>Martin Thomson
<li>Dmitri Tikhonov
<li>Tatsuhiro Tsujikawa
</ul>

<p>
`Mike Bishop^en 氏による貢献が成す部位は、
Microsoft により，彼がそこで雇われている間に~supportされた。
◎
A portion of Mike Bishop's contribution was supported by Microsoft during his employment there.
</p>

</section>
</main></div>