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

DISPATCH                                               M. Kucherawy, Ed.
Internet-Draft                                                          
Intended status: Informational                                 W. Kumari
Expires: 1 December 2025                                        R. Sloan
                                                                  Google
                                                             30 May 2025

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

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 1 December 2025                [Page 1]
Internet-Draft  Media Type Registration for Protocol Buf        May 2025

   This Internet-Draft will expire on 1 December 2025.

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.  Payload Description . . . . . . . . . . . . . . . . . . . . .   3
   3.  Encoding Considerations . . . . . . . . . . . . . . . . . . .   4
   4.  Versions  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
     6.1.  Registration for the "application/protobuf" Media Type  .   5
     6.2.  Registration for "application/protobuf+json" Media
           Type  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   7.  Contact . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     8.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.

Kucherawy, et al.        Expires 1 December 2025                [Page 2]
Internet-Draft  Media Type Registration for Protocol Buf        May 2025

   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 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"
   }

Kucherawy, et al.        Expires 1 December 2025                [Page 3]
Internet-Draft  Media Type Registration for Protocol Buf        May 2025

3.  Encoding Considerations

   Protobuf supports only 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 Content-
   Transfer-Encoding (xref to [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 6 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.

4.  Versions

   Protobuf (without a number), later also referred to as protobuf1, was
   the original private version of protobuf.  Protobuf2 and protobuf3
   came later, with the latter of these being current at the time of
   writing.

   The number associated with the name refers 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 6 include support for versioning
   of the wire format, should it ever change, but do not refer to the
   IDL, which can evolve independently.

   Clients MUST reject payloads with an unsupported version number.

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

Kucherawy, et al.        Expires 1 December 2025                [Page 4]
Internet-Draft  Media Type Registration for Protocol Buf        May 2025

   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.

6.  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:

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

Kucherawy, et al.        Expires 1 December 2025                [Page 5]
Internet-Draft  Media Type Registration for Protocol Buf        May 2025

      be treated as having version 1.  Protobuf implementations should
      accept all versions of wire encodings defined at the time of
      implementation.

   Encoding considerations: binary

   Security considerations: see Section 5

   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

6.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)

Kucherawy, et al.        Expires 1 December 2025                [Page 6]
Internet-Draft  Media Type Registration for Protocol Buf        May 2025

   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.  Protobuf implementations should
      accept all versions of wire encodings defined at the time of
      implementation.

   Encoding considerations: Same as encoding considerations of
   application/json as specified in [RFC7159], Section 11.

   Security considerations: see Section 5

   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: 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>

Kucherawy, et al.        Expires 1 December 2025                [Page 7]
Internet-Draft  Media Type Registration for Protocol Buf        May 2025

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

   Provisional registration? (standards tree only): No

7.  Contact

   Please contact protobuf-team@google.com for requests to adjust this
   specification.  Issues may be raised at
   https://github.com/protocolbuffers/protobuf.

8.  References

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

   [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part Two: Media Types", RFC 2046,
              DOI 10.17487/RFC2046, November 1996,
              <https://www.rfc-editor.org/rfc/rfc2046>.

   [RFC2077]  Nelson, S., Parks, C., and Mitra, "The Model Primary
              Content Type for Multipurpose Internet Mail Extensions",
              RFC 2077, DOI 10.17487/RFC2077, January 1997,
              <https://www.rfc-editor.org/rfc/rfc2077>.

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

   [RFC4289]  Freed, N. and J. Klensin, "Multipurpose Internet Mail
              Extensions (MIME) Part Four: Registration Procedures",
              BCP 13, RFC 4289, DOI 10.17487/RFC4289, December 2005,
              <https://www.rfc-editor.org/rfc/rfc4289>.

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

Kucherawy, et al.        Expires 1 December 2025                [Page 8]
Internet-Draft  Media Type Registration for Protocol Buf        May 2025

   [RFC6657]  Melnikov, A. and J. Reschke, "Update to MIME regarding
              "charset" Parameter Handling in Textual Media Types",
              RFC 6657, DOI 10.17487/RFC6657, July 2012,
              <https://www.rfc-editor.org/rfc/rfc6657>.

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

   [RFC7159]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
              2014, <https://www.rfc-editor.org/rfc/rfc7159>.

   [RFC7303]  Thompson, H. and C. Lilley, "XML Media Types", RFC 7303,
              DOI 10.17487/RFC7303, July 2014,
              <https://www.rfc-editor.org/rfc/rfc7303>.

   [RFC8081]  Lilley, C., "The "font" Top-Level Media Type", RFC 8081,
              DOI 10.17487/RFC8081, February 2017,
              <https://www.rfc-editor.org/rfc/rfc8081>.

   [RFC9694]  Dürst, M.J., "Guidelines for the Definition of New Top-
              Level Media Types", BCP 13, RFC 9694,
              DOI 10.17487/RFC9694, March 2025,
              <https://www.rfc-editor.org/rfc/rfc9694>.

   [RFC9695]  Muthusamy, Y. K. and C. Ullrich, "The 'haptics' Top-Level
              Media Type", RFC 9695, DOI 10.17487/RFC9695, March 2025,
              <https://www.rfc-editor.org/rfc/rfc9695>.

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

Kucherawy, et al.        Expires 1 December 2025                [Page 9]
Internet-Draft  Media Type Registration for Protocol Buf        May 2025

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

   [Proto3]   Protobuf, "Proto3 Schema Language Specification", n.d.,
              <https://protobuf.dev/reference/protobuf/proto3-spec>.

   [ProtoJSON]
              Protobuf, "Protobuf JSON Wire Encoding Spec", n.d.,
              <https://protobuf.dev/programming-guides/json>.

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

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 1 December 2025               [Page 10]