Authors, Just a friendly reminder that this document awaits author action.
Please see the AUTH48 status page at http://www.rfc-editor.org/auth48/rfc9628. Thank you. RFC Editor/mf > On Nov 4, 2024, at 3:54 PM, Megan Ferguson <mfergu...@amsl.com> wrote: > > Authors, > > Please see mail below regarding this document as well as our cluster-wide > email with questions relating to all three related documents. > > This document set has been in AUTH48 since mid-August. Please let us know if > there is anything we can do to facilitate moving the AUTH48 review forward. > > Thank you. > > RFC Editor/mf > >> On Oct 21, 2024, at 9:58 AM, Megan Ferguson <mfergu...@amsl.com> wrote: >> >> Authors, >> >> Just a ping that this reply from Zahed requires author action. Please also >> see our email regarding queries affecting the cluster of documents as a >> whole (originally sent 8/12/24) >> >> We will await your responses prior to moving this document (and its >> companions) forward in the publication process. >> >> Please see the AUTH48 status of this document at >> https://www.rfc-editor.org/auth48/rfc9628. >> >> Please see further cluster information at >> https://www.rfc-editor.org/cluster_info.php?cid=C324. >> >> We look forward to hearing from you at your earliest convenience. >> >> Thank you. >> >> RFC Editor/mf >> >> >>> On Oct 10, 2024, at 4: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. >>> >>> >>> >>> >>> >>>>> 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? >>> >>> >>> >>> >>>>> >>>>> 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 >>> >>> >>> >>> >>> >>> 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
