[要約] RFC 9213は、特定のキャッシュやキャッシュのクラスにキャッシュディレクティブを指定するためのHTTP応答ヘッダーフィールドの規約を定義しています。CDN-Cache-Control応答ヘッダーフィールドを通じて、コンテンツ配信ネットワーク（CDN）キャッシュを対象としています。
Internet Engineering Task Force (IETF) S. Ludin
Request for Comments: 9213 Akamai
Category: Standards Track M. Nottingham
ISSN: 2070-1721 Fastly
Y. Wu
Cloudflare
June 2022
Targeted HTTP Cache Control
ターゲットを絞ったHTTPキャッシュコントロール
Abstract
概要
This specification defines a convention for HTTP response header fields that allow cache directives to be targeted at specific caches or classes of caches. It also defines one such header field, the CDN-Cache-Control response header field, which is targeted at content delivery network (CDN) caches.
この仕様は、キャッシュ指令を特定のキャッシュまたはキャッシュのクラスをターゲットにすることを可能にするHTTP応答ヘッダーフィールドの規則を定義します。また、そのようなヘッダーフィールドであるCDN-Cache-control Response Headerフィールドを定義します。これは、コンテンツ配信ネットワーク（CDN）キャッシュを対象としています。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9213.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9213で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されているように保証なしで提供される修正されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction
1.1. Notational Conventions
2. Targeted Cache-Control Header Fields
2.1. Syntax
2.2. Cache Behavior
2.3. Interaction with HTTP Freshness
2.4. Defining Targeted Fields
3. The CDN-Cache-Control Targeted Field
3.1. Examples
4. IANA Considerations
5. Security Considerations
6. References
6.1. Normative References
6.2. Informative References
Authors' Addresses
Modern deployments of HTTP often use multiple layers of caching. For example, a website might use a cache on the origin server itself; it might deploy a caching layer in the same network as the origin server, it might use one or more CDNs that are distributed throughout the Internet, and it might benefit from browser caching as well.
HTTPの最新の展開は、多くの場合、複数のキャッシングを使用します。たとえば、WebサイトはOrigin Server自体でキャッシュを使用する場合があります。Origin Serverと同じネットワークにキャッシュレイヤーを展開する可能性があり、インターネット全体に分散されている1つ以上のCDNを使用する可能性があり、ブラウザのキャッシングからも恩恵を受ける可能性があります。
Because it is often desirable to control these different classes of caches separately, some means of targeting cache directives at them is necessary. For example, if a publisher has a mechanism to invalidate the contents of a cache that it has a relationship with (such as a CDN cache), they might be more comfortable assigning a more generous caching policy to it while still wanting to restrict the behavior of other caches.
これらの異なるクラスのキャッシュを個別に制御することが望ましいことが多いため、それらでキャッシュ指令をターゲットにする手段が必要です。たとえば、パブリッシャーが（CDNキャッシュなど）との関係があるキャッシュの内容を無効にするメカニズムを持っている場合、動作を制限したい間、より寛大なキャッシュポリシーをより快適に割り当てることができます。他のキャッシュの。
The HTTP Cache-Control response header field (defined in Section 5.2 of [HTTP-CACHING]) is widely used to direct caching behavior. However, it is relatively undifferentiated; while some cache directives (e.g., s-maxage) are targeted at a specific class of caches (for s-maxage, shared caches), targeting is not consistently available across all existing cache directives (e.g., stale-while-revalidate). This is problematic especially as the number of caching extensions grows along with the number of potential targets.
HTTPキャッシュコントロール応答ヘッダーフィールド（[httpキャッシュ]のセクション5.2で定義）は、キャッシュ挙動を指示するために広く使用されています。ただし、比較的差別化されていません。一部のキャッシュディレクティブ（S-Maxageなど）は、特定のクラスのキャッシュ（Sマクセージ、共有キャッシュ用）を対象としていますが、ターゲティングは既存のすべてのキャッシュディレクティブ（例えば、陳腐化した場合の陳腐化）で一貫して利用できません。これは、特にキャッシュ拡張の数が潜在的なターゲットの数とともに増加するため、問題があります。
Some implementations have defined ad hoc control mechanisms to overcome this issue, but their interoperability is low. Section 2 defines a standard framework for targeted cache control using HTTP response headers, and Section 3 defines one such header: the CDN-Cache-Control response header field.
一部の実装では、この問題を克服するためのアドホック制御メカニズムを定義していますが、相互運用性は低いです。セクション2では、HTTP応答ヘッダーを使用してターゲットキャッシュ制御の標準フレームワークを定義し、セクション3では、そのようなヘッダーの1つを定義します：CDN-Cache-Control Response Headerフィールド。
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.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
A Targeted Cache-Control Header Field (hereafter "targeted field") is an HTTP response header field that has the same semantics as the Cache-Control response header field ([HTTP-CACHING], Section 5.2). However, it has a distinct field name that indicates the target for its cache directives.
ターゲットを絞ったキャッシュコントロールヘッダーフィールド（以下「ターゲットフィールド」）は、キャッシュコントロール応答ヘッダーフィールド（[HTTPキャッシュ]、セクション5.2）と同じセマンティクスを持つHTTP応答ヘッダーフィールドです。ただし、キャッシュ指令のターゲットを示す明確なフィールド名があります。
For example:
例えば：
CDN-Cache-Control: max-age=60
CDN-Cache-Control：Max-Age = 60
is a targeted field that applies to CDNs, as defined in Section 3.
セクション3で定義されているように、CDNに適用されるターゲットフィールドです。
Targeted fields are Dictionary Structured Fields (Section 3.2 of [STRUCTURED-FIELDS]). Each member of the Dictionary is an HTTP cache response directive (Section 5.2.2 of [HTTP-CACHING]) including extension response directives (as per Section 5.2.3 of [HTTP-CACHING]). Note that while targeted fields often have the same syntax as Cache-Control fields, differences in error handling mean that using a Cache-Control parser rather than a Structured Fields parser can introduce interoperability issues.
ターゲットフィールドは、辞書構造化場です（[構造化場]のセクション3.2）。辞書の各メンバーは、拡張レスポンスディレクティブ（[HTTPキャッシュ]のセクション5.2.3に従って）を含むHTTPキャッシュ応答指令（[httpキャッシュ]のセクション5.2.2）です。ターゲットフィールドはしばしばキャッシュコントロールフィールドと同じ構文を持っていますが、エラー処理の違いは、構造化されたフィールドパーサーではなくキャッシュコントロールパーサーを使用すると相互運用性の問題を導入できることを意味することに注意してください。
Because cache directives are not defined in terms of structured data types, it is necessary to map their values into the appropriate types. Section 5.2 of [HTTP-CACHING] defines cache directive values to be either absent, a quoted-string, or a token.
Cacheディレクティブは構造化されたデータ型の観点から定義されていないため、値を適切なタイプにマッピングする必要があります。[httpキャッシュ]のセクション5.2では、キャッシュ指令値が不在、引用されたストリング、またはトークンのいずれかであることを定義しています。
This means that cache directives that have no value will be mapped to
a Boolean (Section 3.3.6 of [STRUCTURED-FIELDS]). When the value is
a quoted-string, it will be mapped to a String (Section 3.3.3 of
[STRUCTURED-FIELDS]), and when it is a token, it will map to a Token
(Section 3.3.4 of [STRUCTURED-FIELDS]), an Integer (Section 3.3.1 of
[STRUCTURED-FIELDS]), or a Decimal (Section 3.3.2 of
[STRUCTURED-FIELDS]), depending on the content of the value.
For example, the max-age directive (Section 5.2.2.1 of [HTTP-CACHING]) has an integer value; no-store (Section 5.2.2.5 of [HTTP-CACHING]) always has a Boolean true value, and no-cache (Section 5.2.2.4 of [HTTP-CACHING]) has a value that can be either Boolean true or a string containing a comma-delimited list of field names.
たとえば、最大年齢指令（[HTTPキャッシュ]のセクション5.2.2.1）には整数値があります。ノーストア（[httpキャッシュ]のセクション5.2.2.5）には常にブールの真の値があり、ノーキャッシュ（[httpキャッシング]のセクション5.2.2.4）には、ブールトゥルーまたは文字列のいずれかの値があります。フィールド名のコンマが区切るリストが含まれています。
Implementations MUST NOT generate values that violate these inferred constraints on the cache directive's value. In particular, string values whose first character is not alphabetic or "*" MUST be generated as Strings so that they are not mistaken for other types.
実装は、Cacheディレクティブの値にこれらの推定された制約に違反する値を生成してはなりません。特に、最初の文字がアルファベットではない文字列値または「*」は、他のタイプと間違えないように文字列として生成する必要があります。
Implementations SHOULD NOT consume values that violate these inferred constraints. For example, a consuming implementation that coerces a max-age with a decimal value into an integer would behave differently than other implementations, potentially causing interoperability issues.
実装は、これらの推定された制約に違反する値を消費してはなりません。たとえば、整数に小数値を持つ最大年齢を強制する消費実装は、他の実装とは異なる動作を行い、相互運用性の問題を引き起こす可能性があります。
Parameters received on cache directives are to be ignored, unless other handling is explicitly specified.
キャッシュ指令で受信されたパラメーターは、他のハンドリングが明示的に指定されていない限り、無視されます。
If a targeted field in a given response is empty, or a parsing error is encountered, that field MUST be ignored by the cache (i.e., it behaves as if the field were not present, likely falling back to other cache-control mechanisms present).
特定の応答のターゲットフィールドが空である場合、または解析エラーが発生した場合、そのフィールドはキャッシュによって無視する必要があります（つまり、フィールドが存在しないかのように動作し、おそらく他のキャッシュ制御メカニズムに戻る可能性があります）。
A cache that implements this specification maintains a target list. A target list is an ordered list of the targeted field names that it uses for caching policy, with the order reflecting priority from most applicable to least. The target list might be fixed, user configurable, or generated per request, depending upon the implementation.
この仕様を実装するキャッシュは、ターゲットリストを維持します。ターゲットリストは、キャッシングポリシーに使用するターゲットフィールド名の順序付けられたリストであり、順序は最優先事項から最小限の優先度を反映しています。ターゲットリストは、実装に応じて、リクエストごとに固定、ユーザー構成、または生成される場合があります。
For example, a CDN cache might support both CDN-Cache-Control and a header specific to that CDN, ExampleCDN-Cache-Control, with the latter overriding the former. Its target list would be:
たとえば、CDNキャッシュは、そのCDNに固有のCDNキャッシュ制御とヘッダーの両方をサポートする場合があり、後者は前者を無効にします。そのターゲットリストは次のとおりです。
[ExampleCDN-Cache-Control, CDN-Cache-Control]
[examplecdn-cache-control、cdn-cache-control]
When a cache that implements this specification receives a response with one or more of the header field names on its target list, the cache MUST select the first (in target-list order) field with a valid, non-empty value and use its value to determine the caching policy for the response, and it MUST ignore the Cache-Control and Expires header fields in that response, unless no valid, non-empty value is available from the listed header fields.
この仕様を実装するキャッシュが、ターゲットリストに1つ以上のヘッダーフィールド名を含む応答を受信する場合、キャッシュは有効で空の値で最初の（ターゲットリスト順）フィールドを選択し、その値を使用する必要があります応答のキャッシュポリシーを決定するには、キャッシュコントロールを無視し、リストされているヘッダーフィールドから有効な非空白の値が利用できない限り、その応答でヘッダーフィールドの有効期限が切れなければなりません。
Note that this occurs on a response-by-response basis; if no member of the cache's target list is present, valid, and non-empty, a cache falls back to other cache control mechanisms as required by HTTP [HTTP-CACHING].
これは、応答ごとに発生することに注意してください。キャッシュのターゲットリストのメンバーが存在しない、有効で、無効でない場合、キャッシュはHTTP [HTTPキャッシュ]で要求される他のキャッシュ制御メカニズムに戻ります。
Targeted fields that are not on a cache's target list MUST NOT change that cache's behavior and MUST be passed through.
キャッシュのターゲットリストにないターゲットフィールドは、そのキャッシュの動作を変更してはならず、通過する必要があります。
Caches that use a targeted field MUST implement the semantics of the following cache directives:
ターゲットフィールドを使用するキャッシュは、次のキャッシュ指令のセマンティクスを実装する必要があります。
* max-age
* 最大年齢
* must-revalidate
* 必須の再評価
* no-store
* 店なし
* no-cache
* キャッシュなし
* private
* プライベート
Furthermore, they SHOULD implement other cache directives (including extension cache directives) that they support in the Cache-Control response header field.
さらに、キャッシュコントロール応答ヘッダーフィールドでサポートする他のキャッシュディレクティブ（拡張キャッシュディレクティブを含む）を実装する必要があります。
The semantics and precedence of cache directives in a targeted field are the same as those in Cache-Control. In particular, no-store and no-cache make max-age inoperative, and unrecognized extension directives are ignored.
ターゲットフィールドでのキャッシュ指令のセマンティクスと優先順位は、キャッシュ制御のセマンティックと同じです。特に、非ストアやキャッシュなしで、最大年齢が動作しなくなり、認識されていない拡張ディレクティブが無視されます。
HTTP caching has a single, end-to-end freshness model defined in Section 4.2 of [HTTP-CACHING]. When additional freshness mechanisms are only available to some caches along a request path (for example, using targeted fields), their interactions need to be carefully considered. In particular, a targeted cache might have longer freshness lifetimes available to it than other caches, causing it to serve responses that appear to be prematurely (or even immediately) stale to those other caches, negatively impacting cache efficiency.
HTTPキャッシュには、[HTTPキャッシュ]のセクション4.2で定義された単一のエンドツーエンドの鮮度モデルがあります。追加の鮮度メカニズムが要求パスに沿って一部のキャッシュでのみ利用可能である場合（たとえば、ターゲットフィールドを使用する）、それらの相互作用を慎重に考慮する必要があります。特に、ターゲットを絞ったキャッシュは、他のキャッシュよりも新鮮さの寿命が長くなる可能性があり、他のキャッシュに対して時期尚早に（またはすぐに）古くなっているように見える応答を提供し、キャッシュ効率に悪影響を及ぼします。
For example, a response stored by a CDN cache might be served with the following headers:
たとえば、CDNキャッシュによって保存された応答は、次のヘッダーとともに提供される場合があります。
Age: 1800
Cache-Control: max-age=600
CDN-Cache-Control: max-age=3600
From the CDN's perspective, this response is still fresh after being cached for 30 minutes, while from the standpoint of other caches, this response is already stale. See [AGE-PENALTY] for more discussion.
CDNの観点から見ると、この反応は30分間キャッシュされた後も新鮮ですが、他のキャッシュの観点からは、この応答はすでに古くなっています。詳細については、[Age-Penalty]を参照してください。
When the targeted cache has a strong coherence mechanism (e.g., the origin server has the ability to proactively invalidate cached responses), it is often desirable to mitigate these effects. Some techniques seen in deployments include:
ターゲットキャッシュに強いコヒーレンスメカニズムがある場合（たとえば、Origin Serverにキャッシュされた応答を積極的に無効にする機能があります）、これらの効果を軽減することが望ましいことがよくあります。展開で見られるいくつかのテクニックには次のものがあります。
* Removing the Age header field
* 年齢ヘッダーフィールドの削除
* Updating the Date header field value to the current time
* 日付ヘッダーフィールド値を現在の時刻に更新する
* Updating the Expires header field value to the current time, plus any Cache-Control: max-age value
* 有効期限のヘッダーフィールド値を現在の時刻に更新することに加えて、キャッシュコントロール：最大時代の値
This specification does not place any specific requirements on implementations to mitigate these effects, but definitions of targeted fields can do so.
この仕様では、これらの効果を軽減するための実装に特定の要件を掲載しませんが、ターゲットフィールドの定義はそうすることができます。
A targeted field for a particular class of cache can be defined by requesting registration in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" (<https://www.iana.org/assignments/http-fields/>).
特定のクラスのキャッシュのターゲットフィールドは、「HyperText Transfer Protocol（HTTP）フィールド名レジストリ」（<https://www.iana.org/assignments/http-fields/>）の登録を要求することで定義できます。
Registration requests can use this document as the specification document; in which case, the Comments field should clearly define the class of caches that the targeted field applies to. Alternatively, if other documentation for the field has been created, it can be used as the specification document.
登録リクエストは、このドキュメントを仕様文書として使用できます。その場合、コメントフィールドは、ターゲットフィールドが適用されるキャッシュのクラスを明確に定義する必要があります。または、フィールドの他のドキュメントが作成されている場合、仕様文書として使用できます。
By convention, targeted fields have the suffix "-Cache-Control", e.g., "ExampleCDN-Cache-Control". However, this suffix MUST NOT be used on its own to identify targeted fields; it is only a convention.
慣習により、ターゲットフィールドには接尾辞「-cache-control」があります。ただし、この接尾辞は、ターゲットフィールドを識別するために単独で使用してはなりません。それは単なる慣習です。
The CDN-Cache-Control response header field is a targeted field (Section 2) that allows origin servers to control the behavior of CDN caches interposed between them and clients separately from other caches that might handle the response.
CDN-キャッシュコントロール応答ヘッダーフィールドは、ターゲットフィールド（セクション2）であり、オリジンサーバーは、応答を処理する可能性のある他のキャッシュとは別にクライアントの間に挿入されたCDNキャッシュの動作を制御できます。
It applies to caches that are part of a distributed network that operate on behalf of an origin server (commonly called a CDN).
オリジンサーバー（一般にCDNと呼ばれる）に代わって動作する分散ネットワークの一部であるキャッシュに適用されます。
CDN caches that use CDN-Cache-Control will typically forward this header so that downstream CDN caches can use it as well. However, they MAY remove it when this is undesirable (for example, when configured to do so because it is known not to be used downstream).
CDNキャッシュコントロールを使用するCDNキャッシュは、通常、このヘッダーを転送して、ダウンストリームCDNキャッシュも同様に使用できるようにします。ただし、これが望ましくない場合に削除する場合があります（たとえば、下流に使用しないことがわかっているため、そうするように構成されている場合）。
For example, the following header fields would instruct a CDN cache (i.e., a cache with a target list of [CDN-Cache-Control]) to consider the response fresh for 600 seconds, other shared caches to consider the response fresh for 120 seconds, and any remaining caches to consider the response fresh for 60 seconds:
たとえば、次のヘッダーフィールドは、600秒間応答を新鮮に検討するために、CDNキャッシュ（つまり、[CDN-Cache-Control]のターゲットリストを持つキャッシュ）を指示します。、および残りのキャッシュは、60秒間新鮮な応答を考慮します。
Cache-Control: max-age=60, s-maxage=120
CDN-Cache-Control: max-age=600
These header fields would instruct a CDN cache to consider the response fresh for 600 seconds, while all other caches would be prevented from storing it:
これらのヘッダーフィールドは、CDNキャッシュに600秒間新鮮な応答を検討するように指示しますが、他のすべてのキャッシュはそれを保存することができません。
CDN-Cache-Control: max-age=600 Cache-Control: no-store
CDN-CACHE-CONTROL：MAX-AGE = 600キャッシュコントロール：ストアなし
Because CDN-Cache-Control is not present, this header field would prevent all caches from storing the response:
cdn-cache-controlが存在しないため、このヘッダーフィールドは、すべてのキャッシュが応答を保存するのを防ぎます。
Cache-Control: no-store
キャッシュコントロール：ストアなし
Whereas these would prevent all caches except for CDN caches from storing the response:
一方、これらはCDNキャッシュを除くすべてのキャッシュを防ぎます。
Cache-Control: no-store CDN-Cache-Control: none
キャッシュコントロール：ストアなしCDN-Cache-Control：なし
(Note that 'none' is not a registered cache directive; it is here to avoid sending a header field with an empty value, which would be ignored.)
（「なし」は登録されたキャッシュ指令ではありません。空の値でヘッダーフィールドを送信しないようにするためにここにあります。
IANA has registered the following entry in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" defined by [HTTP]:
IANAは、[HTTP]で定義された「HyperText Transfer Protocol（HTTP）フィールド名レジストリ」に次のエントリを登録しました。
Field Name: CDN-Cache-Control Status: permanent Specification Document: RFC 9213 Comments: Cache directives targeted at content delivery networks
フィールド名：CDN-Cache-Controlステータス：永続的な仕様文書：RFC 9213コメント：コンテンツ配信ネットワークを対象としたキャッシュ指令
The security considerations of HTTP caching [HTTP-CACHING] apply.
HTTPキャッシュのセキュリティ上の考慮事項[HTTPキャッシング]が適用されます。
The ability to carry multiple caching policies on a response can result in confusion about how a response will be cached in different systems, potentially resulting in unintentional reuse of responses with sensitive information. For this reason, care must be exercised.
応答に複数のキャッシュポリシーを携帯する能力は、異なるシステムで応答がどのようにキャッシュされるかについて混乱する可能性があり、潜在的に機密情報を使用して意図しない応答を再利用することになります。このため、注意を払わなければなりません。
[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/info/rfc9110>.
[HTTP] Fielding、R.、Ed。、Nottingham、M.、Ed。、およびJ. Reschke、ed。、 "HTTP Semantics"、Std 97、RFC 9110、DOI 10.17487/RFC9110、2022年6月、<https：//www.rfc-editor.org/info/rfc9110>。
[HTTP-CACHING] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Caching", STD 98, RFC 9111, DOI 10.17487/RFC9111, June 2022, <https://www.rfc-editor.org/info/rfc9111>.
[HTTPキャッシュ] Fielding、R.、Ed。、Nottingham、M.、Ed。、およびJ. Reschke、ed。、 "Http Caching"、Std 98、RFC 9111、DOI 10.17487/RFC9111、2022年6月、<https：//www.rfc-editor.org/info/rfc9111>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<https://www.rfc-editor.org/info/RFC2119>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487/RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[STRUCTURED-FIELDS] Nottingham, M. and P-H. Kamp, "Structured Field Values for HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021, <https://www.rfc-editor.org/info/rfc8941>.
[構造化場]ノッティンガム、M。およびP-H。Kamp、「HTTPの構造化されたフィールド値」、RFC 8941、DOI 10.17487/RFC8941、2021年2月、<https://www.rfc-editor.org/info/rfc8941>。
[AGE-PENALTY] Cohen, E. and H. Kaplan, "The age penalty and its effect on cache performance", March 2001, <https://dl.acm.org/doi/10.5555/1251440.1251447>.
[年齢層]コーエン、E。、およびH.カプラン、「年齢のペナルティとキャッシュパフォーマンスへの影響」、2001年3月、<https://dl.acm.org/doi/10.5555/1251440.1251447>。
Authors' Addresses
著者のアドレス
Stephen Ludin Akamai Email: sludin@ludin.org
Stephen Ludin Akamaiメール：sludin@ludin.org
Mark Nottingham Fastly Prahran Australia Email: mnot@mnot.net URI: https://www.mnot.net/
マークノッティンガム急速プラランオーストラリアメールメール：mnot@mnot.net uri：https：//www.mnot.net/
Yuchen Wu Cloudflare Email: me@yuchenwu.net
Yuchen Wu Cloudflareメール：me@yuchenwu.net