Hi IANA, Please make the following changes to match the updated document:
1) Update the registration for "v3c" in the "Media Types” registry to match the updated registry in Section 10.1 (https://www.iana.org/assignments/media-types/application/v3c). These changes are best viewed in this diff file: https://auth48-transition.rfc-editor.org/authors/rfc10034-diff.html. 2) Update the registration in the "Semantics for the 'group' SDP Attribute” registry to match the edited registry in Section 10.2 (https://www.iana.org/assignments/sdp-parameters#sdp-att-field). These changes are best viewed in this diff file: https://auth48-transition.rfc-editor.org/authors/rfc10034-diff.html. Thank you! Madison Church RFC Production Center > On Aug 19, 2026, at 10:13 AM, Madison Church <[email protected]> > wrote: > > 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]
