]>

superuser@gmail.com

Google

warren@kumari.net

Google

varomodt@gmail.com

ART dispatch MIME Protobuf media type application This document registers media types for Protocol Buffers, a common extensible mechanism for serializing structured data.

Introduction 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 for more information. 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 (which is optimized for wire efficiency) and the format in (which maps the Protobuf schema onto a JSON structure). Serialized objects are occasionally transported within media that make use of media types (see ) 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 .

Key Words 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 when, and only when, they appear in all capitals, as shown here.

Payload Description 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.

1. An example of using the IDL to specify a "Person" object:
2. An example of python code that uses code generated from the IDL definition above to create an instance of a "Person" object:
3. An example of the above instance expressed in JSON:

Encoding Considerations Protobuf supports the formats in and for interchange, both of which are platform-independent. For binary forms that need to transit non-binary transports, a base64 encoding (e.g., ) is recommended. 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 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.

Versions was the first public version of the Protobuf schema language; , , and came later, with being current at the time of writing. Future editions of the IDL are expected. 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 include support for versioning of the wire format, should it ever change, but do not refer to the IDL, which can evolve independently. 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. Clients MUST reject payloads with an unsupported version number.

Security Considerations 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 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., ). 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 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 ), and a manual well-formedness check may be necessary. Further, handling Unicode text generally can be quite complex (due to the problems discussed in and , for example), so it is best to rely on well-supported internationalization libraries whenever possible. 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 to prevent content sniffing for all binary formats. 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 . Per , pure JSON content is indicated by a +json subtype suffix (see also ); 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. In the type described in , 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.

IANA Considerations As per the process defined in , 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.

Media Type: application/protobuf

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 . At the time of writing, no other encoding can be used for application/protobuf, so this parameter is for extensibility.

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.

Encoding considerations:

binary

Security considerations:

See of RFC 9996.

Interoperability considerations:

The Protobuf specification includes versioning provisions to ensure backward compatibility when encountering payloads with unknown properties.

Published specification:

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

Magic number(s):

N/A

File extension(s):

N/A

Macintosh file type code(s):

N/A

Person & email address to contact for further information:

Protobuf Team <protobuf-team@google.com>

Intended usage:

COMMON

Restrictions on usage:

N/A

Author:

<rmsj@google.com>, Protobuf Team <protobuf-team@google.com>

Change controller:

IETF

Media Type: application/protobuf+json

Type name:

application

Subtype name:

protobuf+json

Required parameters:

charset, which must be set to utf-8 (case-insensitive)

Optional parameters:

encoding

Indicates the type of Protobuf encoding and is json by default for application/protobuf+json, indicating the format in . At the time of writing, no other encoding can be used for application/protobuf+json, so this parameter is for extensibility.

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.

Encoding considerations:

Same as encoding considerations of application/json as specified in .

Security considerations:

See of RFC 9996.

Interoperability considerations:

The Protobuf specification includes versioning provisions to ensure backward compatibility when encountering payloads with unknown properties.

Published specification:

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

Magic number(s):

N/A

File extension(s):

N/A

Macintosh file type code(s):

N/A

Person & email address to contact for further information:

Protobuf Team <protobuf-team@google.com>

Intended usage:

COMMON

Restrictions on usage:

N/A

Author:

<rmsj@google.com>, Protobuf Team <protobuf-team@google.com>

Change controller:

IETF

References Normative References Google, LLC Informative References Chromium WHATWG WHATWG Living Standard Commit snapshot: . commit 97921a5 Google, LLC Google, LLC Google, LLC Google, LLC Google, LLC Google, LLC Google, LLC

Acknowledgments provided valuable feedback to this work.