Dear Sandy, I have reviewed the latest updated document and it looks good to me. I can also approve the RFC for publication. Thanks a lot!
Best regards, Kwang Pyo Choi 2026년 2월 7일 (토) AM 2:07, Youngkwon Lim <[email protected]>님이 작성: > 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]
