Sorry for the delayed response. Looks good to me overall, I found one nit in the text for "Figure 1":
"Figure 1: General RTP Payload Format for VP" Just missing the "9". /Stefan On Fri, Feb 14, 2025 at 5:45 PM Zaheduzzaman Sarker < zahed.sarker.i...@gmail.com> wrote: > > > On Fri, Feb 7, 2025 at 9:21 PM Jonathan Lennox <jonathan.len...@8x8.com> > wrote: > >> >> >> On Oct 10, 2024, at 6:28 AM, Zaheduzzaman Sarker < >> zahed.sarker.i...@gmail.com> wrote: >> >> >> >> On Mon, Oct 7, 2024 at 8:35 PM Megan Ferguson <mfergu...@amsl.com> wrote: >> >>> Zahed, >>> >>> Thank you for your reply and guidance. >>> >>> It looks like we note that questions 10, 19, and 21F could also benefit >>> from AD approval/guidance on the AUTH48 status page - and we’ve thrown in >>> question 11 in case you had thoughts (questions and previous replies copied >>> below for your convenience): >>> >>> >>> >> 10) <!--[rfced] If TID expands to "temporal layer ID", does this text >>> say >>> >> "with TID equal to TID"? Please clarify (and see our related >>> cluster-wide question). >>> >> >>> >> Original: >>> >> If this bit is set to 1 for the current picture with temporal layer ID >>> >> equal to TID... >>> >> >>> >> --> >>> > >>> > Yes, that’s poorly worded, but I’m having some trouble expressing it >>> clearly. >>> > >>> > The sentence is trying to talk about a specific frame’s value of SID, >>> so that it can talk about that value later in the sentence. >>> > >>> > Possibly change the variable to “T”, as in: >>> > >>> > Switching up point. If this bit is set to 1 for the current picture >>> with a temporal-layer ID equal to T, then "switch up" to a higher frame >>> rate is possible as subsequent higher temporal-layer pictures will not >>> depend on any picture before the current picture (in coding order) with >>> temporal-layer ID greater than T.¶ >>> > >>> > >>> > The point is that when the bit is set, then if the current frame has a >>> temporal-layer ID value X, then subsequent frames with TID>X will not >>> depend on earlier frames with TID>X. >>> > >>> > Can you help me come up with a clearer way to express this? >>> >>> Perhaps: >>> Switching up point. When this bit is set to 1, if the current picture >>> has a temporal-layer ID equal to value T, then subsequent pictures with >>> temporal-layer ID values higher than T will not depend on any picture >>> before the current picture (in coding order) with a temporal-layer ID value >>> greater than T. >>> >> >> This should be OK. However, as we are introducing a new variable, I would >> like the authors to ping the working group to see if there could be any >> issues with that or not. Authors please send an email to the mailing list >> regarding this proposal. >> >> >> This isn’t a new variable semantically, it’s just naming a nonce value to >> express the existing concept more clearly. Do you really think it needs WG >> approval? >> > > It's not a MUST, but I would be good to inform the wg about this change. > > >> >> >> >> 11) <!--[rfced] We note that not all fields that appear in Figure 4 are >>> >> described following it. Please review and let us know if text >>> >> (or a pointer to where the reader can get more information on >>> >> these fields) should be added. >>> >> >>> >> --> >>> > >>> > R is only specified in the diagram - it is the number of P_DIFF fields >>> that are present. (I agree this is not great.) TID, U, and P_DIFF have the >>> same semantics as they do in the previous section, except that they apply >>> to the picture described in the picture group, rather than the current >>> picture. >>> >>> -Regarding question 11, please provide any updates you would like us to >>> make to add description or pointers to descriptions for the items in the >>> figure. >>> >> >> I will wait for the authors to respond to it. I noted that here we use >> TID, this should be changed to T according to the previous change, right? >> >> >> Agreed, these two descriptions should be parallel. >> >> >> >>> >> 19) <!--[rfced] Please review the entry for "Change Controller" in >>> Section >>> >> 7. While we see similar text for the vp8 and vc2 entries, we want >>> to >>> >> confirm that this entry has been reviewed with the following in >>> >> mind from >>> >> https://www.iana.org/help/protocol-registration: >>> >> >>> >> "The IESG shouldn't be listed as a change controller unless the >>> >> RFC that created the registry (e.g. port numbers, XML namespaces >>> >> and schemas) requires it. The IETF should be named instead." >>> >> >>> >> --> >>> > >>> > I’d be happy for the change controller to be something like "IETF >>> AVTCore Working Group delegated from the IETF”, but I think this should be >>> an AD question. ADs? >>> >> >> This is fine. >> >> >>> >>> >>> >>> >>> >> f) Is N_S an abbreviation for "Number of Spatial layers"? Might the >>> >> explanation in Section 4.2.1 be made clearer? >>> >> >>> >> Original: >>> >> N_S: N_S + 1 indicates the number of spatial layers present in the VP9 >>> >> stream. >>> >> >>> >> Perhaps: >>> >> N_S: Number of Spatial layers. N_S + 1 indicates the number of >>> >> spatial layers present in the VP9 stream. >>> > >>> > Let’s call it “Number of Spatial Layers Minus 1” to be clear? >>> >> >> why the "plus 1" is becoming "minus 1", is not clear to me. Jonathan, >> could you explain? >> >> //Zahed >> >> >> The semantic value is the number of spatial layers, the protocol element >> on the wire is one less than that (since it’s impossible to have zero >> spatial layers). >> >> So if N_S is the protocol element, >> >> N_S + 1 = number of spatial layers >> >> Or rearranging >> N_S = number of spatial layers minus 1. >> > > I see. It's fine with me. > > @rfc-editor. Are there any remaining issues with this document other than > the author's approval? > > //Zahed > > >> >> >> >>> We have updated the files to reflect Zahed's guidance for question 6. >>> >>> Please review the files carefully as we do not make changes after >>> publication. >>> >>> The files have been posted here (please refresh): >>> https://www.rfc-editor.org/authors/rfc9628.txt >>> https://www.rfc-editor.org/authors/rfc9628.pdf >>> https://www.rfc-editor.org/authors/rfc9628.html >>> https://www.rfc-editor.org/authors/rfc9628.xml >>> >>> The relevant diff files have been posted here (please refresh): >>> https://www.rfc-editor.org/authors/rfc9628-diff.html (comprehensive >>> diff) >>> https://www.rfc-editor.org/authors/rfc9628-auth48diff.html (AUTH48 >>> changes only) >>> https://www.rfc-editor.org/authors/rfc9628-lastdiff.html (last to >>> current version only) >>> >>> Please contact us with any further updates/questions/comments you may >>> have. >>> >>> We will await approvals from each of the parties listed on the AUTH48 >>> status page prior to moving forward to publication. >>> >>> The AUTH48 status page for this document is available here: >>> >>> https://www.rfc-editor.org/auth48/rfc9628 >>> >>> Thank you. >>> >>> RFC Editor/mf >>> >>> >>> >>> >>> >>> >>> > On Oct 7, 2024, at 9:36 AM, Zaheduzzaman Sarker < >>> zahed.sarker.i...@gmail.com> wrote: >>> > >>> > Hi, >>> > >>> > For question 6, I would prefer to pick alternative B, for both cases. >>> This option does make it clear without adding the extra "MUST" in the >>> sentence, I am expecting the defaults value is Zero here. >>> > >>> > //Zahed >>> > >>> > On Tue, Aug 13, 2024 at 6:28 AM <rfc-edi...@rfc-editor.org> wrote: >>> > Authors and *AD, >>> > >>> > [AD - please see question 6 below] >>> > >>> > While reviewing this document during AUTH48, please resolve (as >>> necessary) the following questions, which are also in the XML file. >>> > >>> > 1) <!--[rfced] Please note that we have updated the title of Section 2 >>> to >>> > more accurately describe its contents. Please let us know any >>> > objections.--> >>> > >>> > >>> > 2) <!--[rfced] Might replacing the slash in the following with "and", >>> > "or", or "and/or" be helpful to the reader? >>> > >>> > Original: >>> > ...for a particular resolution/quality,... >>> > --> >>> > >>> > >>> > 3) <!-- [rfced] FYI: We've updated the following sentence by adding "a" >>> > before "previously coded frame in time". Please let us know if >>> > this changes the intended meaning. >>> > >>> > Original: >>> > This "inter-layer" dependency can result in additional coding gain >>> > compared to the case where only traditional "inter-picture" >>> dependency is >>> > used, where a frame depends on previously coded frame in time. >>> > >>> > Updated: >>> > This "inter-layer" dependency can result in additional coding gain >>> > compared to the case where only traditional "inter-picture" >>> dependency is >>> > used, where a frame depends on a previously coded frame in time. >>> > --> >>> > >>> > >>> > 4) <!-- [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). >>> > --> >>> > >>> > >>> > 5) <!--[rfced] Should "the specifications" in this text be clarified >>> for >>> > the reader? >>> > >>> > Original: >>> > All integer fields in the specifications are encoded as unsigned >>> > integers in network octet order. >>> > --> >>> > >>> > >>> > 6) <!--[rfced] [*AD] In the following, we believe restructuring the >>> text >>> > may clarify the applicability of the BCP 14 keywords (are both >>> > parts of the sentence MUSTs?). Please review. >>> > >>> > Instance 1: >>> > >>> > Original: >>> > Marker bit (M): MUST be set to 1 for the final packet of the >>> highest >>> > spatial layer frame (the final packet of the picture), and 0 >>> > otherwise. >>> > >>> > Perhap A: >>> > Marker bit (M): This bit MUST be set to 1 for the final packet of >>> > the highest spatial-layer frame (the final packet of the picture); >>> > otherwise, it MUST be 0. >>> > >>> > Perhaps B: >>> > Marker bit (M): This bit MUST be set to 1 for the final packet of >>> > the highest spatial-layer frame (the final packet of the picture); >>> > otherwise, it is 0. >>> > >>> > Instance 2: >>> > >>> > Original: >>> > MUST be set to 1 for the final RTP packet of a >>> > VP9 frame, and 0 otherwise >>> > >>> > Perhaps A: >>> > This bit MUST be set to 1 for the final RTP packet of a VP9 frame; >>> > otherwise, it MUST be 0. >>> > >>> > Perhaps B: >>> > This bit MUST be set to 1 for the final RTP packet of a VP9 frame; >>> > otherwise, it is 0. >>> > --> >>> > >>> > >>> > 7) <!--[rfced] Section 4.2: It seems the descriptions following Figure >>> 3 >>> > apply to both Figures 2 and 3. If that is so, might a note of >>> this appear somewhere earlier in that section for the ease of the reader?--> >>> > >>> > >>> > 8) <!-- [rfced] FYI: We've removed quotes from around certain bit >>> names, >>> > e.g., ""D" bit" for consistency with similar uses in this >>> > document. Please let us know if this is not preferred. Please >>> > also see our cluster-wide question regarding bit names prior to >>> > reply. >>> > --> >>> > >>> > >>> > 9) <!--[rfced] Might a clarification of "This information" be helpful >>> to the reader? >>> > >>> > Original: >>> > >>> > Layer indices: This information is optional but RECOMMENDED >>> whenever >>> > encoding with layers. >>> > >>> > Perhaps: >>> > >>> > Layer indices: This field is optional but RECOMMENDED whenever >>> > encoding with layers. >>> > --> >>> > >>> > >>> > 10) <!--[rfced] If TID expands to "temporal layer ID", does this text >>> say >>> > "with TID equal to TID"? Please clarify (and see our related >>> cluster-wide question). >>> > >>> > Original: >>> > If this bit is set to 1 for the current picture with temporal layer ID >>> > equal to TID... >>> > >>> > --> >>> > >>> > >>> > 11) <!--[rfced] We note that not all fields that appear in Figure 4 are >>> > described following it. Please review and let us know if text >>> > (or a pointer to where the reader can get more information on >>> > these fields) should be added. >>> > >>> > --> >>> > >>> > >>> > 12) <!--[rfced] Section 5.1 is titled "Reference Picture Selection >>> > Indication (RPSI)". The first sentence of this section uses >>> > "reference picture selection index". Please review if "index" is >>> > correct or if it should be made "indication" (or vice versa).--> >>> > >>> > >>> > 13) <!--[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://xml2rfc.tools.ietf.org/xml2rfc-doc.html#name-aside-2). >>> > --> >>> > >>> > >>> > 14) <!-- [rfced] In the following sentences: >>> > >>> > a) does the receiver want to upgrade to {2,1}? How might we clarify >>> > "which"? >>> > >>> > b) please review the use of commas between the braced values. Is our >>> > suggestion correct? >>> > >>> > Original: >>> > LRR {1,0}, {2,1} is sent by an MCU when it is currently relaying >>> > {1,0} to a receiver and which wants to upgrade to {2,1}. In >>> > response the encoder should encode the next frames in layers {1,1} >>> > and {2,1} by only referring to frames in {1,0}, or {0,0}. >>> > >>> > >>> > Perhaps: >>> > LRR {1,0} {2,1} is sent by an MCU when it is currently relaying >>> > {1,0} to a receiver that wants to upgrade to {2,1}. In response, >>> > the encoder should encode the next frames in layers {1,1} and {2,1} >>> > by only referring to frames in {1,0} or {0,0}. >>> > >>> > --> >>> > >>> > >>> > 15) <!--[rfced] In the following, please review the use of "value" >>> > (singular) and "receivers" (not possessive?). >>> > >>> > Original: >>> > ...where a media sender does not have media available that fits within >>> > a receivers max-fs and max-fr value;... >>> > >>> > Perhaps: >>> > ...where a media sender does not have media available that fits within >>> > a receiver's max-fs and max-fr values;... >>> > >>> > --> >>> > >>> > >>> > 16) <!--[rfced] Might adding "each" to the following text be helpful >>> for >>> > the reader? Or is the intention that the width and height be >>> > taken together? (Same question for the last sentence of this >>> > paragraph.) >>> > >>> > Original: >>> > The decoder is capable of decoding this frame size as long as the >>> > width and height of the frame in macroblocks are less than >>> > int(sqrt(max-fs * 8)) - 8))... >>> > >>> > Perhaps: >>> > The decoder is capable of decoding this frame size as long as the >>> > width and height of the frame in macroblocks are each less than >>> > int(sqrt(max-fs * 8)) - 8))... >>> > >>> > --> >>> > >>> > >>> > 17) <!--[rfced] Please note that we have shortened the title of Table 2 >>> > and rephrased to avoid awkward hyphenation. Please review and >>> > let us know any objections. >>> > >>> > Original: >>> > Table of profile-id integer values representing the VP( profile >>> > corresponding to the set of coding tools supported Current: profile-id >>> > to VP9 Profile Integer Comparison >>> > >>> > Current: >>> > Comparison of profile-id to VP9 Profile Integer >>> > --> >>> > >>> > >>> > 18) <!--[rfced] Please note that after AUTH48 concludes, we will >>> > communicate any changes to the media type template in Section 7 >>> > to IANA for corresponding updates to >>> > https://www.iana.org/assignments/media-types/video/VP9 to be >>> > made.--> >>> > >>> > >>> > 19) <!--[rfced] Please review the entry for "Change Controller" in >>> Section >>> > 7. While we see similar text for the vp8 and vc2 entries, we >>> want to >>> > confirm that this entry has been reviewed with the following in >>> > mind from >>> > https://www.iana.org/help/protocol-registration: >>> > >>> > "The IESG shouldn't be listed as a change controller unless the >>> > RFC that created the registry (e.g. port numbers, XML namespaces >>> > and schemas) requires it. The IETF should be named instead." >>> > >>> > --> >>> > >>> > >>> > 20) <!--[rfced] Should any further information on the IANA >>> Considerations >>> > for the "RTP Payload Format Media Types" registry be given? >>> > >>> > Perhaps: >>> > The media type has also been added to the "RTP Payload Format Media >>> > Types" subregistry of th e"Real-Time Transport Protocol (RTP) >>> > Parameters" registry as follows: >>> > >>> > Media Type: video >>> > Subtype: VP9 >>> > Clock Rate (Hz): 90000 >>> > Reference: RFC 9628 >>> > --> >>> > >>> > >>> > 21) <!-- [rfced] Terminology and abbreviations: We had the following >>> > questions related to terminology or abbreviation use throughout >>> > the document. >>> > >>> > a) The following terms had different forms throughout this >>> > document. Please let us know if/how these may be made uniform. >>> > >>> > reference indices vs. Reference Indices >>> > >>> > b) We have updated these terms to be the form on the right to match >>> > use in the companion documents and/or be consistent within this >>> > document. >>> > >>> > key frame vs. keyframe >>> > "max-fs" vs. max-fs >>> > "max-fr" vs. max-fr >>> > "profile-id" vs. profile-id >>> > >>> > c) How may we expand "SRGB"? Segment Routing Global Block? If so, >>> > would you like to add as a note to the table? Or is this something >>> > that could be housed in the Terminology section? >>> > >>> > d) Is SID expanded to spatial-layer ID? It seems so here: >>> > >>> > Original: >>> > ...temporal-layer ID (TID) and spatial layer ID (SID)... >>> > >>> > If SID is spatial-layer ID (please also see our cluster-wide question >>> > regarding this abbreviation as well as our related question about TID >>> > before responding), please review the following text as it seems to >>> > state the SID is equal to SID: >>> > >>> > Original: >>> > Within a picture, a frame with spatial layer ID equal to SID... >>> > >>> > >>> > >>> > e) We note that TL0PICIDX is expanded in RFC-to-be 9626 as "Temporal >>> > Layer 0 Picture Index". Please let us know if/how we may update the >>> > following to make this document consistent within the cluster. >>> > >>> > Original: >>> > TL0PICIDX: 8 bits temporal-layer zero index. >>> > >>> > and >>> > >>> > ...is used to represent temporal layer 0 index (TL0PICIDX)... >>> > >>> > Further, may we update to either "8-bit" or rephrase to put this >>> > information in parentheses (as was done in RFC 9626)? >>> > >>> > f) Is N_S an abbreviation for "Number of Spatial layers"? Might the >>> > explanation in Section 4.2.1 be made clearer? >>> > >>> > Original: >>> > N_S: N_S + 1 indicates the number of spatial layers present in the VP9 >>> > stream. >>> > >>> > Perhaps: >>> > N_S: Number of Spatial layers. N_S + 1 indicates the number of >>> > spatial layers present in the VP9 stream. >>> > >>> > g) Please note that we have expanded these abbreviations as follows. >>> > Please let us know any objections. >>> > >>> > MCU - Multipoint Control Unit (per RFC 5104) >>> > >>> > --> >>> > >>> > >>> > 22) <!-- [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. >>> > >>> > We see the use of "native" but note that it is a quote from RFC 4585. >>> > >>> > In addition, please consider whether "tradition" and "traditionally" >>> > should be updated for clarity. While the NIST website >>> > < >>> https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1 >>> > >>> > indicates that this term is potentially biased, it is also ambiguous. >>> > "Tradition" is a subjective term, as it is not the same for everyone. >>> > --> >>> > >>> > >>> > Thank you. >>> > >>> > RFC Editor/mf >>> > >>> > *****IMPORTANT***** >>> > >>> > Updated 2024/08/12 >>> > >>> > RFC Author(s): >>> > -------------- >>> > >>> > Instructions for Completing AUTH48 >>> > >>> > Your document has now entered AUTH48. Once it has been reviewed and >>> > approved by you and all coauthors, it will be published as an RFC. >>> > If an author is no longer available, there are several remedies >>> > available as listed in the FAQ (https://www.rfc-editor.org/faq/). >>> > >>> > You and you coauthors are responsible for engaging other parties >>> > (e.g., Contributors or Working Group) as necessary before providing >>> > your approval. >>> > >>> > Planning your review >>> > --------------------- >>> > >>> > Please review the following aspects of your document: >>> > >>> > * RFC Editor questions >>> > >>> > Please review and resolve any questions raised by the RFC Editor >>> > that have been included in the XML file as comments marked as >>> > follows: >>> > >>> > <!-- [rfced] ... --> >>> > >>> > These questions will also be sent in a subsequent email. >>> > >>> > * Changes submitted by coauthors >>> > >>> > Please ensure that you review any changes submitted by your >>> > coauthors. We assume that if you do not speak up that you >>> > agree to changes submitted by your coauthors. >>> > >>> > * Content >>> > >>> > Please review the full content of the document, as this cannot >>> > change once the RFC is published. Please pay particular attention >>> to: >>> > - IANA considerations updates (if applicable) >>> > - contact information >>> > - references >>> > >>> > * Copyright notices and legends >>> > >>> > Please review the copyright notice and legends as defined in >>> > RFC 5378 and the Trust Legal Provisions >>> > (TLP – https://trustee.ietf.org/license-info/). >>> > >>> > * Semantic markup >>> > >>> > Please review the markup in the XML file to ensure that elements >>> of >>> > content are correctly tagged. For example, ensure that >>> <sourcecode> >>> > and <artwork> are set correctly. See details at >>> > <https://authors.ietf.org/rfcxml-vocabulary>. >>> > >>> > * Formatted output >>> > >>> > Please review the PDF, HTML, and TXT files to ensure that the >>> > formatted output, as generated from the markup in the XML file, is >>> > reasonable. Please note that the TXT will have formatting >>> > limitations compared to the PDF and HTML. >>> > >>> > >>> > Submitting changes >>> > ------------------ >>> > >>> > To submit changes, please reply to this email using ‘REPLY ALL’ as all >>> > the parties CCed on this message need to see your changes. The parties >>> > include: >>> > >>> > * your coauthors >>> > >>> > * rfc-edi...@rfc-editor.org (the RPC team) >>> > >>> > * other document participants, depending on the stream (e.g., >>> > IETF Stream participants are your working group chairs, the >>> > responsible ADs, and the document shepherd). >>> > >>> > * auth48archive@rfc-editor.org, which is a new archival mailing >>> list >>> > to preserve AUTH48 conversations; it is not an active discussion >>> > list: >>> > >>> > * More info: >>> > >>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc >>> > >>> > * The archive itself: >>> > https://mailarchive.ietf.org/arch/browse/auth48archive/ >>> > >>> > * Note: If only absolutely necessary, you may temporarily opt >>> out >>> > of the archiving of messages (e.g., to discuss a sensitive >>> matter). >>> > If needed, please add a note at the top of the message that >>> you >>> > have dropped the address. When the discussion is concluded, >>> > auth48archive@rfc-editor.org will be re-added to the CC list >>> and >>> > its addition will be noted at the top of the message. >>> > >>> > You may submit your changes in one of two ways: >>> > >>> > An update to the provided XML file >>> > — OR — >>> > An explicit list of changes in this format >>> > >>> > Section # (or indicate Global) >>> > >>> > OLD: >>> > old text >>> > >>> > NEW: >>> > new text >>> > >>> > You do not need to reply with both an updated XML file and an explicit >>> > list of changes, as either form is sufficient. >>> > >>> > We will ask a stream manager to review and approve any changes that >>> seem >>> > beyond editorial in nature, e.g., addition of new text, deletion of >>> text, >>> > and technical changes. Information about stream managers can be found >>> in >>> > the FAQ. Editorial changes do not require approval from a stream >>> manager. >>> > >>> > >>> > Approving for publication >>> > -------------------------- >>> > >>> > To approve your RFC for publication, please reply to this email stating >>> > that you approve this RFC for publication. Please use ‘REPLY ALL’, >>> > as all the parties CCed on this message need to see your approval. >>> > >>> > >>> > Files >>> > ----- >>> > >>> > The files are available here: >>> > https://www.rfc-editor.org/authors/rfc9628.xml >>> > https://www.rfc-editor.org/authors/rfc9628.html >>> > https://www.rfc-editor.org/authors/rfc9628.pdf >>> > https://www.rfc-editor.org/authors/rfc9628.txt >>> > >>> > Diff file of the text: >>> > https://www.rfc-editor.org/authors/rfc9628-diff.html >>> > https://www.rfc-editor.org/authors/rfc9628-rfcdiff.html (side by >>> side) >>> > >>> > Diff of the XML: >>> > https://www.rfc-editor.org/authors/rfc9628-xmldiff1.html >>> > >>> > The following files are provided to facilitate creation of your own >>> > diff files of the XML. >>> > >>> > Initial XMLv3 created using XMLv2 as input: >>> > https://www.rfc-editor.org/authors/rfc9628.original.v2v3.xml >>> > >>> > XMLv3 file that is a best effort to capture v3-related format updates >>> > only: >>> > https://www.rfc-editor.org/authors/rfc9628.form.xml >>> > >>> > >>> > Tracking progress >>> > ----------------- >>> > >>> > The details of the AUTH48 status of your document are here: >>> > https://www.rfc-editor.org/auth48/rfc9628 >>> > >>> > Please let us know if you have any questions. >>> > >>> > Thank you for your cooperation, >>> > >>> > RFC Editor >>> > >>> > -------------------------------------- >>> > RFC9628 (draft-ietf-payload-vp9-16) >>> > >>> > Title : RTP Payload Format for VP9 Video >>> > Author(s) : J. Uberti, S. Holmer, M. Flodman, D. Hong, J. Lennox >>> > WG Chair(s) : Dr. Bernard D. Aboba, Jonathan Lennox >>> > Area Director(s) : Zaheduzzaman Sarker, Francesca Palombini >>> > >>> > >>> >>> >>> >>> >>> >>> >>
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
