]>

superuser@gmail.com

Google

warren@kumari.net

Google

rmsj@google.com

ART DISPATCH MIME protobuf media type application This document registers media types for Protocol Buffers, a common extensible mechanism for serializing structured data. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the DISPATCH Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

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 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 multiple wire formats for interchange: , which is optimized for wire efficiency, and , which maps the Protobuf schema onto a JSON structure. Serialized objects are occasionally transported within media that make use of media types (see 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.

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 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: An example of python code that uses code generated from the IDL definition above to create an instance of a "Person" object: An example of the above instance expressed in JSON:

Encoding Considerations Protobuf supports only the and formats 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. 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 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 and 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 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 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. 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: 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 ) and a manual well-formedness check may be necessary. Further, handling Unicode text generally can be quite complex with problems discussed, for example, in and ; 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 ); 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 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.

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

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

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 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 , Section 11. Security considerations: see 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: None. Additional information: 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

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

References Normative References This initial document specifies the various headers used to describe the structure of MIME messages. [STANDARDS-TRACK] In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice. A content media type name sometimes includes partitioned meta- information distinguished by a structured syntax to permit noting an attribute of the media as a suffix to the name. This document defines several structured syntax suffixes for use with media type registrations. In particular, it defines and registers the "+json", "+ber", "+der", "+fastinfoset", "+wbxml" and "+zip" structured syntax suffixes, and provides a media type structured syntax suffix registration form for the "+xml" structured syntax suffix. This document is not an Internet Standards Track specification; it is published for informational purposes. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. n.d. Informative References This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. Applications often use HTTP as a substrate to create HTTP-based APIs. This document specifies best practices for writing specifications that use HTTP to define new application protocols. It is written primarily to guide IETF efforts to define application protocols using HTTP for deployment on the Internet but might be applicable in other situations. This document obsoletes RFC 3205. Application protocols using Unicode code points in protocol strings need to properly handle such strings in order to enforce internationalization rules for strings placed in various protocol slots (such as addresses and identifiers) and to perform valid comparison operations (e.g., for purposes of authentication or authorization). This document defines a framework enabling application protocols to perform the preparation, enforcement, and comparison of internationalized strings ("PRECIS") in a way that depends on the properties of Unicode code points and thus is more agile with respect to versions of Unicode. As a result, this framework provides a more sustainable approach to the handling of internationalized strings than the previous framework, known as Stringprep (RFC 3454). This document obsoletes RFC 7564. Chromium n.d. WHATWG n.d. Protobuf n.d. Protobuf n.d. Protobuf n.d. Protobuf n.d. Protobuf n.d. Protobuf n.d. Protobuf n.d. IETF n.d.

Acknowledgments Orie Steele provided valuable feedback to this work.