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
