Authors, While reviewing this document during Final Review, please resolve (as necessary) the following questions, which are also in the source file.
1) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> 2) <!-- [rfced] May we rephrase this sentence for clarity and easier readability? Original: It enables capture of an object or a scene in three dimensions (3D) and its playback independent from the original capture position(s) or orientation(s). Perhaps: It enables the three-dimensional (3D) capture and playback of an object or scene, independent from the original capture position(s) or orientation(s). --> 3) <!-- [rfced] Abbreviations (Section 3.2) a) In the RFC Series, expansions of abbreviations are typically introduced before using abbreviations on their own. For example, "atlas coding layer (ACL)" would be shown before simply referring to the term as "ACL" in the text. We note that the abbreviations section is placed after Section 3.1.2, where some definitions use abbreviations that are not yet defined. In this case, may we move the abbreviations section to appear before Section 3.1.2? Perhaps (Table of Contents): 3. Definitions and Abbreviations 3.1. Abbreviations 3.2. Definitions 3.2.1. General 3.2.2. Definitions from the V3C Specification b) If the Abbreviations are moved as suggested, may we remove the multiple expansions of "V3C" in Section 3.1.2? Original: coded visual volumetric video-based coding (V3C) sequence: visual volumetric video-based coding (V3C) atlas sub-bitstream: visual volumetric video-based coding (V3C) video sub-bitstream: visual volumetric video-based coding (V3C) component: visual volumetric video-based coding (V3C) parameter set: Perhaps: coded V3C sequence: V3C atlas sub-bitstream: V3C video sub-bitstream: V3C component: V3C parameter set: --> 4) <!--[rfced] For consistency, we added "DOND" and "DONL" to the Abbreviations list (Section 3.2) under "DON" as shown below. Please let us know of any objections. Original: DON: decoding order number Current DON: decoding order number DOND: decoding order number difference DONL: decoding order number low --> 5) <!-- [rfced] Should "of volumetric frame" be rephrased as "of a volumetric frame" in the following two instances? Or should "volumetric frame" be plural? Current: 2D representations, known as V3C video components, of volumetric frame are encoded using conventional 2D video codecs. Perhaps A (singular): 2D representations, known as V3C video components, of a volumetric frame are encoded using conventional 2D video codecs. Or Perhaps B (plural): 2D representations, known as V3C video components, of volumetric frames are encoded using conventional 2D video codecs. ... Current: Atlas data, known as V3C atlas component, provides information to interpret V3C video components and enables the reconstruction from a 2D representation back into a 3D representation of volumetric frame. Perhaps C (singular): Atlas data, known as V3C atlas component, provides information to interpret V3C video components and enables the reconstruction from a 2D representation back into a 3D representation of a volumetric frame. Or Perhaps D (plural): Atlas data, known as V3C atlas component, provides information to interpret V3C video components and enables the reconstruction from a 2D representation back into a 3D representation of volumetric frames. --> 6) <!-- [rfced] Please review the formatting of Figure 1. Should the pipe characters (|) and the plus signs (+) be aligned, or is the current format okay as is? --> 7) <!-- [rfced] Please clarify "equal" in this sentence. Is the intended meaning perhaps "equal to 1" (option A), or should "equal" be removed (option B)? We also suggest rephrasing the last part of the sentence to avoid hyphenating the expansion of "EOM". Original: vuh_auxiliary_video_flag equal indicates if the associated geometry or attribute video data unit is a RAW and/or EOM coded points video only sub-bitstream. Perhaps A: vuh_auxiliary_video_flag equal to 1 indicates if the associated geometry or attribute video data unit is a video-only sub-bitstream containing RAW and/or explicit occupancy map (EOM) points. or Perhaps B: vuh_auxiliary_video_flag indicates if the associated geometry or attribute video data unit is a video-only sub-bitstream containing RAW and/or explicit occupancy map (EOM) points. --> 8) <!-- [rfced] Please review whether any of the notes in this document (marked with "NOTE:") should be in the <aside> element. It is defined as "a container for content that is semantically less important or tangential to the content that surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside). --> 9) <!--[rfced] For consistency, we have updated "must not" to "MUST NOT" as shown below. Please let us know of any objections. Additionally, is it correct that an FU MUST NOT contain "a subset of" another FU? Or would it be clearer to say an FU MUST NOT contain "any part of" another FU? Original: FUs MUST NOT be nested; i.e., an FU must not contain a subset of another FU. Current: FUs MUST NOT be nested; i.e., an FU MUST NOT contain a subset of another FU. --> 10) <!-- [rfced] May we rephrase the following paragraph and add parentheses for easier readability? Current: The FU payload consists of fragments of the payload of the fragmented NAL unit so that if the FU payloads of consecutive FUs, starting with an FU with the S bit equal to 1 and ending with an FU with the E bit equal to 1, are sequentially concatenated, the payload of the fragmented NAL unit can be reconstructed. Perhaps: The FU payload consists of fragments of the fragmented NAL unit payload such that if the payloads of consecutive FUs (starting with an FU with the S bit set to 1 and ending with an FU with the E bit set to 1) are sequentially concatenated, the payload of the fragmented NAL unit can be reconstructed. --> 11) <!-- [rfced] <artwork> and <sourcecode> elements a) Please review each artwork element and let us know if any should be marked as sourcecode (or another element) instead. We updated <artwork> to <sourcecode> in several sections. Please review and confirm that this is correct. In addition, please consider whether the "type" attribute of any sourcecode element should be set and/or has been set correctly. The current list of preferred values for "type" is available at https://www.rfc-editor.org/materials/sourcecode-types.txt. If the current list does not contain an applicable type, feel free to suggest additions for consideration. Note that it is also acceptable to leave the "type" attribute not set. b) To improve the formatting of Sections 7.2 and 7.3, may we remove the parameters from their respective <artwork> elements and place them into definition lists for readability and consistency with other definition lists throughout the document? --> 12) <!--[rfced] FYI: For consistency, we updated "ssprop-v3c-sei" to "sprop-v3c-sei" in Table 2. Please let us know of any objections. --> 13) <!-- [rfced] Should "parameter" be singular or plural in this sentence? Current: A simple bitrate adaptation for congestion control can be achieved when real-time coding is used for V3C video components where quality parameter can be adaptively tuned. Perhaps (plural): A simple bitrate adaptation for congestion control can be achieved when real-time coding is used for V3C video components where quality parameters can be adaptively tuned. --> 14) <!--[rfced] May we update these sentences for clarity as shown below (i.e., update "PT equal to" to "PT values")? Original: PT equal to 96, 97, 98 and 100 correspond to occupancy, geometry, and attribute video component as well as atlas data component for atlas zero. PT equal to 101, 102, 103 and 104 correspond to respective components for atlas one. Perhaps: PT values 96, 97, 98, and 100 correspond to the occupancy, geometry, and attribute video components, as well as the atlas data component, for atlas zero. PT values 101, 102, 103, and 104 correspond to the respective components for atlas one. --> 15) <!--[rfced] In Section 10.2, may we remove the "Notes" from the ABNF sourcecode and place the text below (outside of) the sourcecode as shown below? Also, may we add a normative reference (RFC 5234) for the ABNF grammar? Original: v3cfmtp-value = byte-string ; Notes: ; - The V3C format parameters are V3C media type parameters and ; need to reflect their syntax. ; - "byte-string" is as defined in RFC 8866. Perhaps: v3cfmtp-value = byte-string Notes: - The V3C format parameters are V3C media type parameters and need to reflect their syntax. - "byte-string" is as defined in [RFC8866]. - ABNF grammar is as defined in [RFC5234]. --> 16) <!-- [rfced] Should the following include a citation to BCP 195 (which includes RFCs 8996, 9325, and 9852), or is the intention to only point to RFC 9325? Current: (D)TLS-based protection: For guidance on using TLS 1.3 and DTLS, applications should refer to BCP 195, including [RFC9325], which provides up-to-date recommendations. --> 17) <!-- [rfced] Please review the following references. These references have been withdrawn and replaced by newer versions. May we update these references to point to the most current versions available? a) ISO.IEC.14496-10 Current: [ISO.IEC.14496-10] ISO/IEC, "Information technology - Coding of audio-visual objects - Part 10: Advanced video coding", ISO/ IEC 14496-10, 2020, <https://www.iso.org/standard/75400.html>. Perhaps: [ISO.IEC.14496-10] ISO/IEC, "Information technology - Coding of audio-visual objects - Part 10: Advanced video coding", ISO/ IEC 14496-10:2025, 2025, <https://www.iso.org/standard/87574.html>. b) ISO.IEC.14496-12 Current: [ISO.IEC.14496-12] ISO/IEC, "Information technology - Coding of audio-visual objects - Part 12: ISO base media file format", ISO/ IEC 14496-12:2020, 2020, <https://www.iso.org/standard/74428.html>. Perhaps: [ISO.IEC.14496-12] ISO/IEC, "Information technology - Coding of audio-visual objects - Part 12: ISO base media file format", ISO/ IEC 14496-12:2022, 2022, <https://www.iso.org/standard/83102.html>. c) ISO.IEC.23008-2 Current: [ISO.IEC.23008-2] ISO/IEC, "Information technology - High efficiency coding and media delivery in heterogeneous environments - Part 2: High efficiency video coding", ISO/IEC 23008-2:2020, 2020, <https://www.iso.org/standard/75484.html>. Perhaps: [ISO.IEC.23008-2] ISO/IEC, "Information technology - High efficiency coding and media delivery in heterogeneous environments - Part 2: High efficiency video coding", ISO/IEC 23008-2:2025, 2025, <https://www.iso.org/standard/90502.html>. d) ISO.IEC.23090-3 Current: [ISO.IEC.23090-3] ISO/IEC, "Information technology - Coded representation of immersive media - Part 3: Versatile video coding", ISO/ IEC 23090-3:2021, 2021, <https://www.iso.org/standard/73022.html>. Perhaps: [ISO.IEC.23090-3] ISO/IEC, "Information technology - Coded representation of immersive media - Part 3: Versatile video coding", ISO/ IEC 23090-3:2024, 2024, <https://www.iso.org/standard/86516.html>. --> 18) <!-- [rfced] We note that the following terms are used inconsistently. If there are no objections, we will use the form on the right, unless you prefer otherwise. Atlas NAL unit vs. atlas NAL unit --> 19) <!-- [rfced] Abbreviations a) If there are no objections, we will use abbreviations throughout the document after their respective expansions have been introduced. b) We note that "DON" is expanded as "decoding order number". How should "DONL" be expanded upon first use? --> 20) <!-- [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. Madison Church and Karen Moore RFC Production Center On Aug 10, 2026, at 4:12 PM, [email protected] wrote: *****IMPORTANT***** RFC Author(s): -------------- Final Review for RFC-to-be 10034 <draft-ietf-avtcore-rtp-v3c> Your document is now available for Final Review (previously AUTH48). Once it has been reviewed and approved by you and all coauthors, it will be published as an RFC. If an author is no longer available, there are several remedies; see the Unavailable Authors section (https://authors.ietf.org/rfc-publication-process#unavailable-authors). You and you coauthors are responsible for engaging other parties (e.g., Contributors or Working Group) as necessary before providing your approval. Planning your review --------------------- Please review the following aspects of your document: * RFC Editor questions Please review and resolve any questions raised by the RFC Editor that have been included in the XML file as comments marked as follows: <!-- [rfced] ... --> These questions will also be sent in a subsequent email. * Changes submitted by coauthors Please ensure that you review any changes submitted by your coauthors. We assume that if you do not speak up that you agree to changes submitted by your coauthors. * Content Please review the full content of the document, as this cannot change once the RFC is published. Please pay particular attention to: - IANA considerations updates (if applicable) - contact information - references * Copyright notices and legends Please review the copyright notice and legends as defined in RFC 5378 and the Trust Legal Provisions (TLP – https://trustee.ietf.org/license-info). * Semantic markup Please review the markup in the XML file to ensure that elements of content are correctly tagged. For example, ensure that <sourcecode> and <artwork> are set correctly. See details at <https://authors.ietf.org/rfcxml-vocabulary>. * Formatted output Please review the PDF, HTML, and TXT files to ensure that the formatted output, as generated from the markup in the XML file, is reasonable. Please note that the TXT will have formatting limitations compared to the PDF and HTML. Submitting changes ------------------ To submit changes, please reply to this email using 'REPLY ALL' as all the parties CCed on this message need to see your changes. The parties include: * your coauthors * [email protected] (the RPC team) * other document participants, depending on the stream (e.g., IETF Stream participants are your working group chairs, the responsible ADs, and the document shepherd). * [email protected], which is an archival mailing list to preserve discussion about the document while in the RPC editorial queue; it is not an active discussion list: * More info: https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc * The archive itself: https://mailarchive.ietf.org/arch/browse/auth48archive/ * Note: If only absolutely necessary, you may temporarily opt out of the archiving of messages (e.g., to discuss a sensitive matter). If needed, please add a note at the top of the message that you have dropped the address. When the discussion is concluded, [email protected] will be re-added to the CC list and its addition will be noted at the top of the message. You may submit your changes in one of two ways: An update to the provided XML file — OR — An explicit list of changes in this format Section # (or indicate Global) OLD: old text NEW: new text You do not need to reply with both an updated XML file and an explicit list of changes, as either form is sufficient. We will ask a stream manager to review and approve any changes that seem beyond editorial in nature, e.g., addition of new text, deletion of text, and technical changes. Information about stream managers can be found in the FAQ. Editorial changes do not require approval from a stream manager. Approving for publication -------------------------- To approve your RFC for publication, please reply to this email stating that you approve this RFC for publication. Please use 'REPLY ALL', as all the parties CCed on this message need to see your approval. Files ----- The files are available here: https://www.rfc-editor.org/authors/rfc10034.xml https://www.rfc-editor.org/authors/rfc10034.html https://www.rfc-editor.org/authors/rfc10034.pdf https://www.rfc-editor.org/authors/rfc10034.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc10034-diff.html https://www.rfc-editor.org/authors/rfc10034-rfcdiff.html (side by side) Diff of the XML: https://www.rfc-editor.org/authors/rfc10034-xmldiff1.html Tracking progress ----------------- Details on the status of your Final Review are here: https://queue.rfc-editor.org/final-review/rfc10034/ Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC 10034 (draft-ietf-avtcore-rtp-v3c) Title : RTP Payload Format for Visual Volumetric Video-based Coding (V3C) Author(s) : L. Ilola, L. Kondrad WG Chair(s) : Jonathan Lennox, Marius Kleidl Area Director(s) : Mike Bishop, Gorry Fairhurst -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
