Dear All,, I confirm that the feedback provided by Lauri reflects my comments as well. I also believe that the document is ready for publication.
Br, Lukasz From: Lauri Ilola (Nokia) <[email protected]> Date: Wednesday, 12. August 2026 at 13:35 To: [email protected] <[email protected]>; Lukasz Kondrad (Nokia) <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: RE: Final Review: RFC-to-be 10034 (draft-ietf-avtcore-rtp-v3c) in XML Dear all, We've gone through the comments and suggestions among the authors. Please see attached the xml-file which contains our responses to the comments as well as the resulting updates. Please let us know, if you have any further questions or suggestions. I believe all the edits are purely editorial in nature improving the readability of the draft. For convenience, I've also copied our comments below as text. If there are no further questions or comments, the document is from my part at least ready for publication. Kind Regards and thank you for the editorial work! -Lauri -----Original Message----- From: [email protected] <[email protected]> Sent: Tuesday, August 11, 2026 2:15 AM To: Lauri Ilola (Nokia) <[email protected]>; Lukasz Kondrad (Nokia) <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: Final Review: RFC-to-be 10034 (draft-ietf-avtcore-rtp-v3c) in XML CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. 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. --> <!-- [authors] Done. --> 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). --> <!-- [authors] Agree with the proposal. Updated. --> 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: --> <!-- [authors] Agree with the proposal a) and b). This has been implemented in the draft. --> 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 --> <!-- [authors] Agree with the proposal, except the DONL definition. Definition of DONL updated below. --> 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. --> <!-- [authors] Our preference would be using singular definitions A) and C). These are updated below. --> 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? --> <!-- [authors]: The lengths of the V3C units are not aligned between V3C components, so misalignment in the table is ok. Having said that, it seems there is a missing empty space in front of the "V3C Unit(V3C_OVD)", fixing it would not fix the alignment for the rest of the row though. Here are the updated graphics anyway. --> 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. --> <!-- [authors]: We would prefer the following definition, which is perhaps the most unambiguous.--> 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). --> <!-- [authors] We've moved all informative notes into the <aside> elements. These are just notes after all. We've also clarified the informative nature of the second note below. --> 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. --> <!-- [authors]: It felt repetitive to capitalize both instances of "must not" considering that the second instance was simply clarifying the first instance. However, We are happy to capitalize both instances as recommended. The intention is to forbid any nesting of FUs, be it another complete FU or a portion of another FU. We would therefore prefer the "Current" wording. --> 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. --> <!-- [authors] Please keep the current wording as it is aligned with similar text in other RFCs. --> 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? --> <!-- [authors] a) We reviewed all <artwork> and <sourcecode> elements. We also considered the type attribute for the <sourcecode> elements. These look ok to us. b) Yes, definition lists are sure better for readability. We've taken the liberty to implement the change. --> 12) <!--[rfced] FYI: For consistency, we updated "ssprop-v3c-sei" to "sprop-v3c-sei" in Table 2. Please let us know of any objections. --> <!-- [authors] This was a good catch. Thank you. -- 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. --> <!-- [authors] The plural is indeed more accurate. Updated. --> 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. --> <!-- [authors] The proposal sounds good to me. Updated.--> 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]. --> <!-- [authors] The proposal sounds reasonable, We've implemented the change. Also added the normative reference for ABNF grammar. --> 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. --> <!-- [authors] We should have had a generic citation to BCP 195, it was not intention to limit only to RF9325. We've updated to refer to BCP 195 directly. --> 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>. --> <!-- [authors] Yes, a) c) d) can be updated as proposed. We've updated them now. We noticed that the there is a 2026 version available for b), which would be better to use. --> 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 --> <!-- [authors] This sounds reasonable. We've updated the document to 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? --> <!-- [authors] This has been now updated in the Abbreviations. DONL: decoding order number least significant bits --> 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. --> <!-- [authors] We've familiarized ourselves with the suggestions. --> 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]
