Media Type Registration for Protocol Buffers

Internet-Draft	Media Type Registration for Protocol Buf	April 2025
Kucherawy, et al.	Expires 27 October 2025	[Page]

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 27 October 2025.¶

Copyright Notice

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.¶

1. Introduction

Protocol Buffers ("protobufs") were introduced in 2008 as a free, open source, platform-independent mechanism for transport and storage of structured data: their use 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 consists of an interface definition language, 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 multiple wire formats for interchange: [Binary], which is optimized for wire efficiency, and [ProtoJSON], which maps the Protobuf schema onto a JSON structure.¶

Serialized objects are occasionally transported within media that make use of media types (see [RFC2045] et seq) to identify payloads. Accordingly, current and historical media types used for this purpose would benefit from registration. This document requests those registrations of IANA.¶

2. Payload Description

These media types 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 figures below, only the third of these would ever be used with these media types (a JSON example is depicted).¶

An example use of the IDL to specify a "Person" object:¶

edition = "2023";

message Person {
  string name = 1;
  int32 id = 2;
  string email = 3;
}

An example of python code that uses code generated from the IDL definition above to create an instance of a "Person" object:¶

person = Person()
person.id = 1234
person.name = "John Doe"
person.email = "jdoe@example.com"

An example of the above instance expressed in JSON:¶

{
  "name": "John Doe",
  "id": 1234,
  "email": "jdoe@example.com"
}

3. Encoding Considerations

Protobuf supports only the [Binary] and [ProtoJSON] for interchange, both of which are platform-independent. For binary forms that need to transit non-binary transports, a base64 Content-Transfer-Encoding (xref to [RFC4648]) is recommended.¶

4. Security Considerations

The payload for these media types contain 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, but 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. [RFC8446]). Implementations should be careful when processing Protobuf like any binary format: a malformed request to a protobuf server could be crafted to, for example, allocate a very large amount of memory, potentially impacting other operations on that server.¶

In order to safely use Protobuf serializations on the web, it is important to ensure that they cannot be interpreted as another document type, such as JavaScript. For this reason, we recommend that binary protobuf serializations be wrapped in a Base64 Content-Transfer-Encoding according to [RFC2045]. 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 can be indicated by a +json subtype suffix (see also [MIMESNIFF]); so when serializing Protobuf content to JSON, users MUST use the application/protobuf+json MIME type. Further, charset can prevent certain encoding confusion attacks so users should specify it for all JSON encodings.¶

In the [Any] type there is technically a link, which was intended to be dereferenced to obtain schemas for a given type; however this is not supported by widely used Protobuf implementations.¶

5. IANA Considerations

This document requests the registration of application/protobuf and application/protobuf+json as media types for Protobuf, and the notation of application/x-protobuf, application/x-protobuffer, and application/x-protobuf+json as deprecated aliases:¶

5.1. Registration for the "application/protobuf" Media Type

Type name: application¶

Subtype name: protobuf¶

Required parameters: none¶

Optional parameters:¶

encoding, which indicates the type of Protobuf encoding and is "binary" by default for application/protobuf, indicating the [Binary] format. Clients MUST reject JSON encodings without the +json subtype suffix and MUST reject unknown encodings. At the time of writing, no other encoding can be used for application/protobuf so this parameter is for extensibility.¶
version, which indicates the version of the encoding specification. Clients MUST reject unknown version settings. At the time of writing, no protobuf encodings are versioned so this parameter is for extensibility.¶

Encoding considerations: binary¶

Security considerations: see Section 4 ¶

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

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: None.¶

Additional information:¶

 Deprecated alias names for this type: `application/x-protobuf`, `application/x-protobuffer`
 Magic number(s):
 File extension(s):
 Macintosh file type code(s):

Person & email address to contact for further information: Protobuf <protobuf-team@google.com>¶

Intended usage: COMMON¶

Restrictions on usage: None¶

Author: Rob Sloan <rmsj@google.com>¶

Change controller: Protobuf <protobuf-team@google.com>¶

Provisional registration? (standards tree only): No¶

5.2. Registration for "application/protobuf+json" Media Type