HTTP データグラムとカプセルプロトコル

1.1. 規約と定義

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

この文書は、 `QUIC$r による各種用語を利用する。 ◎ This document uses terminology from [QUIC].

この文書が~protocol【~protocol要素の】種別を定義する所では、 定義~形式は， `QUIC$r `§ 表記上の規約＠~QUICv1#notation$ による記法を利用する。 各~種別の中の~fieldが整数をとる所では、 それらは `QUIC$r `§ 可変長な整数の符号化法＠~QUICv1#integer-encoding$ を利用して符号化される。 整数~値は、 必要yな最小な~byte数で符号化される必要はない。 ◎ Where this document defines protocol types, the definition format uses the notation from Section 1.3 of [QUIC]. Where fields within types are integers, they are encoded using the variable-length integer encoding from Section 16 of [QUIC]. Integer values do not need to be encoded on the minimum number of bytes necessary.

この文書における用語 `媒介者$は、 `HTTP$r のそれを指す。 ◎ In this document, the term "intermediary" refers to an HTTP intermediary as defined in Section 3.7 of [HTTP].

2.1. ~HTTP3~datagram

~QUIC `DATAGRAM$ft ~frameの `~datagram~data^i ~fieldは、 ~HTTP3と伴に利用されるときは，次の形式を利用する： ◎ When used with HTTP/3, the Datagram Data field of QUIC DATAGRAM frames uses the following format:

~HTTP3~datagram {
  四分~stream~ID (i),
  ~HTTP~datagram~payload (..),
}
◎
HTTP/3 Datagram {
  Quarter Stream ID (i),
  HTTP Datagram Payload (..),
}

`四分~stream~ID^i ◎ Quarter Stream ID:

この~datagramが結付けられた［ ~clientが起動した双方向~stream ］【の`~stream~ID$】を 4 で除算した結果を可変長な整数として包含する （ 4 による除算は、 ~HTTP要請は~clientが起動した双方向~stream上に送信され， その~stream~IDは 4 で割り切れる事実に起因する）。 ~QUIC`~stream~ID$として合法な値の最~大は 2`62^sup ~MINUS 1 なので， `四分~stream~ID^i ~fieldとして合法な値の最~大は 2`60^sup ~MINUS 1 になる。 より大きい値を内包する~HTTP3~datagramの受領は、 `~HTTP3接続~error$( `H3_DATAGRAM_ERROR$er ) として扱わなければナラナイ。 ◎ A variable-length integer that contains the value of the client-initiated bidirectional stream that this datagram is associated with divided by four (the division by four stems from the fact that HTTP requests are sent on client-initiated bidirectional streams, which have stream IDs that are divisible by four). The largest legal QUIC stream ID value is 262-1, so the largest legal value of the Quarter Stream ID field is 260-1. Receipt of an HTTP/3 Datagram that includes a larger value MUST be treated as an HTTP/3 connection error of type H3_DATAGRAM_ERROR (0x33).

`~HTTP~datagram~payload^i ◎ HTTP Datagram Payload:

当の~datagramの~payload — その意味論は、 `~HTTP~datagram$を利用して，当の拡張により定義される。 この~fieldは，空になり得ることに注意。 ◎ The payload of the datagram, whose semantics are defined by the extension that is using HTTP Datagrams. Note that this field can be empty.

受信した~QUIC `DATAGRAM$ft ~frameの~payloadが， `四分~stream~ID^i ~fieldの構文解析を許容しないまでに短か過ぎる場合、 `~HTTP3接続~error$( `H3_DATAGRAM_ERROR$er ) として扱わなければナラナイ。 ◎ Receipt of a QUIC DATAGRAM frame whose payload is too short to allow parsing the Quarter Stream ID field MUST be treated as an HTTP/3 connection error of type H3_DATAGRAM_ERROR (0x33).

~HTTP3~datagramを［ 対応している~streamの送信-側が~openでない間 ］に送信してはナラナイ。 ある~datagramを［ 対応している~streamの受信-側が~closeされた後 ］に受信した場合、 黙って落さなければナラナイ。 ◎ HTTP/3 Datagrams MUST NOT be sent unless the corresponding stream's send side is open. If a datagram is received after the corresponding stream's receive side is closed, the received datagrams MUST be silently dropped.

受信した~HTTP3~datagramの `四分~stream~ID^i ~fieldが， まだ作成されてない~streamへ対応付けられる場合、 `受信器$h3は，次のいずれかに従わなければナラナイ【！SHALL】： ◎ If an HTTP/3 Datagram is received and its Quarter Stream ID field maps to a stream that has not yet been created, the receiver SHALL either＼

• 当の~datagramを黙って落とす。 ◎ drop that datagram silently＼
• 対応している~streamの作成を（何~往復-かの中で）待受けている間， 当の~datagramを一時的に~bufferする。 ◎ or buffer it temporarily (on the order of a round trip) while awaiting the creation of the corresponding stream.

受信した~HTTP3~datagramの `四分~stream~ID^i ~fieldが［ ~clientが起動する双方向~streamの【個数に対する】上限 ］に因り，作成し得ない~streamへ対応付けられる場合、 当の~datagramは， `~HTTP3接続~error$( `H3_ID_ERROR$er ) として扱われるベキである。 ~QUIC~streamの上限は，~HTTP3層には未知かもしれないので、 ~errorを生成することは義務でない。 ◎ If an HTTP/3 Datagram is received and its Quarter Stream ID field maps to a stream that cannot be created due to client-initiated bidirectional stream limits, it SHOULD be treated as an HTTP/3 connection error of type H3_ID_ERROR. Generating an error is not mandatory because the QUIC stream limit might be unknown to the HTTP/3 layer.

この文書では、 ~HTTP3~datagramたちの優先度化は定義されない。 将来の拡張は、［ ~datagramたちを優先度化する方法／ 優先度化の選好を通信することを許容するための通達-法 ］を定義してもヨイ。 ◎ Prioritization of HTTP/3 Datagrams is not defined in this document. Future extensions MAY define how to prioritize datagrams and MAY define signaling to allow communicating prioritization preferences.

2.2. ~capsule利用している~HTTP~datagram

~HTTP3~datagramが［ 可用でない／望ましくない ］ときは、 `~capsule~protocol$を利用して`~HTTP~datagram$を送信できる — `3.5＠#datagram-capsule§ を見よ。 ◎ When HTTP/3 Datagrams are unavailable or undesirable, HTTP Datagrams can be sent using the Capsule Protocol; see Section 3.5.

3.1. ~HTTP~data~stream

この仕様は、 所与の~HTTP`要請$の `~data~stream@ を当の要請, それに対する`最終-応答$ — 成功裡な応答（すなわち， `2xx$st ）／ ~Upgradeされた応答（すなわち， `101$st ） — ~messageの`~header節$に後続する~byteたちが成す双方向~streamとして定義する。 ◎ This specification defines the "data stream" of an HTTP request as the bidirectional stream of bytes that follows the header section of the request message and the final response message that is either successful (i.e., 2xx) or upgraded (i.e., 101).

~HTTP1xにおいては、 `~data~stream$は，当の［ `要請$, それに対する`最終-応答$ ］の`~header節$を終結する`空~行l＠~HTTPv1#empty-line$に後続する［ 当の接続~上のすべての~byte ］からなるので、 `~capsule~protocol$を開始し得るのは，~HTTP1x接続~上の最後の~HTTP要請に限られる。 ◎ In HTTP/1.x, the data stream consists of all bytes on the connection that follow the blank line that concludes either the request header section or the final response header section. As a result, only the last HTTP request on an HTTP/1.x connection can start the Capsule Protocol.

［ ~HTTP2／~HTTP3 ］においては、 所与の~HTTP要請の`~data~stream$は，［ 対応している`~stream~ID$を伴う［ `DATA＠~HTTPv2#section-6.1$ft ／ `DATA＠~HTTPv3#frame-data$ft ］~frame ］内に送信されたすべての~byteからなる。 ◎ In HTTP/2 and HTTP/3, the data stream of a given HTTP request consists of all bytes sent in DATA frames with the corresponding stream ID.

`~data~stream$の概念は、 特に `CONNECT$m などの~method用に関連する — そこでは、 `~header節$の後には~HTTP`~message内容$は無い。 ◎ The concept of a data stream is particularly relevant for methods such as CONNECT, where there is no HTTP message content after the headers.

`~data~stream$は、［ ~streamたち／要請たち ］の優先度化に適した手段を利用して優先度化され得る。 例えば， `PRIORITY$r `§ 11＠~HTTPpriority#section-11$ を見よ。 ◎ Data streams can be prioritized using any means suited to stream or request prioritization. For example, see Section 11 of [PRIORITY].

`~data~stream$は、 下層な層による~flow制御の仕組み （例： ~HTTP2~stream~flow制御, ~HTTP2接続~flow制御, ~TCP~flow制御） の~subjectになる。 ◎ Data streams are subject to the flow control mechanisms of the underlying layers; examples include HTTP/2 stream flow control, HTTP/2 connection flow control, and TCP flow control.

3.2. ~capsule~protocol

新たな~HTTP~Upgrade~tokenの定義は、［ それが結付けられた要請の`~data~stream$は，`~capsule~protocol$を利用する ］ものと言明できる。 そうする場合、 当の`~data~stream$を成す内容は，次の形式を利用する： ◎ Definitions of new HTTP upgrade tokens can state that their associated request's data stream uses the Capsule Protocol. If they do so, the contents of the associated request's data stream uses the following format:

`~capsule~protocol@ {
  ~capsule (..) ...,
}
◎
Capsule Protocol {
  Capsule (..) ...,
}

`~capsule@ {
  ~capsule種別 (i),
  ~capsule長さ (i),
  ~capsule値 (..),
}
◎
Capsule {
  Capsule Type (i),
  Capsule Length (i),
  Capsule Value (..),
}

`~capsule種別^i ◎ Capsule Type:

当の~capsuleの種別を指示する可変長な整数。 `~capsule種別^i のアテガいを管理するため、 ~IANA~registryが利用される — `~capsule種別＠#iana-types§ を見よ。 ◎ A variable-length integer indicating the type of the capsule. An IANA registry is used to manage the assignment of Capsule Types; see Section 5.4.

`~capsule長さ^i ◎ Capsule Length:

［ この~fieldに後続する `~capsule値^i ~field ］の［ ~byte数による長さ ］を［ 可変長な整数 ］に符号化したもの。 この~fieldは、 値 0 をとり得ることに注意。 ◎ The length, in bytes, of the Capsule Value field, which follows this field, encoded as a variable-length integer. Note that this field can have a value of zero.

`~capsule値^i ◎ Capsule Value:

この`~capsule$の~payload。 その意味論は、 `~capsule種別^i ~fieldの値により決定される。 ◎ The payload of this Capsule. Its semantics are determined by the value of the Capsule Type field.

`媒介者$は、［ `Capsule-Protocol$h ~headerの有無 ］または［ 選ばれた~HTTP~Upgrade~tokenを解すること ］を通して，`~capsule~protocol$の利用を識別できる。 ◎ An intermediary can identify the use of the Capsule Protocol either through the presence of the Capsule-Protocol header field (Section 3.4) or by understanding the chosen HTTP Upgrade token.

新たな［ ~protocol／拡張 ］は，新たな `~capsule種別^i を定義するかもしれないので、 将来の拡張能を許容するよう望む`媒介者$は，各`~capsule$を — 利用-中にある `~capsule種別^i の定義が，媒介者による処理を追加的に指定しない限り — 改変することなく回送するベキである。 そのような`~capsule種別^i として、 `DATAGRAM$cps `~capsule$がある — `3.5＠#datagram-capsule§ を見よ。 特に，`媒介者$は、 未知な `~capsule種別^i を伴う各`~capsule$を改変することなく回送するベキである。 ◎ Because new protocols or extensions might define new Capsule Types, intermediaries that wish to allow for future extensibility SHOULD forward Capsules without modification unless the definition of the Capsule Type in use specifies additional intermediary processing. One such Capsule Type is the DATAGRAM Capsule; see Section 3.5. In particular, intermediaries SHOULD forward Capsules with an unknown Capsule Type without modification.

端点は、 受信した ある`~capsule$の `~capsule種別^i が未知な場合には， それを黙って落として~~後続の`~capsule$たちを構文解析し続けなければナラナイ。 ◎ Endpoints that receive a Capsule with an unknown Capsule Type MUST silently drop that Capsule and skip over it to parse the next Capsule.

`~data~stream$の定義により： ◎ By virtue of the definition of the data stream:

• `~capsule~protocol$が利用-中にあるのは、 応答が状態s~code［ `2xx$st ／ `101$st ］を内包する場合に限られる。 ◎ The Capsule Protocol is not in use unless the response includes a 2xx (Successful) or 101 (Switching Protocols) status code.
• `~capsule~protocol$が利用-中にあるときは、 それが結付けられた~HTTP［ 要請／応答 ］は，~HTTP`内容$を運ばない。 将来の拡張は、 新たな`~capsule種別^i として，~HTTP`内容$を運ぶものを定義してもヨイ。 ◎ When the Capsule Protocol is in use, the associated HTTP request and response do not carry HTTP content. A future extension MAY define a new Capsule Type to carry HTTP content.

`~capsule~protocol$は，新たな~HTTP~Upgrade~tokenの定義に限り適用されるので、［ ~HTTP2／~HTTP3 ］においては， `CONNECT$m ~methodを伴う場合に限り利用し得る。 したがって，双方の端点が`~capsule~protocol$を利用することに合意したなら、 当の~streamにおける~frameの用法に対する要件は，［ `HTTP/2$r `§ 8.5＠~HTTPv2#section-8.5$／ `HTTP/3$r `§ 4.4＠~HTTPv3#connect$ ］にて指定されるとおりに変更される。 ◎ The Capsule Protocol only applies to definitions of new HTTP upgrade tokens; thus, in HTTP/2 and HTTP/3, it can only be used with the CONNECT method. Therefore, once both endpoints agree to use the Capsule Protocol, the frame usage requirements of the stream change as specified in Section 8.5 of [HTTP/2] and Section 4.4 of [HTTP/3].

`~capsule~protocol$は、［ `Content-Length$h ／ `Content-Type$h ／ `Transfer-Encoding$h ］~headerを包含する~messageに利用してはナラナイ。 加えて， `~capsule~protocol$を利用する応答においては、 ~HTTP状態s~code［ `204$st, `205$st, `206$st ］を送信してはナラナイ。 受信器は、 これらの要件に対する違反を観測したときは， 当の~HTTP~messageを不正形として扱わなければナラナイ。 ◎ The Capsule Protocol MUST NOT be used with messages that contain Content-Length, Content-Type, or Transfer-Encoding header fields. Additionally, HTTP status codes 204 (No Content), 205 (Reset Content), and 206 (Partial Content) MUST NOT be sent on responses that use the Capsule Protocol. A receiver that observes a violation of these requirements MUST treat the HTTP message as malformed.

受信器は、 各`~capsule$を処理するとき， それを取扱う前に`~data~stream$内の `~capsule値^i ~fieldを成す全部的な長さを累積したくなるかもしれない。 この~approachは、 避けるベキである — そうすると、 下層な層における~flow制御を消費し得る結果，［ ~capsule~dataにより~flow制御~窓が枯渇した場合に~deadlockへ至る ］かもしれないので。 ◎ When processing Capsules, a receiver might be tempted to accumulate the full length of the Capsule Value field in the data stream before handling it. This approach SHOULD be avoided because it can consume flow control in underlying layers, and that might lead to deadlocks if the Capsule data exhausts the flow control window.

3.3. ~errorの取扱い

受信器は、 `~capsule~protocol$の処理-中に~errorに遭遇したときは，それを［ ~HTTP3用には不正形／ ~HTTP2用には不正形／ ~HTTP1x用には`不完全$ ］な~HTTP`~message$を受信したかのように扱わなければナラナイ。 そのような~messageの取扱いは、 次にて述べられる ⇒＃ ~HTTP3用には `HTTP/3$r `§ 不正形な~message＠~HTTPv3#malformed$／ ~HTTP2用には `HTTP/2$r `§ 不正形な~message＠~HTTPv2#section-8.1.1$／ ~HTTP1x用には `HTTP/1.1$r `§ 不完全な~messageの取扱い＠~HTTPv1#incomplete.messages$ ◎ When a receiver encounters an error processing the Capsule Protocol, the receiver MUST treat it as if it had received a malformed or incomplete HTTP message. For HTTP/3, the handling of malformed messages is described in Section 4.1.2 of [HTTP/3]. For HTTP/2, the handling of malformed messages is described in Section 8.1.1 of [HTTP/2]. For HTTP/1.x, the handling of incomplete messages is described in Section 8 of [HTTP/1.1].

各`~capsule$の~payloadは、 正確に，その【 `~capsule値^i の定義の】記述にて識別される~field群を包含しなければナラナイ。 ~payloadが，識別される~field群の［ 後に追加的な~byte列を包含する／ 終端より前に終了する ］場合、 当の~messageは［ 不正形／`不完全$ ］（順不同）であったかのように扱わなければナラナイ。 特に、 冗長に符号化された長さは，自己-整合なことが検証yされなければナラナイ。 ◎ Each Capsule's payload MUST contain exactly the fields identified in its description. A Capsule payload that contains additional bytes after the identified fields or a Capsule payload that terminates before the end of the identified fields MUST be treated as it if were a malformed or incomplete message. In particular, redundant length encodings MUST be verified to be self-consistent.

`~capsule$を運んでいる~streamを成す受信-側が~cleanに終了された下で （これは、 例えば~HTTP3においては，［ `FIN^i ~bitが 1 に設定された~QUIC `STREAM$ft ~frame ］の受信として定義される）， ~stream上の最後の`~capsule$を成す一部が切落された場合、 当の~messageは［ 不正形／`不完全$ ］であったかのように扱われなければナラナイ。 ◎ If the receive side of a stream carrying Capsules is terminated cleanly (for example, in HTTP/3 this is defined as receiving a QUIC STREAM frame with the FIN bit set) and the last Capsule on the stream was truncated, this MUST be treated as if it were a malformed or incomplete message.

3.4. `Capsule-Protocol^h ~header

`Capsule-Protocol^h ~headerは、 `~sf~item$をとる`有構造~field$であり， その値は`~sf真偽値$でなければナラナイ `STRUCTURED-FIELDS$r — 他の値~型である場合、 受信者は，この~fieldを無かったものとして取扱わなければナラナイ （例えば，この~fieldが複数個~内包された場合、 その型は`~sf~list$になり，それらは無視されることになる）。 この文書は、 `Capsule-Protocol^h ~header値~用の~parameter【`~sf~parameter$】を何も定義しないが、 将来の文書は，何らかの~parameterを定義するかもしれない。 受信器は、 未知な~parameterを無視しなければナラナイ。 ◎ The "Capsule-Protocol" header field is an Item Structured Field; see Section 3.3 of [STRUCTURED-FIELDS]. Its value MUST be a Boolean; any other value type MUST be handled as if the field were not present by recipients (for example, if this field is included multiple times, its type will become a List and the field will be ignored). This document does not define any parameters for the Capsule-Protocol header field value, but future documents might define parameters. Receivers MUST ignore unknown parameters.

端点は、 ~T 値を伴う `Capsule-Protocol^h ~headerを送信することにより， `~capsule~protocol$が`~data~stream$上で利用-中にあることを指示する。 ~F 値を伴う `Capsule-Protocol^h ~headerの意味論は、 この~headerが無かったときと同じになる。 ◎ Endpoints indicate that the Capsule Protocol is in use on a data stream by sending a Capsule-Protocol header field with a true value. A Capsule-Protocol header field with a false value has the same semantics as when the header is not present.

`媒介者$は、［ 未知な~HTTP~Upgrade~token用に`~HTTP~datagram$の処理を許容する ］ためとして，この~headerを利用してもヨイ。 これがアリになるのは、［ ~HTTP~Upgrade／ 拡張d `CONNECT$m ］用に限られることに注意。 ◎ Intermediaries MAY use this header field to allow processing of HTTP Datagrams for unknown HTTP upgrade tokens. Note that this is only possible for HTTP Upgrade or Extended CONNECT.

`Capsule-Protocol^h ~headerを`状態s~code$［ `101$st ／ `2xx$st 番台 ］以外を伴う~HTTP応答に利用してはナラナイ。 ◎ The Capsule-Protocol header field MUST NOT be used on HTTP responses with a status code that is both different from 101 (Switching Protocols) and outside the 2xx (Successful) range.

媒介者による処理を単純~化するため、 ~HTTP端点は，`~capsule~protocol$を利用しているときは， `Capsule-Protocol^h ~headerを送信するベキである。 `~capsule~protocol$を利用する新たな~HTTP~Upgrade~tokenの定義は、 この推奨を改めてもヨイ。 ◎ When using the Capsule Protocol, HTTP endpoints SHOULD send the Capsule-Protocol header field to simplify intermediary processing. Definitions of new HTTP upgrade tokens that use the Capsule Protocol MAY alter this recommendation.

3.5. `DATAGRAM^cps ~capsule

この文書は、 `~capsule種別^i として `DATAGRAM@cps （ `0x00^hex ）を定義する。 この`~capsule$は、［ `~HTTP~datagram$を`~capsule~protocol$を利用して~stream上に送信する ］ことを許容する。 これは、 特に，~HTTPが［ ~QUIC `DATAGRAM$ft ~frameを~supportしない~transport ］越しに走っているときに有用になる。 ◎ This document defines the DATAGRAM (0x00) Capsule Type. This Capsule allows HTTP Datagrams to be sent on a stream using the Capsule Protocol. This is particularly useful when HTTP is running over a transport that does not support the QUIC DATAGRAM frame.

~datagram~capsule {
  種別 (i) = 0x00,
  長さ (i),
  ~HTTP~datagram~payload (..),
}
◎
Datagram Capsule {
  Type (i) = 0x00,
  Length (i),
  HTTP Datagram Payload (..),
}

`~HTTP~datagram~payload^i ◎ HTTP Datagram Payload:

当の~datagramの~payload — その意味論は、 `~HTTP~datagram$を利用している拡張により定義される。 この~fieldは、 空になり得ることに注意。 ◎ The payload of the datagram, whose semantics are defined by the extension that is using HTTP Datagrams. Note that this field can be empty.

`DATAGRAM$cps `~capsule$を利用して送信される`~HTTP~datagram$の意味論は、 ~QUIC `DATAGRAM$ft ~frame内に送信されるそれらと同じである。 特に，［ ~HTTP~datagramの送信が いつ許容されるか／ ~HTTP~datagramを処理する方法 ］に対する（ `§ ~HTTP3~datagram＠#format$ による）制約は、 `DATAGRAM$cps `~capsule$を利用して［ 送信される／受信される ］`~HTTP~datagram$にも適用される。 ◎ HTTP Datagrams sent using the DATAGRAM Capsule have the same semantics as those sent in QUIC DATAGRAM frames. In particular, the restrictions on when it is allowed to send an HTTP Datagram and how to process them (from Section 2.1) also apply to HTTP Datagrams sent and received using the DATAGRAM Capsule.

`媒介者$は、 `~HTTP~datagram$を回送するに伴い，符号化し直せる。 言い換えれば、 `媒介者$は，［ ~QUIC `DATAGRAM$ft ~frame内に受信した~HTTP~datagram ］を回送するためとして `DATAGRAM$cps `~capsule$を送信しても，その逆を行ってもヨイ。 `媒介者$は、［ 対応している要請~streamにおける`~capsule~protocol$の利用 ］を識別した場合 （ `§ ~capsule~protocol＠#capsule-protocol$ を見よ） を除き， この再-符号化法を遂行してはナラナイ。 ◎ An intermediary can re-encode HTTP Datagrams as it forwards them. In other words, an intermediary MAY send a DATAGRAM Capsule to forward an HTTP Datagram that was received in a QUIC DATAGRAM frame and vice versa. Intermediaries MUST NOT perform this re-encoding unless they have identified the use of the Capsule Protocol on the corresponding request stream; see Section 3.2.

`DATAGRAM$cps `~capsule$たちは，［ 順序どおり`依拠-可能$に送達される~stream ］上に送信されるので、 `媒介者$は~messageを回送するときに［ `DATAGRAM$cps `~capsule$を~QUIC `DATAGRAM$ft ~frameの中へ符号化し直す ］こともあり，その結果［ 喪失／並替ng ］が生じ得ることに注意。 ◎ Note that while DATAGRAM Capsules, which are sent on a stream, are reliably delivered in order, intermediaries can re-encode DATAGRAM Capsules into QUIC DATAGRAM frames when forwarding messages, which could result in loss or reordering.

`媒介者$は、［ ~QUIC `DATAGRAM$ft ~frame内に受信した~HTTP~datagram ］を［ ~QUIC `DATAGRAM$ft ~frameを~supportする接続 ］上に回送している場合には， その~HTTP~datagramを `DATAGRAM$cps `~capsule$へ変換するベキでない。 ~HTTP~datagramが `DATAGRAM$ft ~frame内に収まるには大き過ぎる場合 （例えば， ~QUIC接続の経路~MTU（ ~PMTU ）が低過ぎるか， ~QUIC接続~上で広告された最大~UDP~payload~sizeが低過ぎるために）、 `媒介者$は，当の~HTTP~datagramを `DATAGRAM$cps `~capsule$へ変換することなく落とすベキである。 これは、［ `~datagram~packet化~層~用の~PMTUの発見^cite `DPLPMTUD$r などの~method ］が依存している［ 端点間における不依拠-能の特性 ］を保全する。 `媒介者$が~QUIC `DATAGRAM$ft ~frameを `DATAGRAM$cps `~capsule$へ変換した場合、 喪失の難を伴わずに，`~HTTP~datagram$が任意に大きくなることを許容する。 これは、 誤った経路~propを表現し得る結果，~DPLPMTUDなどの~methodを打破することになる。 ◎ If an intermediary receives an HTTP Datagram in a QUIC DATAGRAM frame and is forwarding it on a connection that supports QUIC DATAGRAM frames, the intermediary SHOULD NOT convert that HTTP Datagram to a DATAGRAM Capsule. If the HTTP Datagram is too large to fit in a DATAGRAM frame (for example, because the Path MTU (PMTU) of that QUIC connection is too low or if the maximum UDP payload size advertised on that connection is too low), the intermediary SHOULD drop the HTTP Datagram instead of converting it to a DATAGRAM Capsule. This preserves the end-to-end unreliability characteristic that methods such as Datagram Packetization Layer PMTU Discovery (DPLPMTUD) depend on [DPLPMTUD]. An intermediary that converts QUIC DATAGRAM frames to DATAGRAM Capsules allows HTTP Datagrams to be arbitrarily large without suffering any loss. This can misrepresent the true path properties, defeating methods such as DPLPMTUD.

`DATAGRAM$cps `~capsule$は， 理論~上は長さ 2`62^sup ~MINUS 1 までの~payloadを運べるが、 `~HTTP~datagram$を利用する ほとんどの~HTTP拡張は， ~datagram~payloadの~sizeに実用的な自前の上限を~~課すことになる。 実装は、 `DATAGRAM$cps `~capsule$を構文解析する際に，それらの上限を織り込むベキである。 流入 `DATAGRAM$cps `~capsule$の長さが利用-可能でないほど巨大なことが知れた場合、 実装は，当の`~capsule$を — その内容を~memoryの中へ~bufferすることなく — 破棄するベキである。 ◎ While DATAGRAM Capsules can theoretically carry a payload of length 262-1, most HTTP extensions that use HTTP Datagrams will have their own limits on what datagram payload sizes are practical. Implementations SHOULD take those limits into account when parsing DATAGRAM Capsules. If an incoming DATAGRAM Capsule has a length that is known to be so large as to not be usable, the implementation SHOULD discard the Capsule without buffering its contents into memory.

~QUIC `DATAGRAM$ft ~frameは， ~QUIC~packetの中に収まることが要求されるので、 `DATAGRAM$cps `~capsule$を~QUIC `DATAGRAM$ft ~frameの中へ符号化し直す実装は， `~capsule$全体を — 符号化し直す前に — ~stream内に累積したくなるかもしれないが、 そうするのは避けるベキである — そうすると，~flow制御の問題を生じさせ得るので — `§ ~capsule~protocol＠#capsule-protocol$ を見よ。 ◎ Since QUIC DATAGRAM frames are required to fit within a QUIC packet, implementations that re-encode DATAGRAM Capsules into QUIC DATAGRAM frames might be tempted to accumulate the entire Capsule in the stream before re-encoding it. This SHOULD be avoided, because it can cause flow control problems; see Section 3.2.

~HTTP拡張にとっては、 `~capsule~protocol$を利用せずに`~HTTP~datagram$を利用することもアリであることに注意。 例えば，`~HTTP~datagram$を利用する ある~HTTP拡張が［ ~QUIC `DATAGRAM$ft ~frameを~supportする~transport越しに限られる ］ものとして定義された場合、 ~stream符号化法は不要かもしれない。 加えて、 ~HTTP拡張は，`~HTTP~datagram$を自前の~data~stream~protocolで利用し得る。 しかしながら，新たな~HTTP拡張は、 `~HTTP~datagram$を利用するよう望むなら，`~capsule~protocol$を利用するベキである — そうすることに失敗すると、 当の~HTTP拡張は［ ~HTTP3以外の~HTTP~versionを~supportするのが難しくなる ］ことに加え［ `~capsule~protocol$しか~supportしない`媒介者$たちとの相互運用能を妨げる ］ことになるので。 ◎ Note that it is possible for an HTTP extension to use HTTP Datagrams without using the Capsule Protocol. For example, if an HTTP extension that uses HTTP Datagrams is only defined over transports that support QUIC DATAGRAM frames, it might not need a stream encoding. Additionally, HTTP extensions can use HTTP Datagrams with their own data stream protocol. However, new HTTP extensions that wish to use HTTP Datagrams SHOULD use the Capsule Protocol, as failing to do so will make it harder for the HTTP extension to support versions of HTTP other than HTTP/3 and will prevent interoperability with intermediaries that only support the Capsule Protocol.