Great! Thank you. Sincerely, Young
On Tue, Feb 10, 2026, 10:29 Sandy Ginoza <[email protected]> wrote: > Greetings all, > > Thank you for your review and prompt responses. We have received all of > the needed approvals and will continue with publication at this time. > > Thanks, > Sandy Ginoza > RFC Production Center > > > > > On Feb 8, 2026, at 2:14 PM, Youngkwon Lim <[email protected]> wrote: > > > > I think we've got all authors confirmed. > > > > Sincerely, > > Youngkwon. > > > > On Fri, Feb 6, 2026, 11:07 Youngkwon Lim <[email protected]> wrote: > > 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]
