Internet Engineering Task Force (IETF) P. Meenan, Ed.
Request for Comments: 9842 Google LLC
Category: Standards Track Y. Weiss, Ed.
ISSN: 2070-1721 Shopify Inc.
September 2025
This document specifies a mechanism for dictionary-based compression in the Hypertext Transfer Protocol (HTTP). By utilizing this technique, clients and servers can reduce the size of transmitted data, leading to improved performance and reduced bandwidth consumption. This document extends existing HTTP compression methods and provides guidelines for the delivery and use of compression dictionaries within the HTTP protocol.
このドキュメントは、ハイパーテキスト転送プロトコル（HTTP）における辞書ベースの圧縮のメカニズムを指定します。この手法を利用することにより、クライアントとサーバーは送信されたデータのサイズを削減し、パフォーマンスの向上と帯域幅の消費の削減につながる可能性があります。このドキュメントは、既存のHTTP圧縮方法を拡張し、HTTPプロトコル内の圧縮辞書の配信と使用に関するガイドラインを提供します。
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/rfc9842.
このドキュメントの現在のステータス、任意のERRATA、およびそれに関するフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9842で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 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ライセンステキストを含める必要があります。
1. Introduction
1.1. Use Cases
1.1.1. Version Upgrade
1.1.2. Common Content
1.2. Notational Conventions
2. Dictionary Negotiation
2.1. Use-As-Dictionary
2.1.1. "match"
2.1.2. "match-dest"
2.1.3. "id"
2.1.4. "type"
2.1.5. Examples
2.2. Available-Dictionary
2.2.1. Dictionary Freshness Requirement
2.2.2. Dictionary URL Matching
2.2.3. Multiple Matching Dictionaries
2.3. Dictionary-ID
3. The "compression-dictionary" Link Relation Type
4. Dictionary-Compressed Brotli
5. Dictionary-Compressed Zstandard
6. Negotiating the Content Encoding
6.1. Accept-Encoding
6.2. Content-Encoding
7. IANA Considerations
7.1. Content Encoding Registration
7.2. Header Field Registration
7.3. Link Relation Registration
8. Compatibility Considerations
9. Security Considerations
9.1. Changing Content
9.2. Reading Content
9.3. Security Mitigations
9.3.1. Cross-Origin Protection
9.3.2. Response Readability
9.3.3. Server Responsibility
10. Privacy Considerations
11. References
11.1. Normative References
11.2. Informative References
Authors' Addresses
This specification defines a mechanism for using designated HTTP [HTTP] responses as an external dictionary for future HTTP responses for compression schemes that support using external dictionaries (e.g., Brotli [RFC7932] and Zstandard [ZSTD]).
この仕様は、指定されたHTTP [HTTP]応答を、外部辞書（例：Brotli [RFC7932]およびZstandard [ZSTD]）を使用してサポートする圧縮スキームの将来のHTTP応答の外部辞書として使用するメカニズムを定義します。
This document describes the HTTP headers used for negotiating dictionary usage and registers content-encoding values for compressing with Brotli and Zstandard using a negotiated dictionary.
このドキュメントでは、辞書の使用の交渉に使用されるHTTPヘッダーについて説明し、交渉辞書を使用してBrotliとZstandardに圧縮するためのコンテンツエンコード値を登録します。
The negotiation of dictionary usage leverages HTTP's content negotiation (see Section 12 of [HTTP]) and is usable with all versions of HTTP.
辞書の使用法の交渉は、HTTPのコンテンツネゴシエーション（[http]のセクション12を参照）をレバレッジし、HTTPのすべてのバージョンで使用できます。
Any HTTP response can be specified for use as a compression dictionary for future HTTP requests, which provides a lot of flexibility. Two common use cases that are seen frequently are described below.
HTTP応答は、将来のHTTPリクエストの圧縮辞書として使用するために指定できます。これは、多くの柔軟性を提供します。頻繁に見られる2つの一般的なユースケースを以下に説明します。
Using a previous version of a resource as a dictionary for a newer version enables delivery of a delta-compressed version of the changes, usually resulting in significantly smaller responses than what can be achieved by compression alone.
新しいバージョンの辞書として以前のバージョンのリソースを使用すると、デルタが圧縮されたバージョンの変更を配信できます。通常、圧縮だけで達成できるものよりも大幅に小さい応答が得られます。
For example:
例えば：
Client Server
| |
| GET /app.v1.js |
|------------------------------------------------->|
| |
| 200 OK |
| Use-As-Dictionary: match="/app*js" |
| <full app.v1.js resource - 100KB compressed> |
|<-------------------------------------------------|
| |
Some time later ...
Client Server
| |
| GET /app.v2.js |
| Available-Dictionary: :pZGm1A...2a2fFG4=: |
| Accept-Encoding: gzip, br, zstd, dcb, dcz |
|------------------------------------------------->|
| |
| 200 OK |
| Content-Encoding: dcb |
| <delta-compressed app.v2.js resource - 1KB> |
|<-------------------------------------------------|
| |
Figure 1: Version Upgrade Example
図1：バージョンアップグレードの例
If several resources share common patterns in their responses, then it can be useful to reference an external dictionary that contains those common patterns, effectively compressing them out of the responses. Some examples of this are common template HTML for similar pages across a site and common keys and values in API calls.
いくつかのリソースが応答に共通のパターンを共有する場合、それらの一般的なパターンを含む外部辞書を参照し、それらを応答から効果的に圧縮することが役立ちます。これのいくつかの例は、サイト全体で同様のページの一般的なテンプレートHTMLと、API呼び出しの一般的なキーと値です。
For example:
例えば：
Client Server
| |
| GET /index.html |
|--------------------------------------------------->|
| |
| 200 OK |
| Link: <.../dict>; rel="compression-dictionary" |
| <full index.html resource - 100KB compressed> |
|<---------------------------------------------------|
| |
| GET /dict |
|--------------------------------------------------->|
| |
| 200 OK |
| Use-As-Dictionary: match="/*html" |
|<---------------------------------------------------|
| |
Some time later ...
Client Server
| |
| GET /page2.html |
| Available-Dictionary: :pZGm1A...2a2fFG4=: |
| Accept-Encoding: gzip, br, zstd, dcb, dcz |
|--------------------------------------------------->|
| |
| 200 OK |
| Content-Encoding: dcb |
| <delta-compressed page2.html resource - 10KB> |
|<---------------------------------------------------|
| |
Figure 2: Common Content Example
図2：一般的なコンテンツの例
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」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
This document uses the following terminology from Section 3 of [STRUCTURED-FIELDS] to specify syntax and parsing: Dictionary, String, Inner List, Token, and Byte Sequence.
このドキュメントでは、[構造化場]のセクション3の次の用語を使用して、構文と解析を指定します：辞書、文字列、内側リスト、トークン、およびバイトシーケンス。
This document uses the line folding strategies described in [FOLDING].
このドキュメントでは、[折りたたみ]で説明されているライン折りたたみ戦略を使用しています。
This document also uses terminology from [HTTP] and [HTTP-CACHING].
このドキュメントでは、[http]および[httpキャッシング]の用語も使用しています。
When responding to an HTTP Request, a server can advertise that the response can be used as a dictionary for future requests for URLs that match the rules specified in the "Use-As-Dictionary" response header.
HTTP要求に応答する場合、サーバーは、「辞書としての使用」応答ヘッダーで指定されたルールに一致するURLの将来のリクエストの辞書として応答を使用できることを宣伝できます。
The "Use-As-Dictionary" response header is a Structured Field [STRUCTURED-FIELDS] Dictionary with values for "match", "match-dest", "id", and "type".
「辞書の使用」応答ヘッダーは、「一致」、「マッチデスト」、「ID」、および「タイプ」の値を備えた構造化されたフィールド[構造化場]辞書です。
The "match" value of the "Use-As-Dictionary" response header is a String value that provides the URL Pattern to use for request matching (see [URLPATTERN]).
「辞書の使用」応答ヘッダーの「一致」値は、リクエストマッチングに使用するURLパターンを提供する文字列値です（[urlpattern]を参照）。
The URL Pattern used for matching does not support using regular expressions.
一致に使用されるURLパターンは、正規表現の使用をサポートしません。
The following algorithm is used to validate that a given String value is a valid URL Pattern that does not use regular expressions and is for the same Origin (Section 4.3.1 of [HTTP]) as the dictionary. It will return TRUE for a valid match pattern and FALSE for an invalid pattern that MUST NOT be used.
次のアルゴリズムは、特定の文字列値が正規表現を使用せず、辞書と同じ起源（[http]のセクション4.3.1）であることを検証するために使用されます。使用してはならない無効なパターンでは、有効な一致パターンがtrueで、Falseをfalseに戻します。
1. Let MATCH be the value of "match" for the given dictionary.
1. 一致して、指定された辞書の「一致」の値とします。
2. Let URL be the URL of the dictionary request.
2. URLを辞書リクエストのURLとします。
3. Let PATTERN be a "URL pattern struct" created by running the steps to "create a URL pattern" by setting input=MATCH and baseURL=URL (see Section 1.4 of [URLPATTERN]).
3. パターンを、入力= MatchとbaseURL = URLを設定して「URLパターンを作成する」ために手順を実行することによって作成された「URLパターン構造」とします（[urlpattern]のセクション1.4を参照）。
4. If the result of running the "has regexp groups" steps for PATTERN returns TRUE, then return FALSE (see the last list in Section 1.4 of [URLPATTERN]).
4. パターンの「Regexグループを持っている」手順を実行した結果がtrueを返した場合、falseを返します（[URLパターン]のセクション1.4の最後のリストを参照）。
5. Return TRUE.
5. trueを返します。
The "match" value is required and MUST be included in the "Use-As-Dictionary" response header for the dictionary to be considered valid.
「一致」値が必要であり、有効と見なされる辞書の「辞書としての使用」応答ヘッダーに含める必要があります。
Operating at the HTTP level, the specified match patterns will operate on the percent-encoded version of the URL path (see Section 2 of [URL]).
HTTPレベルで動作すると、指定された一致パターンは、URLパスのパーセントエンコードバージョンで動作します（[URL]のセクション2を参照）。
For example, the URL "http://www.example.com/düsseldorf" would be encoded as "http://www.example.com/d%C3%BCsseldorf" and a relevant match pattern would be:
たとえば、URL「http://www.example.com/düsseldorf」は「http://www.example.com/d%C3%Bcsseldorf」としてエンコードされ、関連する一致パターンは次のとおりです。
Use-As-Dictionary: match="/d%C3%BCsseldorf"
The "match-dest" value of the "Use-As-Dictionary" response header is an Inner List of String values that provides a list of Fetch request destinations for the dictionary to match (see "RequestDestination" in Section 5.4 of [FETCH]).
「辞書の使用」応答ヘッダーの「マッチデスト」値は、辞書のフェッチ要求宛先のリストを提供する文字列値の内側リストです（[FETCH]のセクション5.4の「要求destination」を参照）。
An empty list for "match-dest" MUST match all destinations.
「マッチデスト」の空のリストは、すべての宛先と一致する必要があります。
For clients that do not support request destinations, the client MUST treat it as an empty list and match all destinations.
リクエストの目的地をサポートしていないクライアントの場合、クライアントはそれを空のリストとして扱い、すべての目的地を一致させる必要があります。
The "match-dest" value is optional and defaults to an empty list.
「マッチデスト」値はオプションであり、デフォルトは空のリストになります。
The "id" value of the "Use-As-Dictionary" response header is a String value that specifies a server identifier for the dictionary. If an "id" value is present and has a string length longer than zero, then it MUST be sent to the server in a "Dictionary-ID" request header when the client sends an "Available-Dictionary" request header for the same dictionary (see Section 2.2).
「辞書の使用」応答ヘッダーの「ID」値は、辞書のサーバー識別子を指定する文字列値です。「ID」値が存在し、文字列の長さがゼロより長い場合、クライアントが同じ辞書の「利用可能な辞書」要求ヘッダーを送信するときに「辞書」要求ヘッダーでサーバーに送信する必要があります（セクション2.2を参照）。
The server identifier MUST be treated as an opaque string by the client.
サーバー識別子は、クライアントによって不透明な文字列として扱われる必要があります。
The server identifier MUST NOT be relied upon by the server to guarantee the contents of the dictionary. The dictionary hash MUST be validated before use.
サーバー識別子は、辞書の内容を保証するためにサーバーに依存してはなりません。辞書のハッシュは、使用する前に検証する必要があります。
The "id" value string length (after any decoding) supports up to 1024 characters.
「ID」値文字列の長さ（任意のデコード後）は、最大1024文字をサポートします。
The "id" value is optional and defaults to the empty string.
「ID」値はオプションであり、デフォルトは空の文字列になります。
The "type" value of the "Use-As-Dictionary" response header is a Token value that describes the file format of the supplied dictionary.
「辞書の使用」応答ヘッダーの「タイプ」値は、提供された辞書のファイル形式を記述するトークン値です。
"raw" is defined as a dictionary format that represents an unformatted blob of bytes suitable for any compression scheme to use.
「RAW」は、使用する任意の圧縮スキームに適したバイトの未処理のブロブを表す辞書形式として定義されます。
If a client receives a dictionary with a type that it does not understand, it MUST NOT use the dictionary.
クライアントが理解できないタイプの辞書を受信した場合、辞書を使用してはなりません。
The "type" value is optional and defaults to "raw".
「タイプ」値はオプションであり、デフォルトは「raw」になります。
A response that contained a response header (as shown below) would specify matching any document request for a URL with a path prefix of /product/ on the same Origin (Section 4.3.1 of [HTTP]) as the original request:
応答ヘッダー（以下に示すように）を含む応答は、元のリクエストとして、同じオリジン（[http]のセクション4.3.1）の /製品 /のパスプレフィックスを持つURLのドキュメント要求を一致させることを指定します。
NOTE: '\' line wrapping per RFC 8792
Use-As-Dictionary: \
match="/product/*", match-dest=("document")
A response that contained a response header (as shown below) would match any path that starts with "/app/" and ends with "/main.js":
応答ヘッダーを含む応答（以下に示すように）は、「/app/」で始まり「/main.js」で終わる任意のパスと一致します。
Use-As-Dictionary: match="/app/*/main.js"
When an HTTP client makes a request for a resource for which it has an appropriate dictionary, it can add an "Available-Dictionary" request header to the request to indicate to the server that it has a dictionary available to use for compression.
HTTPクライアントが適切な辞書を持つリソースをリクエストすると、「利用可能な辞書」要求ヘッダーをリクエストに追加して、圧縮に使用できる辞書があることをサーバーに示すことができます。
The "Available-Dictionary" request header is a Structured Field [STRUCTURED-FIELDS] Byte Sequence containing the SHA-256 [SHA-256] hash of the contents of a single available dictionary.
「利用可能な辞書」要求ヘッダーは、単一の使用可能な辞書の内容のSHA-256 [SHA-256]ハッシュを含む構造化されたフィールド[構造化場]バイトシーケンスです。
The client MUST only send a single "Available-Dictionary" request header with a single hash value for the best available match that it has available.
クライアントは、利用可能な最良の試合には、単一のハッシュ値を持つ単一の「利用可能な」要求ヘッダーのみを送信する必要があります。
For example:
例えば：
Available-Dictionary: :pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=:
To be considered as a match, the dictionary resource MUST be either fresh [HTTP-CACHING] or allowed to be served stale (see [RFC5861]).
一致と見なされるには、辞書リソースは新鮮な[httpキャッシング]か、古くすることを許可されている必要があります（[rfc5861]を参照）。
When a dictionary is stored as a result of a "Use-As-Dictionary" directive, it includes a "match" string and an optional "match-dest" string that are used to match an outgoing request from a client to the available dictionaries.
辞書が「辞書としての使用」ディレクティブの結果として保存される場合、クライアントから利用可能な辞書への発信要求を一致させるために使用される「一致」文字列とオプションの「マッチデスト」文字列が含まれます。
To see if an outbound request matches a given dictionary, the following algorithm will return TRUE for a successful match and FALSE for no-match:
アウトバウンドリクエストが特定の辞書と一致するかどうかを確認するには、次のアルゴリズムが試合を成功させるためにTrueを返し、NOMATCHの場合はFalseを返します。
1. If the current client supports request destinations and a "match-dest" string was provided with the dictionary:
1. 現在のクライアントがリクエストの目的地をサポートし、「マッチデスト」文字列に辞書が提供された場合：
* Let DEST be the value of "match-dest" for the given dictionary.
* Destを指定された辞書の「マッチデスト」の値とします。
* Let REQUEST_DEST be the value of the destination for the current request.
* request_destを現在のリクエストの宛先の値とします。
* If DEST is not an empty list and if REQUEST_DEST is not in the DEST list of destinations, return FALSE.
* Destが空のリストではなく、request_destが宛先のDestリストにない場合は、falseを返します。
2. Let BASEURL be the URL of the dictionary request.
2. baseurlを辞書リクエストのURLとします。
3. Let URL represent the URL of the outbound request being checked.
3. URLがチェックされているアウトバウンドリクエストのURLを表します。
4. If the Origin of BASEURL and the Origin of URL are not the same, return FALSE (see Section 4.3.1 of [HTTP]).
4. Baseurlの起源とURLの起源が同じでない場合は、Falseを返します（[http]のセクション4.3.1を参照）。
5. Let MATCH be the value of "match" for the given dictionary.
5. 一致して、指定された辞書の「一致」の値とします。
6. Let PATTERN be a "URL pattern struct" created by running the steps to "create a URL pattern" by setting input=MATCH and baseURL=URL (see Section 1.4 of [URLPATTERN]).
6. パターンを、入力= MatchとbaseURL = URLを設定して「URLパターンを作成する」ために手順を実行することによって作成された「URLパターン構造」とします（[urlpattern]のセクション1.4を参照）。
7. Return the result of running the "match" steps on PATTERN with input=URL, which will check for a match between the request URL and the supplied "match" string (see "Match" in Section 1.4 of [URLPATTERN]).
7. Patternの「一致」ステップを入力= URLで実行した結果を返します。これにより、リクエストURLと「[urlpattern]のセクション1.4の「一致」を参照）の一致が確認されます。
When there are multiple dictionaries that match a given request URL, the client MUST pick a single dictionary using the following rules:
特定の要求URLに一致する複数の辞書がある場合、クライアントは次のルールを使用して単一の辞書を選択する必要があります。
1. For clients that support request destinations, a dictionary that specifies and matches a "match-dest" takes precedence over a match that does not use a destination.
1. リクエストの目的地をサポートするクライアントの場合、「マッチデスト」を指定および一致させる辞書は、宛先を使用しない試合よりも優先されます。
2. Given equivalent destination precedence, the dictionary with the longest "match" takes precedence.
2. 同等の宛先の優先順位を考えると、最も長い「一致」を持つ辞書が優先されます。
3. Given equivalent destination and match length precedence, the most recently fetched dictionary takes precedence.
3. 同等の宛先と一致の長さの優先順位を考えると、最近のFetched Dictionaryが優先されます。
When an HTTP client makes a request for a resource for which it has an appropriate dictionary and the dictionary was stored with a server-provided "id" in the "Use-As-Dictionary" response header, the client MUST echo the stored "id" in a "Dictionary-ID" request header.
HTTPクライアントが適切な辞書を備えたリソースを要求し、辞書が「辞書としての使用」応答ヘッダーにサーバーが提供する「ID」で保存された場合、クライアントは「辞書ID」要求ヘッダーに保存された「ID」をエコーする必要があります。
The "Dictionary-ID" request header is a Structured Field [STRUCTURED-FIELDS] String of up to 1024 characters (after any decoding) and MUST be identical to the server-provided "id".
「辞書」要求ヘッダーは、最大1024文字の構造化されたフィールド[構造化場]文字列であり（デコード後）、サーバーが提供する「ID」と同一でなければなりません。
For example, given an HTTP response that set a dictionary ID:
たとえば、辞書IDを設定するHTTP応答が与えられています。
Use-As-Dictionary: match="/app/*/main.js", id="dictionary-12345"
A future request that matches the given dictionary will include both the hash and the ID:
指定された辞書に一致する将来の要求には、ハッシュとIDの両方が含まれます。
Available-Dictionary: :pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=:
Dictionary-ID: "dictionary-12345"
This specification defines the "compression-dictionary" link relation type [WEB-LINKING] that provides a mechanism for an HTTP response to provide a URL for a compression dictionary that is related to but not directly used by the current HTTP response.
この仕様は、現在のHTTP応答では直接使用されていない圧縮辞書のURLを提供するために、HTTP応答のメカニズムを提供する「圧縮ディクショナリ」リンク関係タイプ[Web-linking]を定義します。
The "compression-dictionary" link relation type indicates that fetching and caching the specified resource is likely to be beneficial for future requests. The response to some of those future requests likely have the ability to use the indicated resource as a compression dictionary.
「圧縮辞書」リンク関係タイプは、指定されたリソースを取得してキャッシュすることが将来のリクエストに有益である可能性が高いことを示しています。これらの将来のリクエストのいくつかに対する応答は、おそらく指定されたリソースを圧縮辞書として使用する能力を持っている可能性があります。
Clients can fetch the provided resource at a time that they determine would be appropriate.
クライアントは、適切であると判断した時点で提供されたリソースを取得できます。
The response to the fetch for the compression dictionary needs to include a "Use-As-Dictionary" response header and a caching response header for it to be usable as a compression dictionary. The link relation only provides the mechanism for triggering the fetch of the dictionary.
圧縮辞書のフェッチへの応答には、「辞書の使用」応答ヘッダーと、圧縮辞書として使用できるキャッシュ応答ヘッダーを含める必要があります。リンク関係は、辞書のフェッチをトリガーするメカニズムのみを提供します。
The following example shows a link to a resource at https://example.org/dict.dat that is expected to produce a compression dictionary:
次の例は、圧縮辞書を作成すると予想されるhttps://example.org/dict.datのリソースへのリンクを示しています。
Link: <https://example.org/dict.dat>; rel="compression-dictionary"
The "dcb" content encoding identifies a resource that is a "Dictionary-Compressed Brotli" stream.
「DCB」コンテンツをエンコードすると、「辞書が圧縮されたBrotli」ストリームであるリソースが識別されます。
A "Dictionary-Compressed Brotli" stream has a fixed header that is followed by a Shared Brotli [SHARED-BROTLI] stream. The header consists of a fixed 4-byte sequence and a 32-byte hash of the external dictionary that was used. The Shared Brotli stream is created using the referenced external dictionary and a compression window that is at most 16 MB in size.
「辞書圧縮Brotli」ストリームには、共有Brotli [Shared-Brotli]ストリームが続く固定ヘッダーがあります。ヘッダーは、固定4バイトシーケンスと、使用された外部辞書の32バイトハッシュで構成されています。共有Brotliストリームは、参照された外部辞書と、最大16 MBのサイズの圧縮ウィンドウを使用して作成されます。
The dictionary used for the "dcb" content encoding is a "raw" dictionary type as defined in Section 2.1.4 and is treated as a prefix dictionary as defined in Section 8.2 of [SHARED-BROTLI].
「DCB」コンテンツエンコードに使用される辞書は、セクション2.1.4で定義されている「生の」辞書タイプであり、[Shared-Brotli]のセクション8.2で定義されているプレフィックス辞書として扱われます。
The 36-byte fixed header is as follows:
36バイトの固定ヘッダーは次のとおりです。
Magic_Number:
Magic_Number：
4 fixed bytes -- 0xff, 0x44, 0x43, 0x42.
4固定バイト-0xff、0x44、0x43、0x42。
SHA_256_Hash:
SHA_256_HASH：
32 bytes. SHA-256 hash digest of the dictionary [SHA-256].
32バイト。辞書[SHA-256]のSHA-256ハッシュダイジェスト。
Clients that announce support for dcb content encoding MUST be able to decompress resources that were compressed with a window size of up to 16 MB.
DCBコンテンツエンコードのサポートを発表するクライアントは、最大16 MBのウィンドウサイズで圧縮されたリソースを解凍できなければなりません。
With Brotli compression, the full dictionary is available during compression and decompression independent of the compression window, allowing for delta-compression of resources larger than the compression window.
Brotli圧縮により、圧縮ウィンドウとは無関係に圧縮と減圧中に完全な辞書が利用でき、圧縮ウィンドウよりも大きなリソースのデルタ圧縮が可能になります。
The "dcz" content encoding identifies a resource that is a "Dictionary-Compressed Zstandard" stream.
「DCZ」コンテンツをエンコードすると、「辞書が圧縮されたZSTANDARD」ストリームであるリソースが識別されます。
A "Dictionary-Compressed Zstandard" stream is a binary stream that starts with a 40-byte fixed header and is followed by a Zstandard [ZSTD] stream of the response that has been compressed with an external dictionary.
「辞書圧縮されたZSTANDARD」ストリームは、40バイトの固定ヘッダーから始まるバイナリストリームであり、その後、外部辞書で圧縮された応答のZSTANDARD [ZSTD]ストリームが続きます。
The dictionary used for the "dcz" content encoding is a "raw" dictionary type as defined in Section 2.1.4 and is treated as a raw dictionary as per Section 5 of [ZSTD].
「DCZ」コンテンツエンコードに使用される辞書は、セクション2.1.4で定義されている「生の」辞書タイプであり、[ZSTD]のセクション5に従って生の辞書として扱われます。
The 40-byte header consists of a fixed 8-byte sequence followed by the 32-byte SHA-256 hash of the external dictionary that was used to compress the resource:
40バイトのヘッダーは、固定された8バイトシーケンスに続いて、リソースを圧縮するために使用された外部辞書の32バイトSHA-256ハッシュで構成されています。
Magic_Number:
Magic_Number：
8 fixed bytes -- 0x5e, 0x2a, 0x4d, 0x18, 0x20, 0x00, 0x00, 0x00.
8固定バイト-0x5e、0x2a、0x4d、0x18、0x20、0x00、0x00、0x00。
SHA_256_Hash:
SHA_256_HASH：
32 bytes. SHA-256 hash digest of the dictionary [SHA-256].
32バイト。辞書[SHA-256]のSHA-256ハッシュダイジェスト。
The 40-byte header is a Zstandard skippable frame (little-endian 0x184D2A5E) with a 32-byte length (little-endian 0x00000020) that is compatible with existing Zstandard decoders.
40バイトのヘッダーは、既存のズスタンダードデコーダーと互換性のある32バイトの長さ（リトルエンディアン0x00000020）を備えたズスタンダードスキップ可能なフレーム（リトルエンディアン0x184D2A5E）です。
Clients that announce support for dcz content encoding MUST be able to decompress resources that were compressed with a window size of at least 8 MB or 1.25 times the size of the dictionary, whichever is greater, up to a maximum of 128 MB.
DCZコンテンツエンコーディングのサポートを発表するクライアントは、少なくとも8 MBまたは辞書のサイズの1.25倍のウィンドウサイズで圧縮されたリソースを減圧することができなければなりません。
The window size used will be encoded in the content (currently, this can be expressed in powers of two only) and it MUST be lower than this limit. An implementation MAY treat a window size that exceeds the limit as a decoding error.
使用されるウィンドウサイズは、コンテンツにエンコードされます（現在、これは2つのパワーでのみ表現できます）、この制限よりも低くする必要があります。実装は、制限を超えるウィンドウサイズをデコードエラーとして扱う場合があります。
With Zstandard compression, the full dictionary is available during compression and decompression until the size of the input exceeds the compression window. Beyond that point, the dictionary becomes unavailable. Using a compression window that is 1.25 times the size of the dictionary allows for full delta compression of resources that have grown by 25% between releases while still giving the client control over the memory it will need to allocate for a given response.
Zstandard圧縮により、入力のサイズが圧縮ウィンドウを超えるまで、圧縮と減圧中に完全な辞書が利用できます。その点を超えて、辞書は利用できなくなります。辞書のサイズの1.25倍の圧縮ウィンドウを使用すると、リリースの間に25％増加したリソースの完全なデルタ圧縮が可能になり、特定の応答に割り当てる必要があるメモリをクライアントに制御する必要があります。
When a compression dictionary is available to compress the response to a given request, the encoding to be used is negotiated through the regular mechanism for negotiating content encoding in HTTP through the "Accept-Encoding" request header and "Content-Encoding" response header.
特定のリクエストに対する応答を圧縮するために圧縮辞書が利用可能である場合、使用するエンコードは、「受け入れ」リクエストヘッダーと「コンテンツエンコード」応答ヘッダーを介してHTTPでエンコードするコンテンツを交渉するための通常のメカニズムを通じてネゴシエートされます。
The dictionary to use is negotiated separately and advertised in the "Available-Dictionary" request header.
使用する辞書は別々にネゴシエートされ、「利用可能な辞書」要求ヘッダーに宣伝されています。
When a dictionary is available for use on a given request and the client chooses to make dictionary-based content encoding available, the client adds the dictionary-aware content encodings that it supports to the "Accept-Encoding" request header. For example:
特定の要求で辞書が使用できるようになり、クライアントが辞書ベースのコンテンツを使用できるようにすることを選択した場合、クライアントは「承認エンコード」リクエストヘッダーをサポートする辞書を意識したコンテンツエンコーディングを追加します。例えば：
Accept-Encoding: gzip, deflate, br, zstd, dcb, dcz
When a client does not have a stored dictionary that matches the request or chooses not to use one for the request, the client MUST NOT send its dictionary-aware content encodings in the "Accept-Encoding" request header.
クライアントがリクエストに一致する保存された辞書を持っていない場合、またはリクエストに使用しないことを選択した場合、クライアントは「Accept-Encoding」リクエストヘッダーに辞書を意識したコンテンツエンコーディングを送信してはなりません。
If a server supports one of the dictionary encodings advertised by the client and chooses to compress the content of the response using the dictionary that the client has advertised, then it sets the "Content-Encoding" response header to the appropriate value for the algorithm selected. For example:
サーバーがクライアントによって宣伝された辞書エンコーディングの1つをサポートし、クライアントが宣伝した辞書を使用して応答のコンテンツを圧縮することを選択した場合、選択したアルゴリズムの適切な値に「コンテンツエンコード」応答ヘッダーを設定します。例えば：
Content-Encoding: dcb
If the response is cacheable, it MUST include a "Vary" header to prevent caches from serving dictionary-compressed resources to clients that don't support them or serving the response compressed with the wrong dictionary. For example:
応答がキャッシュ可能な場合は、キャッシュが辞書で圧縮されたリソースをサポートしていないクライアントに提供したり、間違った辞書で圧縮された応答を提供したりするのを防ぐための「変化」ヘッダーを含める必要があります。例えば：
Vary: accept-encoding, available-dictionary
IANA has added the following entries to the "HTTP Content Coding Registry" maintained at <https://www.iana.org/assignments/http-parameters/>:
IANAは、<https://www.iana.org/assignments/http-parameters/>に維持されている「HTTPコンテンツコーディングレジストリ」に次のエントリを追加しました。
Name:
名前：
dcb
DCB
Description:
説明：
"Dictionary-Compressed Brotli" data format.
「辞書圧縮Brotli」データ形式。
Reference:
参照：
RFC 9842, Section 4
RFC 9842、セクション4
Name:
名前：
dcz
DCZ
Description:
説明：
"Dictionary-Compressed Zstandard" data format.
「辞書圧縮ズスタンダード」データ形式。
Reference:
参照：
RFC 9842, Section 5
RFC 9842、セクション5
IANA has added the following entries to the "Hypertext Transfer Protocol (HTTP) Field Name Registry" maintained at <https://www.iana.org/assignments/http-fields/>:
IANAは、<https://www.iana.org/assignments/http-fields/>に維持されている「HyperText Transfer Protocol（HTTP）フィールド名レジストリ」に次のエントリを追加しました。
+======================+===========+=======================+
| Field Name | Status | Reference |
+======================+===========+=======================+
| Use-As-Dictionary | permanent | RFC 9842, Section 2.1 |
+----------------------+-----------+-----------------------+
| Available-Dictionary | permanent | RFC 9842, Section 2.2 |
+----------------------+-----------+-----------------------+
| Dictionary-ID | permanent | RFC 9842, Section 2.3 |
+----------------------+-----------+-----------------------+
Table 1
IANA has added the following entry to the "Link Relation Types" registry maintained at <https://www.iana.org/assignments/link-relations/>:
IANAは、<https://www.iana.org/assignments/link-relations/>に維持されている「リンク関係タイプ」レジストリに次のエントリを追加しました。
Relation Name:
関係名：
compression-dictionary
圧縮辞書
Description:
説明：
Refers to a compression dictionary used for content encoding.
コンテンツエンコーディングに使用される圧縮辞書を指します。
Reference:
参照：
RFC 9842, Section 3
RFC 9842、セクション3
It is not unusual for devices to be on the network path that intercept, inspect, and process HTTP requests (web proxies, firewalls, intrusion detection systems, etc.). To minimize the risk of these devices incorrectly processing dictionary-compressed responses, compression dictionary transport MUST only be used in secure contexts (HTTPS).
HTTP要求（Webプロキシ、ファイアウォール、侵入検知システムなど）を傍受、検査、および処理するネットワークパス上にデバイスが存在することは珍しいことではありません。これらのデバイスのリスクを最小限に抑えるために、辞書圧縮応答を誤って処理するには、圧縮辞書輸送は安全なコンテキスト（HTTP）でのみ使用する必要があります。
The security considerations for Brotli [RFC7932], Shared Brotli [SHARED-BROTLI], and Zstandard [ZSTD] apply to the dictionary-based versions of the respective algorithms.
Brotli [RFC7932]、共有Brotli [Shared-Brotli]、およびZstandard [ZSTD]のセキュリティ上の考慮事項は、それぞれのアルゴリズムの辞書ベースのバージョンに適用されます。
The dictionary must be treated with the same security precautions as the content because a change to the dictionary can result in a change to the decompressed content.
辞書はコンテンツと同じセキュリティ上の注意事項で扱う必要があります。これは、辞書を変更すると、減圧コンテンツが変更される可能性があるためです。
The dictionary is validated using an SHA-256 hash of the content to make sure that the client and server are both using the same dictionary. The strength of the SHA-256 hash algorithm isn't explicitly needed to counter attacks since the dictionary is being served from the same origin as the content. That said, if a weakness is discovered in SHA-256 and it is determined that the dictionary negotiation should use a different hash algorithm, the "Use-As-Dictionary" response header can be extended to specify a different algorithm and the server would just ignore any "Available-Dictionary" requests that do not use the updated hash.
辞書は、コンテンツのSHA-256ハッシュを使用して検証され、クライアントとサーバーが両方とも同じ辞書を使用していることを確認します。SHA-256ハッシュアルゴリズムの強度は、辞書がコンテンツと同じ起源から提供されているため、攻撃に対抗するために明示的に必要ではありません。とはいえ、SHA-256で弱点が発見され、辞書交渉が別のハッシュアルゴリズムを使用する必要があると判断された場合、「辞書としての使用」応答ヘッダーを拡張して異なるアルゴリズムを指定でき、サーバーは更新されたHasHを使用しない「利用可能な辞書」要求を無視するだけです。
The compression attacks in Section 2.6 of [RFC7457] show that it's a bad idea to compress data from mixed (e.g., public and private) sources. The data sources include not only the compressed data but also the dictionaries. For example, if secret cookies are compressed using a public-data-only dictionary, information about the cookies is still leaked.
[RFC7457]のセクション2.6の圧縮攻撃は、混合（パブリックおよびプライベート）ソースからデータを圧縮することは悪い考えであることを示しています。データソースには、圧縮データだけでなく、辞書も含まれます。たとえば、パブリックデータのみの辞書を使用してシークレットクッキーが圧縮されている場合、Cookieに関する情報はまだ漏れています。
The dictionary can reveal information about the compressed data and vice versa. That is, data compressed with the dictionary can reveal contents of the dictionary when an adversary can control parts of the data to compress and see the compressed size. On the other hand, if the adversary can control the dictionary, the adversary can learn information about the compressed data.
辞書は、圧縮データに関する情報を明らかにすることができ、その逆も同様です。つまり、辞書で圧縮されたデータは、敵がデータの一部を制御して圧縮されたサイズを圧縮して確認できる場合、辞書の内容を明らかにすることができます。一方、敵が辞書を制御できる場合、敵は圧縮データに関する情報を学ぶことができます。
If any of the mitigations do not pass, the client MUST drop the response and return an error.
緩和のいずれかが合格しない場合、クライアントは応答をドロップしてエラーを返す必要があります。
To make sure that a dictionary can only impact content from the same origin where the dictionary was served, the URL Pattern used for matching a dictionary to requests (Section 2.1.1) is guaranteed to be for the same origin that the dictionary is served from.
辞書が辞書が提供されたのと同じ起源からのみコンテンツに影響を与えることができることを確認するために、辞書とリクエスト（セクション2.1.1）を一致させるために使用されるURLパターンは、辞書が提供されるのと同じ起源であることが保証されます。
For clients, like web browsers, that provide additional protection against the readability of the payload of a response and against user tracking, additional protections MUST be taken to make sure that the use of dictionary-based compression does not reveal information that would not otherwise be available.
Webブラウザーのようなクライアントの場合、応答のペイロードの読みやすさとユーザー追跡に対する追加の保護を提供する場合は、辞書ベースの圧縮を使用しても、それ以外の場合は利用できない情報が表示されないことを確認するために、追加の保護を取る必要があります。
In these cases, dictionary compression MUST only be used when both the dictionary and the compressed response are fully readable by the client.
これらの場合、辞書の圧縮は、辞書と圧縮応答の両方がクライアントが完全に読みやすい場合にのみ使用する必要があります。
In browser terms, that means either the dictionary and compressed response are same-origin to the context they are being fetched from or the response is cross-origin and passes the Cross-Origin Resource Sharing (CORS) check (see Section 4.9 of [FETCH]).
ブラウザの用語では、辞書と圧縮応答のいずれかがそれらからフェッチされているコンテキストと同じオリジンであるか、応答がクロスオリジンであり、クロスオリジンリソース共有（CORS）チェックに合格することを意味します（[フェッチ]のセクション4.9を参照）。
As with any usage of compressed content in a secure context, a potential timing attack exists if the attacker can control any part of the dictionary or if it can read the dictionary and control any part of the content being compressed while performing multiple requests that vary the dictionary or injected content. Under such an attack, the changing size or processing time of the response reveals information about the content, which might be sufficient to read the supposedly secure response.
安全なコンテキストでの圧縮コンテンツの使用と同様に、攻撃者が辞書の任意の部分を制御できる場合、または辞書を読み取ってコンテンツの一部を制御して、辞書または注入されたコンテンツを変更している間に圧縮されているコンテンツの任意の部分を制御できる場合、潜在的なタイミング攻撃が存在します。このような攻撃の下では、応答のサイズの変化または処理時間は、コンテンツに関する情報を明らかにします。これは、おそらく安全な応答を読み取るのに十分かもしれません。
In general, a server can mitigate such attacks by preventing variations per request, as in preventing active use of multiple dictionaries for the same content, disabling compression when any portion of the content comes from uncontrolled sources, and securing access and control over the dictionary content in the same way as the response content. In addition, the following requirements on a server are intended to disable dictionary-aware compression when the client provides CORS request header fields that indicate a cross-origin request context.
一般に、サーバーは、同じコンテンツの複数辞書の積極的な使用を防ぎ、コンテンツの一部が制御されていないソースからの圧縮を無効にし、応答コンテンツと同じ方法で辞書コンテンツへのアクセスと制御を保護するように、要求ごとのバリエーションを防ぐことにより、このような攻撃を軽減できます。さらに、サーバー上の次の要件は、クライアントがクロスオリジン要求のコンテキストを示すCORSリクエストヘッダーフィールドを提供するときに、辞書を認識する圧縮を無効にすることを目的としています。
The following algorithm will return FALSE for cross-origin requests where precautions such as not using dictionary-based compression should be considered:
次のアルゴリズムは、辞書ベースの圧縮を使用しないなどの予防策を考慮する必要がある場合に、クロスオリジン要求に対してfalseを返します。
1. If there is no "Sec-Fetch-Site" request header, return TRUE.
1. 「Sec-Fetch-Site」リクエストヘッダーがない場合は、trueを返します。
2. If the value of the "Sec-Fetch-Site" request header is "same-origin", return TRUE.
2. 「SEC-FETCH-SITE」要求ヘッダーの値が「同じオリジン」の場合、trueを返します。
3. If there is no "Sec-Fetch-Mode" request header, return TRUE.
3. 「sec-fetch-mode」要求ヘッダーがない場合は、trueを返します。
4. If the value of the "Sec-Fetch-Mode" request header is "navigate" or "same-origin", return TRUE.
4. 「SEC-FETCH-MODE」要求ヘッダーの値が「ナビゲート」または「同じオリジン」である場合、trueを返します。
5. If the value of the "Sec-Fetch-Mode" request header is "cors":
5. 「Sec-Fetch-Mode」要求ヘッダーの値が「cors」である場合：
* If the response does not include an "Access-Control-Allow-Origin" response header, return FALSE.
* 応答に「アクセスコントロールアロウオリジン」応答ヘッダーが含まれていない場合は、falseを返します。
* If the request does not include an "Origin" request header, return FALSE.
* リクエストに「Origin」要求ヘッダーが含まれていない場合は、falseを返します。
* If the value of the "Access-Control-Allow-Origin" response header is "*", return TRUE.
* 「アクセスコントロール - アロウオリジン」応答ヘッダーの値が「*」の場合、trueを返します。
* If the value of the "Access-Control-Allow-Origin" response header matches the value of the "Origin" request header, return TRUE.
* 「Access-Control-Allow-Origin」応答ヘッダーの値が「Origin」要求ヘッダーの値と一致する場合、trueを返します。
6. Return FALSE.
6. falseを返します。
Since dictionaries are advertised in future requests using the hash of the content of the dictionary, it is possible to abuse the dictionary to turn it into a tracking cookie.
辞書は辞書のコンテンツのハッシュを使用して将来のリクエストで宣伝されているため、辞書を悪用して追跡クッキーに変えることができます。
To mitigate any additional tracking concerns, clients MUST treat dictionaries in the same way that they treat cookies [RFC6265]. This includes partitioning the storage using partitioning similar to or stricter than the partitioning used for cookies, as well as clearing the dictionaries whenever cookies are cleared.
追加の追跡懸念を軽減するために、クライアントはCookieを扱うのと同じ方法で辞書を扱う必要があります[RFC6265]。これには、Cookieに使用されるパーティションに類似またはより厳格なパーティションを使用してストレージをパーティション化すること、およびCookieがクリアされるたびに辞書をクリアすることが含まれます。
[FETCH] WHATWG, "Fetch Standard", WHATWG Living Standard,
<https://fetch.spec.whatwg.org/>. Commit snapshot:
<https://fetch.spec.whatwg.org/commit-
snapshots/5a9680638ebfc2b3b7f4efb2bef0b579a2663951/>
[FOLDING] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
"Handling Long Lines in Content of Internet-Drafts and
RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
<https://www.rfc-editor.org/info/rfc8792>.
[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-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>.
[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>.
[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>.
[SHA-256] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>.
[SHARED-BROTLI]
Alakuijala, J., Duong, T., Kliuchnikov, E., Szabadka, Z.,
and L. Vandevenne, Ed., "Shared Brotli Compressed Data
Format", RFC 9841, DOI 10.17487/RFC9841, September 2025,
<https://www.rfc-editor.org/info/rfc9841>.
[STRUCTURED-FIELDS]
Nottingham, M. and P. Kamp, "Structured Field Values for
HTTP", RFC 9651, DOI 10.17487/RFC9651, September 2024,
<https://www.rfc-editor.org/info/rfc9651>.
[URL] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[URLPATTERN]
WHATWG, "URL Pattern Standard", WHATWG Living Standard,
<https://urlpattern.spec.whatwg.org/>. Commit snapshot:
<https://urlpattern.spec.whatwg.org/commit-
snapshots/696b4029d52e5854044bac6b72cdb198cb962ed0/>
[WEB-LINKING]
Nottingham, M., "Web Linking", RFC 8288,
DOI 10.17487/RFC8288, October 2017,
<https://www.rfc-editor.org/info/rfc8288>.
[ZSTD] Collet, Y. and M. Kucherawy, Ed., "Zstandard Compression
and the 'application/zstd' Media Type", RFC 8878,
DOI 10.17487/RFC8878, February 2021,
<https://www.rfc-editor.org/info/rfc8878>.
[RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale
Content", RFC 5861, DOI 10.17487/RFC5861, May 2010,
<https://www.rfc-editor.org/info/rfc5861>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/info/rfc6265>.
[RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing
Known Attacks on Transport Layer Security (TLS) and
Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457,
February 2015, <https://www.rfc-editor.org/info/rfc7457>.
[RFC7932] Alakuijala, J. and Z. Szabadka, "Brotli Compressed Data
Format", RFC 7932, DOI 10.17487/RFC7932, July 2016,
<https://www.rfc-editor.org/info/rfc7932>.
Patrick Meenan (editor)
Google LLC
Email: pmeenan@google.com
Yoav Weiss (editor)
Shopify Inc.
Email: yoav.weiss@shopify.com