HTTP 用の拡張可能な優先度付けスキーム

1. 序論

`資源$の`表現$ `HTTP$r が，他の何個かの資源と関係性があることは、 共通的にある。 ~clientは、 検索取得した表現を処理している間に，これらの関係性を発見することが多く、 その結果，更なる検索取得~要請へ至ることがある。 その一方で、 そのような関係性には，~clientが［ 局所的に可用な資源の処理を継続することを阻む ］かどうかを決定する資質もある。 例として、 ~HTML文書の描画（視覚的な具現化）は， 文書が指す~CSS~fileの検索取得により阻まれることもある。 対照的に，~inline画像は、 描画を阻むことなく，画像を成す~chunkたちが到着するに伴い増分的に描かれる。 ◎ It is common for representations of an HTTP [HTTP] resource to have relationships to one or more other resources. Clients will often discover these relationships while processing a retrieved representation, which may lead to further retrieval requests. Meanwhile, the nature of the relationships determines whether a client is blocked from continuing to process locally available resources. An example of this is the visual rendering of an HTML document, which could be blocked by the retrieval of a Cascading Style Sheets (CSS) file that the document refers to. In contrast, inline images do not block rendering and get drawn incrementally as the chunks of the images arrive.

［ ~HTTP2 `HTTP/2$r ／~HTTP3 `HTTP/3$r ］は、 単独の接続~内で いくつもの［ 要請, 応答 ］を多重化することを~supportする。 ［ 多重化を供する~protocolの実装 ］を成す重要な特能として、［ 情報の送信を優先度化する能 ］がある。 例えば，~HTTP~serverにとっては、［ ~HTML文書の有意義な呈示をできるだけ早く供する ］ため， ~clientへ送信する［ ~HTTP応答たち，それらを成す~chunkたち ］を優先度化することが重要になる。 ◎ HTTP/2 [HTTP/2] and HTTP/3 [HTTP/3] support multiplexing of requests and responses in a single connection. An important feature of any implementation of a protocol that provides multiplexing is the ability to prioritize the sending of information. For example, to provide meaningful presentation of an HTML document at the earliest moment, it is important for an HTTP server to prioritize the HTTP responses, or the chunks of those HTTP responses, that it sends to a client.

［ ~HTTP2~server／~HTTP3~server ］は、［ 同時並行な応答~dataの伝送 ］を自身が選ぶ どの手段でも~scheduleできる。 ~serverは、 ~clientからの優先度~通達を無視でき， それでも~HTTP応答を成功裡に~serveする。 しかしながら、［ ~clientが各~要請をどう発行して，対する応答をどう消費するか ］を無視する下で運用している~serverは、［ ~clientにおける応用の処理能 ］を最適とは言えないものにし得る。 優先度~通達は、 ~clientが［ 自身にとっての要請の優先度を通信する ］ことを許容する。 ~serverは、［ ~clientの必要性とは独立な自前の必要性がある ］ので，［ 優先度の通達を他の可用な情報と組合せた結果 ］として［ 応答~dataの~schedule法を伝える ］ことが多い。 ◎ HTTP/2 and HTTP/3 servers can schedule transmission of concurrent response data by any means they choose. Servers can ignore client priority signals and still successfully serve HTTP responses. However, servers that operate in ignorance of how clients issue requests and consume responses can cause suboptimal client application performance. Priority signals allow clients to communicate their view of request priority. Servers have their own needs that are independent of client needs, so they often combine priority signals with other available information in order to inform scheduling of response data.

`旧~HTTP2$（~RFC 7540 ）の~stream優先度は、［ ある “優先度~tree” を~serverへ通信する，一連の優先度~通達 ］を送信することを~clientに許容した。 この~treeの構造は、 ~clientにより選好される［ ~HTTP応答どうしの相対的な順序付け, ~HTTP応答たちに対する重み付きな帯域幅の分配 ］を表現する。 ~serverは、 これらの優先度~通達を［ 優先度化の裁定に対する入力として利用する ］こともできる。 ◎ RFC 7540 [RFC7540] stream priority allowed a client to send a series of priority signals that communicate to the server a "priority tree"; the structure of this tree represents the client's preferred relative ordering and weighted distribution of the bandwidth among HTTP responses. Servers could use these priority signals as input into prioritization decisions.

`旧~HTTP2$の~stream優先度の設計と実装には、 `2§にて説明されるとおり， 短所があることも観測された。 その帰結として、 ~HTTP2 `HTTP/2$r は，［ これらの~stream優先度~通達の利用 ］を非推奨にした。 この文書に定義される［ 優先度化~scheme, 優先度~通達 ］は、［ `旧~HTTP2$の~stream優先度を代用するもの ］として動作し得る。 ◎ The design and implementation of RFC 7540 stream priority were observed to have shortcomings, as explained in Section 2. HTTP/2 [HTTP/2] has consequently deprecated the use of these stream priority signals. The prioritization scheme and priority signals defined herein can act as a substitute for RFC 7540 stream priority.

この文書は、 ~HTTP応答たちを優先度化するための，拡張-可能な~schemeを述べる `that uses absolute values^en 【？】。 `4§は、 優先度~parameterを定義する — それは、［ 標準~化され，拡張-可能な優先度~情報 ］の形式である。 `5§は、 `Priority$h ~HTTP~headerを定義する — それは、 ~protocol~versionに依存しない，`端点間$な優先度~通達である。 ~clientは、この~headerを送信して，［ 自身にとって，応答たちがどう優先度化されるべきか ］を通達できる。 類似に，`媒介者$の背後にある~serverは、 それを利用して，媒介者へ優先度を通達できる。 ~clientは、 要請を送信した後に，~HTTP~versionに特有な~frameを — ［ `7.1§／ `7.2§ ］にて定義されるとおり — 送信することにより，自身にとっての応答~優先度を変更できる （ `6§を見よ）。 ◎ This document describes an extensible scheme for prioritizing HTTP responses that uses absolute values. Section 4 defines priority parameters, which are a standardized and extensible format of priority information. Section 5 defines the Priority HTTP header field, which is an end-to-end priority signal that is independent of protocol version. Clients can send this header field to signal their view of how responses should be prioritized. Similarly, servers behind an intermediary can use it to signal priority to the intermediary. After sending a request, a client can change their view of response priority (see Section 6) by sending HTTP-version-specific frames as defined in Sections 7.1 and 7.2.

［ ~header／~frame ］による優先度~通達は、 ~serverの応答~優先度化~処理nに対する入力である。 それらは、 示唆でしかなく，［ 応答に対する特定0の処理／応答どうしの相対的な伝送~順序 ］を保証しない。 ［ `10§, `12§ ］は、［ ~serverが，通達に際して どう動作し得るか ］についての考慮点と指導を供する。 ◎ Header field and frame priority signals are input to a server's response prioritization process. They are only a suggestion and do not guarantee any particular processing or transmission order for one response relative to any other response. Sections 10 and 12 provide considerations and guidance about how servers might act upon signals.

3. 拡張-可能な優先度~schemeの適用能

この文書により定義される優先度~schemeは、 首に，~HTTP`応答~message$ `HTTP$r たちの優先度化に注力する。 それは、［ 新たな優先度~parameterたち （ `4§ ）, それらを伝達する手段 （ `5§, `7§ ） ］を定義する。 それは、［ 応答たちを優先度化する責務がある~serverへ，応答たちの優先度を通信する ］ことが意図される。 `10§ は、 ~serverが［ それらの通達に対し，他の入力や要因との組合nで動作する ］ための考慮点を供する。 ◎ The priority scheme defined by this document is primarily focused on the prioritization of HTTP response messages (see Section 3.4 of [HTTP]). It defines new priority parameters (Section 4) and a means of conveying those parameters (Sections 5 and 7), which is intended to communicate the priority of responses to a server that is responsible for prioritizing them. Section 10 provides considerations for servers about acting on those signals in combination with other inputs and factors.

`CONNECT$m ~method `HTTP$r は、 `~tunnel$を確立するために利用され得る。 通達-法は、 ~tunnelにも類似に適用される — ~serverによる優先度化~用の追加的な考慮点は、 `11§にて与えられる。 ◎ The CONNECT method (see Section 9.3.6 of [HTTP]) can be used to establish tunnels. Signaling applies similarly to tunnels; additional considerations for server prioritization are given in Section 11.

`9§では、 ~clientが［ この~schemeを成す要素たち ］を局所的に［ 自身が`生成-$する要請~messageたちに，どう任意選択で適用できるか ］を述べる。 ◎ Section 9 describes how clients can optionally apply elements of this scheme locally to the request messages that they generate.

~HTTP拡張には、 何らかの形で［［ ~HTTP2／~HTTP3 ］~streamの挙動を変更するもの／ 新たな~dataを運ぶための仕組みを定義するもの ］もあるかもしれない。 そのような拡張も、［ この優先度~schemeが，自身に どう適用されるか ］を定義し得る。 ◎ Some forms of HTTP extensions might change HTTP/2 or HTTP/3 stream behavior or define new data carriage mechanisms. Such extensions can themselves define how this priority scheme is to be applied.

4. 優先度~parameter

優先度~情報は、［ ( ~key, 値 ) が成す~pair ］たちが成す連列であり，将来の拡張~用の部屋を供する。 各~pairは、 ある優先度~parameterを表現する。 ◎ The priority information is a sequence of key-value pairs, providing room for future extensions. Each key-value pair represents a priority parameter.

`Priority$h ~HTTP~headerは、［ 要請／応答 ］が発行されるときに［ この優先度~parameterたちが成す集合 ］を`端点間$で伝送する仕方である。 ~clientは、 要請を送信した後に，［ `7.1§, `7.2§ ］にて定義されるとおり［ ~HTTP~versionに特有な `PRIORITY_UPDATE$ft ~frameを送信する ］ことにより［ 自身にとっての，応答~優先度 ］を変更できる （`6§）。 これらの~frameは、 `内方$にある次の~serverに限り優先度~parameterを伝送する。 ◎ The Priority HTTP header field (Section 5) is an end-to-end way to transmit this set of priority parameters when a request or a response is issued. After sending a request, a client can change their view of response priority (Section 6) by sending HTTP-version-specific PRIORITY_UPDATE frames as defined in Sections 7.1 and 7.2. Frames transmit priority parameters on a single hop only.

`媒介者$は、［ `PRIORITY_UPDATE$ft ~frame, `Priority$h ~header ］どちらに対しても，［ それら内の優先度~通達を消費できる／ それら内に優先度~通達を生産できる ］。 `媒介者$のうち`内方$にある次の~serverへ `Priority$h 要請~headerのみを渡すものは、 ~clientからの元の`端点間$な通達を保全する — `14§を見よ。 `媒介者$は、 `Priority$h ~headerを渡すこともでき， `PRIORITY_UPDATE$ft ~frameを追加的に送信することもできる。 これは、 元の［ ~clientによる端点間な通達 ］を保全する一方で， `内方$にある次の~serverに異なる優先度を利用するよう指図する効果がある — `7§ による指導に従って。 `媒介者$のうち， `Priority$h 要請~headerを［ 置換する／追加する ］ものは、元の［ ~clientによる端点間な通達 ］を上書きする — それは、 後続な［ 当の要請の受信者~すべて ］用の優先度化に影響し得る。 ◎ Intermediaries can consume and produce priority signals in a PRIORITY_UPDATE frame or Priority header field. An intermediary that passes only the Priority request header field to the next hop preserves the original end-to-end signal from the client; see Section 14. An intermediary could pass the Priority header field and additionally send a PRIORITY_UPDATE frame. This would have the effect of preserving the original client end-to-end signal, while instructing the next hop to use a different priority, per the guidance in Section 7. An intermediary that replaces or adds a Priority request header field overrides the original client end-to-end signal, which can affect prioritization for all subsequent recipients of the request.

優先度~parameterたちが成す集合は、［ `Priority$h ~header, `PRIORITY_UPDATE$ft ~frame ］どちらにおいても，`~sf辞書$ `STRUCTURED-FIELDS$r として`符号化され$sFる。 ◎ For both the Priority header field and the PRIORITY_UPDATE frame, the set of priority parameters is encoded as a Dictionary (see Section 3.2 of [STRUCTURED-FIELDS]).

この文書は、 優先度~parameterとして，［ `緊急度$（ `u^c ）, `増分的か$（ `i^c ） ］を定義する。 ~serverは、 これらの優先度~parameterを運ばない~HTTP要請を受信したときは， 各自に既定の値が指定されていたかのように動作するベキである。 ◎ This document defines the urgency (u) and incremental (i) priority parameters. When receiving an HTTP request that does not carry these priority parameters, a server SHOULD act as if their default values were specified.

`媒介者$は、 自身が回送する［ 要請, 対する応答 ］に対し，［ 当の要請の通達, 当の応答の通達 ］を組合できる。 応答における優先度~parameterの省略に対する取扱いは、 要請におけるそれとは異なることに注意 — `8§を見よ。 ◎ An intermediary can combine signals from requests and responses that it forwards. Note that omission of priority parameters in responses is handled differently from omission in requests; see Section 8.

受信器は、 `~sf辞書$を `STRUCTURED-FIELDS$r `有構造~fieldの構文解析-法＠~STRUCTURED-FIELDS#text-parse§ に述べられるとおりに構文解析する。 この文書は、 成功裡に構文解析された`~sf辞書$に対し，追加的な要件を設置する： 優先度~parameterのうち，その［ 【~keyが】未知なもの／ 値が範囲~外であるもの／ 値が期待されない型であるもの ］は、 無視しなければナラナイ。 ◎ Receivers parse the Dictionary as described in Section 4.2 of [STRUCTURED-FIELDS]. Where the Dictionary is successfully parsed, this document places the additional requirement that unknown priority parameters, priority parameters with out-of-range values, or values of unexpected types MUST be ignored.

:method = GET
:scheme = https
:authority = example.net
:path = /style.css
priority = u=0

:method = GET
:scheme = https
:authority = example.net
:path = /image.jpg
priority = u=5, i

5. `Priority^h ~HTTP~header

`Priority^h ~HTTP~headerは、 優先度~parameter群を運ぶ`~sf辞書$をとる （ `4§を見よ）。 それは、［ 要請~内, 応答~内 ］どちらにも出現し得る。 それは、［ 自身にとって，~HTTP応答たちがどう優先度化されるべきか ］を指示する`端点間$な通達である。 `8§は、 `媒介者$が［ ~client, ~server ］から送信された優先度~情報をどう組合できるかを述べる。 ~clientは、 `Priority^h 応答~headerの［ 出現／省略 ］を優先度化が生じたことの承認としては解釈できない。 端点が `Priority^h ~header値に対し どう動作できるかに関する指導は、［ `9§, `10§ ］にて与えられる。 ◎ The Priority HTTP header field is a Dictionary that carries priority parameters (see Section 4). It can appear in requests and responses. It is an end-to-end signal that indicates the endpoint's view of how HTTP responses should be prioritized. Section 8 describes how intermediaries can combine the priority information sent from clients and servers. Clients cannot interpret the appearance or omission of a Priority response header field as acknowledgement that any prioritization has occurred. Guidance for how endpoints can act on Priority header values is given in Sections 9 and 10.

`Priority^h ~headerを伴う~HTTP要請は、［ ~cacheされ，後続な要請~用に再利用される ］かもしれない — `CACHING$r を見よ。 `生成元~server$には、［ `Priority^h 応答~headerを受信した~HTTP要請の特質に基づいて`生成-$する ］ときには［ ~cacheした応答に対する~cachingの挙動 ］を制御する~header （例： `Cache-Control$h, `Vary$h ） を利用して［ ~cache能／適用能 ］を制御することが期待される。 ◎ An HTTP request with a Priority header field might be cached and reused for subsequent requests; see [CACHING]. When an origin server generates the Priority response header field based on properties of an HTTP request it receives, the server is expected to control the cacheability or the applicability of the cached response by using header fields that control the caching behavior (e.g., Cache-Control, Vary).

6. 再~優先度化

~clientは、 要請を送信した後，対する応答の優先度を変更すると有益になることもある。 例として、 ~web~browserは， ある~JS~file用に~prefetch【事前~fetch】要請を — その `Priority$h 要請~headerの`緊急度$に `u=7^c （~background~task用）を設定して — 発行するかもしれない。 当の~prefetchが進捗-中にある間に， 利用者が当の【！new】~JS~fileを参照する~pageへ~navigateしたときには、 ~browserは，再~優先度化~通達として［ `u=0^c に設定された `~Priority~field値^i ~fieldを伴うもの ］を送信することになろう。 そのような再~優先度化には、 `PRIORITY_UPDATE$ft ~frameを利用できる。 ◎ After a client sends a request, it may be beneficial to change the priority of the response. As an example, a web browser might issue a prefetch request for a JavaScript file with the urgency parameter of the Priority request header field set to u=7 (background). Then, when the user navigates to a page that references the new JavaScript file, while the prefetch is in progress, the browser would send a reprioritization signal with the Priority Field Value set to u=0. The PRIORITY_UPDATE frame (Section 7) can be used for such reprioritization.

7. `PRIORITY_UPDATE^ft ~frame

この文書は、［ ~HTTP2 `HTTP/2$r ／ ~HTTP3 `HTTP/3$r ］用に，新たな `PRIORITY_UPDATE^ft ~frameを指定する。 それは、 優先度~parameter群を運ぶとともに， ~HTTP~versionに特有な識別子に基づいて優先度化の~targetを参照する。 この識別子は、 ~HTTP2においては~stream~ID【`~stream識別子＠~HTTPv2#StreamIdentifiers$】であり，~HTTP3においては［ `~stream~ID$h3／`~push~ID$h3 ］である。 `Priority$h ~headerと違って、 `PRIORITY_UPDATE^ft ~frameは，`隣点間$な通達である。 ◎ This document specifies a new PRIORITY_UPDATE frame for HTTP/2 [HTTP/2] and HTTP/3 [HTTP/3]. It carries priority parameters and references the target of the prioritization based on a version-specific identifier. In HTTP/2, this identifier is the stream ID; in HTTP/3, the identifier is either the stream ID or push ID. Unlike the Priority header field, the PRIORITY_UPDATE frame is a hop-by-hop signal.

`PRIORITY_UPDATE^ft ~frameは、［ 当の応答を運ぶ~streamとは独立に送信する ］ことを~clientに許容するよう， ~clientにより`制御~stream$上に送信される。 すなわち，~clientは、 それを次のために利用できる： ◎ PRIORITY_UPDATE frames are sent by clients on the control stream, allowing them to be sent independently of the stream that carries the response. This means they can be used＼

• ［ 応答~stream／~push~stream ］を優先度化し直す ◎ to reprioritize a response or a push stream,＼
• `Priority$h ~headerの代わりに， 応答の初期~優先度を通達する ◎ or to signal the initial priority of a response instead of the Priority header field.

`PRIORITY_UPDATE^ft ~frameは、 `~Priority~field値^i ~field内に［ すべての優先度~parameterたちが成す完全な集合 ］を通信する。 ある優先度~parameterを省略した場合、 その既定の値を利用する通達になる。 `~Priority~field値^i の構文解析に失敗した場合、［ ~HTTP2においては `接続~error$( `PROTOCOL_ERROR$er ) ／ ~HTTP3においては `接続~error$( `H3_GENERAL_PROTOCOL_ERROR$er ) ］として扱ってもヨイ。 ◎ A PRIORITY_UPDATE frame communicates a complete set of all priority parameters in the Priority Field Value field. Omitting a priority parameter is a signal to use its default value. Failure to parse the Priority Field Value MAY be treated as a connection error. In HTTP/2, the error is of type PROTOCOL_ERROR; in HTTP/3, the error is of type H3_GENERAL_PROTOCOL_ERROR.

~clientは、 `PRIORITY_UPDATE^ft ~frameを［ それが参照する~streamが~openになる前 ］に送信してもヨイ （ただし、 ~HTTP2用の~push~streamを除く — `7.1§を見よ）。 さらには、［ ~HTTP3は、 ~streamたちの順序付けに何も保証を提供しない ］ので，［ 当の~frameが意図されるより早く受信される ］こともある。 どちらの事例も、 ~serverが［ まだ~openでない要請~streamを参照する `PRIORITY_UPDATE^ft ~frame ］を受信した場合，競走~条件へ至らす — これを解くため、 ~schedule法の目的においては，［ `PRIORITY_UPDATE^ft ~frameのうち最も近過去に受信されたもの ］が［ 他の通達を上書きする~~最新な情報である ］と見なせる。 ~serverは、 最も近過去に受信した `PRIORITY_UPDATE^ft ~frameを~bufferして， 参照された~streamが~openされたなら それを適用するベキである。 各~stream用に `PRIORITY_UPDATE^ft ~frameを保持することは、 ~server資源が要求されるので，局所的な実装~施策に束縛され得る。 送信され得る `PRIORITY_UPDATE^ft ~frameの個数には上限は無いが、 最も近過去に受信した~frameに限り格納することで，資源を~~節約できる。 ◎ A client MAY send a PRIORITY_UPDATE frame before the stream that it references is open (except for HTTP/2 push streams; see Section 7.1). Furthermore, HTTP/3 offers no guaranteed ordering across streams, which could cause the frame to be received earlier than intended. Either case leads to a race condition where a server receives a PRIORITY_UPDATE frame that references a request stream that is yet to be opened. To solve this condition, for the purposes of scheduling, the most recently received PRIORITY_UPDATE frame can be considered as the most up-to-date information that overrides any other signal. Servers SHOULD buffer the most recently received PRIORITY_UPDATE frame and apply it once the referenced stream is opened. Holding PRIORITY_UPDATE frames for each stream requires server resources, which can be bounded by local implementation policy. Although there is no limit to the number of PRIORITY_UPDATE frames that can be sent, storing only the most recently received frame limits resource commitment.

~HTTP2 `PRIORITY_UPDATE^ft ~frame {
  長さ (24),
  種別 (8) = 0x10,

  ~flag群（利用されない） (8),

  予約-済み (1),
  ~stream識別子 (31),

  予約-済み (1),
  優先度化された~stream~ID (31),
  ~Priority~field値 (..),
}
◎
HTTP/2 PRIORITY_UPDATE Frame {
  Length (24),
  Type (8) = 0x10,

  Unused Flags (8),

  Reserved (1),
  Stream Identifier (31),

  Reserved (1),
  Prioritized Stream ID (31),
  Priority Field Value (..),
}

~HTTP3 `PRIORITY_UPDATE^ft ~frame {
  種別 (i) = 0xF0700..0xF0701,
  長さ (i),
  優先度化された要素~ID (i),
  ~Priority~field値 (..),
}
◎
HTTP/3 PRIORITY_UPDATE Frame {
  Type (i) = 0xF0700..0xF0701,
  Length (i),
  Prioritized Element ID (i),
  Priority Field Value (..),
}

8. ~client駆動な優先度~parameterと~server駆動な優先度~parameterの併合-法

~clientは、 各~HTTP応答が どう優先度化されるに~~価するか，常に最善に解するとは限らない。 ~serverは、［ 当の応答の優先度化を改善する ］ために［ ~clientが指示した優先度と組合せれる ］ような追加的な情報を有するかもしれない。 例えば、 ある~HTML文書の利用は，数ある~inline画像のうち一つに大きく依存するかもしれない — そのような依存関係の存在を最良に知れるのは、 概して~serverである。 あるいは、 ~serverは，［ ~font, 画像 ］ `RFC8081$r への要請として同じ`緊急度$を伴うもの受信したとき、 視覚的な~clientが~textな情報を より早く描画できるよう， ~fontの優先順位を画像より高くするかもしれない。 ◎ It is not always the case that the client has the best understanding of how the HTTP responses deserve to be prioritized. The server might have additional information that can be combined with the client's indicated priority in order to improve the prioritization of the response. For example, use of an HTML document might depend heavily on one of the inline images; the existence of such dependencies is typically best known to the server. Or, a server that receives requests for a font [RFC8081] and images with the same urgency might give higher precedence to the font, so that a visual client can render textual information at an early moment.

`生成元~server$【！origin】は、 `Priority$h 応答~headerを利用して［ ~HTTP応答が，自身にとって どう優先度化されるべきか ］を指示できる。 ~HTTP応答を回送する`媒介者$は、 その優先度化~処理nへの入力として， `Priority$h 応答~header内に見出された優先度~parameterを ~clientの `Priority$h 要請~headerと組合せて利用できる。 これらの優先度を併合するために供される指導は無い — それは、 実装の裁定に委ねられる。 ◎ An origin can use the Priority response header field to indicate its view on how an HTTP response should be prioritized. An intermediary that forwards an HTTP response can use the priority parameters found in the Priority response header field, in combination with the client Priority request header field, as input to its prioritization process. No guidance is provided for merging priorities; this is left as an implementation decision.

~HTTP応答~内に優先度~parameterが無い場合、 ~serverは，~clientが供する値の変化に関心が無いことを指示する。 これは、 要請~headerとは異なる — そこでは、 優先度~parameterの省略は，その既定の値の利用を含意する （ `4§を見よ）。 ◎ The absence of a priority parameter in an HTTP response indicates the server's disinterest in changing the client-provided value. This is different from the request header field, in which omission of a priority parameter implies the use of its default value (see Section 4).

:method = GET
:scheme = https
:authority = example.net
:path = /menu.png
priority = u=5, i

:status = 200
content-type = image/png
priority = u=1

9. ~clientにおける~schedule法

~clientは、［ 自身が起動する要請たちについて，自身に局所的な［ 処理-法／~schedule法 ］の選択を為す ］にあたって，優先度~値を利用してもヨイ。 ◎ A client MAY use priority values to make local processing or scheduling choices about the requests it initiates.

10. ~serverにおける~schedule法

~HTTP~serverにとっては、 一般に，すべての応答をアリな限り早く送信することが有益になる。 しかしながら、 複数の要請に対し単独の接続~上で~serveするときには， それら`資源$への要請どうしで［ 接続~帯域幅などの争い ］が生じることもある。 この節では、 そのような争いが存在するとき，~serverが［ 争っている応答たちを どの順序で送信するよう~scheduleできるか ］に関する考慮点を述べる。 ◎ It is generally beneficial for an HTTP server to send all responses as early as possible. However, when serving multiple requests on a single connection, there could be competition between the requests for resources such as connection bandwidth. This section describes considerations regarding how servers can schedule the order in which the competing responses will be sent when such competition exists.

~serverにおける~schedule法は，多くの入力に基づく優先度化~処理nであり、 優先度~通達は，入力を成す一つの形でしかない。 実装による選択や配備~環境などの要因も，その役割を担う。 所与のどの接続も、 動的な並替えを何回も経る見込みが高い。 これらの理由から、［ 普遍的な~schedule法を成す~algo ］を述べることはアリではない。 この文書は、 ~serverが［ 優先度~parameterに対し どう動作し得るか ］について［ 基本的な網羅的でない推奨 ］をいくつか供する — ~serverが［ 優先度~通達を他の要因と どう組合できるか ］は、 詳細に述べないが。 端点は、 特定0の［ 優先度~通達に基づく扱い ］には依存できない。 優先度を表出することは、 示唆でしかない。 ◎ Server scheduling is a prioritization process based on many inputs, with priority signals being only one form of input. Factors such as implementation choices or deployment environment also play a role. Any given connection is likely to have many dynamic permutations. For these reasons, it is not possible to describe a universal scheduling algorithm. This document provides some basic, non-exhaustive recommendations for how servers might act on priority parameters. It does not describe in detail how servers might combine priority signals with other factors. Endpoints cannot depend on particular treatment based on priority signals. Expressing priority is only a suggestion.

~serverには、 アリなときは［ `緊急度$を尊重して，応答のうち`緊急度$が高いものほど早く送信する ］ことが`推奨される^2119。 ◎ It is RECOMMENDED that, when possible, servers respect the urgency parameter (Section 4.1), sending higher-urgency responses before lower-urgency responses.

`増分的か$は、［ 応答を成す各~byte列が到着するに伴い，それらを~clientがどう処理するか ］を指示する。 ~serverには、 アリなときは［ `増分的か$を尊重する ］ことが`推奨される^2119。 ◎ The incremental parameter indicates how a client processes response bytes as they arrive. It is RECOMMENDED that, when possible, servers respect the incremental parameter (Section 4.2).

同じ`緊急度$を伴う非-増分的な応答たちは、［ 帯域幅の割振nを各~応答の~stream~IDの昇順で優先度化する ］ことにより，~serveされるベキである — この順序は、［ それらの応答が応対した要請たち ］を~clientが為した順序に対応する。 そうすることは、 ~clientが［ 要請の順序付けを応答の順序に波及させるために利用できる ］ことを確保する。 ◎ Non-incremental responses of the same urgency SHOULD be served by prioritizing bandwidth allocation in ascending order of the stream ID, which corresponds to the order in which clients make requests. Doing so ensures that clients can use request ordering to influence response order.

同じ`緊急度$を伴う増分的な応答たちは、 それらで帯域幅を共有することにより~serveするベキである。 増分的な応答の`~message内容$は、 それを成す［ 各部／各~chunk ］が受信されるに伴い利用される。 ~clientは、 単独の`資源$を成す全体よりも［ これらすべての資源を成す ある部位 ］を受信する方が便益があるかもしれない。 処理能を改善するにあたって有用になるために必要な［ 資源を成す部位の大きさ ］は、 資源の型【`~MIME型$など】に応じて変わる — ~criticalな要素を先頭近くに配置する型もあれば、 情報を漸進的に利用できる型もある。 この~schemeは、 ~serverが優先度化する方法を裁定するために［ ~size, 型, その他の入力 ］をどう利用するべきかについて，明示的に義務付けるものを何も供さない。 ◎ Incremental responses of the same urgency SHOULD be served by sharing bandwidth among them. The message content of incremental responses is used as parts, or chunks, are received. A client might benefit more from receiving a portion of all these resources rather than the entirety of a single resource. How large a portion of the resource is needed to be useful in improving performance varies. Some resource types place critical elements early; others can use information progressively. This scheme provides no explicit mandate about how a server should use size, type, or any other input to decide how to prioritize.

~serverが複数の［ 増分的な応答, 非-増分的な応答 ］を同じ`緊急度$で~scheduleする必要がある局面もあり得る。 ［ `緊急度$, 要請の生成~順序 ］に基づく~schedule法の指導を厳密に守ることは、 ~clientにおいて最適とは言えない結果へ至らすかもしれない — 早く来た非-増分的な応答が，後で発行される増分的な応答を~serveできなくするかもしれないので。 そのような難題の例として，次が挙げられる： ◎ There can be scenarios where a server will need to schedule multiple incremental and non-incremental responses at the same urgency level. Strictly abiding by the scheduling guidance based on urgency and request generation order might lead to suboptimal results at the client, as early non-incremental responses might prevent the serving of incremental responses issued later. The following are examples of such challenges:

• 同じ`緊急度$で、［ 大きい資源~用の非-増分的な要請 ］に［ 小さい資源~用の増分的な要請 ］が後続する。 ◎ At the same urgency level, a non-incremental request for a large resource followed by an incremental request for a small resource.
• 同じ`緊急度$で、［ 長さが不確定な増分的な要請 ］に［ 大きい資源~用の非-増分的な要請 ］が後続する。 ◎ At the same urgency level, an incremental request of indeterminate length followed by a non-incremental large resource.

~serverには、 アリな所では，そのような後回を避けることが`推奨される^2119。 そのための手法は、 実装の裁定である。 例えば、 ~serverは、 他の情報 — `内容$の~sizeなど — に基づいて， 特定0の増分的な【！incremental type】応答を先取的に送信するかもしれない。 ◎ It is RECOMMENDED that servers avoid such starvation where possible. The method for doing so is an implementation decision. For example, a server might preemptively send responses of a particular incremental type based on other information such as content size.

~server~pushの最適な~schedule法は、 困難である — とりわけ、 ~pushされる資源と作動中な同時並行な要請たちが争っているときには。 ~serverは、 ~scheduleするときに，多くの要因を考慮できる — ~pushされている資源の型や~size, 当の~pushを誘発した要請の優先度, 作動中な同時並行な応答たちの総数, 他の作動中な同時並行な各~応答の優先度, 等々 — など。 これらを最善な仕方で適用するための一般な指導は無い。 単純~過ぎる~serverは，［ 高過ぎる優先度で~pushして~client要請を阻む／ 低過ぎる優先度で~pushして応答を遅延する ］ようにもなり易く、 その結果，~server~pushに意図された目標を否定することになる。 ◎ Optimal scheduling of server push is difficult, especially when pushed resources contend with active concurrent requests. Servers can consider many factors when scheduling, such as the type or size of resource being pushed, the priority of the request that triggered the push, the count of active concurrent responses, the priority of other active concurrent responses, etc. There is no general guidance on the best way to apply these. A server that is too simple could easily push at too high a priority and block client requests, or push at too low a priority and delay the response, negating intended goals of server push.

優先度~通達は、 ~server~pushを~scheduleするための要因を成す。 ~clientが明示的に通達する初期~優先度は無いので、 既定の~parameter値の概念は，その適用-法が少し異なる。 ~serverは、 `生成元~server$【！origin】からの応答~内に供された優先度~通達を適用できる — `8§ にて与えた併合-法の指導を見よ。 生成元~server【！origin】からの通達が無い場合、 既定の~parameter値を適用すると，最適とは言えない結果になることもある。 ~serverは、［ ~pushされる応答たちを~scheduleするための手段 ］として自身が裁定したものが何であれ，［［ `PUSH_PROMISE^ft ／ `HEADERS^ft ］~frame内に`~Priority~field値^i ~fieldを内包する ］ことにより， 意図される優先度を~clientへ通達できる。 ◎ Priority signals are a factor for server push scheduling. The concept of parameter value defaults applies slightly differently because there is no explicit client-signaled initial priority. A server can apply priority signals provided in an origin response; see the merging guidance given in Section 8. In the absence of origin signals, applying default parameter values could be suboptimal. By whatever means a server decides to schedule a pushed response, it can signal the intended priority to the client by including the Priority field in a PUSH_PROMISE or HEADERS frame.

11. ~schedule法と `CONNECT^m ~method

この文書における~schedule法の指導は、 ある~streamが `CONNECT$m 要請を運ぶときには， 当の~stream上の~frameたちに適用される。 複数の `CONNECT$m 要請を発行する~clientは、 `増分的か$を ~T に設定し得る。 `増分的か$を取扱うための推奨（ `10§ ）を実装する~serverは、 そのような~streamが他の~streamを阻まないようにするために， それらを公平に~scheduleする見込みが高い。 ◎ When a stream carries a CONNECT request, the scheduling guidance in this document applies to the frames on the stream. A client that issues multiple CONNECT requests can set the incremental parameter to true. Servers that implement the recommendations for handling of the incremental parameter (Section 10) are likely to schedule these fairly, preventing one CONNECT stream from blocking others.

12. 再~伝送の~schedule法

~TCPや~QUICなどの~transport~protocolは、［ ~packet喪失を検出して，喪失した情報を伝送し直す ］ことにより，依拠-能を供する。 `10§ における考慮点に加えて、 再~伝送~dataの~schedule法も，新たな~dataのそれと争うことがある。 以下では、 ~QUICを利用しているときの考慮点を論じる。 ◎ Transport protocols such as TCP and QUIC provide reliability by detecting packet losses and retransmitting lost information. In addition to the considerations in Section 10, scheduling of retransmission data could compete with new data. The remainder of this section discusses considerations when using QUIC.

`QUIC$r `13.3＠~RFCx/rfc9000#section-13.3§ は、 端点は、 応用により指定された優先度が他を指示しない限り， 新たな~dataの送信よりも~dataの再~伝送を優先するベキである と言明する。 ある~HTTP3応用が［ この文書にて定義された優先度~scheme ］を利用していて， 当の~QUIC~transport実装は［ 応用が指示した~stream優先度 ］を~supportするとき、 当の~transportが［ 新たな~dataと再~伝送~dataの両者を~scheduleするときに， ~streamどうしの相対的な優先度を考慮する ］ならば，当の応用の期待に より良く合致するかもしれない。 しかしながら，［ ~transportが，この情報に基づく~schedule法をどう選ぶか ］に対する要件は無い — そのような裁定は、 いくつかの要因や~trade-offに依存するので。 ~transportは、［ 優先度がより低い~stream用の再~伝送~dataより， 緊急度がより高い~stream用の新たな~dataを優先する ］こともあれば，［ 緊急度に関わらず，新たな~dataよりも再~伝送~dataを優先する ］こともある。 ◎ Section 13.3 of [QUIC] states the following: "Endpoints SHOULD prioritize retransmission of data over sending new data, unless priorities specified by the application indicate otherwise". When an HTTP/3 application uses the priority scheme defined in this document and the QUIC transport implementation supports application-indicated stream priority, a transport that considers the relative priority of streams when scheduling both new data and retransmission data might better match the expectations of the application. However, there are no requirements on how a transport chooses to schedule based on this information because the decision depends on several factors and trade-offs. It could prioritize new data for a higher-urgency stream over retransmission data for a lower-priority stream, or it could prioritize retransmission data over new data irrespective of urgencies.

`QUIC-RECOVERY$r `6.2.4＠~RFCx/rfc9002#section-6.2.4§ は、［ `Probe Timeout timer^en の失効より後に探査~packetを送信する ］ときの［ 応用~優先度に関する考慮点 ］も特に挙げている。 ~QUIC実装のうち［ 応用が指示する優先度を~supportするもの ］は、［ 探査~dataを選ぶときに， ~streamどうしの相対的な優先度を利用する ］かもしれない。 ◎ Section 6.2.4 of [QUIC-RECOVERY] also highlights considerations regarding application priorities when sending probe packets after Probe Timeout timer expiration. A QUIC implementation supporting application-indicated priorities might use the relative priority of streams when choosing probe data.

13. 公平性

~HTTP実装は、［ 帯域幅を争っている接続どうしの公平性 ］を，概して下層の~transportに依存して保守する。 `媒介者$は、［ いくつかの~client ］からの［ いくつかの接続 ］上で受信した［ いくつかの~HTTP要請 ］を［ いくつかの~backend接続 ］へ回送する。 媒介者が異なる~backend接続たちにわたって，要請たちを どう［ 合体する／分割する ］かに依存して、 各~clientが経験する処理能は，類似でないかもしれない。 この非類似性は、 媒介者が各~要請を回送するときに優先度~通達も利用する場合には， 拡大するかもしれない。 ［ `13.1§, `13.2§ ］では、 この［ 不公平性の拡大 ］に対する軽減策を論じる。 ◎ Typically, HTTP implementations depend on the underlying transport to maintain fairness between connections competing for bandwidth. When an intermediary receives HTTP requests on client connections, it forwards them to backend connections. Depending on how the intermediary coalesces or splits requests across different backend connections, different clients might experience dissimilar performance. This dissimilarity might expand if the intermediary also uses priority signals when forwarding requests. Sections 13.1 and 13.2 discuss mitigations of this expansion of unfairness.

逆に，`13.3§では、 ~serverが［ 接続たちに割振る帯域幅 ］を［ 優先度~通達に依存して，どう意図的に不均等にし得るか ］を論じる。 ◎ Conversely, Section 13.3 discusses how servers might intentionally allocate unequal bandwidth to some connections, depending on the priority signals.

14. なぜ端点間な~headerを利用するか？

~HTTP2による［ `隣点間$な~frameを利用する優先度化~scheme ］とは対照的に、 `Priority$h ~headerは、 “端点間” として定義される。 ◎ In contrast to the prioritization scheme of HTTP/2, which uses a hop-by-hop frame, the Priority header field is defined as "end-to-end".

~clientが応答を処理する仕方は、［ `媒介者$ではなく，当の応答が応対した要請を`生成-$した~client ］に結付けられる特質であり、 したがって，`端点間$な特質である。 ［ `Priority$h ~headerにより運ばれる これら端点間な特質 ］が［ 同じ接続を共有する応答どうしの優先度化にどう影響するか ］は、 `隣点間$な課題である。 ◎ The way that a client processes a response is a property associated with the client generating that request, not that of an intermediary. Therefore, it is an end-to-end property. How these end-to-end properties carried by the Priority header field affect the prioritization between the responses that share a connection is a hop-by-hop issue.

`Priority$h ~headerを`隣点間$ではなく`端点間$として定義したことは、 ~cacheしている`媒介者$にとって重要である。 そのように定義するだけで、 媒介者は［ `Priority$h ~headerの値を応答と伴に~cacheして、 ~cacheした応答を~serveするときに，その値も用立てれる ］ようになるので。 ◎ Having the Priority header field defined as end-to-end is important for caching intermediaries. Such intermediaries can cache the value of the Priority header field along with the response and utilize the value of the cached header field when serving the cached response, only because the header field is defined as end-to-end rather than hop-by-hop.

15. ~securityの考慮点

`7§は、 `PRIORITY_UPDATE$ft ~frameを~bufferしている~server用の考慮点を述べる。 ◎ Section 7 describes considerations for server buffering of PRIORITY_UPDATE frames.

`10§は、 応答たちをある種の仕方で優先度化する~serverは， 一部の応答を伝送する能が後回され得る例を呈示する。 ◎ Section 10 presents examples where servers that prioritize responses in a certain way might be starved of the ability to transmit responses.

`STRUCTURED-FIELDS$r による~securityの考慮点は、 `4§に定義される優先度~parameterの処理にも適用される。 ◎ The security considerations from [STRUCTURED-FIELDS] apply to the processing of priority parameters defined in Section 4.

16. ~IANA考慮点

この仕様は、 `HTTP$r【！`HTTP/2$r】 にて定義される `~HTTP~field名~registry＠~IANA-a/http-fields/$cite 内に，次の~entryを登録する： ◎ This specification registers the following entry in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" defined in [HTTP/2]:

• ~field名 ⇒ `Priority$h ◎ Field Name: • Priority
• 位置付け ⇒ `恒久的^i ◎ Status: • permanent
• 参照 ⇒ この文書 ◎ Reference: • This document

この仕様は、 `HTTP/2$r にて定義された `~HTTP2設定群~registry＠~IANA-a/http2-parameters/#settings$cite 内に，次の~entryを登録する： ◎ This specification registers the following entry in the "HTTP/2 Settings" registry defined in [HTTP/2]:

• ~code ⇒ `0x9^hex ◎ Code: • 0x9
• 名前 ⇒ `SETTINGS_NO_RFC7540_PRIORITIES$sp ◎ Name: • SETTINGS_NO_RFC7540_PRIORITIES
• 初期~値 ⇒ 0 ◎ Initial Value: • 0
• 参照 ⇒ この文書 ◎ Reference: • This document

この仕様は、 `HTTP/2$r にて定義された `~HTTP2~frame種別~registry＠~IANA-a/http2-parameters/#frame-type$cite 内に，次の~entryを登録する： ◎ This specification registers the following entry in the "HTTP/2 Frame Type" registry defined in [HTTP/2]:

• ~code ⇒ `0x10^hex ◎ Code: • 0x10
• ~frame種別 ⇒ `PRIORITY_UPDATE$ft ◎ Frame Type: • PRIORITY_UPDATE
• 参照 ⇒ この文書 ◎ Reference: • This document

この仕様は、 `HTTP/3$r により確立された `~HTTP3~frame種別~registry＠~IANA-a/http3-parameters/#http3-parameters-frame-types$cite 内に，次の~entryを登録する： ◎ This specification registers the following entry in the "HTTP/3 Frame Types" registry established by [HTTP/3]:

• 値 ⇒ `0xF0700^hex 〜 `0xF0701^hex ◎ Value: • 0xF0700-0xF0701
• ~frame種別 ⇒ `PRIORITY_UPDATE$ft ◎ Frame Type: • PRIORITY_UPDATE
• 位置付け ⇒ `恒久的^i ◎ Status: • permanent
• 参照 ⇒ この文書 ◎ Reference: • This document
• 変更~制御者 ⇒ ~IETF ◎ Change Controller: • IETF
• 連絡先 ⇒ ietf-http-wg@w3.org ◎ Contact: • ietf-http-wg@w3.org

~IANAは、 `~HTTP優先度~registry＠~IANA-a/http-priority$cite を作成して， それを`次の表t＠#iana-parameter-table$に挙げる~entryたちで拡充した。 登録~手続-は、 `4.3.1§を見よ。 ◎ IANA has created the "Hypertext Transfer Protocol (HTTP) Priority" registry at <https://www.iana.org/assignments/http-priority> and has populated it with the entries in Table 1; see Section 4.3.1 for its associated procedures.

謝辞

`Roy Fielding^en 氏は、 `https://www.ietf.org/proceedings/83/slides/slides-83-httpbis-5.pdf＠https://www.ietf.org/proceedings/83/slides/slides-83-httpbis-5.pdf$ にて，優先度を表現する~headerを利用する案を呈示された。 `Patrick Meenan^en 氏は、 `https://github.com/pmeenan/http3-prioritization-proposal＠https://github.com/pmeenan/http3-prioritization-proposal$ にて， ( 緊急度, 同時並行~度 ) が成す~tupleを利用して優先度を表現することを提唱された。 ~HTTP2優先度化を不能化する能は、 `PRIORITY-SETTING$r により着想された — それは、 `Brad Lassey^en, `Lucas Pardue^en 各氏により著作され， その文書の更新の中へは組入れられなかった~feedbackに基づく改変を伴う。 ◎ Roy Fielding presented the idea of using a header field for representing priorities in <https://www.ietf.org/proceedings/83/slides/slides-83-httpbis-5.pdf>. In <https://github.com/pmeenan/http3-prioritization-proposal>, Patrick Meenan advocated for representing the priorities using a tuple of urgency and concurrency. The ability to disable HTTP/2 prioritization is inspired by [PRIORITY-SETTING], authored by Brad Lassey and Lucas Pardue, with modifications based on feedback that was not incorporated into an update to that document.

~HTTP2優先度の代替を定義する動機は、 広範な~HTTP~communityの中での論点から引き出された。 この文書~内に明示的に組入れられた~textを寄せられた `Roberto Peon^en 氏, `Martin Thomson^en 氏, Netflix に特に感謝する。 ◎ The motivation for defining an alternative to HTTP/2 priorities is drawn from discussion within the broad HTTP community. Special thanks to Roberto Peon, Martin Thomson, and Netflix for text that was incorporated explicitly in this document.

上に挙げた方々に加えて、 この文書は，~HTTP優先度~設計~teamの［ 次に挙げる方々, この文書の著作者 ］による多方面な論点に多くを負っている ⇒＃ `Alan Frindell^en, `Andrew Galloni^en, `Craig Taylor^en, `Ian Swett^en, `Matthew Cox^en, `Mike Bishop^en, `Roberto Peon^en, `Robin Marx^en, `Roy Fielding^en ◎ In addition to the people above, this document owes a lot to the extensive discussion in the HTTP priority design team, consisting of Alan Frindell, Andrew Galloni, Craig Taylor, Ian Swett, Matthew Cox, Mike Bishop, Roberto Peon, Robin Marx, Roy Fielding, and the authors of this document.

`Yang Chi^en 氏は、 再~伝送の~schedule法についての節を貢献された。 ◎ Yang Chi contributed the section on retransmission scheduling.