Hi Gorry, Thanks for the quick reply! We’ve noted your approval here: https://queue.rfc-editor.org/final-review/rfc10034/.
Now that we’ve received all necessary approvals, we will send updates along to IANA. Thank you! Madison Church RFC Production Center > On Aug 19, 2026, at 9:40 AM, Gorry Fairhurst <[email protected]> wrote: > > On 19/08/2026 15:19, Madison Church wrote: >> Hi Gorry, >> >> This is a friendly weekly reminder that we await your approval as >> responsible AD for the two changes listed in this thread. Once we receive >> your approval, we will contact IANA for registry updates before moving >> forward with publication of this document. >> >> Thank you! >> Madison Church >> RFC Production Center > > This is approved, thank you. > > Gorry > > (Responsible AD) > >> >>> On Aug 12, 2026, at 10:04 AM, Madison Church <[email protected]> >>> wrote: >>> >>> Hi *Gorry, Lauri, Lukasz, >>> >>> *Gorry - Please review and approve the following changes as responsible AD >>> for this document: >>> >>> 1) Updated use of <bcp14> tags. >>> >>> 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. >>> >>> 2) Addition of RFC 5234 to the Normative References section. >>> >>> Lauri, Lukasz - Thank you both for your quick replies/approvals and for >>> sending along an updated XML file. It made the Final Review process much >>> easier on our end! We have updated the document accordingly and have no >>> followup items to address. Your approvals have been noted here: >>> https://queue.rfc-editor.org/final-review/rfc10034/. >>> >>> The files have been posted here (please refresh): >>> https://www.rfc-editor.org/authors/rfc10034.txt >>> https://www.rfc-editor.org/authors/rfc10034.pdf >>> https://www.rfc-editor.org/authors/rfc10034.html >>> https://www.rfc-editor.org/authors/rfc10034.xml >>> >>> Updated diff files: >>> https://www.rfc-editor.org/authors/rfc10034-diff.html >>> https://www.rfc-editor.org/authors/rfc10034-rfcdiff.html (side by side) >>> https://www.rfc-editor.org/authors/rfc10034-auth48diff.html >>> https://www.rfc-editor.org/authors/rfc10034-auth48rfcdiff.html (side by >>> side) >>> >>> Once we receive Gorry’s approval as AD for the changes listed above, we >>> will contact IANA for registry updates before moving forward with >>> publication. >>> >>> Thank you! >>> Madison Church >>> RFC Production Center >>> >>>> On Aug 12, 2026, at 6:44 AM, Lukasz Kondrad (Nokia) >>>> <[email protected]> wrote: >>>> >>>> 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]
