Media Type Registration for Protocol Buffers
draft-ietf-dispatch-mime-protobuf-07

DISPATCH M. Kucherawy, Ed.
Internet-Draft 
Intended status: Informational W. Kumari
Expires: 4 June 2026 R. Sloan
 Google
 1 December 2025
 Media Type Registration for Protocol Buffers
 draft-ietf-dispatch-mime-protobuf-07
Abstract
 This document registers media types for Protocol Buffers, a common
 extensible mechanism for serializing structured data.
About This Document
 This note is to be removed before publishing as an RFC.
 The latest revision of this draft can be found at
 https://github.com/wkumari/draft-murray-dispatch-mime-protobuf.
 Status information for this document may be found at
 https://datatracker.ietf.org/doc/draft-ietf-dispatch-mime-protobuf/.
 Discussion of this document takes place on the DISPATCH Working Group
 mailing list (mailto:dispatch@ietf.org), which is archived at
 https://www.ietf.org/mailman/listinfo/dispatch. Subscribe at
 https://www.ietf.org/mailman/listinfo/dispatch/.
 Source for this draft and an issue tracker can be found at
 https://github.com//wkumari/draft-murray-dispatch-mime-protobuf.
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."
Kucherawy, et al. Expires 4 June 2026 [Page 1]
Internet-Draft Media Type Registration for Protocol Buf December 2025
 This Internet-Draft will expire on 4 June 2026.
Copyright Notice
 Copyright (c) 2025 IETF Trust and the persons identified as the
 document authors. All rights reserved.
 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.
Table of Contents
 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
 2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 3
 3. Payload Description . . . . . . . . . . . . . . . . . . . . . 3
 4. Encoding Considerations . . . . . . . . . . . . . . . . . . . 4
 5. Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4
 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
 7.1. Registration for the "application/protobuf" Media Type . 6
 7.2. Registration for "application/protobuf+json" Media
 Type . . . . . . . . . . . . . . . . . . . . . . . . . . 7
 8. Contact . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
 9.1. Normative References . . . . . . . . . . . . . . . . . . 8
 9.2. Informative References . . . . . . . . . . . . . . . . . 9
 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10
 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
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 ("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
Kucherawy, et al. Expires 4 June 2026 [Page 2]
Internet-Draft Media Type Registration for Protocol Buf December 2025
 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. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
 capitals, as shown here.
3. 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:
Kucherawy, et al. Expires 4 June 2026 [Page 3]
Internet-Draft Media Type Registration for Protocol Buf December 2025
 {
 "name": "John Doe",
 "id": 1234,
 "email": "jdoe@example.com"
 }
4. Encoding Considerations
 Protobuf supports the [Binary] and [ProtoJSON] formats 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.
 The media type includes 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.
5. Versions
 [Proto2] was the first public version of the Protobuf schema
 language, and [Proto3] and [Edition2023] came later, with the last of
 these 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
 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.
 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.
6. 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,
 that applies to the schema language, not serializations.
Kucherawy, et al. Expires 4 June 2026 [Page 4]
Internet-Draft Media Type Registration for Protocol Buf December 2025
 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.
 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 with problems discussed, for example, in [UniChars] and
 [RFC8264]; 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 [RFC9205] 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 ([CORB]). Per
 [RFC6839], pure JSON content is indicated by a +json subtype suffix
 (see also [MIMESNIFF]); so 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 [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.
7. IANA Considerations
 As per the process defined in [RFC6838], 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:
Kucherawy, et al. Expires 4 June 2026 [Page 5]
Internet-Draft Media Type Registration for Protocol Buf December 2025
7.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. 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 wire encoding
 specification (not the schema language), with default 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 Section 6
 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):
Kucherawy, et al. Expires 4 June 2026 [Page 6]
Internet-Draft Media Type Registration for Protocol Buf December 2025
 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>, Protobuf Team <protobuf-
 team@google.com>
 Change controller: IETF
 Provisional registration? (standards tree only): No
7.2. Registration for "application/protobuf+json" Media Type
 Type name: application
 Subtype name: protobuf+json
 Required parameters: charset, which must be set to utf-8 (case-
 insensitive)
 Optional parameters:
 * encoding, which indicates the type of Protobuf encoding and is
 json by default for application/protobuf+json, indicating the
 [ProtoJSON] format. At the time of writing, no other encoding can
 be used for application/protobuf+json so this parameter is for
 extensibility.
 * version, which indicates the version of the wire encoding
 specification (not the schema language), with default 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 [RFC8259], Section 11.
 Security considerations: see Section 6
 Interoperability considerations: The Protobuf specification includes
 versioning provisions to ensure backward compatibility when
 encountering payloads with unknown properties.
 Published specification: [Protobuf]
Kucherawy, et al. Expires 4 June 2026 [Page 7]
Internet-Draft Media Type Registration for Protocol Buf December 2025
 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: x-protobuf+json
 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>. Protobuf Team <protobuf-
 team@google.com>
 Change controller: IETF
 Provisional registration? (standards tree only): No
8. Contact
 Please contact protobuf-team@google.com for requests to adjust this
 specification. Issues may be raised at
 https://github.com/protocolbuffers/protobuf.
9. References
9.1. Normative References
 [Protobuf] "Protocol Buffers", n.d., <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/rfc/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/rfc/rfc2119>.
Kucherawy, et al. Expires 4 June 2026 [Page 8]
Internet-Draft Media Type Registration for Protocol Buf December 2025
 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
 <https://www.rfc-editor.org/rfc/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/rfc/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/rfc/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/rfc/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/rfc/rfc8259>.
9.2. Informative References
 [Any] Protobuf, "any.proto Schema Definition", n.d., <https://gi
 thub.com/protocolbuffers/protobuf/blob/main/src/google/
 protobuf/any.proto>.
 [Binary] Protobuf, "Protobuf Binary Wire Encoding Spec", n.d.,
 <https://protobuf.dev/programming-guides/encoding>.
 [CORB] Chromium, "Cross-Origin Read Blocking for Web Developers",
 n.d., <https://www.chromium.org/Home/chromium-security/
 corb-for-developers>.
 [Edition2023]
 Protobuf, "Proto Edition 2023 Schema Language
 Specification", n.d.,
 <https://protobuf.dev/reference/protobuf/edition-
 2023-spec>.
 [MIMESNIFF]
 WHATWG, "MIME Sniffing: Living Standard", n.d.,
 <https://mimesniff.spec.whatwg.org/#mime-type-groups>.
 [Proto2] Protobuf, "Proto2 Schema Language Specification", n.d.,
 <https://protobuf.dev/reference/protobuf/proto2-spec>.
Kucherawy, et al. Expires 4 June 2026 [Page 9]
Internet-Draft Media Type Registration for Protocol Buf December 2025
 [Proto3] Protobuf, "Proto3 Schema Language Specification", n.d.,
 <https://protobuf.dev/reference/protobuf/proto3-spec>.
 [ProtoFeatures]
 Protobuf, "Protobuf Feature Settings for Editions", n.d.,
 <https://protobuf.dev/editions/features/>.
 [ProtoJSON]
 Protobuf, "Protobuf JSON Wire Encoding Spec", n.d.,
 <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/rfc/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/rfc/rfc8446>.
 [RFC9205] Nottingham, M., "Building Protocols with HTTP", BCP 56,
 RFC 9205, DOI 10.17487/RFC9205, June 2022,
 <https://www.rfc-editor.org/rfc/rfc9205>.
 [UniChars] IETF, "Unicode Character Repertoire Subsets", n.d.,
 <https://datatracker.ietf.org/doc/draft-bray-unichars/>.
Acknowledgments
 Orie Steele provided valuable feedback to this work.
Authors' Addresses
 Murray S. Kucherawy (editor)
 Email: superuser@gmail.com
 Warren Kumari
 Google
 Email: warren@kumari.net
 Rob Sloan
 Google
 Email: rmsj@google.com
Kucherawy, et al. Expires 4 June 2026 [Page 10]