[要約] RFC 9996は、構造化データを直列化する拡張可能な仕組みであるProtocol Buffersのメディアタイプを登録します。IANAのMedia Typesレジストリにapplication/protobufとapplication/protobuf+jsonを登録し、application/x-protobuf、application/x-protobuffer、application/x-protobuf+jsonは非推奨の別名として扱います。
Internet Engineering Task Force (IETF) M. Kucherawy, Ed.
Request for Comments: 9996
Category: Informational W. Kumari
ISSN: 2070-1721 R. Sloan
Google
July 2026
This document registers media types for Protocol Buffers, a common extensible mechanism for serializing structured data.
このドキュメントでは、構造化データをシリアル化するための一般的な拡張可能なメカニズムであるプロトコル バッファーのメディア タイプを登録します。
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書は Internet Standards Track 仕様ではありません。情報提供を目的として公開されています。
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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されました。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/rfc9996.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9996 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 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 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。この文書から抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
2. Key Words
3. Payload Description
4. Encoding Considerations
5. Versions
6. Security Considerations
7. IANA Considerations
7.1. Media Type: application/protobuf
7.2. Media Type: application/protobuf+json
8. References
8.1. Normative References
8.2. Informative References
Acknowledgments
Authors' Addresses
Protocol Buffers (also called "Protobuf") were introduced in 2008 as a free, open-source, platform-independent mechanism for transport and storage of structured data. The use of Protobuf has become increasingly common, and Protobuf implementations exist in many languages (C++, C#, Dart, Go, Java, Kotlin, Objective-C, Python, JavaScript, Ruby, Swift, and perhaps others). See [Protobuf] for more information.
プロトコル バッファー (「Protobuf」とも呼ばれる) は、構造化データの転送と保存のための、無料のオープンソースでプラットフォームに依存しないメカニズムとして 2008 年に導入されました。Protobuf の使用はますます一般的になり、Protobuf の実装は多くの言語 (C++、C#、Dart、Go、Java、Kotlin、Objective-C、Python、JavaScript、Ruby、Swift、およびおそらくその他) で存在します。詳細については、「Protobuf」を参照してください。
Protobuf consists of an interface definition language (IDL), wire encoding formats, and language-specific implementations (typically involving a generated API) so that clients and servers can be easily deployed using a common schema. Protobuf supports two wire formats for interchange: the format in [Binary] (which is optimized for wire efficiency) and the format in [ProtoJSON] (which maps the Protobuf schema onto a JSON structure).
Protobuf は、インターフェイス定義言語 (IDL)、ワイヤ エンコード形式、および言語固有の実装 (通常は生成された API を含む) で構成されているため、クライアントとサーバーは共通のスキーマを使用して簡単に展開できます。Protobuf は、交換用に 2 つのワイヤ形式をサポートしています。1 つは [Binary] の形式 (ワイヤの効率性のために最適化されています) と [ProtoJSON] の形式は (Protobuf スキーマを JSON 構造にマッピングします)。
Serialized objects are occasionally transported within media that make use of media types (see [RFC2045]) to identify payloads. Accordingly, current and historical media types used for this purpose would benefit from registration. IANA has registered two Protobuf media types; see Section 7.
シリアル化されたオブジェクトは、ペイロードを識別するためにメディア タイプ ([RFC2045] を参照) を利用するメディア内で転送されることがあります。したがって、この目的で使用される現在および過去のメディア タイプは、登録することでメリットが得られます。IANA は 2 つの Protobuf メディア タイプを登録しています。セクション 7 を参照してください。
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] で説明されているように解釈されます。
The media types defined in this document are used in the transport of serialized objects only. The IDL and object definitions, if transported, would be used with any appropriate text media type. In the three examples below, only the third (depicted in JSON) would ever be used with these media types.
この文書で定義されているメディア タイプは、シリアル化されたオブジェクトのトランスポートでのみ使用されます。IDL およびオブジェクト定義は、転送される場合、適切なテキスト メディア タイプで使用されます。以下の 3 つの例では、これらのメディア タイプで使用されるのは 3 番目 (JSON で示されている) だけです。
1. An example of using the IDL to specify a "Person" object:
1. IDL を使用して「人」オブジェクトを指定する例:
edition = "2023";
message Person {
string name = 1;
int32 id = 2;
string email = 3;
}
2. An example of python code that uses code generated from the IDL definition above to create an instance of a "Person" object:
2. 上記の IDL 定義から生成されたコードを使用して「person」オブジェクトのインスタンスを作成する Python コードの例:
person = Person()
person.id = 1234
person.name = "John Doe"
person.email = "jdoe@example.com"
3. An example of the above instance expressed in JSON:
3. JSON で表現された上記のインスタンスの例:
{
"name": "John Doe",
"id": 1234,
"email": "jdoe@example.com"
}
Protobuf supports the formats in [Binary] and [ProtoJSON] for interchange, both of which are platform-independent. For binary forms that need to transit non-binary transports, a base64 encoding (e.g., [RFC4648]) is recommended.
Protobuf は、交換用に [Binary] および [ProtoJSON] の形式をサポートしており、どちらもプラットフォームに依存しません。非バイナリトランスポートを転送する必要があるバイナリ形式の場合は、base64 エンコーディング ([RFC4648] など) が推奨されます。
Both of the media types defined in this document include an optional "encoding" parameter indicating which encoding format is to be used with that particular payload. This is included for future extensibility. Valid values for this parameter are "binary" and "json", and other values MUST be treated as an error. See Section 7 for the defaults for each of the two registered media types. Using "binary" for the JSON type or "json" for the binary type MUST be treated as an error.
この文書で定義されている両方のメディア タイプには、その特定のペイロードでどのエンコード形式が使用されるかを示すオプションの「エンコーディング」パラメータが含まれています。これは将来の拡張性のために含まれています。このパラメータの有効な値は「binary」と「json」で、その他の値はエラーとして扱われなければなりません。登録されている 2 つのメディア タイプのそれぞれのデフォルトについては、セクション 7 を参照してください。JSON タイプに "binary" を使用するか、バイナリ タイプに "json" を使用する場合は、エラーとして扱われなければなりません (MUST)。
[Proto2] was the first public version of the Protobuf schema language; [Proto3], [Edition2023], and [Edition2024] came later, with [Edition2024] being current at the time of writing. Future editions of the IDL are expected.
[Proto2] は、Protobuf スキーマ言語の最初の公開バージョンでした。[Proto3]、[Edition2023]、および [Edition2024] は後に登場し、[Edition2024] がこの記事の執筆時点での最新のものです。IDL の将来の版が期待されています。
These versions refer to evolutions of the schema of the IDL, not the wire format. Accordingly, a serialized object generated by any of these is compatible with any other. The media type registrations in Section 7 include support for versioning of the wire format, should it ever change, but do not refer to the IDL, which can evolve independently.
これらのバージョンは、ワイヤ形式ではなく、IDL のスキーマの進化を指します。したがって、これらのいずれかによって生成されたシリアル化されたオブジェクトは、他のオブジェクトと互換性があります。セクション 7 のメディア タイプの登録には、ワイヤ フォーマットが変更された場合に備えて、そのバージョン管理のサポートが含まれていますが、独立して進化する可能性がある IDL については参照しません。
Note that there may be semantic changes implicit in the IDL version, which can affect the interpretation of otherwise compatible bits on the wire. For example, in Proto2, unknown values of an enumeration were interpreted as invalid, whereas in Proto3, they are retained.
IDL バージョンには暗黙的なセマンティックの変更が存在する可能性があり、それが通信上の互換性のあるビットの解釈に影響を与える可能性があることに注意してください。たとえば、Proto2 では、列挙型の不明な値は無効であると解釈されましたが、Proto3 では、それらの値は保持されます。
Clients MUST reject payloads with an unsupported version number.
クライアントは、サポートされていないバージョン番号を持つペイロードを拒否しなければなりません (MUST)。
The payload for these media types contains no directly executable code. While it is common for a Protobuf definition to be used as input to a code generator, which then produces something executable, that applies to the schema language, not serializations.
これらのメディア タイプのペイロードには、直接実行可能なコードは含まれません。Protobuf 定義がコード ジェネレーターへの入力として使用されるのが一般的ですが、コード ジェネレーターはシリアル化ではなくスキーマ言語に適用される実行可能ファイルを生成します。
Protobuf provides no security, privacy, integrity, or compression services. Clients or servers for which this is a concern should avail themselves of solutions that provide such capabilities (e.g., [RFC8446]). Implementations should be careful when processing Protobuf like any binary format; for example, a malformed request to a Protobuf server could be crafted to allocate a very large amount of memory, potentially impacting other operations on that server.
Protobuf は、セキュリティ、プライバシー、整合性、または圧縮サービスを提供しません。これが懸念されるクライアントまたはサーバーは、そのような機能を提供するソリューション (例: [RFC8446]) を利用する必要があります。実装では、他のバイナリ形式と同様に Protobuf を処理するときに注意する必要があります。たとえば、Protobuf サーバーへの不正なリクエストは、非常に大量のメモリを割り当てるように作成され、そのサーバー上の他の操作に影響を与える可能性があります。
Protobuf supports embedded content in string or bytes fields: In both cases, applications should ensure that the format of the content is precisely as expected. Note that UTF-8 validation of string fields is optional (see [ProtoFeatures]), and a manual well-formedness check may be necessary. Further, handling Unicode text generally can be quite complex (due to the problems discussed in [UniChars] and [RFC8264], for example), so it is best to rely on well-supported internationalization libraries whenever possible.
Protobuf は、文字列またはバイト フィールドの埋め込みコンテンツをサポートします。どちらの場合でも、アプリケーションはコンテンツの形式が正確に期待どおりであることを確認する必要があります。文字列フィールドの UTF-8 検証はオプションであり ([ProtoFeature] を参照)、手動による整形式チェックが必要な場合があることに注意してください。さらに、Unicode テキストの処理は一般に非常に複雑になる可能性があるため ([UniChars] や [RFC8264] で説明されている問題などにより)、可能な限り十分にサポートされている国際化ライブラリに依存するのが最善です。
In order to safely use Protobuf serializations on the Web, it is important to ensure that they are not interpreted as another document type, such as JavaScript: We recommend base64-encoding binary Protobuf responses whenever possible to prevent parsing as active content. Servers should generally follow the advice of [RFC9205] to prevent content sniffing for all binary formats.
Web 上で Protobuf シリアル化を安全に使用するには、JavaScript などの別のドキュメント タイプとして解釈されないようにすることが重要です。アクティブ コンテンツとして解析されないように、可能な限り、バイナリ Protobuf 応答を Base64 エンコードすることをお勧めします。サーバーは通常、[RFC9205] のアドバイスに従って、すべてのバイナリ形式のコンテンツ スニッフィングを防止する必要があります。
Further, when using JSON serializations, it is important that it is clear to browsers that the content is pure JSON so that they can inhibit Cross-Site Script Inclusion or side-channel attacks using techniques such as Cross-Origin Read Blocking [CORB]. Per [RFC6839], pure JSON content is indicated by a +json subtype suffix (see also [MIMESNIFF]); thus, when serializing Protobuf content to JSON, users MUST use the application/protobuf+json media type. When using JSON, charset can prevent certain encoding confusion attacks, so users should specify it for all JSON encodings.
さらに、JSON シリアル化を使用する場合は、クロスサイト スクリプト インクルージョンや、クロスオリジン読み取りブロック (CORB) などの技術を使用したサイドチャネル攻撃を阻止できるように、コンテンツが純粋な JSON であることがブラウザーにとって明らかであることが重要です。[RFC6839] によれば、純粋な JSON コンテンツは +json サブタイプ接尾辞によって示されます ([MIMESNIFF] も参照)。したがって、Protobuf コンテンツを JSON にシリアル化する場合、ユーザーは application/protobuf+json メディア タイプを使用する必要があります。JSON を使用する場合、文字セットは特定のエンコーディングの混乱攻撃を防ぐことができるため、ユーザーはすべての JSON エンコーディングに対してそれを指定する必要があります。
In the type described in [Any], there is technically a link that was intended to be dereferenced to obtain schemas for a given type; however, this is not supported by widely used Protobuf implementations.
[Any] で説明されている型には、技術的には、指定された型のスキーマを取得するために参照解除されることを目的としたリンクがあります。ただし、これは広く使用されている Protobuf 実装ではサポートされていません。
As per the process defined in [RFC6838], IANA has registered application/protobuf and application/protobuf+json in the "Media Types" registry. The following are deprecated aliases: application/ x-protobuf, application/x-protobuffer, and application/ x-protobuf+json.
[RFC6838] で定義されているプロセスに従って、IANA は application/protobuf および application/protobuf+json を「メディア タイプ」レジストリに登録しました。非推奨のエイリアスは、application/ x-protobuf、application/x-protobuffer、および application/ x-protobuf+json です。
Type name:
型名:
application
応用
Subtype name:
サブタイプ名:
protobuf
プロトブフ
Required parameters:
必須パラメータ:
N/A
該当なし
Optional parameters:
オプションのパラメータ:
encoding
エンコーディング
Indicates the type of Protobuf encoding and is "binary" by default for application/protobuf, indicating the format in [Binary]. At the time of writing, no other encoding can be used for application/protobuf, so this parameter is for extensibility.
Protobuf エンコーディングのタイプを示します。application/protobuf のデフォルトでは「バイナリ」で、[バイナリ] の形式を示します。執筆時点では、application/protobuf には他のエンコーディングを使用できないため、このパラメータは拡張性を目的としています。
version
バージョン
Indicates the version of the wire encoding specification (not the schema language), with a default of 1. At the time of writing, no Protobuf wire encodings are versioned, so this parameter is for extensibility. Unversioned wire encodings should be treated as having version 1.
ワイヤ エンコーディング仕様 (スキーマ言語ではない) のバージョンを示します。デフォルトは 1 です。執筆時点では、Protobuf ワイヤ エンコーディングはバージョン管理されていないため、このパラメータは拡張性を目的としています。バージョン管理されていないワイヤ エンコーディングは、バージョン 1 を持つものとして扱う必要があります。
Encoding considerations:
エンコーディングに関する考慮事項:
binary
バイナリ
Security considerations:
セキュリティに関する考慮事項:
See Section 6 of RFC 9996.
RFC 9996 のセクション 6 を参照してください。
Interoperability considerations:
相互運用性に関する考慮事項:
The Protobuf specification [Protobuf] includes versioning provisions to ensure backward compatibility when encountering payloads with unknown properties.
Protobuf 仕様 [Protobuf] には、未知のプロパティを持つペイロードに遭遇した場合に下位互換性を確保するためのバージョン管理規定が含まれています。
Published specification:
公開された仕様:
[Protobuf]
[プロトバッファ]
Applications that use this media type:
このメディア タイプを使用するアプリケーション:
Any application with a need to exchange or store structured objects across platforms or implementations.
プラットフォームまたは実装間で構造化オブジェクトを交換または保存する必要があるアプリケーション。
Fragment identifier considerations:
フラグメント識別子の考慮事項:
N/A
該当なし
Additional information:
追加情報：
Deprecated alias names for this type:
このタイプの非推奨のエイリアス名:
application/x-protobuf, application/x-protobuffer
アプリケーション/x-protobuf、アプリケーション/x-protobuf
Magic number(s):
マジックナンバー:
N/A
該当なし
File extension(s):
ファイル拡張子:
N/A
該当なし
Macintosh file type code(s):
Macintosh ファイルタイプコード:
N/A
該当なし
Person & email address to contact for further information:
詳細についての連絡先の担当者と電子メール アドレス:
Protobuf Team <protobuf-team@google.com>
Protobuf チーム <protobuf-team@google.com>
Intended usage:
使用目的:
COMMON
一般
Restrictions on usage:
使用上の制限:
N/A
該当なし
Author:
著者：
Rob Sloan <rmsj@google.com>, Protobuf Team <protobuf-team@google.com>
ロブ・スローン <rmsj@google.com>、Protobuf チーム <protobuf-team@google.com>
Change controller:
コントローラーを変更します:
IETF
IETF
Type name:
型名:
application
応用
Subtype name:
サブタイプ名:
protobuf+json
プロトバッファ+json
Required parameters:
必須パラメータ:
charset, which must be set to utf-8 (case-insensitive)
charset。utf-8 (大文字と小文字を区別しない) に設定する必要があります。
Optional parameters:
オプションのパラメータ:
encoding
エンコーディング
Indicates the type of Protobuf encoding and is json by default for application/protobuf+json, indicating the format in [ProtoJSON]. At the time of writing, no other encoding can be used for application/protobuf+json, so this parameter is for extensibility.
Protobuf エンコーディングのタイプを示します。application/protobuf+json のデフォルトでは json であり、[ProtoJSON] の形式を示します。執筆時点では、application/protobuf+json には他のエンコーディングを使用できないため、このパラメーターは拡張性を目的としています。
version
バージョン
Indicates the version of the wire encoding specification (not the schema language), with a default of 1. At the time of writing, no protobuf wire encodings are versioned, so this parameter is for extensibility. Unversioned wire encodings should be treated as having version 1.
ワイヤ エンコーディング仕様 (スキーマ言語ではない) のバージョンを示します。デフォルトは 1 です。執筆時点では、protobuf ワイヤ エンコーディングはバージョン管理されていないため、このパラメータは拡張性を目的としています。バージョン管理されていないワイヤ エンコーディングは、バージョン 1 を持つものとして扱う必要があります。
Encoding considerations:
エンコーディングに関する考慮事項:
Same as encoding considerations of application/json as specified in [RFC8259], Section 11.
[RFC8259] のセクション 11 で規定されている application/json のエンコードに関する考慮事項と同じです。
Security considerations:
セキュリティに関する考慮事項:
See Section 6 of RFC 9996.
RFC 9996 のセクション 6 を参照してください。
Interoperability considerations:
相互運用性に関する考慮事項:
The Protobuf specification [Protobuf] includes versioning provisions to ensure backward compatibility when encountering payloads with unknown properties.
Protobuf 仕様 [Protobuf] には、未知のプロパティを持つペイロードに遭遇した場合に下位互換性を確保するためのバージョン管理規定が含まれています。
Published specification:
公開された仕様:
[Protobuf]
[プロトバッファ]
Applications that use this media type:
このメディア タイプを使用するアプリケーション:
Any application with a need to exchange or store structured objects across platforms or implementations.
プラットフォームまたは実装間で構造化オブジェクトを交換または保存する必要があるアプリケーション。
Fragment identifier considerations:
フラグメント識別子の考慮事項:
N/A
該当なし
Additional information:
追加情報：
Deprecated alias names for this type:
このタイプの非推奨のエイリアス名:
application/x-protobuf+json
アプリケーション/x-protobuf+json
Magic number(s):
マジックナンバー:
N/A
該当なし
File extension(s):
ファイル拡張子:
N/A
該当なし
Macintosh file type code(s):
Macintosh ファイルタイプコード:
N/A
該当なし
Person & email address to contact for further information:
詳細についての連絡先の担当者と電子メール アドレス:
Protobuf Team <protobuf-team@google.com>
Protobuf チーム <protobuf-team@google.com>
Intended usage:
使用目的:
COMMON
一般
Restrictions on usage:
使用上の制限:
N/A
該当なし
Author:
著者：
Rob Sloan <rmsj@google.com>, Protobuf Team <protobuf-team@google.com>
ロブ・スローン <rmsj@google.com>、Protobuf チーム <protobuf-team@google.com>
Change controller:
コントローラーを変更します:
IETF
IETF
[Protobuf] Google, LLC, "Protocol Buffers", <https://protobuf.dev/>.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<https://www.rfc-editor.org/info/rfc2045>.
[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>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>.
[RFC6839] Hansen, T. and A. Melnikov, "Additional Media Type
Structured Syntax Suffixes", RFC 6839,
DOI 10.17487/RFC6839, January 2013,
<https://www.rfc-editor.org/info/rfc6839>.
[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>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
[Any] "any.proto Schema Definition", commit 97921a5, 12 February
2026, <https://github.com/protocolbuffers/protobuf/blob/ma
in/src/google/protobuf/any.proto>.
[Binary] Google, LLC, "Protobuf Binary Wire Encoding Spec",
<https://protobuf.dev/programming-guides/encoding>.
[CORB] Chromium, "Cross-Origin Read Blocking for Web Developers",
<https://www.chromium.org/Home/chromium-security/corb-for-
developers>.
[Edition2023]
Google, LLC, "Protocol Buffers Edition 2023 Language
Specification", <https://protobuf.dev/reference/protobuf/
edition-2023-spec>.
[Edition2024]
Google, LLC, "Protocol Buffers Edition 2024 Language
Specification", <https://protobuf.dev/reference/protobuf/
edition-2024-spec>.
[MIMESNIFF]
WHATWG, "MIME Sniffing - MIME Type Groups", WHATWG Living
Standard,
<https://mimesniff.spec.whatwg.org/#mime-type-groups>.
Commit snapshot:
<https://mimesniff.spec.whatwg.org/commit-
snapshots/67bde18bc4f75a5c5b5dfb1217161137ce385124/>.
[Proto2] Google, LLC, "Protocol Buffers Language Specification
(Proto2 Syntax)",
<https://protobuf.dev/reference/protobuf/proto2-spec>.
[Proto3] Google, LLC, "Protocol Buffers Language Specification
(Proto3)",
<https://protobuf.dev/reference/protobuf/proto3-spec>.
[ProtoFeatures]
Google, LLC, "Protobuf Feature Settings for Editions",
<https://protobuf.dev/editions/features/>.
[ProtoJSON]
Google, LLC, "Protobuf JSON Wire Encoding Spec",
<https://protobuf.dev/programming-guides/json>.
[RFC8264] Saint-Andre, P. and M. Blanchet, "PRECIS Framework:
Preparation, Enforcement, and Comparison of
Internationalized Strings in Application Protocols",
RFC 8264, DOI 10.17487/RFC8264, October 2017,
<https://www.rfc-editor.org/info/rfc8264>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC9205] Nottingham, M., "Building Protocols with HTTP", BCP 56,
RFC 9205, DOI 10.17487/RFC9205, June 2022,
<https://www.rfc-editor.org/info/rfc9205>.
[UniChars] Bray, T. and P. Hoffman, "Unicode Character Repertoire
Subsets", RFC 9839, DOI 10.17487/RFC9839, August 2025,
<https://www.rfc-editor.org/info/rfc9839>.
Orie Steele provided valuable feedback to this work.
Orie Steele はこの作品に貴重なフィードバックを提供してくれました。
Murray S. Kucherawy (editor)
Email: superuser@gmail.com
Warren Kumari
Google
Email: warren@kumari.net
Rob Sloan
Google
Email: varomodt@gmail.com