Hi Sandy, Thank you for clarification.
Sincerely, Youngkwon. On Fri, Feb 6, 2026, 11:01 Independent Submissions Editor (Eliot Lear) < [email protected]> wrote: > Hi Youngkwon > > Thanks for that. However, each author should separately review and > approve. > > Regards, > > Eliot > On 06.02.2026 17:43, Youngkwon Lim wrote: > > Dear Sandy, > > We have reviewed the updated document and everything looks good to us. On > behalf of ther authors, I can approve the RFC for publication. Thank you! > > Sincerely, > Youngkwon > > On Fri, Feb 6, 2026, 08:55 Sandy Ginoza <[email protected]> > wrote: > >> Hi Youngkwon, >> >> The document has been updated and the files are available here: >> https://www.rfc-editor.org/authors/rfc9924.xml >> https://www.rfc-editor.org/authors/rfc9924.txt >> https://www.rfc-editor.org/authors/rfc9924.pdf >> https://www.rfc-editor.org/authors/rfc9924.html >> >> >> Diffs of most recent updates only: >> https://www.rfc-editor.org/authors/rfc9924-lastdiff.html >> https://www.rfc-editor.org/authors/rfc9924-lastrfcdiff.html (side by >> side) >> >> >> AUTH48 diffs: >> https://www.rfc-editor.org/authors/rfc9924-auth48diff.html >> https://www.rfc-editor.org/authors/rfc9924-auth48rfcdiff.html (side >> by side) >> >> Comprehensive diffs: >> https://www.rfc-editor.org/authors/rfc9924-diff.html >> https://www.rfc-editor.org/authors/rfc9924-rfcdiff.html (side by side) >> >> >> Please review and let us know if any additional updates are needed or if >> you approve the RFC for publication. >> >> Thank you, >> Sandy Ginoza >> RFC Production Center >> >> >> >> > On Feb 5, 2026, at 8:04 PM, Youngkwon Lim <[email protected]> wrote: >> > >> > Dear Sandy, >> > >> > Thank you for the quick response. We have reviewed the new changes and >> they are all looking good. During the final review, we have identified >> several additional typos. Please see attached file with corrections. >> > >> > Sincerely, >> > Youngkwon >> > >> > On Thu, Feb 5, 2026, 16:04 Sandy Ginoza <[email protected]> >> wrote: >> > Hi Youngkwon, Eliot*, >> > >> > * Eliot - please review the updates and let us know if you have any >> concerns. >> > >> > Youngkwon, thank you for your thorough reply and for updating the XML! >> We made a few additional changes (e.g., removed “version of this document” >> in additional places), so please be sure to review the updates carefully >> and let us know if any further changes are needed. >> > >> > The files here available here: >> > https://www.rfc-editor.org/authors/rfc9924.xml >> > https://www.rfc-editor.org/authors/rfc9924.txt >> > https://www.rfc-editor.org/authors/rfc9924.pdf >> > https://www.rfc-editor.org/authors/rfc9924.html >> > >> > AUTH48 diffs (highlights updates since entering AUTH48): >> > https://www.rfc-editor.org/authors/rfc9924-auth48diff.html >> > https://www.rfc-editor.org/authors/rfc9924-auth48rfcdiff.html (side >> by side) >> > >> > Comprehensive diffs: >> > https://www.rfc-editor.org/authors/rfc9924-diff.html >> > https://www.rfc-editor.org/authors/rfc9924-rfcdiff.html (side by >> side) >> > >> > Thank you, >> > Sandy Ginoza >> > RFC Production Center >> > >> > >> > >> > > On Feb 5, 2026, at 11:18 AM, Youngkwon Lim <[email protected]> >> wrote: >> > > >> > > Dear Sandy, >> > > >> > > I have reviewed your comments. They are really helpful. I have >> disposed all of them. Please see the comments in red below. I have made >> changes to XML file and created PDF and DIFF ast attached so that I can >> review the version after update. >> > > >> > > >> > > >> > > 1) <!-- [rfced] Does "but between transformed values" mean "but with >> > > prediction between transformed values"? Please clarify. >> > > Agree with the suggested text >> > > >> > > Original: >> > > * Intra frame coding without prediction between pixel values but >> > > between transformed values for low delay encoding; >> > > --> >> > > >> > > * Intra frame coding without prediction between pixel values but >> with prediction >> > > between transformed values for low delay encoding; >> > > >> > > >> > > >> > > 2) <!-- [rfced] For clarity, may this text be updated as follows? >> > > >> > > Agree with the suggested text >> > > >> > > Original: >> > > * Multiple decoding and re-encoding without severe visual quality >> > > degradation; and >> > > >> > > --> >> > > >> > > * the ability to decode and re-encode multiple times without >> severe >> > > visual quality degradation; and >> > > >> > > >> > > >> > > 3) <!-- [rfced] We do not believe we see "I" used in this manner, >> though we >> > > do see instances of "i". Please review and let us know if "I" should >> be >> > > removed or if other changes are needed. >> > > >> > > “I” can be removed. “i” in section 3.2.1 and 5.3.7 are array index. >> They can stay unchanged. >> > > >> > > >> > > Original Section 2.2: >> > > * I: intra >> > > >> > > Original Section 3.2.1: >> > > * sum (i=x, y, f(i)) : a summation of f(i) with i taking all >> integer >> > > values from x up to and including y >> > > >> > > Original Section 5.3.7: >> > > The array index i specifies an indicator for the color >> > > component; ... >> > > --> >> > > >> > > >> > > 4) <!-- [rfced] For clarity, may we update the text as follows? If >> this is >> > > incorrect, please clarify what is following widely used industry >> practices. >> > > Or is the exception per widely used industry practices? >> > > The operators in Sections 3.2.1 and 3.2.2 are the exceptions from C >> programming language. Updated text proposed. >> > > >> > > Original: >> > > The operators and the order of precedence are the same as used in >> the >> > > C programming language [ISO9899], with the exception of the >> operators >> > > described in the Section 3.2.1 and Section 3.2.2 following widely >> > > used industry practices for video codecs. >> > > >> > > Perhaps: >> > > Following widely used industry practices for video codecs, the >> operators >> > > and the order of precedence are the same as used in the C >> programming >> > > language [ISO9899], with the exception of the operators described >> in the >> > > Sections 3.2.1 and 3.2.2. >> > > --> >> > > The operators and the order of precedence are the same as used in >> the >> > > C programming language [ISO9899]. However, there are some >> exceptions described in the >> > > Sections 3.2.1 and 3.2.2, which follows widely >> > > >> > > used industry practices for video codecs. >> > > >> > > >> > > 5) <!-- [rfced] Should "square parentheses" be "square brackets"? >> > > In our understanding both square parentheses and square brackets >> refers “[“ and “]”. We can change square parentheses to square brackets. >> > > >> > > >> > > >> > > Original: >> > > Square parentheses are used for the indexing >> > > of arrays. >> > > --> >> > > Square brackets are used for the indexing >> > > of arrays. >> > > >> > > 6) <!-- [rfced] We are having trouble parsing "depending on the Chroma >> > > format sampling structure" - what is depending on that structure? >> > > The values of the variables depends on the chroma format and the >> chroma format is signaled by the syntax element chroma_format_idc. >> > > >> > > >> > > >> > > Original: >> > > The variables SubWidthC, SubHeightC and NumComps are specified in >> > > Table 2, depending on the chroma format sampling structure, which >> is >> > > specified through chroma_format_idc. >> > > >> > > Perhaps: >> > > The variables SubWidthC, SubHeightC, and NumComps are specified in >> > > Table 2, according to the chroma format sampling structure, which >> is >> > > specified through chroma_format_idc. >> > > --> >> > > The values of the variables SubWidthC, SubHeightC and NumComps >> depends on the chroma format sampling structure as specified in >> > > Table 2. The chroma format sampling structure is signaled through >> chroma_format_idc. >> > > >> > > >> > > >> > > 7) <!-- [rfced] Is "1D" needed here, as section 4.4.1 indicates that >> the >> > > zig-zag process converts a 2D array into a 1D array? Simplifying the >> > > sentence improves readability. >> > > >> > > Agree with the suggestion. >> > > >> > > Original: >> > > * The variable forwardScan is derived by invoking zig-zag scan >> order >> > > 1D array initialization process as specified in Section 4.4.1 >> with >> > > input parameters blkWidth and blkHeight. >> > > >> > > Perhaps: >> > > * The variable forwardScan is derived by invoking the zig-zag scan >> > > order process as specified in Section 4.4.1 with >> > > input parameters blkWidth and blkHeight. >> > > --> >> > > >> > > * The variable forwardScan is derived by invoking the zig-zag scan >> > > order initialization process as specified in Section 4.4.1 with >> > > >> > > input parameters blkWidth and blkHeight. >> > > >> > > >> > > >> > > 8) <!-- [rfced] For readability, may we update this sentence as >> follows? >> > > Agree with the suggestion. >> > > >> > > >> > > Original: >> > > The APV bitstream is described in this document using syntax code >> > > based on the C programming language [ISO9899] and uses its if/else, >> > > while, and for keywords as well as functions defined within this >> > > document. >> > > >> > > Perhaps: >> > > The APV bitstream is described using syntax code >> > > based on the C programming language [ISO9899] - including use of >> the >> > > keywords if/else, while, and for - as well as functions defined >> within >> > > this document. >> > > --> >> > > The APV bitstream is described using syntax code >> > > based on the C programming language [ISO9899] - including use of >> the >> > > keywords if/else, while, and for - as well as functions defined >> within >> > > this document. >> > > >> > > 9) <!-- [rfced] Can "of this version of the document" be dropped in >> > > multiple places, since section references are assumed to be in this >> > > document (unless specified otherwise) and because the HTML and PDF >> link to >> > > the relevant sections of the given document? For example: >> > > Agree with the suggestion. It was a kind of habit to mention ‘this >> version’ to make the document future proof. As there will be no versioning >> of RFC, it will be fine to remove such phrase. >> > > >> > > >> > > Original Section 5.3.3: >> > > * reserved_zero_8bits >> > > >> > > MUST be equal to 0 in bitstreams conforming to the profiles >> > > specified in Section 9 of this version of document. Values of >> > > reserved_zero_8bits greater than 0 are reserved for future use. >> > > Decoders conforming to the profiles specified in Section 9 of >> this >> > > version of document MUST ignore PBU with values of >> > > reserved_zero_8bits greater than 0. >> > > --> MUST be equal to 0 in bitstreams conforming to the profiles >> > > specified in Section 9. Values of >> > > >> > > reserved_zero_8bits greater than 0 are reserved for future use. >> > > Decoders conforming to the profiles specified in Section 9 MUST >> ignore PBU with values of >> > > reserved_zero_8bits greater than 0. >> > > >> > > >> > > >> > > Original Section 5.3.5: >> > > * reserved_zero_8bits >> > > >> > > MUST be equal to 0 in bitstreams conforming to the profiles >> > > specified in Section 9 of this version of document. Values of >> > > reserved_zero_8bits greater than 0 are reserved for future use. >> > > Decoders conforming to the profiles specified in Section 9 of >> this >> > > version of document MUST ignore PBU with values of >> > > reserved_zero_8bits greater than 0. >> > > --> >> > > MUST be equal to 0 in bitstreams conforming to the profiles >> > > specified in Section 9. Values of >> > > >> > > reserved_zero_8bits greater than 0 are reserved for future use. >> > > Decoders conforming to the profiles specified in Section 9 MUST >> ignore PBU with values of >> > > reserved_zero_8bits greater than 0. >> > > >> > > 10) <!-- [rfced] We are trying to draw a more clear connection >> between the >> > > text before and after the semicolon. Please consider whether the >> suggested >> > > text conveys the intended meaning. Otherwise, please clarify. >> > > >> > > Note that this text appears multiple times; we will update all >> similar instances based on the outcome of this discussion. >> > > >> > > The sentence tries to say that if i==0 it is Y, if i==1 it is Cb, and >> if i==2 it is Cr. I have proposed revision to make it clearer. >> > > >> > > Original: >> > > The array index i specifies an indicator for the color >> > > component; when chroma_format_idc is equal to 2 or 3, 0 for Y, 1 >> > > for Cb and 2 for Cr. >> > > >> > > Perhaps: >> > > The array index i specifies an indicator for the color >> > > component when chroma_format_idc is equal to 2 or 3, Y is 0, >> > > Cb is 1, and CR is 2. >> > > --> >> > > The array index i specifies an indicator for the color >> > > component; when chroma_format_idc is equal to 2 or 3, the value >> of the index i is equal to 0 for Y component, 1 >> > > >> > > for Cb and 2 for Cr. >> > > >> > > >> > > 11) <!-- [rfced] Please confirm that no additional explanatory text is >> > > needed after Figure 21. >> > > >> > > A sentence describing the basic function of the code can be added. >> > > >> > > --> The tile_data() syntax calculates the location of the macroblocks >> belong to each tile and collect them. >> > > >> > > >> > > >> > > 12) <!-- [rfced] How may we expand "DC"? Differential coding? Will >> it be >> > > understood by readers without expansion? >> > > >> > > In signal processing, DC refers mean value of the waveform. The term >> originally came from direct current. Normally it is not expanded. (DC bias >> - Wikipedia) >> > > >> > > >> > > Original: >> > > * abs_dc_coeff_diff >> > > >> > > specifies the absolute value of the difference between the >> current >> > > DC transform coefficient level and PrevDC. >> > > --> >> > > >> > > >> > > 13) <!-- [rfced] "It is the requirement of bitstream conformance" is >> a bit >> > > awkward to read. Please consider whether the suggested update is >> correct. >> > > Otherwise, please clarify. >> > > >> > > The phrase describes the requirements to the bitstream conforming to >> this document. Please see the revised text below. >> > > >> > > Original: >> > > It is the requirement of bitstream conformance that >> > > the coded tiles of the frame MUST contain tile data for every MB >> > > of the frame, such that the division of the frame into tiles and >> > > the division of the tiles into MBs each forms a partitioning of >> > > the frame. >> > > >> > > Perhaps: >> > > For conforming bitstreams, the coded tiles of the frame MUST >> contain >> > > tile data for every MB >> > > of the frame, such that the division of the frame into tiles and >> > > the division of the tiles into MBs each forms a partitioning of >> > > the frame. >> > > --> >> > > For the bitstreams conforming to this document, the coded tiles >> of the frame MUST contain >> > > tile data for every MB >> > > of the frame, such that the division of the frame into tiles and >> > > the division of the tiles into MBs form a partitioning of >> > > the frame. >> > > >> > > 14) <!-- [rfced] Please clarify "(when chroma_format_idc is equal to >> 2 or >> > > 3, Y, Cb, and Cr)." Perhaps "(when chroma_format_idc is equal to 2 >> or 3, >> > > and Y, Cb, and Cr are specified)"? >> > > >> > > The phrase tries to say that the three components, Y component, Cb >> component and Cr component are reconstructed. Please see the revised text >> below. >> > > >> > > Original: >> > > Outputs of this process are the >> > > reconstructed samples of all the NumComps color components (when >> > > chroma_format_idc is equal to 2 or 3, Y, Cb, and Cr) for the >> current >> > > MB. >> > > >> > > --> >> > > Outputs of this process are the reconstructed samples of all color >> components. The total number of color components is indicated by the value >> of the NumComps for the current MB. For example, when chroma_format_idc is >> equal to 2 or 3, the value of NumComps is equal to 3 and three components, >> Y component, Cb component, and Cr component, are reconstructed >> > > >> > > >> > > Similarly, please let us know how/if mention of Cb and Cr may be >> clarified >> > > here as well? >> > > >> > > Color components are ordered as Y, Cb and Cr. So, the first component >> is Y, the 2nd component is Cb and the 3rd component is Cr. Please see the >> revised text below. >> > > >> > > >> > > Original: >> > > * When chroma_format_idc is not equal to 0, let recSamples[1] be a >> > > (MbWidthC)x(MbHeightC) array of the reconstructed samples of the >> > > second color component (when chroma_format_idc is equal to 2 or >> 3, >> > > Cb). >> > > >> > > --> * When chroma_format_idc is not equal to 0, let recSamples[1] >> be a >> > > >> > > (MbWidthC)x(MbHeightC) array of the reconstructed samples of the >> > > second color component. For example, when chroma_format_idc is >> equal to 2 or 3, >> > > recSamples[1] is Cb component. >> > > >> > > >> > > ... >> > > >> > > * When chroma_format_idc is not equal to 0, let recSamples[2] be a >> > > (MbWidthC)x(MbHeightC) array of the reconstructed samples of the >> > > third color component(when chroma_format_idc is equal to 2 or 3, >> > > Cr). >> > > >> > > >> > > --> >> > > * When chroma_format_idc is not equal to 0, let recSamples[2] be a >> > > (MbWidthC)x(MbHeightC) array of the reconstructed samples of the >> > > third color component. For example, when chroma_format_idc is >> equal to 2 or 3, >> > > recSamples[2] is Cr component. >> > > >> > > >> > > >> > > 15) <!-- [rfced] Section 6.2: Is there text missing after these >> bullets? >> > > Nothing appears after "the following applies." Also, the formatting >> here >> > > looks odd. Please review and let us know how the text may be updated. >> > > I have corrected nesting order and indentations of the section 6.2. >> > > >> > > * For yIdx = 0..numBlkY - 1, the following applies: >> > > >> > > o For xIdx = 0..numBlkX - 1, the following applies: >> > > --> >> > > >> > > >> > > 16) <!-- [rfced] Should the last 3 bulleted items be regular text >> (i.e., >> > > not part of the bulleted list)? >> > > I have corrected nesting order and indentations of the section >> 6.3.2.2. >> > > >> > > >> > > >> > > 6.3.2.2. Transformation process >> > > >> > > Inputs to this process are: >> > > >> > > * a variable nTbS specifying the sample size of scaled transform >> > > coefficients, and >> > > >> > > * a list of scaled transform coefficients x with elements x[j], >> with >> > > j = 0..(nTbS - 1). >> > > >> > > * Output of this process is the list of transformed samples y with >> > > elements y[i], with i = 0..(nTbS - 1). >> > > >> > > * The transformation matrix derivation process as specified in >> > > Section 6.3.2.3. invoked with the transform size nTbS as input, >> > > and the transformation matrix transMatrix as output. >> > > >> > > * The list of transformed samples y[i] with i = 0..(nTbS - 1) is >> > > derived as follows: >> > > >> > > y[i] = sum(j = 0, nTbS - 1, transMatrix[i][j] * x[j]) >> > > --> >> > > >> > > >> > > 17) <!-- [rfced] Please confirm that no additional explanatory text is >> > > needed after Figure 28. --> >> > > >> > > added one sentence. >> > > >> > > 18) <!-- [rfced] Will readers be familiar with CIE 1931? Please >> consider >> > > whether a reference should be added. Note that "CIE 1931" is >> mentioned 4 >> > > times. If you would like to add a reference, please provide the >> reference >> > > entry. >> > > >> > > Added the reference to ISO specification specifying CIE 1931. >> > > >> > > >> > > Original: >> > > * primary_chromaticity_x[i] >> > > >> > > specifies a 0.16 fixed-point format of X chromaticity coordinate >> > > of mastering display as defined by CIE 1931, where i = 0, 1, 2 >> > > specifies Red, Green, Blue respectively. >> > > --> >> > > >> > > >> > > 19) <!-- [rfced] Please note that we expanded UUID as "Universally >> Unique >> > > Identifier." Please let us know if any corrections are needed. >> > > OK >> > > >> > > Original: >> > > * uuid >> > > >> > > MUST be a 128-bit value specified as a generated UUID according >> to >> > > the procedures specified in [RFC9562]. >> > > --> >> > > >> > > >> > > 20) <!-- [rfced] We are having trouble parsing this sentence. >> Perhaps "to >> > > specifically create different sets of constraints" is intended? >> > > >> > > sentence corrected. >> > > >> > > >> > > >> > > Original: >> > > For example, a certain level L and a certain band >> > > B can be combined with either profile X or profile Y to >> specifically >> > > different set of constraints. >> > > --> >> > > For example, a certain level L and a certain band B can be combined >> with either profile X or profile Y to specifically define two different set >> of constraints. >> > > >> > > 21) <!-- [rfced] This sentence appears many times in this document. >> May we >> > > update it as follows? >> > > >> > > Updated with new sentence. >> > > >> > > >> > > Original: >> > > Any levels and bands constraints specified in Section 9.4 MUST be >> > > fulfilled. >> > > >> > > Perhaps: >> > > Any levels and bands MUST adhere to the constraints specified in >> > > Section 9.4. >> > > --> >> > > Coded frames conforming to the 422-10 profile <bcp14>MUST</bcp14> >> also conform to any levels and bands constraints specified in Section 9.4. >> > > >> > > >> > > 22) <!-- [rfced] Is "level B" correct, as opposed to "band B"? Note >> that >> > > "level B" appears multiple times. >> > > >> > > Yes, it must be “band B” I have changed all. >> > > >> > > >> > > * The coded frame is indicated to conform to a band (by a specific >> > > value of band_idc) that is lower than or equal to level B. >> > > --> >> > > >> > > >> > > 23) <!-- [rfced] We have updated the format of the header row of >> table 4 so >> > > it fits within the line-length limitiation. Please review carefully >> and >> > > let us know if and adjustments are needed or if you have other >> suggestions >> > > for how it can be rendered. >> > > --> >> > > OK >> > > >> > > >> > > 24) <!-- [rfced] "no read" can be difficult to parse. Perhaps this >> can be >> > > reworded? >> > > >> > > Original: >> > > The implementation MUST ensure that no read outside >> > > allocated and initialized memory occurs. >> > > >> > > A is OK. >> > > >> > > >> > > Perhaps A: >> > > The implementation MUST ensure that any data outside >> > > of the allocated and initialized memory cannot be read. >> > > >> > > Perhaps B: >> > > The implementation MUST ensure that there is no >> > > data outside of the allocated and initialized memory. >> > > --> >> > > >> > > >> > > 25) <!-- [rfced] [ISO9899] Please review. >> > > This reference currently points to a withdrawn version of ISO/IEC >> 9899: >> > > https://www.iso.org/standard/74528.html. >> > > The most current version of this reference is ISO/IEC 9899:2024. >> > > >> > > Should this reference be updated to point to the most current version? >> > > >> > > YES! >> > > >> > > >> > > Current: >> > > [ISO9899] ISO/IEC, "Information technology - Programming >> languages - >> > > C", ISO/IEC 9899:2018, 2018, >> > > <https://www.iso.org/standard/74528.html>. >> > > --> >> > > >> > > >> > > 26) <!-- [rfced] [CEA-861.3] Please review. >> > > CEA-861.3 appears to have been placed in "Historical" status (see: >> > > https://webstore.ansi.org/standards/cea/cea8612015-1528168). The most >> > > current version of this standard appears to be CTA-861.3-A (see: >> > > https://www.cta.tech/standards/cta-8613-a/). Note that the Consumer >> > > Electronics Association (CEA) changed its name to the "Consumer >> > > Technology Association" (CTA) in 2015. >> > > >> > > Should this reference be updated to point to CTA-861.3-A? >> > > >> > > agree with the update. >> > > >> > > >> > > Current: >> > > [CEA-861.3] >> > > CEA, "CEA-861.3, HDR Static Metadata Extension", January >> > > 2015. >> > > --> >> > > >> > > >> > > 27) <!-- [rfced] Please review whether any of the notes in this >> document >> > > 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). >> > > --> >> > > NOTES are used to provide additional information for the readers. We >> don’t think the definition of <aside> matches with the intention. Please >> keep them as the notes. >> > > >> > > 28) <!-- [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. >> > > --> >> > > We have found none. >> > > >> > > In addition to the changes according to your comments, I have also >> updated two references. >> > > >> > > OLD >> > > >> > > [FFmpegAPVdec] >> > > "FFmpeg implementation of APV decoder", 19 April 2025, >> > > <https://git.ffmpeg.org/gitweb/ffmpeg.git/ >> > > commit/483cadf8d77d3260eec8781f5f18c50f27e468f8>. >> > > >> > > [FFmpegAPVenc] >> > > "FFmpeg implementation of APV encoder", 23 April 2025, >> > > <https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/ >> > > fab691edaf53bbf10429ef3448f1f274e5078395>. >> > > >> > > >> > > >> > > NEW >> > > >> > > [FFmpegAPVdec] >> > > "FFmpeg implementation of APV decoder" , 20 November 2025, >> > > <https:// >> > > ffmpeg.org/download.html#release_8.0> >> > > . >> > > [FFmpegAPVenc] >> > > "FFmpeg implementation of APV encoder" , 4 May 2025, >> > > <https:// >> > > git.ffmpeg.org/gitweb/ffmpeg.git/commit/ >> fab691edaf53bbf10429ef3448f1f274e5078395> >> > > >> > > Please let us know if you have any further questions or comments. >> > > >> > > >> > > Sincerely, >> > > Youngkwon >> > > >> > > >> > > On Wed, Feb 4, 2026, 13:47 Sandy Ginoza <[email protected]> >> wrote: >> > > Hi Youngkwon, >> > > >> > > Thank you for your reply. We will wait to hear from you. >> > > >> > > Thank you, >> > > Sandy Ginoza >> > > RFC Production Center >> > > >> > > >> > > >> > > > On Feb 4, 2026, at 10:12 AM, Youngkwon Lim <[email protected]> >> wrote: >> > > > >> > > > Dear Sandy, >> > > > >> > > > Thank you for the notes. I have received your email yesterday. I'm >> reviewing the comments. I'll be able to send you the answers probably by >> tomorrow. >> > > > >> > > > Sincerely, >> > > > Youngkwon. >> > > > >> > > > On Wed, Feb 4, 2026, 12:10 Sandy Ginoza < >> [email protected]> wrote: >> > > > Hi Youngkwon, >> > > > >> > > > We understand that you would like to publish this document as >> quickly as possible. This document was moved to AUTH48 (see >> https://mailarchive.ietf.org/arch/msg/auth48archive/gLcjKw1Lm4JZQefWIc2249CjaA0/). >> Please follow the instructions to ensure timely publication. >> > > > >> > > > In addition, please reply to the questions in our followup mail >> (see >> > > > >> https://mailarchive.ietf.org/arch/msg/auth48archive/2RYT4cM76OIcNmJl9PU5KFcBOqA/). >> Note that the RFC will not be published until the questions have been >> resolved and each of the authors has indicated that they have reviewed the >> document and approve it for publication. >> > > > >> > > > Please let us know if you have any questions. >> > > > >> > > > Thank you, >> > > > Sandy Ginoza >> > > > RFC Production Center >> > > > >> > > > >> > > > >> > > > > On Feb 1, 2026, at 10:59 AM, Youngkwon Lim <[email protected]> >> wrote: >> > > > > >> > > > > Dear Eliot, >> > > > > >> > > > > We fully understand and appreciate the efforts by the RPC and the >> reviewers including you. I absolutely agree with you that the quality of >> the work shouldn't be compromised for any reason. We, the authors, just >> don't want miss the opportunity to be part of the big events by a small >> delay which will also be an opportunity to express our thanks to the RPC as >> well. >> > > > > >> > > > > Sincerely, >> > > > > Youngkwon >> > > > > >> > > > > >> > > > > On Sun, Feb 1, 2026, 12:49 Independent Submissions Editor (Eliot >> Lear) <[email protected]> wrote: >> > > > > Hi! >> > > > > I want to make clear that publication of RFCs is not for >> marketing events. The RPC will have worked quite hard to ensure the best >> quality version of your work. For that to happen they MUST NOT be rushed. >> > > > > Eliot >> > > > > On 30.01.2026 20:42, Sarah Tarrant wrote: >> > > > >> Hi Youngkwon, >> > > > >> >> > > > >> We can do our best to get this to AUTH48 earlier next week. And >> from there, the best support you can give us to expedite the AUTH48 process >> is to send updates and approvals once you get that AUTH48 email. >> > > > >> >> > > > >> Sincerely, >> > > > >> Sarah Tarrant >> > > > >> RFC Production Center >> > > > >> >> > > > >> >> > > > >>> On Jan 30, 2026, at 1:06 PM, Youngkwon Lim <[email protected]> >> wrote: >> > > > >>> >> > > > >>> Dear Sarah, >> > > > >>> >> > > > >>> Thank you for checking. Would it be possible to make it happen >> by the next week? We are working on a big event regarding APV in general. I >> don't want to miss the opportunity to be part of it due to just a week >> delay. It will be really appreciated if you can consider the situation. >> Please let me know if you need any support from us to expedite the process. >> > > > >>> >> > > > >>> Sincerely, >> > > > >>> Youngkwon >> > > > >>> >> > > > >>> On Fri, Jan 30, 2026, 13:01 Sarah Tarrant < >> [email protected]> wrote: >> > > > >>> Hi Youngkwon, >> > > > >>> >> > > > >>> Thank you for checking in! Now, it looks like this draft should >> move to AUTH48 in the next 1 or 2 weeks. >> > > > >>> >> > > > >>> Sincerely, >> > > > >>> Sarah Tarrant >> > > > >>> RFC Production Center >> > > > >>> >> > > > >>> >> > > > >>>> On Jan 30, 2026, at 11:22 AM, Youngkwon Lim < >> [email protected]> wrote: >> > > > >>>> >> > > > >>>> Dear Sarah, >> > > > >>>> >> > > > >>>> As today is the last working day of the January, I'm just >> touching base with you again if there has been any update on the progress >> of the production. Thank you! >> > > > >>>> >> > > > >>>> Sincerely, >> > > > >>>> Youngkwon. >> > > > >>>> >> > > > >>>> >> > > > >>>> On Fri, Jan 9, 2026, 14:00 Sarah Tarrant < >> [email protected]> wrote: >> > > > >>>> Hi Youngkwon, >> > > > >>>> >> > > > >>>> Happy New Year to you as well! >> > > > >>>> >> > > > >>>> It's still looking like your draft should enter AUTH48 closer >> to the end of January 2026. >> > > > >>>> >> > > > >>>> Sincerely, >> > > > >>>> Sarah Tarrant >> > > > >>>> RFC Production Center >> > > > >>>> >> > > > >>>> >> > > > >>>>> On Jan 8, 2026, at 1:37 PM, Youngkwon Lim <[email protected]> >> wrote: >> > > > >>>>> >> > > > >>>>> Dear Sarah, >> > > > >>>>> >> > > > >>>>> Happy New Year! >> > > > >>>>> >> > > > >>>>> I hope you have a enjoyable holiday season and started a >> great new year. >> > > > >>>>> >> > > > >>>>> I just wanted to touch base with you about the progress of >> the edit and see if you have more visibility about the dates for the next >> step. >> > > > >>>>> >> > > > >>>>> Sincerely, >> > > > >>>>> Youngkwon Lim >> > > > >>>>> >> > > > >>>>> >> > > > >>>>> >> > > > >>>>> On Thu, Oct 23, 2025, 11:52 Sarah Tarrant < >> [email protected]> wrote: >> > > > >>>>> Hi Young, >> > > > >>>>> >> > > > >>>>> Based on the current processing time, it looks like >> draft-lim-apv-09 would enter AUTH48 in January, after the holiday season. >> > > > >>>>> >> > > > >>>>> Sincerely, >> > > > >>>>> Sarah Tarrant >> > > > >>>>> RFC Production Center >> > > > >>>>> >> > > > >>>>> >> > > > >>>>>> On Oct 22, 2025, at 8:32 AM, Youngkwon Lim < >> [email protected]> wrote: >> > > > >>>>>> >> > > > >>>>>> Thank you for the confirmation. BTW, do you have any time >> frame expected about AUTH48 in this case you can guess? Just in case, as we >> are approaching holiday season. >> > > > >>>>>> >> > > > >>>>>> Sincerely, >> > > > >>>>>> Young. >> > > > >>>>>> >> > > > >>>>>> On Wed, Oct 22, 2025, 07:49 Sarah Tarrant < >> [email protected]> wrote: >> > > > >>>>>> Hi Young, >> > > > >>>>>> >> > > > >>>>>> Thank you for your reply. We will reach out if we need >> further clarification on anything during the editing process. >> > > > >>>>>> >> > > > >>>>>> Sincerely, >> > > > >>>>>> Sarah Tarrant >> > > > >>>>>> RFC Production Center >> > > > >>>>>> >> > > > >>>>>> >> > > > >>>>>>> On Oct 21, 2025, at 7:43 PM, Youngkwon Lim < >> [email protected]> wrote: >> > > > >>>>>>> >> > > > >>>>>>> Dear the RPC Team, >> > > > >>>>>>> >> > > > >>>>>>> We are really excited that the draft has reached this step >> and ready for production. >> > > > >>>>>>> >> > > > >>>>>>> We have reviewed the questions in your email and can >> confirm that no updates are required and there are no special request to >> make. You can process the 09 version of the draft as it is. >> > > > >>>>>>> >> > > > >>>>>>> We are really grateful to the shepherd who has reviewed the >> draft many times thoroughly and provide us many good comments. We will be >> happy to work with you to move forward this draft to the final publication. >> Please feel free to reach out to us if there are any questions or request >> to us. Thank you! >> > > > >>>>>>> >> > > > >>>>>>> Sincerely, >> > > > >>>>>>> Young >> > > > >>>>>>> >> > > > >>>>>>> >> > > > >>>>>>> >> > > > >>>>>>> ------ Original Message ------ >> > > > >>>>>>> >From "Sarah Tarrant" <[email protected]> >> > > > >>>>>>> To [email protected]; [email protected]; >> [email protected]; [email protected]; [email protected] >> > > > >>>>>>> Cc [email protected]; [email protected]; >> [email protected] >> > > > >>>>>>> Date 10/21/2025 4:42:46 PM >> > > > >>>>>>> Subject Document intake questions about <draft-lim-apv-09> >> > > > >>>>>>> >> > > > >>>>>>> >> > > > >>>>>>>> Author(s), >> > > > >>>>>>>> Congratulations, your document has been successfully added >> to the RFC Editor queue! >> > > > >>>>>>>> The team at the RFC Production Center (RPC) is looking >> forward to working with you >> > > > >>>>>>>> as your document moves forward toward publication. To help >> reduce processing time >> > > > >>>>>>>> and improve editing accuracy, please respond to the >> questions below. Please confer >> > > > >>>>>>>> with your coauthors (or authors of other documents if your >> document is in a >> > > > >>>>>>>> cluster) as necessary prior to taking action in order to >> streamline communication. >> > > > >>>>>>>> If your document has multiple authors, only one author >> needs to reply to this >> > > > >>>>>>>> message. >> > > > >>>>>>>> As you read through the rest of this email: >> > > > >>>>>>>> * If you need/want to make updates to your document, we >> encourage you to make those >> > > > >>>>>>>> changes and resubmit to the Datatracker. This allows for >> the easy creation of diffs, >> > > > >>>>>>>> which facilitates review by interested parties (e.g., >> authors, ADs, doc shepherds). >> > > > >>>>>>>> * If you feel no updates to the document are necessary, >> please reply with any >> > > > >>>>>>>> applicable rationale/comments. >> > > > >>>>>>>> Please note that the RPC team will not work on your >> document until we hear from you >> > > > >>>>>>>> (that is, your document will remain in AUTH state until we >> receive a reply). Even >> > > > >>>>>>>> if you don't have guidance or don't feel that you need to >> make any updates to the >> > > > >>>>>>>> document, you need to let us know. After we hear from you, >> your document will start >> > > > >>>>>>>> moving through the queue. You will be able to review and >> approve our updates >> > > > >>>>>>>> during AUTH48. >> > > > >>>>>>>> Please feel free to contact us with any questions you may >> have at >> > > > >>>>>>>> [email protected]. >> > > > >>>>>>>> Thank you! >> > > > >>>>>>>> The RPC Team >> > > > >>>>>>>> -- >> > > > >>>>>>>> 1) As there may have been multiple updates made to the >> document during Last Call, >> > > > >>>>>>>> please review the current version of the document: >> > > > >>>>>>>> * Is the text in the Abstract still accurate? >> > > > >>>>>>>> * Are the Authors' Addresses, Contributors, and >> Acknowledgments >> > > > >>>>>>>> sections current? >> > > > >>>>>>>> 2) Please share any style information that could help us >> with editing your >> > > > >>>>>>>> document. For example: >> > > > >>>>>>>> * Is your document's format or its terminology based on >> another document? >> > > > >>>>>>>> If so, please provide a pointer to that document (e.g., >> this document's >> > > > >>>>>>>> terminology should match DNS terminology in RFC 9499). >> > > > >>>>>>>> * Is there a pattern of capitalization or formatting of >> terms? (e.g., field names >> > > > >>>>>>>> should have initial capitalization; parameter names should >> be in double quotes; >> > > > >>>>>>>> <tt/> should be used for token names; etc.) >> > > > >>>>>>>> 3) Please review the entries in the References section >> carefully with >> > > > >>>>>>>> the following in mind. Note that we will update as follows >> unless we >> > > > >>>>>>>> hear otherwise at this time: >> > > > >>>>>>>> * References to obsoleted RFCs will be updated to point to >> the current >> > > > >>>>>>>> RFC on the topic in accordance with Section 4.8.6 of RFC >> 7322 >> > > > >>>>>>>> (RFC Style Guide). >> > > > >>>>>>>> * References to I-Ds that have been replaced by another >> I-D will be >> > > > >>>>>>>> updated to point to the replacement I-D. >> > > > >>>>>>>> * References to documents from other organizations that >> have been >> > > > >>>>>>>> superseded will be updated to their superseding version. >> > > > >>>>>>>> Note: To check for outdated RFC and I-D references, you >> can use >> > > > >>>>>>>> idnits <https://author-tools.ietf.org/idnits>. You can >> also help the >> > > > >>>>>>>> IETF Tools Team by testing idnits3 < >> https://author-tools.ietf.org/idnits3/> >> > > > >>>>>>>> with your document and reporting any issues to them. >> > > > >>>>>>>> 4) Is there any text that should be handled extra >> cautiously? For example, are >> > > > >>>>>>>> there any sections that were contentious when the document >> was drafted? >> > > > >>>>>>>> 5) Is there anything else that the RPC should be aware of >> while editing this >> > > > >>>>>>>> document? >> > > > >>>>>>>> 6) Would you like to participate in the RPC Pilot Test for >> editing in kramdown-rfc? >> > > > >>>>>>>> If so, please let us know and provide a self-contained >> kramdown-rfc file. For more >> > > > >>>>>>>> information about this experiment, see: >> > > > >>>>>>>> >> https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc. >> > > > >>>>>>>> >> > > > >>>>>>>> >> > > > >>>>>>>>> On Oct 21, 2025, at 4:39 PM, [email protected] >> wrote: >> > > > >>>>>>>>> Author(s), >> > > > >>>>>>>>> Your document draft-lim-apv-09, which has been approved >> for publication as >> > > > >>>>>>>>> an RFC, has been added to the RFC Editor queue >> > > > >>>>>>>>> <https://www.rfc-editor.org/current_queue.php>. >> > > > >>>>>>>>> If your XML file was submitted using the I-D submission >> tool >> > > > >>>>>>>>> <https://datatracker.ietf.org/submit/>, we have already >> retrieved it >> > > > >>>>>>>>> and have started working on it. >> > > > >>>>>>>>> If you did not submit the file via the I-D submission >> tool, or >> > > > >>>>>>>>> if you have an updated version (e.g., updated contact >> information), >> > > > >>>>>>>>> please send us the file at this time by attaching it >> > > > >>>>>>>>> in your reply to this message and specifying any >> differences >> > > > >>>>>>>>> between the approved I-D and the file that you are >> providing. >> > > > >>>>>>>>> You will receive a separate message from us asking for >> style input. >> > > > >>>>>>>>> Please respond to that message. When we have received >> your response, >> > > > >>>>>>>>> your document will then move through the queue. The first >> step that >> > > > >>>>>>>>> we take as your document moves through the queue is >> converting it to >> > > > >>>>>>>>> RFCXML (if it is not already in RFCXML) and applying the >> formatting >> > > > >>>>>>>>> steps listed at < >> https://www.rfc-editor.org/pubprocess/how-we-update/>. >> > > > >>>>>>>>> Next, we will edit for clarity and apply the style guide >> > > > >>>>>>>>> (<https://www.rfc-editor.org/styleguide/>). >> > > > >>>>>>>>> You can check the status of your document at >> > > > >>>>>>>>> <https://www.rfc-editor.org/current_queue.php>. >> > > > >>>>>>>>> You will receive automatic notifications as your document >> changes >> > > > >>>>>>>>> queue state (for more information about these states, >> please see >> > > > >>>>>>>>> <https://www.rfc-editor.org/about/queue/>). When we have >> completed >> > > > >>>>>>>>> our edits, we will move your document to AUTH48 state and >> ask you >> > > > >>>>>>>>> to perform a final review of the document. >> > > > >>>>>>>>> Please let us know if you have any questions. >> > > > >>>>>>>>> Thank you. >> > > > >>>>>>>>> The RFC Editor Team >> > > > >>>>>>>>> >> > > > >>>>>> >> > > > >>>>> >> > > > >>>> >> > > > >>> >> > > > >> >> > > > >> > > >> > >> > >> <rfc9924_0205.diff.html><rfc9924_0205_authors.xml><rfc9924_0205_authors.pdf> >> >>
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
