Authors, While reviewing this document during Final Review, please resolve (as necessary) the following questions, which are also in GitHub issues (see https://github.com/rfc-editor/FinalReview-rfc9996/issues).
1) <!-- [rfced] This is a question for Rob. The datatracker currently lists your email address as <[email protected]>, but this document lists your email address as <[email protected]>. In the document, the <[email protected]> address appears in the Authors' Addresses section and in the Media Type templates in the IANA Considerations section. Please confirm which email address you would like to use in the document. Note that you can update your email address (if needed) in datatracker by logging into your datatracker account. --> 2) <!-- [rfced] We updated the document title as follows (removed "Registration") to align with titles of other documents that register media types. We also used this updated title as the abbreviated title (appears in the running header at the top of each page in the PDF output). Let us know any concerns. Original: Media Type Registration for Protocol Buffers Current (document title and abbreviated title): Media Types for Protocol Buffers --> 3) <!-- [rfced] Should "These media types" here be updated to "The media types defined in this document" (or similar)? Original: These media types are used in the transport of serialized objects only. Perhaps: The media types defined in this document are used in the transport of serialized objects only. --> 4) <!-- [rfced] Should "The media type includes" be updated to "Both of the media types defined in this document include" (or similar)? Original: The media type includes an optional "encoding" parameter indicating which encoding format is to be used with that particular payload. Perhaps: 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. --> 5) <!-- [rfced] It appears a more recent version of the protobuf schema language was published in 2024. See https://protobuf.dev/reference/protobuf/edition-2024-spec/. Would you like to include this as a reference in this document as well? Current ([Edition2023] being current...): [Proto2] was the first public version of the Protobuf schema language; [Proto3] and [Edition2023] came later, with [Edition2023] being current at the time of writing. Future editions of the IDL are expected. Perhaps ([Edition2024] being current...): [Proto2] was the first public version of the Protobuf schema language; [Proto3], [Edition2023], and [Edition2024] came later, with [Edition2024] being current at the time of writing. Future editions of the IDL are expected. ... [Edition2024] Google, LLC, "Protocol Buffers Edition 2023 Language Specification", <https://protobuf.dev/reference/protobuf/ edition-2024-spec/>. --> 6) <!-- [rfced] IANA Considerations section a) We made some changes to the Media Type templates in Sections 7.1 and 7.2. Prior to publication, we will ask IANA to update the corresponding templates on their site to match: https://www.iana.org/assignments/media-types/application/protobuf https://www.iana.org/assignments/media-types/application/protobuf+json b) Section 7.2: Would you like to update "x-protobuf+json" to "application/x-protobuf+json" to align with the similar text in Sections 7 and 7.1? Original: Deprecated alias names for this type: x-protobuf+json Perhaps: Deprecated alias names for this type: application/x-protobuf+json c) In the templates in Sections 7.1 and 7.2, we have updated instances of "None" to "N/A" per Section 5.6 of RFC 6838, which states: "N/A", written exactly that way, can be used in any field if desired to emphasize the fact that it does not apply or that the question was not omitted by accident. Do not use 'none' or other words that could be mistaken for a response. We also added "N/A" to the Magic number(s), File extension(s), and Macintosh file type code(s) fields, which were empty. --> 7) <!-- [rfced] May we remove this section? Once published, this specification cannot be adjusted (although errata can be submitted). Also, the <[email protected]> email address already appears in the Media Type templates in Sections 7.1 and 7.2. Original: 8. Contact Please contact [email protected] for requests to adjust this specification. Issues may be raised at https://github.com/protocolbuffers/protobuf. --> 8) <!-- [rfced] In Section 3, the IDL example was tagged as <artwork>. We updated to <sourcecode> but left the "type" attribute empty. Let us know if the "type" attribute should be set. If the current list of preferred values for "type" (https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types) does not contain an applicable type, then feel free to suggest a new one. Also, it is acceptable to leave the "type" attribute not set. --> 9) <!-- [rfced] Terminology a) We see both of the following forms in general text in the document (excluding title case). Should these be uniform? If so, please let us know which form is preferred. Protobuf protobuf b) "Protocol Buffer" is consistently capitalized in this document, but we see the lowercase form used at <https://protobuf.dev/>. Please review and let us know if any updates are needed. c) The first sentence below is the only instance of plural "protobufs" in the document. Other instances use the singular "Protobuf" or "protobuf". See second paragraph below for examples, but note that the singular form occurs throughout the document. Please review singular/plural with this and let us know if any updates are needed. Original: 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 ... Perhaps: Protocol Buffers (also called "protobuf") were introduced in 2008 as free, open- source, platform-independent mechanisms 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 [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 ... --> 10) <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> Thank you. Sarah Tarrant and Rebecca VanRheenen RFC Production Center On May 28, 2026, at 6:55 PM, [email protected] wrote: *****IMPORTANT***** Updated 2026/05/28 RFC Author(s): -------------- Your document has now entered Final Review (previously AUTH48). Final Review is being handled in GitHub as part of the GitHub pilot test (see https://www.rfc-editor.org/rpc/wiki/doku.php?id=rpc-github-phase-0-pilot-test). Your document is available for review at: https://github.com/rfc-editor/FinalReview-rfc9996 Please do the following: a) accept your invitations to join the repo as collaborators. Rob, please provide your GitHub username so that we can send you an invitation. We have already sent invitations to Murray, Warren, and Andy (AD). If WG Chairs (Jim Fenton and Shuping Peng) would like invitations as well, please provide GitHub usernames. b) see the README for details on the Final Review process: https://github.com/rfc-editor/FinalReview-rfc9996/blob/Approved/README.md c) review and resolve the issues: https://github.com/rfc-editor/FinalReview-rfc9996/issues Once the content is stable in GitHub, we will provide the updated XML file and the output files for review and approval. You and your coauthors are responsible for engaging other parties (e.g., contributors or working group) as necessary before providing your approval. Once the document has been reviewed and approved by all of the authors, it will be published as an RFC. If an author is no longer available, there are several remedies available as listed in the FAQ (https://www.rfc-editor.org/faq/). Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC 9996 (draft-ietf-dispatch-mime-protobuf) Title : Media Type Registration for Protocol Buffers Author(s) : M. Kucherawy, Ed., W. Kumari, R. Sloan WG Chair(s) : Shuping Peng, Jim Fenton Area Director(s) : Charles Eckel, Andy Newton -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
