Hi, This change is complete:
https://www.iana.org/assignments/media-types/video/VP9 We'll update the reference to the document once it's been published. thanks, Amanda Baber IANA Operations Manager On Thu Mar 13 19:26:02 2025, mfergu...@staff.rfc-editor.org wrote: > IANA, > > Please update https://www.iana.org/assignments/media-types/video/VP9 > to match Section 7 of this document. > > We have included the text and diff files below for your convenience: > > https://www.rfc-editor.org/authors/rfc9628.txt > https://www.rfc-editor.org/authors/rfc9628-diff.html > > Please let us know when these updates are complete and/or if you have > any questions or concerns about the updates themselves. > > Thank you. > > RFC Editor/mf > > > > On Mar 13, 2025, at 12:18 PM, Justin Uberti <jus...@uberti.name> > > wrote: > > > > I see the address has been updated. I approve the publication of this > > document. > > > > Justin > > > > On Fri, Mar 7, 2025 at 11:55 AM Jonathan Lennox > > <jonathan.len...@8x8.com> wrote: > > For this draft as well, I approve once the issue of Justin’s postal > > address is resolved. > > > > > On Mar 4, 2025, at 2:11 PM, Megan Ferguson <mfergu...@staff.rfc- > > > editor.org> wrote: > > > > > > Authors (and *AD), > > > > > > Just checking in to see if you’ve had a chance to review the files > > > posted and/or *AD queries in the emails below? > > > > > > Please let us know if any further changes are necessary or if you’d > > > like to approve the current version. > > > > > > We are awaiting approvals from authors and *AD guidance/approval: > > > once those are received, we will send any necessary updates to IANA > > > registries to align them with the document. After the registry > > > update(s) are confirmed, this document will be ready to move > > > forward in the publication process with its cluster. > > > > > > The AUTH48 status page for this document is available here: > > > > > > https://www.rfc-editor.org/auth48/rfc9628 > > > > > > Please see the AUTH48 status page for all documents in the cluster > > > here: > > > > > > https://www.rfc-editor.org/auth48/C324 > > > > > > Thank you. > > > > > > RFC Editor/mf > > > > > >> On Feb 21, 2025, at 3:10 PM, Megan Ferguson <mfergu...@staff.rfc- > > >> editor.org> wrote: > > >> > > >> Just an update to add the following change to the AD review list: > > >> > > >>> In the definition of Picture ID, in section 4.2, in the phrase > > >>> "if the field transitions from 15 bits to 7 bits, it is truncated > > >>> (i.e., the value after 0x1bbe is 0xbf)” the value “0xbf” should > > >>> be replaced by “0x3f”. (0xbf is not a 7-bit value.) > > >> > > >> Thank you. > > >> > > >> RFC Editor/mf > > >> > > >> > > >>> On Feb 21, 2025, at 3:08 PM, Megan Ferguson <mfergu...@staff.rfc- > > >>> editor.org> wrote: > > >>> > > >>> Hi Jonathan, Justin, and *AD, > > >>> > > >>> Thanks for your reply. > > >>> > > >>> We have updated to use Mo’s proposed text as related to question > > >>> 10 (the text sent to the WG). We will await *AD > > >>> review/confirmation that we are okay to go forward with this > > >>> text: > > >>> > > >>> Current: > > >>> U: Switching up point. When this bit is set to one, 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 > > >>> decode order) with a temporal-layer ID value greater than > > >>> T. > > >>> > > >>> We are hoping to hear from Justin as to how to edit the postal > > >>> address (affiliation has been updated as requested). > > >>> > > >>> 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) > > >>> https://www.rfc-editor.org/authors/rfc9628-lastrfcdiff.html > > >>> (ditto but side by side) > > >>> > > >>> 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 Feb 21, 2025, at 1:53 PM, Jonathan Lennox > > >>>> <jonathan.len...@8x8.com> wrote: > > >>>> > > >>>> I also notice that Justin’s affiliation was updated for 9627, > > >>>> but not for 9628. > > >>>> > > >>>>> On Feb 21, 2025, at 3:51 PM, Jonathan Lennox > > >>>>> <jonathan.len...@8x8.com> wrote: > > >>>>> > > >>>>> > > >>>>> > > >>>>>> On Feb 20, 2025, at 2:21 PM, Megan Ferguson > > >>>>>> <mfergu...@staff.rfc-editor.org> wrote: > > >>>>>> > > >>>>>> All, > > >>>>>> > > >>>>>> Thank you for your replies. We have updated according to the > > >>>>>> responses we have received thus far to the document—specific > > >>>>>> and cluster-wide queries. > > >>>>>> > > >>>>>> We had the following questions/comments to (hopefully) finish > > >>>>>> the list of queries out: > > >>>>>> > > >>>>>> 1) Related to the cluster-wide bit name question: we suggest > > >>>>>> making no changes to this document as we were able to glean > > >>>>>> these names from the existing in-document descriptions (and no > > >>>>>> pattern seems to be changing in RFC 9626 to use “the X (name) > > >>>>>> bit” format). > > >>>>> > > >>>>> Good. > > >>>>> > > >>>>>> > > >>>>>> 2) Jonathan - please review the suggested text that uses > > >>>>>> “module” where the document used “modulo”. We will await your > > >>>>>> reply prior to closing this out. > > >>>>>> > > >>>>>>> Same item next paragraph, I realized the wording as written > > >>>>>>> technically contradicts the first paragraph. The last > > >>>>>>> sentence should read “Every picture containing a frame with > > >>>>>>> show_frame==1, however, MUST have a unique timestamp module > > >>>>>>> the 2^32 wrap of the field.” I.e., add “picture containing a” > > >>>>>>> after “Every”. > > >>>>> > > >>>>> Thanks for catching that, yes, that was an autocorrect error. > > >>>>> It should indeed be “modulo”. > > >>>>> > > >>>>> > > >>>>>> 3) Just a reminder that this document has a question out to > > >>>>>> the WG and that IANA updates to match the changes in the Media > > >>>>>> Type Registration in Section 7 will be requested once all > > >>>>>> author approvals are received (as possible delays to moving > > >>>>>> forward in the publication process). > > >>>>> > > >>>>> Mo had a response to the WG mail about that language — I agree > > >>>>> with him, the parenthetical phrase would be better as “(in > > >>>>> decoding order)” to match other usages. > > >>>>> > > >>>>> > > >>>>> I also have two more changes for this document: > > >>>>> > > >>>>> In the definition of Picture ID, in section 4.2, in the phrase > > >>>>> "if the field transitions from 15 bits to 7 bits, it is > > >>>>> truncated (i.e., the value after 0x1bbe is 0xbf)” the value > > >>>>> “0xbf” should be replaced by “0x3f”. (0xbf is not a 7-bit > > >>>>> value.) > > >>>>> > > >>>>> The title of section 4.5 should be “Example of a VP9 RTP > > >>>>> Stream”, because there is only one example. > > >>>>> > > >>>>> Thank you! > > >>>> > > >>> > > >> > > > > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
